By Julia Pottinger
Originally posted on Techbeacon
Automated testing may be increasingly popular, but it doesn’t eliminate the need for manual testing. Proper manual testing increases application usability, especially during user acceptance testing.
And while automated tools can handle the visual confirmation of requirements, manual testing is the best way to quickly verify requirements and features. Manual testing techniques allow exploratory testing and let you verify changing requirements in a shorter time than can automated testing.
Manual techniques also help reduce cost and time when implemented properly. But while it’s crucial to understand the importance of manual testing in delivering quality software, it’s even more important to avoid these seven common mistakes that many manual testers make.
1. Testing without understanding requirements
Many of us have been thrown on a project and asked to start testing without viewing a requirements document. In some instances, there may not be any test cases or user stories. And on many projects, the actual requirements method used is largely undocumented. Testing without having the proper requirements, or testing without understanding the requirements, can lead to false positives or negatives, with features incorrectly marked as having passed or failed. This results in missing features and buggy software, and is a waste of time, resources, and money.
Without requirements, you may end up going back and forth with the developer to try to determine the correct way the application should function. When that happens, testers become the source of product requirements, which can result in the application deviating from the client’s needs. If requirements are not present or you don’t understand them, it will be that much more difficult to validate and verify the product.
2. Not time-boxing exploratory testing
Exploratory testing, when implemented properly, can provide great results for a system that has little or no requirements. It is also useful in agile environments, where you have many changing requirements or where testers are learning the product or designing test cases.
When you time-box exploratory testing, the reproducibility of found issues is increased and time spent testing is reduced. (Time-boxing is the process of allocating a specific fixed maximum amount of time to an activity.) Also, issues and questions raised are properly documented and tracked. Testers with appropriate knowledge or experience should perform exploratory testing, following a test charter that defines the scope and goal for testing in a time box.
There are times when testers become so invested in testing a feature or trying to reproduce a bug that they lose track of time and go down the proverbial rabbit hole. When they finally resurface, they realize that while this may or may not have been necessary, other important tasks were not getting done.
This is a loss of time and resources. By not time-boxing exploratory testing, you may end up spending more time in one area while neglecting others.
3. Not prioritizing test cases
Test case prioritization can make the difference between the success or failure of an application. Imagine that, without first prioritizing test cases with the test manager and other relevant shareholders, you execute 80 out of the 100 test cases. When your organization delivers the product to the client, they are extremely unsatisfied because the 20 test cases that you didn’t perform were critical to their business.
Or imagine an ATM application where you test everything except the option to withdraw money. Upon delivery, the customer discovers a huge bug and no one can make withdrawals. This would be catastrophic.
Fortunately, that doesn’t always happen, and you may get lucky. But to have a greater level of confidence in the quality of the systems you test, prioritize your test cases and the overall testing effort. And don’t just do it yourself: Engage the test manager and other project stakeholders—including the client, business analyst, product owner, project manager, and development team. All should participate in prioritization of features so that you develop and test the most important or high-risk features first.
4. Testing only after you have deployed the code
In the agile lifecycle, requirements and features are constantly evolving, so start testing as early as possible. Sit with developers to go over requirements and discuss what they are working on before they deploy it to the testing environment.
When should you start? As soon as you have a draft of the requirements document or user stories. Early testing is one of the seven principles of proper manual testing. You’ll find defects earlier and fix them more cheaply. The later in the lifecycle you find issues, the more expensive they are to fix.
You can test requirements documents to ensure that there are no gaps in requirements, that requirements are clear, and that the quality of the requirements is adequate for your project. This helps the right product to be built and reduces the cost associated with requirement defects that make it all the way to production.
Additionally, poor quality or gaps in requirements increase development and sustainment costs and often cause major schedule overruns.
5. Not reporting defects correctly
Reporting a bug correctly is just as important as finding the bug. Proper defect reporting allows for easy identification and reproduction of the problem and for the issue to be fixed in a timely manner.
If the defect report is vague or incomplete, the developer will waste time trying to understand what the defect is. A good bug report reduces the time from bug detection to resolution. Bugs can delay a release and sour the relationship with the customer, especially when time to resolution is extended because the developer didn’t understand the defect report.
Think of the defect report as a form of communication between the tester, the developer, and other project stakeholders. You can use issue- and project-tracking software with links to web-based test management tools that contain detailed test cases. Such tools usually have suggested fields to ensure that your defect reports are as clear as possible.
6. Failure to implement traceability across the project lifecycle
Traceability empowers project stakeholders such as project managers, clients, and development teams to make decisions. It can help a test manager or project manager determine whether all requirements for project completion have been met.
You can also use traceability to determine whether or not entry and exit criteria for testing have been met. Traceability metrics such as test coverage, the number of bugs found for specific requirements, number of defects outstanding, and the severity of the defects are all important and are used to make decisions about releases and the product.
Some questions to consider when executing tests are:
- Are the prioritized test cases that are being executed tied to a requirement?
- Are the defects that are found linked to a test case or a requirement?
7. Not performing root-cause analysis
Root-cause analysis , the process of finding the origin of a problem or the underlying cause of a defect, finds a permanent solution for reported defects and reduces the chances of recurrence. Root cause analysis saves money in the long run, since the cost of fixing defects increases the further along you are in the software development process.
Testers will get even more respect if they log both bugs and suggest solutions. Testers gain insight into how the system works and can therefore develop more robust tests for the system.
You can do this by first identifying the main problem, then analyzing why the problem is occurring. It could be as a result of inadequate requirements, negligence, an incorrect assumption, design gaps, or deployment issues.
And, working with other stakeholders, try to identify when the issue occurred. Was this error present in the previous release? Is it a regression as a result of a fix? Did a new feature cause a failure? These are some questions to ask.
Tying it all together
With an increased demand for high-quality software, the critical role of proper manual testing practices cannot be understated. This list of mistakes is not exhaustive and they can certainly be addressed with a certain degree of ease if each involved party understands and owns their role in creating efficient testing processes.
With a commitment to adopting testing best practices, testers, and all project stakeholders can prevent common blunders and inaccuracies that may seem small but can cost a fortune in the future. This is how QA teams can ensure an efficient process that will safeguard the quality of products.