Why I talk about Context-Driven Testing?

Written by: Devender Sharma| 01 Apr, 2019| 3 MIN READ |1247
Why I talk about Context-Driven Testing?

As we know sometimes Testing Practices and Testing Techniques become very rigid and imitation based. So there must be some way by which we can easily shift our testing practices, techniques and even definition as per the circumstances or requirements. This is exactly Context-Driven Testing.

There can be different circumstances with every project we are going to deal with-

●    Requirements can be documented or not.
●    Enough time vs fighting schedules.
●    Tools Availability.
●    Clients Requirements.
●    Selection of best process for the project.
●    Trained employees’ vs untrained employees.
●    Time zone issues between the Development and Testing teams.

Suggested Read

Performance Engineering - Challenges, Benefits & Best Practices

Performance Engineering - Challenges, Benefits & Best Practices


The Testing team working on the Context-driven testing are going to select their testing objectives, techniques, and deliverables (contains test documentation); also find out the details of the specific situation, the wishes of the stakeholders, etc.

The utmost priority of it is about doing the best with what we are having in our pocket. In Spite of applying “Principal practices and industrial testing standards”, we can accept each and every different practice or even different definition which can work best under different circumstances.

 

Basic principles of Context-driven testing –

●    The actual return of any practice is directly dependent on its context.
●    In context, there are good practices but not best practices.
●    How people are working together is very much important.
●    Over time, project unfolds in many ways, which are often not predictable.
●    The product is a kind of solution, if the problem doesn’t solve, the product doesn’t work.
●    Good Software testing is challenging deep thinking and intensive reasoning task.
●    Can we do the correct work at the correct time to do productive testing of our products via appropriate judgment, skill, and unified work?

 

Some testers may favor life-cycle models and organizational models. Let’s consider the V-model; it is a kind of disjunction between Testing group and Development group, here the testing team demand for all code along with detailed specifications. Context-driven testing has no room for this kind of philosophy. Also, agile development is related to a particular set of values that belong to only one kind of context. Context-driven testing is far broader than that. Testers get what they get, and they know how to cope with what comes their way. More importantly, a tester is basically a customer advocate. Testers should try their best to understand the customer position and make the best case when they feel it isn’t being addressed.

So the final call will be before ensuing Context-Driven testing, we should ask our self –

●    Do we value more in individuals rather than their interactions over processes or tools?
●    Do we value more in seeing working software over documentation?
●    Do we value more in responding to change over following the plan?

Expert testers can better explore how the product should work from a user’s point of view, and identify and address barriers that prevent users from fully adopting or accepting the product.

Context Driven Testing is not for every organization, and it’s not a replacement for other forms of testing.