Rita asks, “My test manager has asked me to test a FMCG retailing website to test. I have never tested such a website before. Can you guide me how to start testing this website? Can you point me to some best practices that can be followed while testing this website? Please help.”Ritika asks, “I am doing my project work in component based integration testing and I am new to this field. So I need your help. I have to implement different integration testing techniques like UML based, dataflow specification etc. Could you please help me?”
Deepak asks, “Hi Debasis, nice articles. I tried searching for context-driven testing but couldn't find any article. I am new to testing and want to pursue my career in testing, a little bit about me. I want to know the framework for context-driven testing. Is it possible to write an article w.r.t the above-mentioned framework? Thanks any way. It is a pleasure reading your article (although I have read only one article)!”
Can you pick out the common thing in the above 3 questions? Do you have answers to any of the above FAQs? If your answer is No, then read on. In case your answer is Yes, then this post might be intended for testers like you, keep reading!
What is a ‘context’?
The WordWeb dictionary of my desktop computer defines a “context” as “The set of facts or circumstances that surround a situation or event”. Definition apart, a context is the circumstances relevant to something under consideration. It is the background information that enhances understanding of technical and business environments to which the problem relates.
What is ‘context-driven testing’?
The context-driven testing is often considered as a flavor of Agile Testing that recommends continuous and creative evaluation of testing opportunities in light of the potential information revealed (mostly by context-based questioning) and the value of that information to the organization right now! It can be defined as testing driven by an understanding of the environment, culture, and intended use of software. For example, the testing approach for life-critical space-ship control software (remember Columbia disaster?) would be completely different than that for a low-cost payroll processing software.
A doctor does not use a chopper (that a butcher uses) while operating a patient. Instead, he uses a scalpel. Both the chopper and the scalpel are sharp knives and are meant for cutting but they can’t replace each other and has their use in their own specific areas (contexts). Neither a chopper can be used for operating a patient nor a scalpel can be used for slaughtering a pig! As the context changes, the effectiveness of the equipments (practices/approaches) also changes. So there is nothing such thing like one-approach-fits-all! Approaches need to change with the change of situation and change in circumstances.
As James Bach puts it - “Context-driven” means to match your solutions to your problems as your problems change. Good practice is not a matter of popularity. It’s a matter of skill and context.
I believe that, context-driven testing starts with context-driven thinking! Context-driven testers never try to fit in the same solution to different problems and still hope that they would eventually succeed! Rather they try to find a different solution that might solve the new problem and follow it! Remember, there is no “master key” (best practice that succeeds in *every* cases, no matter what is the context) in software testing. [Master key is a key that secures entrance everywhere by fitting into multiple locks!]
The Seven Basic Principles of the Context-Driven School!
1. The value of any practice depends on its context.
2. There are good practices in context, but there are no best practices.
3. People, working together, are the most important part of any project's context.
4. Projects unfold over time in ways that are often not predictable.
5. The product is a solution. If the problem isn't solved, the product doesn't work.
6. Good software testing is a challenging intellectual process.
7. Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.
Context-driven testers agree with these principles and follow them while solving testing problems! In case you are interested in knowing about other schools of software testing you might consider reading this post by Dr. Cem Kaner.
What a context-driven tester like me might do when allotted to a testing assignment?
1. A context-driven tester might start by asking a bunch of context-based/context-related questions in an attempt to know the context better and deduce information about the mission, aims and objectives of the testing assignment! As it is said, proper questioning has the capability of solving half of the problem; and a context-driven tester knows this fact clearly from his experience and practice!
2. Once somebody said - The only thing that does not change in this world is “the word change” itself! This applies to software development too. Projects keep changing shapes as the development phase continues. A smart context-driven tester knows and understands that it is wise to be flexible and change the testing strategy as the context changes during a development phase. He can change mind and change the way he thinks once he realizes that the context has changed and is not the same as it was before!
3. A context-driven tester understands that the testing practices/approaches/procedures that had worked in his earlier testing project might or might not work in the current assignment simply because the context of both these projects might not be the same! A context-driven tester clearly knows that what looked like the “best practice” (so called!) in the earlier project might suddenly loose its value and become a “bad practice” once the context is different!
4. A context-driven tester also understands that context-driven testing is a set of values rather than a process or technique. It revolves around the fact that software users are human beings with diverse preferences, needs, abilities and limitations. A program that works well for one person in a given situation might prove inadequate or inappropriate for another person or situation.
“Survival of the fittest” [Charles Darwin has called it as 'natural selection', or the preservation of favored races in the struggle for life in his theories of evolution in the book “The Origin of Species”] is a phrase that refers to the process by which favorable traits that are heritable become more common in successive generations of a population of reproducing organisms, and unfavorable traits that are heritable become less common! In other words, those who are better equipped with the power of adaptation survive and the rest perish! In a software development environment where the context is unstable and is likely to change, the testers those are better trained to adapt themselves and change gears with the changing context have a better chance of success than those who are unable to do so! It is all about adjusting yourself (the tester) to the situation than to adjust the situation as per your comfort level! We can't change this world. The world won't change until we change. The questions are:
» "Will we change"?
» “Are we prepared to evolve”?
» “Are we prepared to change our practices and approaches to testing when the context has changed”?
» “Are we prepared to stop expecting any best practice to come to our rescue and do wonders for us even when the context in question is entirely different from the case where these practices had been successful”?
What do you think? Do you let the *context* drive your testing approach or the *best practices*? I am excited to hear your views. It is time to get vocal and let out your views/opinions by commenting.
Happy Testing…
Absolutely beleive in Context driven approach. A practice can be "Best" in certain context and completely "Expensive" in other context. This signifies the beauty of Software Testing. I was recently involved in 2 projects related to Internationalization testing. The practice of pseudo localization reaped rich cost savings in a completely new project (having the new UI) whereas in an existing project with a very few modifications in UI, it didnt make any sense to use pseudo localization. No practice can be blindly followed even if it has a track record of huge cost savings in previous projects, it simply wont work if the context changes.
ReplyDeleteVery Thoughtful and practical explanation.
ReplyDeleteVery well explained context-driven testing.
ReplyDelete- Software testing and quality assurance