The classy approach to 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. In order to successfully conduct this type of testing, software developers must identify the intended market and evaluate the environments in which people are likely to employ the product.
Context-driven software testing is a set of values about test methodology. It is not itself a test technique. To be a context-driven tester is to approach each testing situation as if it were unique in important ways, and to develop the skills to react to situations with a broad and deep awareness of problems in projects and possible testing-related solutions to those problems.
Listed below are a few basic principles of context driven school
- The value of any practice depends on its context.
- People, working together, are the most important part of any project’s context.
- 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 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.
Best practices are a set of rules or guidelines that have consistently shown superior results for a practitioner. Take a look at the best practices of context-driven testing:
Have an unquenchable curiosity.
Asking questions is one of the major concepts that the context-driven testers throw light on. Ask questions of stakeholders. Ask questions of the development team. Ask questions of your fellow testers. Without asking a slew of questions it’s extremely difficult to understand the context of a project, which in turn makes it very difficult to obtain maximum test coverage. Asking questions is the best way to have an interactive session. This helps in a lot of learning – freshers from mentors and at the same time mentors too can brushen up their basics by the freshers. The most successful and known testers are those who have an unquenchable curiosity and are able to spread the knowledge they’ve gained over the years to those around them.
Share your test plan with the team – it helps!
The best reward of having knowledge is to impart it to others, this way knowledge never goes for a waste. There seems to be no logic in gaining knowledge all by yourself without sharing with those who need it and, sharing is the most efficient use. Creating and sharing your test plan with the rest of your team and project stakeholders not only makes you more efficient, it builds rapport with the rest of the company and spurns more meaningful conversations. It is not mandatory that you run here and there to take feedback from each and everyone involved in the project but sharing your initial test plans with the most prominent stakeholders gives them real insight into the type of return they should expect to see. This leaves a positive impact on them that there are some guidelines to what your team is following, and that any changes in their own plan will impact the testing strategy.
Have a flexible approach.
Not necessary all plans work as expected, this happens very rarely. If such a thing happens, be on the move to accept changes and implement them. Failing to be at least somewhat flexible with your test strategy will likely lead to all around frustration and less thorough test coverage. Schedules change, features are added, new priorities arise, and your strategy should adapt accordingly. At the same time, if you have shared your plan with the stakeholders, don’t be too pro-active to make up for mistakes at the initial stages of the project. Not to forget, your ultimate goal is to achieve the maximum test coverage given the parameters at hand. If those parameters change through the course of the project, it will not leave a good impact on you and on the organization because the plan no longer serves that ultimate goal.
Leave powers for the Stakeholders.
As testers, we can’t not take all the powers, the stakeholders have the power and thus the responsibility, for deciding what timeline everyone on the project is working toward. This is their job and no tester can define or redefine any deadlines as per their convenience. As testers, your job is to meet the deadlines, test the software thoroughly within the limitations laid down by the stakeholders and to give them all the information/result they desire.
Keep a check on applying your applied practice.
This might be considered as one of the most important stone on which the context-driven ideology is based. There are times when the testers will not be able to get answers from their project managers, at times the project is at such a stage that no one has ample amount of time to prepare a descriptive plan. In these times it is advisable to sit back and watch the stakeholders play their role no matter whatsoever decision they make. To be on the safer side, play your role best with all the details you have for the project.
It is very certain that best practices especially in context driven testing are not ideal for every scenario. However, best practices can help to serve as benchmarks for any given project.