But BDD is really about developers!
That statement is true. To some extent. Yet software QA testing should not be considered useless. That may be one of any businesses primary mistakes.
What I mean is, yes, of course, developers do write step definitions and implement them into the behavior of the system. Then all may be effectively automated. So where is the place for testers you may ask? Well everywhere, actually. Such an approach just allows testers to be more focused on their primary task. Proper, well organized exploratory testing.
So here are the 5 tips that will help you with inputting QA testing in order to achieve proper (as much as actually is possible) software before the release date.
- It is important to fully understand BDD for a QA specialist. Realize that QA is drastically different from SCROOM or any other methodology of such sort. BDD is upside-down, so be prepared to use all your skills of finding and eliminating bugs before the code is written. The goal is not fighting bugs. The goal is a preventive strike. You will be identifying scenarios that are possible rather than dealing with some post production consequences.
In BDD any bug is a scenario that has been missed. Thus if something doesn’t work that means that it was not identified earlier. Being a QA is being the quality police officer with guns and badges and stuff during the whole project. You will be using ‘snitches’ of a kind. Well that actually is a metaphor, yet you will need to be pro-active. You will have to be obtaining information from every thinkable source in order to illuminate threats as early as possible.
- Be the interviewer in the specifications workshop. That is a great way of actually being pro-active and a splendid path of gathering information. Ask questions, discuss all the possible scenarios, and make notes. Be a detective. Or you are risking of missing lots of important issues and being left behind. Thus you can’t afford loosing time during such workshops.
The perfect scenario is when a tester is asking the business owners a reasonable and valuable list of questions and transforms the answers into acceptance tests. In here you will get a chance to use your mind to braking software before rather than after it is implemented. This might appear challenging, but you have all the chances once you put your mind to it. Plus here you will get assistance from the entire team. Such valuable opportunity is not to be missed.
- Learn from developers. Watch them at work. Understand the code-base. Even when solid feature files are written it is in no way the end stop. Keep track of how these feature files are being implemented (and try not to use too much foul language in the process). It might actually add more profit if you see how your code was refactored and organized. You can even try implementing new features or scenarios on your own if referring to step definitions that have been written by developers.
- Stop all the developers’ attempts of changing feature files. They may try to do so in order for the implementation to be easier for them. In any case and whatever the reason the feature file can not be changed unless the decision is pre-discussed and approved by the entire team as well as the business people.
- Every missed scenario is a missed bug. Never forget that. In order to avoid such happenings try keeping involved everybody you possibly can. One head is good, a team is victory!