So, if you believe you should use Context-Driven Testing in your project and such an approach is valid in your particular case, the following post is designed for you. Simply go through the following information and determine whether you already know all that will be noted before you get started with testing.
Context-Driven Testing Dogmas
- Each practice has a certain value. That value depends on context!
- Any project has vital parts of context. In CDT people working together are this most vital part of context.
- You can never predict a project’s unfold.
- If you are looking for a nice example of a solution look at the actual product under test. It will never work unless the issue is solved.
- There are no such things as best practices in existence. There are good ones, though.
- It’s not the method you use that brings you closer to victory, it’s your skill, your team, shared effort and collaboration that allow projects to succeed.
- Software testing is only good when it is challenging.
What may be gained from the above knowledge?
First things first. You, as a tester are working to add value to your project. You work on it and serve value to the project in general, not just its development part. You will literally have to walk in other people shoes. You must become the stakeholder for one session and the end-user for another. Those people have different expectations from the overall project and all those desires have to be satisfied. It’s not easy, but you are always free to have different groups of testers with different missions to ensure a clear sight on the general picture when all efforts are combined.
Here are several more tips you must always consider while in CDT:
- All metrics have to be valid, updated and useful, otherwise they present an actual threat to the project.
- Automation is not your silver bullet. It was designed to make testing easier, not to replace people. And it simply can’t replace humans, don’t even bother trying or fooling yourself with this belief.
- Use as much methods of testing as possible. Different approaches reveal different defects. One are vital to the development side, while others are a threat for business purposes or end-user experience.
Always remember that you are a tester and your goal is ultimate quality. Just do the best you can to achieve it and you are probably doing everything right.