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 ...
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....
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 ...
One of the reasons why the Slack team chose TypeScript is its being a
superset of ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 ...
How to store code in a repository has many factors.
How many people are working on this project?
Who is responsible for testing (devs only, devs and qa)?
What testing methods are in use: unit tests, integration tests, UI tests?
Is there a difference between end-to-end and full stack testing?
Are you the only one working on this project and are responsible ...
Depends on the goal of the test.
I like to differentiate test goals, for example between:
Pure Functional, Tests which check if the functionality works in general. This should work on a stable pipeline, simple and fast for quick feedback loops.
Browser/OS/Device compatibility, tests to garantuee it works on multiple different devices.
Now you need to ...
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 ...
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.
> 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.
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(...
Assumption: I believe we are just talking here on e2e testing of React using protractor.
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,...
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 ...
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 ...
Cypress stub() and spy() are adopted from Sinon.js spies and stubs. Based on Sinon
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 ...
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.
It depends on the context.
If your users are using different browsers and operating systems, or desktop/mobile versions of your app, or different versions of browsers, then it is a good idea to test on multiple build agents.
Discover the actual/prospect usage matrix to drive testing based on risk:(Sample Matrix)
Testing is purely risk driven activity. I would suggest to find out the production usage base matrix (OS/Browser/devices wise) to find out the actual risk to drive the test efforts accordingly.
It only makes sense to test on wider combinations of configurations if the ...
What you are looking for is Contract Testing.
It asks "Do I provide the responses that components that depend on me expect?"
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, ...
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 ...
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.
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 ...