Agile Testing – Context driven testing perspective
The context driven school of testing is a good representation of my personal normal state of mind when it comes to my profession. I really like to hang out with like-minded people that are outspoken about belonging to this community of testers. I also recognize many of the people within this community to be interested in and are practicing good Agile testing. When I started to write this post I also realized I gave it a shot 3 years ago, when I still hadn’t wrapped my head around context-driven. But although my knowledge and experience has changed a lot during that time I still think the post is valid in some sense.
Before continuing, read my previous posts in this series:
Agile Testing – Traditional testing perspective
Agile Testing – Agile perspective
Agile Testing – Programmer perspective
Agile Testing – Project management perspective
Context driven testers
Similar to the Agile movement, the context-driven school has a set of principles (http://context-driven-testing.com/), followed by explanations to them for clarification. Even this concept might give a never ending loop when it comes to the “there is no best practice principle”, when it is written in the definition which could be seen as the best practice of context driven (topic for another time). What the principles point out is the fact that for context-driven testers nothing is EVER written in stone, but can always be questioned to reveal more information. 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 an outspoken goal to do the best possible testing with the context given and be able to be proud of that work. These things actually overlap some with the software craftsmanship movement (also another topic).
Although testing and software quality is the main interest of the community, many of the context driven testers are also highly interested in other areas like systems thinking, epistemology, philosophy and the like. And surprise, these topics also have their own specialized communities.
It is very important for context driven people that quality decisions are made by “management” or “product owners”. The decision is at least never on the lone testers table. “I can tell you whats wrong, but now its hands off for me, since I am not being responsible at all for the reactions of the information in my test results.” This is one of many examples how even though people are criticizing the throwing-software-over-the-wall approach, context driven community still talks about and practices testing as though it is a sport of its own within software development projects.
There are plenty of things from context driven that relate to how good Agile works. The example I had in my previous post, where my colleague was asked to name the “explore > learn > adapt and then explore again” and he called it Agile, while I was in fact describing exploratory testing shows that to some extent. There is no standard answer to any question in this community, but I am quite sure that Exploratory testing is a good starting point when context driven testers are asked about what Agile testing is.
When it comes to test automation, its really just testing when created, and then its called checking. This is something that I know very many people outside of the context-driven community is having a hard time understanding or grasping. And when I have explained it to developers for example, they don’t really see the point in me trying to rename something they have been calling tests for many years. I know the value of having a good check suite that might fail on a commit, this means I can draw the conclusions myself that the newest software is not worthy my testing yet. There is good value in that, although are called unit tests by my developers.
A couple of years ago tried to explain the value of Specification by example/BDD/ATDD to some of the most prominent people within the context driven community, and I must say that these supportive ways of discovering gaps in communication before code is written did not really seem interesting at all. This is an example of proactive testing activity that I think is very important for successful Agile projects. However this and other pro-active test activities do not seem to appeal to the most extreme context driven people.
Context driven testing is a very tester/testing centric view of software development. As much as the context driven school has developed the craft of testing it still has the “reacting-after-the-fact” mentality. Doing “the best we can with what we get” (cited context-driven-testing.com) is a mentality I can’t do in projects. If something is wrong with how the project is run, I will make a change happen. It is everyone’s job to improve the situation of the project. A big part of this is test activities that support the whole team to being able to create better software in the first place.
- Exploratory testing is the first and only thing that comes into mind when asked about Agile testing
- You think quality decisions must /never ever/ be the testers responsibility
- You do not acknowledge quality to be a responsibility of the whole team
- No test results are ever good enough if they only consist of red/green or pass/fail information
- Your view of testing is highly based on re-active activities and thinking
Is it possible to perform good Agile testing? Will you be a support or a burden to any Agile team you are on?