12

If the product is at the MVP stage and your QA is just getting started, there's a problem. As a BA I saw this time and time again with dev vs QA where the dev team only got the BA to do testing when they felt the product was "ready to deliver to QA" which is a notion all developers should aim to dispel. Most developers went to university and took some ...


9

Are you aware that “Most of the bugs in software are due to incomplete or inaccurate functional requirements?” What would be the best use of QA engineer's time while the project is in an early stage? Test the requirements itself, not the product... by asking the right questions to uncover & challenge implicit assumptions in the requirements....


6

Although all observations are valid, from a project point of view, I am missing the motivational and learning point of view. Starting some automation now can also be part of the learning of that engineer, and the team. He will be motivated as he can do something he wants to do. Yes, the product will change. But he can also grow along with the development of ...


5

The nice thing of TypeScript you do not have to migrate at once. TypeScript is a superset and can parse plain JavaScript as well. You can keep your old code and start using TypeScript for new code or just some features. Read this story about gradually switching at Slack: One of the reasons why the Slack team chose TypeScript is its being a superset of ...


5

Of course a passing unit test does not guarantee a functioning system. A buggy unit test could produce a false negative. The system could also use the component in a way the unit test does not, e.g. in a way the component author did not anticipate, or in a way the unit test author did not anticipate. You can also think about this in terms of the ...


4

I agree that it may be too early for much automation. But there is still a lot QA can bring to the project to help it be successful at this stage. If it were me on the project, along with learning everything I could about the requirements, I would be looking at what the customer(s) really do & what their workflow is, what our competitors might offer ...


4

NO. I would not suggest doing so until you have a specific objective to be met by doing it. In my opinion, its only worth the effort if you are working on large development project but for comparatively smaller UI automation projects with less than 1K tests, I would not suggest so. Also, there are a lot of misconceptions about the advantages of moving ...


3

It sounds like you're on the right lines already but, in addition to going through the requirements and getting familiarised with the roadmap, it's definitely worth getting him to exploratory test the MVP and get a feel of the product as early as possible. Also, static testing the requirement document would be beneficial as it allows for early feedback and ...


3

I want to explore two areas: Scope and terminology. There are systems at (at least) two different scopes here: The end-to-end system and the unit, which is also a system. When I'm analyzing a "defect," I like to think in terms of three parts: Failure, fault, and conditions. The failure is the system's production of incorrect results. The fault is the ...


3

Every fix should be analyzed separately. You need to ask yourself How can I verify that this bug has actually been fixed? How can I verify that this fix hasn't introduced new issues or side-effects? What other tests does this fix suggest I should perform? Sometimes, a very isolated bug requires only an isolated test for verification. And sometimes a fix ...


3

note: I assume you are CTO or similar role or the "boss" for QA stuff In order to clarify my "idea" of QA during project/product development, I've write down following workflow as example: requirements: formalize them, update them, take track on every release, as use case or user story. define tests: define how user story are tested, with edge cases should ...


2

If the amount of load is not important and you only want to know which elements in your webpage are consuming more time (from a single client perspective) you could take a look at YSlow. It also gives you recommendations on how to improve your load time. In case you need to check this within stress conditions, Silk Performer's TrueLog includes very similar ...


2

We need end-to-end testing because our assumptions about how components interact are never completely accurate. You might also ask why we need to test A->B if we're testing A->B->...->Z. Testing A->B by themselves helps with diagnosis because we can narrow down any bugs to A, B, and interactions between A and B.


2

> Should I re-test fix at system level when the issue is at unit level? The unittest only garantees that one possible root cause was fixed but it does not garantee that this was the only reason for failiure. Therefore I would repeat the system-level test.


2

You can use css: td button.remove or xpath: //td/button[@class='remove'] If you have multiple filters you should add constraint for that section like: .wood td button.remove


2

