How to Test Smarter: Explore More, Document Less

How Can You Test More Effectively?

Faced with today’s demanding environments and tight timeframes, testing teams are performing remarkably well. Remarkably so, given budget restrictions and anxiety over security and usability. The purpose of this article is to provide guidance on how to test in a more efficient and effective manner without additional complexity.

By refocusing their energy, we can help testers enhance their performance. Rather than allocating time for test documentation, we can motivate them to devote more attention to broadening exploratory and ad-hoc testing.

Identifying the Issue

A notable hurdle faced by IT corporations nowadays is the compressed development cycle. Unless working on an extensive enterprise project, planning stages surpassing a few months are seldom scheduled. Managers are left with the responsibility of handling stringent cycles while ensuring the delivery of top-quality software.

Software developers are tasked with flexible, quick coding, while testers must adapt to ever-evolving and increasingly intricate programs, ensuring no errors go unnoticed.

Implementing a Solution

Several measures need to be implemented in order to augment tester efficiency. Enhanced SDLC (Software Development Lifecycle) apparatuses can undoubtedly increase productivity for both coders and testers. Additionally, technology for automated testing is pivotal for agile and traditional teams.

Despite the presence of exceptional development tools, agile methodologies, continuous integration, and systems for test automation, quality assurance often becomes an obstacle as business needs intensify pressure and compress deadlines.

Thus, the importance of smarter testing methods is underscored. The strategy involves a shift of resources from documentation to high-value procedures like Exploratory Testing.

Diminishing documentation does not impair quality. Test scripts can still be produced and carried out. Testing more effectively involves programmers and testers cooperating to assemble and execute essential Unit tests, Functional tests, Acceptance tests, and Security tests.

Nonetheless, smarter testing acknowledges the fact that some tests are more imperative than others and therefore deserve more consideration, including documentation.

For instance, consider a conventional agile team tasked with integrating new functionalities to a website or mobile application. At the onset of the sprint, the team formulates a testing plan, develops novel test cases, or modifies current ones. Once coding is finalized, the team performs the tests, documents the results, along with any detected defects.

In the event that defects are recognized, the code is corrected, and the tests are performed again. Sometimes, defects might necessitate revisiting the test cases and code, which could also require updating before retesting. The process of forming and revising test cases, and documenting test cases and test runs, consumes invaluable time and resources.

However, not all test documentations add business value. By carrying out smarter testing, testers can prioritize documenting test runs only when defects are found instead of documenting every single test case and run. If the test run yields negative results (i.e., zero defects), it’s time to proceed.

However, if the results are positive (i.e., defects are discovered), then testers ought to document the test, incorporating any essential information for reproducing the defect.

An Illustrative Example

Let’s envision there are 100 fresh test cases for a particular sprint. The standard procedure would involve reviewing, possibly updating, and documenting all 100 test cases thoroughly.

Adapting a Smarter Testing Approach: Let’s test more effectively. Let’s say it has been ascertained that only 10 of those test cases need to be transported forward for future regression testing. Moreover, 15 tests did not pass during execution, resulting in unexpected or unanticipated outcomes. In this scenario, the team would exclusively document the 25 fundamental test cases that failed, in contrast to documenting all 100. This approach saves substantial time.

The time saved can be put towards further improving quality by facilitating more exploratory and ad-hoc forms of testing amongst developers, testers, and other stakeholders. If the team has automation tools that can convert impromptu tests into reusable scripts for future regression tests, it serves as an added benefit allowing exploratory tests to be morphed into test-case workflows.

A Word of Caution: Prior to deciding on smarter testing and reducing documentation for certain tests, it’s crucial to ascertain that the testers have a comprehensive understanding of the goals of a particular development project or phase. This way, they can determine if new tests will be required for future sprints.

In agile environments, this necessitates grasping the objectives of each sprint. It’s essential to know what’s novel or revamped in the sprint and backlog and understand the user narratives. The team must reach a consensus regarding the tests required for that specific sprint – some of which may not necessitate documentation, and the tests required for forthcoming Regression Testing and acceptance testing; these are to be thoroughly documented.

Pose this question to yourself, “What areas would the end-users concentrate on when they receive the code from this sprint?” Direct your testing and documentation towards these areas. Still, also ponder upon, “Which sections of the code might not be a point of concern for end-users but could cause potential issues?”

These questions will steer developers, testers, and other stakeholders towards exceptions and circumstances that call for exploratory and ad-hoc testing.

Team managers should sketch a high-level testing route. Identify pivotal scenarios for each sprint that necessitate testing and retesting due to high susceptibility or their foundational role in future sprints. Once recognized, these scenarios can be curated for future regression testing.

Conversely, areas of code that present lower risk can be tested once, particularly if the code is stable and won’t impact future enhancements. Therefore, no documentation is necessary.

Closing Remarks

Circumstances demand code delivery at a rapid pace. To expedite software development without compromising on quality, testing must be carried out more efficiently!

Whenever feasible, employ automated testing and maintain unit tests when new code is inserted into the source-code management system. Document and exercise regression tests on critical code sections, but don’t squander time on documenting tests unnecessary for future use.

Instead, allocate your testing resources towards exploratory testing. This step will enhance quality and speed up the development lifecycle.

About the Author

Vu Lam is the founder and CEO of QASymphony, a provider of defect-tracking applications that record user interactions with software. Prior to this, he was associated with First Consulting Group and was an early player in Vietnam’s offshore IT services industry beginning in 1995. He holds a Master’s degree in electrical engineering from Purdue University. Vu Lam can be reached at [email protected].

Your Thoughts, Queries, or Feedback are Welcome