Ask questions or share your requirements with us. We'll get back to you at the earliest.
Thursday March 7, 2019
Software testing process is an important yet many a times under-rated part of every software development process. It evaluates whether the end product meets the required specifications and standards.
The overall software testing process is a continual improvement process. It is also a time-consuming process and with each increment of the software the time taken to complete the entire AUT keeps on increasing exponentially.
Now, it may not always be possible to complete the entire testing within the available time frame. So what do you do? The first thought that comes to the mind is to prioritize the test cases. Yes, good thought. But that may not always be sufficient.
But don’t lose heart, read on to find out some very smart and quick ideas to improve your software testing process.
1. Double confirm the requirements from the client. Make sure there are no ambiguities. If there are any get them sorted out at the onset. The entire quality is based on the user requirements; you cannot afford to go wrong in this area.
2. Get involved from the beginning of the development process to get a comprehensive understanding of the AUT which would, in turn, help you identify areas needing more intensive testing
3. During the design phase, you can start working on test cases based on design documents and with the help of the developers. This will mean less time for creating and updating test cases during the actual testing phase.
4. The test plan should be written by a Manager or QA lead. The good test plan will cover deadlines, scope, schedule, risk identifications among other things. Make sure to have it reviewed by the project manager as well for concurrence.
5. Ensure that the quality is maintained right from the beginning irrespective of whether it is development, testing or network support. QA’s are like the gatekeepers of quality, they should not let anything pass which is not as per the expected quality.
6. Testing as early as possible and as frequently as possible also helps get more detailed testing done. Do not worry about the number of modules delivered, if you have the bandwidth get the testing done for even a single module.
7. User training should be provided to the QA team for a better understanding of the way the product is actually used by the clients or end users. This will also help them in testing the product better.
8. While creating test cases make sure that all the permutation and combination of different types of data input are covered. Use the well-known principles like boundary value analysis (BVA), Equivalence Partitioning (EP), Decision Table This ensures that the code is tested thoroughly.
9. Always ensure that testing goes in parallel with development. Make sure to test individual modules as and when they are ready for testing instead of waiting for the completion of the entire module.
10. Make use of stubs and drivers to testing smaller modules which requiring input from other modules or are pushing data to other subsystems.
Know More: 50 QA Interview Questions To land a Job!
11. Make a distinction between testable and non-testable items in the requirement document and include it as part of the test plan. This will be helpful in having confusion later on.
12. Always ensure that one test case covers only 1 validation point. Though in some cases it may lead to duplication and extra effort for writing the test cases, this is needed for better traceability of the bugs.
13. Test Coverage is an important aspect of ensuring a quality product. Use a traceability matrix to make sure each requirement is mapped to at least one or more test cases. This ensures complete coverage of the system.
14. Ensure that the test case documents are completed, reviewed and signed off by the stakeholders before the actual testing starts. Also, make sure that the test cases document is made available to the rest of the team for understanding and doubt clearance if any.
15. Identify and group test cases based on their importance or priority. This is helpful at the time when only limited test cases can be run during a particular testing cycle. This grouping is also needed when you aim to run or re-run only a particular set based on their priority.
16. You can also have test cases grouped based on functionality. This is useful at the time of regression testing done after a bug fix in any particular module. For example, if there has been a bug fix related to functionality in module A, then you can pick all test cases grouped as module A for the next regression test.
17. Reviews are important to ensure correctness, following of guidelines etc. Ensure that all test cases are reviewed internally within the team (peer review) and once externally also to ensure correctness of the expected results and any other discrepancies.
18. Involve tools to make your life simpler. Tools like Quality Centre, Test Complete, Rally etc. make your life much easier by taking care of a lot of metrics generation and data collection. These tools help you manage your testing projects in a much better and more professional manner.
19. Automation is very important. It reduces manual effort on repetitive tasks. So it is always a good choice to go in for automation of modules or features which are stable and repetitive.
20. Encourage team members to come up with innovative thoughts to make the testing process less time consuming but at the same time more fruitful. Many minds at work is always better than a single one.
21. Always have clear precise and achievable deliverables. Keep a 10% buffer for retesting and other risks. Keeps you and your plan safe and viable.
22. Version control all your artefacts. This is especially important if you are using automation. Make sure the code is version controlled so you are able to create multiple branches and each one should be easy to revert back to in the worst cases if needed.
23. If feasible implement CI/CD. This ensures that each time a build is created the automation suite is run automatically to check if the basic build and its functionalities are in place or not. This helps save a lot of time as well as human error in forgetting to test a particular build.
24. Delegate responsibility to team members for modules or smaller sections. This makes them work harder for ensuring the quality
25. Always look at the software from the eyes of the user as a product and not as a project. The product is most important, think like a consumer when you use the product.
26. Has the environment set up in such a way that it replicates the production environment as closely as possible?
27. Ensure that all API’s, backend systems, user access, admin roles, test data and any other input needed are set up well ahead of the testing cycle. This is to ensure a loss of time in setting up when the testing window in open.
28. Always have a healthy relationship with the development team. This will help in a quick turnaround in case of clarifications.
29. Always ensure to have constant communication with the developer at every stage of the testing process so that everyone is aware of the testing activity in the process.
30. Have at least one person from the testing team join the daily project meetings, so that the testing is aware of the modules coming up for testing in the next release and hence can start preparing for it.
31. During the testing phase, have a daily meeting within the team, to clear any doubts and get additional information where ever needed. This is also helpful in tracking the testing progress.
32. Each team has a role to play in the delivery of a good quality software product. Ensure that each team is assigned clear cut guidelines and areas, avoiding a conflict of interest.
33. Establish a clear and precise communication plan along with SPOC (Single point of contact) list and escalation matrix which will contain a list people or contacts to be used in case of any escalations or in cases where information is needed immediately.
34. It is always advisable to have the team members test a different module each time. The reason is twofold. For one the tester get a better understanding of the complete project instead of a single module and also new bugs can be found if the module is tested by fresh testers each time.
35. Always be prepared for changes and contingencies this also includes the risks. Planning such situations help you avoid panic and face the scenario more gracefully too.
36. Always maintain a risk register and review it frequently. You can also have a time slot set aside with all the stakeholders to review this risk register say weekly. Also, make sure that all risks and mitigation plans are captured accurately.
37. Maintain and update simple metrics as defect found, defects fixed and percentage completion, quality level etc. Send out these metrics to all stakeholders and people involved preferably in a pictorial format, along with the comparison with previous week’s data. This will have a much greater impact and visibility than you can imagine. Give it a try.
38. Monitor your production app. And yes for the unfortunate bugs that do find their way to production, make sure they are included as part of the regression test suite with a high priority.
All the information regarding bugs and product development should be maintained in a common Share Point or repository for everyone to access and derive reports when needed.
40. Always have a fresh and open mind when testing software. Have no assumptions. And always refer to the requirements document for doubts and clarifications.
41. The entire product module should be divided into smaller parts to ensure each and every part is tested thoroughly
42. Always ensure to have included the maximum details in the bug report which should include the user credentials, navigations or step to reproduce, expected and actual results, environment, version, logs and screenshots of the error.
43. Always give clear instructions to reproduce an issue. Do not assume that the reader will know the application. Mention each object (button, link, edit box etc.) and action to be performed (click, enter, double click etc.) along with the pages navigated.
44. Discuss and reach a consensus before the starting of the testing on the number of high priority and medium priority bugs can remain open or deferred at the time of movement to production
45. Metrics are important criteria proving the effectiveness of any testing process. Choose appropriate metrics based on the project you are working on. Defect Density, Defect Removal Rate, Testing Efficiency, Test Case Execution Rate etc. are some commonly used software testing metrics.
46. Verbal communications should be topped up by documenting the same in email and shared with relevant stakeholders. This not only creates better visibility but is also helpful in having a chronological record of communications.
47. TDD – Test Driven Development is a newer form of development which takes the base from the test cases. This can also be employed for a better quality of code development.
48. Have a UAT testing at least once before the product is released into production. This will be useful in identifying issues which are related to actual client usage. UAT testing is best performed by the users themselves.
49. Always keep a check on the time taken by the development to fix the bugs. This data is part of an important metrics which is used to calculate the overall efficiency of the development team.
50. Last but not least, trust your instincts. Yes, the QA people sense issues. So just follow your instincts, if you feel a certain area can have issues, mark my words there more chances that issues will be found in that part of the code.
As important as testing and quality assurance is, we should give it the time and resources it needs. This pays off in the long run. These tips will be helpful to you for implementing a good test strategy as well as a quality product.