Basics of Context Driven Testing

Context-driven testing recommends testers to choose their testing objectives, techniques, test deliverable and test documentation by looking first to the details of the specific situation. The meaning of context-driven testing is project-appropriate application of skill and judgment. Testing is a solution to a very difficult problem, it must be suitable to the context of the project, and therefore testing is a human activity that requires a great deal of skill to do well.

The context-driven software testing methodology suggests for continuous and creative evaluation of testing opportunities. This approach of testing advocates testing in a way that conforms to the context of the project, rather than applying “best practice”. For context driven, a good tester should ask as many questions as possible to reveal not only parts of the context but enough of it to be able to act on the information. It is also a goal to do the best possible testing with the context given and be able to be proud of that work.

Why we need Context driven testing? Let’s see a scenario here. Most of the times, programmers are not given a proper well document that tells them exactly how to do the work they are to do.  But, they may have a spec that tells them what they need to do. But it is assumed they have brains so they are allowed to figure out the best way to accomplish the task.

Many of the other testing methodologies include a regimented document that is given to testers (test plan) with specific lists of actions (test cases) that many times are written so that any person can execute them. Here basically they don’t need any skill.  Here it can be assumed that the people executing the tests can’t be trusted to think, so everything they need to do to accomplish a task is documented for them; so long as they can read and push a button, they can test.

The context-driven approach of testing believes that testers are, and need to be, intelligent, thinking people, who can and need to be trusted to figure out how they need to test to accomplish a given goal.

Is Context driven methodology is same as agile process. If no, then what is the difference. Agile development models advocate for a customer-responsive, waste-minimizing, humanistic approach to software development and so does context-driven testing. However, context-driven testing is not inherently part of the agile development movement. Here it can be understood in a better way by taking an example.

Agile development generally relies upon extensive use of unit tests. But in Context-driven testing, testers will modify how they test if they know that unit testing was done well. Many context-driven testers will recommend unit testing as a way to make later system testing much more efficient. However, if the development team doesn’t create reusable test suites, the context-driven tester will suggest testing approaches that don’t expect or rely on successful unit tests. Similarly, Agile developers often recommend an evolutionary or spiral life cycle model with minimal documentation that is developed as needed. But many context-driven testers would be particularly comfortable working within this life cycle, but it is no less context-driven to create extensively-documented tests within a waterfall project that creates big documentation up front.

Ultimately, context-driven testing is about doing the best we can with what we get.

Here we can say there might not be such a thing as Agile Testing in the absence of effective unit testing, but there can be existence of context-driven testing even without unit testing.

Any techniques/principles we need for context driven testing? Context-driven testing is an approach/method, not a technique. But some testing techniques evolved in the Context-Driven Testing School which includes Exploratory and Gray Box testing. But some principles need to be followed for context driven testing.

  • The value of any practice depends on its context.
  • There are good practices in context, but there are no best practices.
  • People, working together, are the most important part of any project’s context.
  • It is not a testers’ job to demand documentation. Good testers work with the information they have, use unofficial documents.
  • The product is a solution. If the problem isn’t solved, the product doesn’t work.
  • The value of testing is determined by whether it provides useful and timely information (about the quality of the software).
  • Good software testing is a challenging intellectual process.
  • 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.
  • A tester is a customer advocate. Testers try to understand the customer position and make the best case when they feel it isn’t being address.

Basically, here our task as a tester is to do the best testing we can under any circumstances using more and more techniques we know, the more options we have available when considering how to cope with a new situation.


Written By: Debasis Arukh, QA Engineer, Mindfire Solutions


Posted on March 28, 2014, in Manual Testing and tagged , , , , , , , , , , . Bookmark the permalink. Leave a comment.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: