Let’s first understand what is Context-driven testing? Context-driven testing is a model for advancing and debugging computer software that takes into consideration the ways in which the program will be executed or is expected to be executed in the practical world. In order for this type of testing to be conducted successfully, software developers must identify the intended market and gauge the environments or domains in which the product will be employed by the people. There are seven primary or basic principles of Context Driven Testing, viz.

• The value of any practice depends on its context.

• There are no best practices in context but there are good practices.

• The most important part of any project’s context are the People working together in it.

• Projects unfold over time in ways that are often not predictable.

• The product is a solution. If the problem isn’t solved, the product doesn’t work.

• Good software testing is often referred as a challenging intellectual process.

• We are able to do the right things at the right times to effectively test our products only through judgement and skill, exercised cooperatively throughout the entire project.

Talking about the methodologies and technologies, there are no terms as such for Context-Driven Testing. Instead, it urges the right attitudes- Context-Oblivious, Context-Specific, Context-Imperial and Context-Driven.

• Context-Oblivious: Being context-oblivious is being unaware of the correlations between the way you work and the many facets of the context in which you work. A context-oblivious practitioner has knowledge of doing things, but can’t tell us the reason it’s done that way. This is typical of newcomers, of course, but also of experienced or knowledgeable people who do not like to think about methodology (a methodology being a set of methods; a method being a way of performing something).

• Context-Specific: Being context-specific is being suited to a context and to know that you are suited. You know what difficulties you face, and you find a solution to them. But those problems/difficulties don’t change, and hence you don’t need to fine-tune your solutions. It’s not difficult to believe that being context-specific is good enough, but beware: What if you unexpectedly are deprived of half your team, or a part of your testing get outsourced, or attributes of your product change extensively, or you have to remodel yourself to use a new tool. You may not have the choice of adapting to one context only.

• Context-Imperial: Being context-imperial is keeping your solutions the same while aiming to change the context around you to shape those solutions. A typical example is when a tester refuses to perform testing without a “complete specification” instead he should be learning how to test when he doesn’t have a spec. Another first-rate example is the typical testing consultant who affirms we should all use some Best Practice he has thought of. When it doesn’t give desired results, he says, we must not be using “engineering discipline” to follow the path to victory, or maybe we don’t possess “upper management support” to drive us do the right thing. The solution can’t be wrong, so the context must be.

• Context-Driven: The main concept in Being context-driven is behaving as if there is strictly nothing called as a best practice.We can only hope for better practices with reference to the context. Context-driven methodologists are very keen in learning about practices. They then decompose and recompose them to squeeze-in the situation at hand.

Context-Driven Testing vs. Exploratory Testing

Context-driven testing means that when planning testing on a project, choosing the practices, methods and so on.. in order to fit the context; choosing the approach.

While Exploratory testing is just a methodology, where testers explore a particular part of the application and dynamically plan and run test cases, possibly traversing new areas and new tests.

For more insights on Odoo and its related modules you can get in touch with us through sales@bistasolutions.com and write your inputs on this blog at feedback@bistasolutions.com