The idea behind behavior driven development is that testers are able to verify the product, prevent bugs and reduce cost. Because the product is built using coding practices that put testing upfront in the process. This is supposed to accelerate deployment and maintain the quality of software products by allowing software developers engineers in test (SDETs) to build frameworks to verify the behavior defined by product owners and developed by software engineers.
So why is it that the more automated tests we build the more they fail, the more maintenance they have and ultimately creating noise in our quality metrics; reliability, maintainability, usability, security and so on:
Software engineers build software and are not particularly good at writing tests.
Product owners and manual testers do not read code they read natural language
The more the product evolves the more complex the testing framework the more likely the tests are going to require maintenance, overhead and refactoring.
Enter Specification Driven Development, (SDD), this methodology encompasses the development style working for your Team; BDD, TDD, spaghetti code, get stuff done development by any means necessary. SDD, is changing the way we think and execute development and testing and is only possible with the evolution of machine learning and artificial intelligence in the space of quality and test engineering.
Executing tests validates the expected behavior and when that behavior changes based on a new specification the test case changes so we test again. And if we’ve broken a test in our automation framework we have to code again. With SDD the execution of the testing IS what is building out the test suite for test automation and simultaneously validating the product specification all without building out an environment to have a test automation framework run where those automated tests typically won’t even be refactored until after the delivery of the new specification.
I cannot count the number of times I’ve been asked to test a deliverable but don’t have any documentation or just a couple words in a ticket, much less a test that is written by the engineer as a part of their BDD, not the unit test but an actual test that describes the required behavior for success.
There is no guesswork when using SDD, there is turning on the testing tool and starting your test, no need to stand up an environment, automation framework, create meetings to collaborate with business analysts, product owners and engineers to ensure that we’re automating the correct tests. Instead just start testing and reporting on the results of those tests based on the specification delivered.
In SDD product owners can read a test case just as easily as the tester or software developer, since they are written in a natural language and run as steps as the user would. This test methodology is agnostic to the development methodology.
Complex end to end tests are created as a manual tester validates the specification. In years past this was only accomplished by a quality analyst that ran the manual tests to work with an SDET to build automation around the parts of the end to end rarely covering a full end to end via test automation.
In SDD testers are able to verify the product, prevent bugs and reduce cost, faster Because the product is built as a software engineer does what they do best and build great software. SDD accelerates deployment and maintains the quality of our software products by allowing anyone to be a tester not just an SDET and a QA engineer because the tests are written in natural language and run the same way, (go here click here, see result).
Testing is agnostic to the engineering practice used to develop the product
The test can be read by anyone
No need for a complex environments and frameworks to support
Specification driven development is changing the why we think about delivering a product and the testing that goes with that. What happens when the product owner changes their product? In BDD all or the majority of the test cases are likely no longer useful until a refactor can take place so we end up with a lot of red, knowing that it will never go green. In SDD, your tester runs through the product re-writing the test automation as they manually test without a huge load on refactoring test code or changing the framework to match the ever changing product specifications.
With ML and AI taking over so many other areas in the software industry this is the natural next step in quality; having people that are good at what they do best, solving problems and allow the tools and software to do the rest.
