Here are few tit-bits that most of us as QA’s know, but at times we take them for granted and forget to practice them.
1. Analyzing the requirements beforehand :
Analyzing the requirements by a full fledged QA team should be a mandatory practice inherited by companies globally, reason being requirements freezed need not always make sense in terms of implementation while considering the business perspective. For example we should be able to raise a flag, well in advance, to the client that apprehending the requirements would enhance the usability. Nevertheless, this doesn’t mean we would not cater the business requirements. We will instead enhance or suggest a substitute, in simpler terms suggest a better way in implementing their requirements. This would mean, that the QA team should be well versed with the current trends in the markets as well as have strong domain knowledge.
2. Maximize the Test coverage to the fullest:
After the requirements have been finalized, the QA team should be in a position to visualize the application being implemented. If sadly we are not able to do this, there is a need to go back to the first step and get our doubts cleared. While sketching the scenarios one must be careful of covering the entire application leaving no bit untouched, however, we should at the same time be careful about duplicity. A simple practice which I personally have always followed for better test coverage is to first segregate the application flow into two parts:
- Positive flow to terminate the application.
- Negative flow to terminate the application
The above two categories can again be segregated into smaller parts further, depending on the application modules if any or based on the page navigations. One must also not forget to cater the chain reactions when the negative flow is considered. This phase might require the QA team to spend more time, however things will certainly fall in their place if we are able to sketch the scenarios. Changes to the requirements if needed can be handled in this stage reducing the cost which would have incurred if the requirements were to be changed after the implementation.
3. Allowing the developers access our scenarios:
Yes, we have put in the efforts in sketching them and most of my fellow QA’s would not support me on this. But we as testers shouldn’t forget that we are responsible for final quality of the product delivered, then why not support the team from the initial stages and help reduce the re work time. Remember, logging multiple defects should never be our motto, instead, logging quality and critical defects should be our tag line.
4. Precise Test case preparation buckled with rigorous review is a must:
Test case preparation is always observed to be the most critical stage of any project. It basically reflects the derivable under test. Test cases should always be detailed with each step elaborated. The test case should include each navigation step. The next most important practice every tester must follow is to map each test case to the correct requirements. After successfully mapping the requirements to the test cases, one should follow the naming convention decided unanimously by the entire team. The main reason to follow this is to maintain uniformity and avoid duplicity. Test cases must also include test data where ever mandatory details are required i.e. data like login details or mandatory field so as to fulfill the scenario under test.
The next step is to adhere to a fixed review process. This can be achieved either by regular review meetings with the entire testing team or one can also opt peer review as a practice. This isn’t a process to find faults in test cases written by peers, but to cross check on the test case coverage. Any deletion, addition or modification needed should be made with the consent of the test case owner. This will also help the entire team have an overview on all the test cases written by the team.
5. Accurate defect management mechanism in place:
Defect management is not only about raising quality defects. One must always remember defects can be as low priority as incorrect font size. Never should we as tester under estimate any defect. Then comes the next step of logging the defects. Defects raised must always be carefully linked to appropriate test cases. They must contain the steps that were followed during the execution, so that they can be reproduced. Each step must be captured as screenshots and attached to the defect. These raised defect must be visible to all the testers to avoid duplicity.
The next step is to set up a mechanism, to decide the defect priority. Incorrect prioritization of defects may lead to major failure of the project.
It’s always a good practice to analysis the defects raised, simply because they help us in taking preventive regression measures.
Hope these were helpful, please feel free to add your insights in the comments section below