No, Create a single E2E test without seed accounts and test individual features in integration tests using seed accounts. In this scenario, I would create a single E2E test covering primary user flow( how end user typically will use the application 80-90% of the time in production).In this, I will not use any mocking/ DB insertions for test data creation(...


2

Assumption: I believe we are just talking here on e2e testing of React using protractor. Generalized JavaScript Framework agnostic to any Frontend frameworks IMHO, in such cases we should strive to generalize the framework on JavaScript level taking advantage of latest ESx features(like async/await for promise resolution) .The framework should be agnostic ...


2

I think it's a good time to ask questions about how you're defining quality for the app (ie, how quick it needs to be, how accessible it needs to be, supported browsers) I've also found that test automation can take a little time to get up and running. There's lots of drivers to be installed and/or docker/virtual machine type containers to get up and running,...


2

Test cases don't need to complete an entire workflow at one time. This often makes them flakier and may limit the granular visibility of what works and what doesn't when they fail. The first thing that comes to mind is you should have available data and tools in your testing environment that allows you to break up that workflow into smaller pieces. As one ...


2

So, in above scenario, each part (Given, When, And, or Then) are seperate testcases. But still the order of testcase is crucial. They should not be separate tests. This might be a constraint you or someone else has put into the system (hopefully not a technical constraint) but you should question the value. How often do your users log-in and then not do ...


2

Cypress stub() and spy() are adopted from Sinon.js spies and stubs. Based on Sinon documentation: When to use stubs? Use a stub when you want to: Control a method’s behavior from a test to force the code down a specific path. Examples >include forcing a method to throw an error in order to test error handling. When you want to prevent a ...


2

E2E testing should be testing without stubbing and then having another layer for testing in isolation where stubbing will be more valuable. For the isolation testing, there may be some instances in which an application sends XHR on page load, so stubbing those requests would be beneficial for execution time.


1

What you are looking for is Contract Testing. It asks "Do I provide the responses that components that depend on me expect?" Situation: You have two web apps that fetch data from one service. The three have unit/component tests with proper mocking. The web apps tests may log the mocked responses for each request. If they provide this log to the service, ...


1

You've correctly spotted the problematic use of dynamic ids, that makes it hard(er) to write and maintain tests with Selenium. I'm not entirely sure, but it should be possible for the developers to add (unique) names to each widget, making stuff easier to find. Regarding your question, 'what are the tools', I suggest you take a look at Sencha's own testing ...


1

I have to admit, I'm a bit unclear on what you're trying to do. However, if you need to take a series of steps and see the result of those interactions, I would look at tools like Fitnesse or Specflow. My gut feel is that Fitnesse is closer to what you want to accomplish though.


1

I believe your question is one I have asked and solved in a few organizations. Many organizations have multi-part form workflows to gather information. This leads to UI testing which is slow because to test anything on page J you always have to go to A,B,C,D,E,F,G,H,I to get to it. Every. Single. Time. This leads to horrendously slow UI tests. Also, as ...


1

A possible solution to avoid lengthy or expensive end to end tests is to use contract testing. This is where you test the contracts between the various parts of your system to gain more confidence about how they will integrate. Once you have a reasonable level of confidence you can then run the more expensive tests with less chance of reruns. Pact is well ...


1

Yeah what you're describing for testcase setup is definitely blowing up the duration and size of your tests. I understand why this could cause you some speed and stability issues. You're going down the right path thinking about seed data but I would also suggest thinking about how you get the data into the application under test in a way that is quick and ...


1

It is happening because JavaScript is asynchronous and it may not execute statements in sequence as you might be expecting.I would rewrite as below using async/await: it('LOGIN - Submit-Button "Login" must be enable after entering UserName and Password', async() => { await page.getInputFields().userNameInput.sendKeys('Qw12'); await page....


1

For End-to-End testing, no, it's not great, but you may not have other options. If that's the case, as the test team, you need to make sure that the powers that be are aware of the risk that's being taken by mocking versus true end-to-end testing. They also need to realize that the mocking isn't free; you're going to have to maintain and update the mocking ...


Only top voted, non community-wiki answers of a minimum length are eligible