I’ve been working with BDD for years and felt that it needed an application that would facilitate the Behaviour-driven development work-flow. It would need to be made in a away that anyone can use it. By anyone I mean people with or without technical skills. Coders, testers, analysts, managers, business, etc. In that spirit, I started working on BDD Assistant. It is an open source application that can be used to create, manage and run BDD stories.
Now I feel that it is finally ready to go public. The application is far from being finished but there is enough done for the community to see what it’s all about. More information can be found in the BDD Assistant site. Latest release can be downloaded from our GitHub repo. Live demo (with some features disabled due to hosting limitations) can be seen from the BDD Assistant demo. Continue reading →
Behavior-Driven Development (BDD) is a process or it can be a tool. In many cases, BDD is both. However, it should not be a goal in itself. The goal of software development is to deliver quality as fast and as cheap as possible. The only real measure of quality is whether it fulfills user needs in a reliable manner. The best way we can take to accomplish that goal is through continuous integration, deployment and delivery. For the sake of this article I will ignore the differences between those three and refer to all of them as continuous integration or CI. Continue reading →
Documentation needs to be comprehensive, always up-to-date and accessible. By comprehensive I mean that it must cover all important areas of the code as well as all functions of the application. While importance of documentation is obvious to most, many struggle without success to have it accurate and up-to-date. Response to “poor” documentation is often assignment of more resources and more time. More often than not, documentation is created for wrong reasons.
When moving from the traditional waterfall process with manual testing towards BDD with automated execution of scenarios, one of the often asked questions is “how do you measure your test coverage?”. What it really wants to say is “we have high test coverage with manual testing, can you guarantee the same or more with the BDD?”. From there on usually comes the suggestion to transfer one-to-one manual tests to the BDD format. That’s not a good idea since the result would be less than adequate transformation to the different format without any tangible change. BDD is not only about automation but about the way we construct and deliver software.
Code Coverage Analysis
Main usages of code coverage analysis is to:
Find areas of software under test that were not exercised by a set of test cases.
Help in creation of additional test cases to increase the coverage.
Provide quantitative measure of test coverage as indirect measure of quality.
Identify redundant test cases that do not increase coverage
Since years, many software companies have their Quality department, which in many cases implies that they have the responsibility to assess the quality of the releases. This department is typically called QA department (standing for Quality Assurance), but I rather think that they are doing much more of checking releases than to assure the quality and I see a huge difference these two concepts, that is, between a QA engineer and a QC engineer:
QA stands for Quality Assurance, therefore an engineer that ensures the quality. Every time a new release is being built, the QA engineer ensures that the quality is built in it. The QA is responsible for improving the processes and participates actively in the creation of the testing tools.
QC stands for Quality Checking or Quality Control. This engineer typically waits for the release to be finished in order to check if the quality is built there. A Quality Checker typically creates a list of test cases based on the requirements themselves and puts them in a tool to plan each of the BTCs. Later he executes all the test cases, in most cases manually and tracks their execution.
Testing shows the presence, not the absence of bugs. Edsger W. Dijkstra
Two common types of testing are black-box and white-box testing. Both can drive or be driven by development.
Black-box testing (also known as functional testing) treats software under test as a black-box without knowing its internals. Tests are using software interfaces and trying to ensure that they work as expected. As long as functionality of interfaces remains unchanged, tests should pass even if internals are changed. Tester is aware of what the program should do but does not have the knowledge of how it does it. Black-box testing is most commonly used type of testing in traditional organizations that have testers as a separate department, especially when they are not proficient in coding and have difficulties to understand the code. It provides external perspective of the software under test. Continue reading →
The first 3 posts explored the process to define project requirements as behaviors. Once you have mastered writing BDD stories you are ready to start the journey towards the automation of scenarios.
Decision on which framework to choose should be based on which technology your team is most comfortable with, as well as the support it provides for the implementation of the phases described below. Next post in this series will provide comparison of different BDD frameworks.
Successful implementation of the BDD automation should be done in three phases.
You should start with the first phase. As soon as enough steps have been created to support the first scenario, you can start with execution of the other two phases. From there on, work on all three phases should be done in parallel.