“To err is human” – Alexander Pope.
Everyone makes mistakes, but you cannot ignore all mistakes. Some of them can prove to be very expensive.
During testing of an application/product, a tester makes sure that mistakes done by developers are discovered and fixed before the product reaches the end user. The primary objective of testing is to deliver a quality product to the end user, which fulfils the customer’s need and expectation in most efficient manner. The requirements and expectations will always vary from one application to another, from one customer to the other, but there are certain practices to assure and retain product’s quality and, surely, they will bring fruitful results to your testing efforts.
Product Knowledge: It’s crucial to have a thorough knowledge of the product before testing starts. You cannot test an application until and unless you have an understanding of the product and how it will be used. If the product is to be developed then go through the requirements, analyse and understand them. It will help you in understanding the need of the customer and hence do a good quality of testing. If the product has already been developed then you must go through the release notes, requirement documents and also set up a meeting with the concerned stakeholder, if needed, to gather as much information as you can relate to the product.
Test Case Creation & Traceability: Once you have understood the requirements, start writing possible test scenarios. Test scenarios help in generating good test cases. It’s recommended to write good quality test cases with proper pre-requisites, detailed description, complete steps of execution and clear expected result. To avoid skipping any of the requirements, have the habit of linking test cases with the matching requirement.
Identify Sanity & Regression Test Cases: Make sure to identify the test cases as Sanity or Regression. It’s a cumbersome activity to run manually all the test cases every time a build arrives or before every release; a tester should always have separate Sanity and Regression Suites, consisting only of appropriate test cases.
Test Case Review: It ensures that each and every functionality mentioned in Software Requirement Specification is covered. Ideally, review should be done in three steps– Self Review, Peer Review and Review by Lead.
Focus: Testing is a vital part of any application to validate its functional and non-functional behaviour and whether it acts according to the business objective. One should perform testing with full focus and dedication. Focus should be given to each and every aspect – UI, Functionality and Response time. If you are not focused during the testing then the chances are that some functionalities might get missed or, worse, you might miss a non-frequent bug.
Avoid Assumptions: You should NEVER ASSUME things in testing. Even if you are 101% sure that something will be working, test it. Ask questions, if you have doubts. Never proceed in testing with doubts or assumptions in mind. Your assumption can prove to be costly in terms of money or life, depending on what product you are testing.
No False Commitments: Don’t give less estimation time just to earn some brownie points. Use proper test estimation techniques and do consider the time for defect logging and their verification, once they are fixed. Do keep some buffer time, in case something goes wrong. Also don’t give too much estimation time just for your comfort. Be genuine in your approach.
Avoid Bug Leakage: If such a bug is found that could have been found in the earlier build/version, then this situation is called bug leakage. The cost of fixing a bug in the higher environment or later stages of SDLC is high, so it is important to avoid leakage of the bugs as far as possible. Bug leakage also raises questions about the quality of testing.
Bug Reporting: It is easy to write a bug report, but not everyone can write an effective bug report. A good bug report will help the developer in fixing the issue, and also it will avoid unnecessary communication to gather more information about the bug from developers. There are certain things that you must not fail in providing while reporting a bug:
Title: Bug title should be descriptive and meaningful.
Module: In which module you found the bug.
Platform: Windows, Linux, Mac, Android, iOS.
Priority: Blocker, Critical, Major, Minor or Trivial.
Severity: Critical, Major, Minor or Trivial.
Description: A clear and detailed description of the bug. Do mention steps to reproduce, actual result and expected result. Wherever needed, do mention the credentials that were used and if it is a web application then specify the URL.
Screenshot: Do attach a screenshot in almost all bugs. However for certain bugs, you might not be able to provide a screenshot.
Coordinate Well: Coordination within the testing team and also with the development team is very important. If there will be a poor coordination, then there are chances of friction among team members which could result in an unhealthy work environment and it further might impact the quality of work.
Save Screenshots: Like catches win matches, screenshots during testing helps a lot. As soon as you encounter something unexpected, the first thing you should do is take a screenshot and then try to replicate it. Sometimes you might not be able to replicate an issue but if you have a screenshot then you can share it with the developers for further analysis.
Every drop makes an ocean. You cannot achieve the quality results overnight. It can only be achieved with continuous and regular efforts in the right direction. Start implementing these practices and you will observe the difference in the quality of your work.