Practice a quality defect description and work planning
Competent bug tracking and test management add to the overall value of the software testing process by improving the individual skills of each tester, timely overcoming difficulties that can slow down the testing process, and building interaction between development and testing teams.
Describe the software testing process appropriate for your team
To ensure effective testing as a type of software quality assurance, it is important to create a pre-established process. It should be debugged and approved by experts who know how business processes in the company go so that sudden difficulties do not affect the testing process. Despite the fact that unconditional adherence to the established process is not necessary, it may be useful in the early stages of testing. The description can be enhanced by adding preconditions for performing product tests.
Tune in to the irremissible bug detection
For testing to be effective, the tester must tune in to a positive result - i.e. the presence of at least a few bugs - before starting work. This will inspire him to carefully search for defects and use the ability to correctly describe them in practice. Believe that the application has a bunch of different bugs and errors, and at the end of testing you will definitely find them all.
Build a proper testing environment
Make sure that the environment in which the product is tested adequately reflects the environment in which it goes into mass use - the duty of the testing team. This is necessary to ensure that no bugs were missed due to problems in organizing the testing process.
Delve into the core of issues
To make changes and improvements to the test plan, based on the bugs found by customers, the tester must constantly delve into their details. The tester’s reputation depends on this: he has to try to demonstrate the presence/absence of the stated problem. There is one more reason why experienced testers themselves often study projects for bugs: by doing this, you can better understand the structure of the product, understand who its potential user is, how and why it will use the product, what problem it should solve and how the product should look and work, which in the end will help to test it in more detail and with high quality.
Now let's talk a little about strategy.
There are not many test automation strategies. The pyramid proposed by Mike Cohn can help teams find the best approach to test automation.
The most straightforward approach to test automation that you can come up with is simply to take test cases created for manual testing and automate them at the user interface (GUI) level using tools like Selenium. At the same time, this is the least effective approach. Automated tests at the UI level are slow, vulnerable to any changes, and difficult to maintain.
Mike Cohn's pyramid of automation perfectly illustrates a more efficient approach. The width of each level of the pyramid shows how many tests should be at each level compared to others.
At the lower level of the pyramid are a component, or unit tests. They should make up most of your tests. For example, to test a class that calculates interest on the amount, a unit test is created that passes the interest rate x and balance y. Expected result: the correct calculation of the amount of interest with the desired accuracy.
The middle level is occupied by tests that verify business behavior (but not through the GUI!). Such tests are sometimes called API tests. If you use the behavior-driven development (BDD) methodology, your automated tests will be at that level. You may need a fairly large number of tests at this level, but still, there should be fewer than unit tests. Such tests can affect several components at the same time and test the behavior of the product from a business point of view. Example: after calculating the interest on the deposit, the required amount is added to the balance.
The top level of the pyramid is automatic tests that directly affect the user interface. They should be much smaller than the rest. An example of such a test: after calculating the interest, the correct, new amount is displayed in the bank statement.
And, “cherry on a cake” - manual tests. Some types of testing cannot be automated, for example, research testing or usability testing, but ideally, you should try to minimize the number of manual tests.
Some more important principles related to the pyramid of automation:
Avoid duplicating tests at different levels.
It makes no sense to repeat the same tests at different levels. For example, if the boundary values were checked at the unit test level, do not repeat them at the GUI level - this way we are unlikely to get new information.
In general, where possible, you should
strive to shift the tests to a lower level.
Suppose checking the calculation of percentages from a negative amount is probably possible at the “average level” or even at the unit test level, so why do this at the user interface level? Automating tests at a lower level is more efficient, it allows earlier to detect defects, saves time and money.