Just as there are various models for the SDLC, there are different “schools of thought” within the testing community. A school of thought is simply defined as “a belief (or system of beliefs) shared by a group.” Dr. Cem Kaner, Bret Pettichord, and James Bach are most often cited in regard to the “software testing schools.” They are also responsible for creating the Context-Driven approach to testing. The first real discussion about these schools was by Bret Pettichord (2003) who described the following four schools. Since that time, Agile and the Test-Driven school were added to the list.

Analytical School 

The Analytical school sees testing as rigorous and technical. This school emphasizes “structural” testing. It has dozens of code-coverage metrics and provides an objective “measure” of testing.

    Implications

• Precise and detailed specifications are a prerequisite for testing.
• Testers verify that the software behavior conforms to its specification.
• Most prevalent in academia and high-reliability industries

 

Factory School 

The Factory School emphasizes requirements traceability. It attempts to ensure that every requirement has been tested. It resists changing plans, and encourages industry testing standards, “best practices,” and certification. Outsourcing aligns well with the Factory school approach.

    Implications

• Requires clear boundaries between testing and other activities (start/stop criteria).
• Resists changing plans (complicates progress tracking).
• Most prevalent in government IT projects.

 

 Quality Assurance School 

In the Quality school, testing is a stepping stone to “process improvement,” and relies heavily on standards. Testers may view themselves as the gatekeepers who protect the users from the poor quality software. The software isn’t ready until QA says it’s ready.

    Implications

• Prefers “Quality Assurance” over “Testing.”
• May alienate developers
• Most prevalent in large bureaucracies and organizations under stress.

 

Context-driven School 

In the Context-driven school emphasizes Exploratory Testing, which utilizes concurrent learning, test design, and test execution. In this school the focus is on product and people rather than process.

    Implications

• Expect changes and adapt testing plans on test results.
• Unchallenged assumptions are dangerous.
• Effectiveness of test strategies can only be determined with field research.
• Focus on skill over practice.
• Most prevalent in commercial, market-driven software.

Agile School

The Agile school emphasizes the continuous delivery of working product. Testing is code-focused testing by programmers. In the Agile school, testing is focused on automated unit tests as used in test-driven development or test-first development.

Which Way is Best?

The introduction of the schools of software testing was not a moment in time event but rather as the profession matured, diversity of thought evolved, and a relatively discrete number of similar approaches emerged. One school of thought is not suggested as better than the next, nor are they competitive, but rather a problem solving approach to test software.

The one that is picking up the most steam, and makes the most sense for UConn (in my opinion) is the Context-driven School. The testing approach used is completely determined by the context of the project. This offers the most versatility, and fits nicely with UConn’s disparate array of software projects.

What I like best about the Context-Driven approach.

• We are not restricted to one way of testing for all projects. This is the best of all worlds. Each project is different and requires a different approach or methodology. I have already experienced the difficulty in trying to force strict process rules and documentation templates to UConn projects.
• Testing is multidisciplinary. We get to use the best of the best approaches when the context calls for it. Every project is different and provides a challenge that allows learning and growth.
• We expect changes. So we can adapt the testing plans as necessary based on the test results.
• It minimizes the time spent on documentation. We choose our testing objectives, techniques, and deliverables (including test documentation) by looking first to the details of the specific situation.
• It focuses on skill over practice. The essence is project-appropriate application of skill and judgment that provides good information to the project.

Ultimately, context-driven testing is about doing the best we can with what we get. Rather than trying to apply “best practices,” we accept that very different practices will work best under different circumstances.

---