5 Old Testing Techniques to Retire (or Revamp)

As a professional discipline, quality assurance has a long history. From the late 1950s through the early 1980s, software testing evolved from simply detecting errors to creating complex charts and logical calculations meant to narrow down the data needed for testing. 

Many testing techniques used from the early 1980s to early 2000s are still in use today, although in a variety of ways and without the pre-planning detail, complex mathematical calculations, charting and graphing from those days of yore. These old-fashioned testing techniques were referred to as structured test design techniques, which were intended to predict test coverage and create test structures based on managing risk. However, in modern software testing, many of the original structured test design techniques are too cumbersome and time-consuming to use.

Today’s QA world relies heavily on automated testing and manual testing at speed. Modern testing teams create a test strategy that includes both manual and automated test execution. These testing strategies keep QA focused on maximizing both efficiency and test coverage within rapid development cycles. But that doesn’t mean we can’t learn from past testing practices.

In this blog, we’ll discuss five old-fashioned testing techniques that no longer work in modern QA testing and tips for revamping the ones with the greatest testing benefits. 

Equivalence partitioning

Equivalence class partitioning (ECP) is a black-box testing technique that reduces the amount of data types tested. In ECP, testers divide identified inputs into data classes. From these created data classes, testers design and test data from each class. Essentially, you reduce the amount of testing needed by reducing the number of test input values.

Equivalence partitioning uses either a range of values or a set of specific values. From each value set, an equivalence class is created with a valid and invalid value. Values can be boolean, numeric or any set of defined strings. 

For example, you’re testing an application that only sells certain products to specific U.S. states. As a tester using ECP, you would create data sets with one to four products per state. Ensure you have at least one invalid value in each data set. Each data set becomes an input class. During testing, use each input class and create a test case for each. 

As a modern tester, I’ve never had the luxury of enough time to divide up all possible input conditions from the code into data sets. To modernize equivalence partitioning, testers can logically choose the values customers would realistically use and create test data sets. I suggest creating data sets and input classes that are focused on realistic customer values. In other words, create input classes with values customers normally use rather than values that are rarely used. 

Condition/decision coverage

Decision tables or condition/decision coverage is another old-fashioned structured test design technique that doesn’t fit in modern testing. Decision tables are generally created as test matrix tables. The test matrix takes the requirements documentation — we will assume a full requirements document exists with detailed descriptions of every possible decision path in the code — and documents the possible outcomes one by one for all data sets. 

The test matrix becomes a table of test scenarios based on requirements and application code functionality. When requirements change, the team updates the test matrix to reflect changes in the condition path or test scenario. Most test matrices are extremely complex and take significant time to create and maintain. Think about the enormity of creating a test matrix that covers all functions, procedures, subroutines, framework functions and test data. 

Not only are decision tables and test matrices complex, but they are also difficult to edit or update without the risk of breaking a condition or coverage path. For a testing team working within an Agile methodology, the time for creating and identifying all conditions and decisions in an application typically does not exist. 

Retire decision tables and test matrices. There’s simply not enough time in an iteration with constantly evolving code and acceptance criteria to create an accurate test matrix. The team would spend all of its testing time trying to update it story by story. If you have access to test automation with AI, you could consider trying to have the AI create a test script that exercises all decisions in the application. Remember to maintain it as the code changes with new features or changes to existing functions. 

State transition diagrams

Many software testers today develop a natural tendency to test all application state transitions during functional, integration and usability testing. State transition diagrams are an old-fashioned structured testing technique that came about with object-oriented programming. State transition diagrams are graphical depictions or flow charts that identify all conditions that must be met before a transition occurs. 

State transition diagrams use a set of standard notations including:

• State
  • Condition that occurs on an object that satisfies a condition, performs an action or waits for an event.
• Event
  • An occurrence that triggers a state transition. 
• Guard
  • Boolean expression that causes a state transition when set to true.
• Transition
  • A change of state for an object.
• Action
  • Actions an object performs in response to a state change.

Testers work through each diagrammed pathway for all objects that cause, react or perform an action when a transition occurs. State transition testing uses syntax testing to verify the diagram is correct and complete. The purpose of reviewing the completeness of the diagram is a way to identify missing requirements. 

State transitions occur frequently in modern web and mobile application testing. Documenting each transition along with the cause and effect is useful, but it’s also an inhibitively time-consuming and never-ending task.

State transition information is valuable, but modern testing teams can cover it with user story functional testing. Consider creating automated functional tests that verify critical transition paths. In this way, testing teams gain the value of understanding where and why transitions occur without investing additional time into creating an endless reference diagram. 

Static testing

The static testing technique includes multiple variations for testing without exercising any actual code or application build. So, how is that testing? Static testing helps fill in gaps within user stories or requirements. For modern testing, static testing is a handy way to test and identify defects in application design, theory, UI/UX and integration. 

Types of static testing include:

• reviews
• walkthroughs
• technical or code reviews
• inspections

Reviews range from informal pair programming or pair testing discussions, which can help identify defects early. Walkthroughs are similar to demos but might be in front of a product manager as a finished release product or between developers and testers for each feature as it’s developed. Walkthroughs help explain how features are intended to function and identify missing requirements or integration dependencies. 

All static testing techniques were designed for use with requirements documents, design specifications and release-level test plans as well as coded features. With that in mind, technical reviews might be a code review or a review from other design professionals on the UI/UX design plans. Finally, inspections are formal meetings where a moderator manages the document or code review. The moderator makes the process more generic rather than focused on the individual creator. 

Static testing is easy to revamp to work with an Agile QA environment. Static testing is a valuable practice that can be relevant for modern testing. It’s a flexible approach that teams can execute before and during code development. Add a review or a walkthrough to help the testing team identify test cases and discover if any necessary scenarios are missing.

Static testing can help cross-training between development and QA team members. As you use walkthroughs or even reviews of the code, testers gain a deep understanding of how the code functions. 

Path testing

Path testing involves using a control flow graph for an application as part of a design specification or technical architecture design document. The intent is to identify linear independent execution paths within the application code. Testers create a control flow graph to ensure they’ve identified all the executable paths in the code base.

Next, cyclomatic complexity determines the number of linearly independent decision paths. 

McCabe’s cyclomatic complexity = E N -2P where:

• E = number of edges in the control flow graph
• N = number of vertices in the control flow graph
• P = program factor

Testers then write test cases for each set identified through the cyclometric equation. Testers would first create a control flow graph from the entire code base, calculate the cyclomatic complexity and write test cases for each set.

It would take a significant amount of time for a tester to perform all of this work, and it would need to be redone as the code changed. It’s basically impossible in modern day development to create a functional test case for every code path, let alone regression test the entire suite for every release.

Path testing might work for a brand new app, but the process likely breaks down after three or more releases. It’s simply too resource intensive to create the tests and then execute them all before the next release. 

One way to revamp path testing could be to use it as a unit test development framework for developers. Most Agile development teams do not produce the design specifications typically used, which means developers could create unit and automated integration tests for each build using path testing. Unit tests could include all integrated dependencies and third-party applications used. In this way, path testing provides a structured and thorough framework for unit and automated integration tests that are executed against each code build.

Lessons from the past

Structured test design has a long history in software testing. It provides a multitude of techniques that can be used to create a set of foundational tests based on the code design. However, with Agile, there’s typically not enough depth of detail in the documentation for many of these techniques to be relevant today. The code is often in progress and changes every iteration, making it difficult to pin down the precise detail required. While software testers can still find some value in many structured test design techniques, the bulk of the old-fashioned testing techniques simply don’t fit in the tight timelines or generate the customer-centric focus modern QA demands.