The idea for this article came to me when I started working at a new startup, chous.ai. Since our manual and automated testing teams are merged, the question of unifying our test documentation became pressing. Since we use BDD in automation, I came up with the idea of bringing that experience to manual testing as well, replacing test cases with scenarios. Since I couldn't find any serious documentation on this topic in Russian, I wrote this article, which describes in detail how to apply the TDD and BDD approaches to the QA process.
Testing early, for example while the code is being written, was once an innovative idea, but it is catching on more and more, because it leads to a significant improvement in code quality. Write your tests in advance and you stand a chance of winning the "crystal star" of the galactic championship. Besides, being able to verify how the code works and debug it ahead of time undoubtedly speeds up development.
But even knowing all this, we are still very far from the time when writing tests before writing code becomes the common standard. Just as TDD became the next stage in the evolution of extreme programming (XP) and brought unit-testing infrastructure to the forefront, the next evolutionary leap was made from the level where TDD stands. Here, TDD evolved into its intuitive relative: behavior-driven development (BDD). But let's take things in order.
Test-Driven Development - TDD
Test-driven development (TDD) is a modern software development standard built on repeating very short development cycles: first you write a test that covers the desired change, then you write the code that lets the test pass, and finally you refactor the new code to meet the appropriate standards. Kent Beck, who is considered the inventor of this technique, stated in 2003 that test-driven development lets you be confident in the productivity of your code, which ultimately reduces the overall development time. When it first appeared in 1999, test-driven development was closely tied to the "test-first" concept used in extreme programming, but it later emerged as an independent methodology. At its foundation lies the unit test, a software procedure that can either confirm or disprove that the code works. The TDD technique is easy to picture with this diagram:
Now let me explain in more detail how this works:
1. A test is written based on the specification, mockups, and other source documentation. It is written for a program that hasn't even been written yet. If you run such a test, it will, of course, fail.
2. The programmer writes the code and builds the program, with the test serving as an indicator. As soon as the test passes, the code is done.
3. Refactoring. The test is finished or reworked as a result of changing requirements, and new parameters are added if needed. A feature is rarely accepted on the first try.
This cycle can repeat n times until the program reaches the desired state.
Behavior-Driven Development
Now that we've learned that modern development practices merge with testing to form TDD, TDD went on to evolve into BDD (behavior-driven development). By now these acronyms have most likely confused you, and everything has blended into one big BDSM.
But let's turn to the experts.
Matt Wynne, one of the developers of the BDD interpreter for the Cucumber Limited framework, conveys the essence of the technology like this:
"BDD practitioners explore, discover, define, and then deliver that behavior of the software, using conversation, concrete examples, and automated tests."
After a great deal of trial and error, teams came to understand that they needed an approach that would unite testers, programmers, product managers, business analysts, and customers, and give them documentation that everyone uses and understands. Let's see how BDD fits into the TDD cycle.
There is nothing revolutionary about the BDD approach. It is simply an evolutionary offshoot of TDD in which the word "test" is replaced with the word "should." Setting the words aside, many people find the notion of "should" more natural for the development process than the notion of "test." Thinking in terms of functionality (what the code should do) leads to an approach where you first write the classes that verify the specification, and those, in turn, can turn out to be a very effective implementation tool.
As you've already figured out for yourself, the BDD approach is about trying to find out what your client or business wants from the software before you start working on it. The first way to do that is to actually collaborate with those people.
Once we have that collaboration, we need to write down what we've learned in a way that makes sense to anyone who looks at it, so that anyone can come by later, look at it, understand it, and, if they want to, comment on it. To achieve this, we need to use a language everyone understands.
People often use the words "Given," "When," "Then," and "And" to build a chain of logical reasoning. So let's use these words as the keywords for building tests that everyone can understand.
So, our test document will be called a scenario, and it will use only keyword phrases for each step. At first we'll spell out what each one means, but after that we'll use only the English phrases. Our scenario will follow this structure:
GIVEN <context> Given <the context or initial state>
WHEN <event> When <an event occurs>
THEN <outcome> Then <the result>
How it works:
Given <I put the system under test into its initial state for the test>
When <I perform an action>
Then <I verify the result>
And now, an example:
GIVEN I am logged into the system as a user
WHEN I open the inbox
THEN I see the 20 most recent messages.
Thank you for your attention. You can find a fuller version of this topic in level 16 of the Galaxy QA Academy learning system. Access to the topic can also be purchased separately. To do that, contact us.
#TDD #BDD #QA2017 #AQA #qaautomation #SoftwareTesting #QAAcademy #TestingAndDevelopment #ModernTesting #ModernTestDocumentation