History and Roots of Context-Driven Testing
The individuals responsible for founding the context-driven school were James Bach, Brian Marick, Cem Kaner, and Bret Pettichord. On 21st November 1999, James Bach, Cem Kaner, and Brian Marick were conversing regarding the prospect of writing a testing book together and at that time school was founded. After a few days, the context-driven testing mailing list on Yahoo groups was established by them. A couple of years later, James, Cem, and BretPettichord were responsible for publishing the first context driven self-described testing book named Lessons Learned in Software Testing: A Context-Driven Approach. At the time, the context-driven testing strategy was likewise distributed.
Even though the school had been declared in 1999, one can trace back direct roots to the 80s when Cem and James were trying autonomously and not succeeding to establish “best practices” of testing work where commercial mass-market software items were dominating. They developed practitioner-centered and agile test methodologies independently. Cem and James met in 1995 and started collaborating with one another while finding better techniques to analyze and discuss the relative value of technical practices with like-minded individuals.
In 1997, BrianLawrence and Cem Kaner began to host the Los Altos Workshops on Software Testing. This gave the opportunity to many testers to come together while sharing experiences and learning how to share concepts across barricades of market, project size, technology, and various other project context aspects. This marked the beginning of the context-driven testing school. Amongst the individuals who participated in LAWST workshops, mention may be made of Brian Marick, James Bach, Elisabeth Hendrickson, Bret Pettichord, Johanna Rothman, Doug Hoffman, Noel Nyman, and others.
A lot of context-driven testers have studied the philosophy of epistemology and science to get some idea regarding how to think of software testing. One particular instance of this is interpreting the verification principle of KarlPopper for testing scientific concepts as a means of thinking about testing software.
Early Context Driven Writings
The period between 1992 and 1999 has seen the development of the concepts of context-driven testing in different writings.
The Testing Computer Software was published by Cem Kaner in 1988, asserting that testers required to work efficiently in the common scenario where individuals instead of specifications regulate the product’s quality and the programmers need not follow the regulations. Before its publication, the majority of the testing literature claimed that testers could be successful only if the waterfall method were developed by the programmers which provided specifications in detail. The testers who had worked with successful teams that had achieved success by focusing on working code and speed over extensive documentation and planning welcomed this book. TCS was supplemented by Kaner in 1988 with Test Planning for Consumer Software which advised the testers specifically to promote evolutionary development over waterfall to curtail test-related documentation and put emphasis on their quality vision from customer requirements in rather than code or process out.
The “Process Evolution in a Mad World” was written by JamesBach in 1993 and “The Immaturity of the CMM” was also authored by him in 1994 along with several other articles in 1997 and 1998. He also wrote “Good Practice Hunting” in 1999 which was published just before the declaration of the school, and it had been inspired by the discussions held at LAWST. You will find all these articles at http://www.satisfice.com many of which had been seen as outlining the validity of an approach towards development which was later labeled as “agile”.
“Classic Testing Mistakes” was authored by Brian Marick.
Principles and Goals of Context-Driven Testing
- It is the context which decides the value of any practice.
- Although you will come across good practices in context, there aren’t any best practices.
- Individuals, working together, happen to be the most crucial part of the context of a project.
- Over time, projects unfold in ways which cannot be predicted in most cases.
- The product is nothing but a solution. It is not going to work in case the problem is not solved.
- Good software testing is a difficult intellectual procedure.
- It will be possible for us to perform the right things at the proper time to test our products efficiently only through skill and judgment exercised cooperatively during the entire project.
When to use Context Driven Testing?
Context-driven testing will be used when one is trying to attain the objectives mentioned below:
- Clarify your objective.
- Supervise the major test planning challenges.
- Evaluate the product.
- Analyze any risk associated with the product.
- Set up logistics.
- Plan the test strategy.
- Share the idea.