FYI: My presentation on Behavior Driven Development (BDD)

In case you are in the Copenhagen area and are interested in learning a bit about the many benefits of Behavior Driven Development (BDD), I am doing a 2 hour presentation on BDD for Dansk IT on the 30th October 2012 and a second 45 minute presentation for the Danish Software Testing Board (DSTB), at their general assembly on the 22th of November 2012.

About the presentation:

This presentation aims at testers, business analysts, developers and project managers that want to collaborate better and in a way that improves quality, agility and project economics.

Main subjects:

• The communication gap between people of different professions using different processes, languages/notations, tools and skills.
• How increased co-operation between testers, developers and requirements specialists are key for improving quality, agility and to reduce costs.
• The agile method of Behavior-driven development (BDD) and how it relates to Test Driven Development (TDD).
• Executable specifications, stories and scenarios.
• Introducing BDD tool(s).
• Testability, test automation and acceptance testing

Testable software architecture in a nutshell

Many software architects concentrate so much on the customer’s  requirements/needs, that they overlook other key sources of requirements from the professionals that work on creating and delivering the project like developers, testers, designers, deployment/production staff etc. Forgetting to map their extra requirements can result in substantial project delays, poor quality, cost overruns and failed projects altogether.

In this posting I will concentrate on testing issues and provide a bit of practical advice on what a good architect should always keep in mind regarding testability. Thus enabling high quality of the solution and making sure professional testers and developers alike can be effective.

Most importantly, the architecture, design (and requirements) of the system should be made explicitly testable. As an architect you start out with the basics of good design like separation of concerns & being able to code/run/test/debug objects in isolation. Then you make sure you have also designed for:

• controllability: The degree to which it is possible to control the state of the component(s) under test before/after a test is run. Most importantly, a tester or automated sw test must be able to roll back changes in state, so that the test can be repeated (regression testing). This may involve designing a system providing additional transactions for tests, rollback scripts, new Api methods or gui controls to modify the system just for test purposes.
• observability: The degree to which it is possible to observe (intermediate and final) test results.  Most importantly, a tester or automated sw test must be able to inspect all relevant data/values/attributes in the system to evaluate if the test succeeded or not . This may involve designing a system with extra Api methods or gui controls just for being able to read or display state.
• automatability: The degree to which it is possible to automate testing of the component under test. Making sure a system is both controllable and observable usually goes a long way in enabling automate testing. But sometimes features in f.x. security/authentication  block the ability to automate testing. In these cases a separate “unsecure” mode may be needed for automated testing.

Note that designing for testability may seemingly contradicts user requirements – f.x. if the user specifies that one must never be able to delete a data item in the system and the controllability requirement insists that you make sure that all data items can be deleted. Here it is important that there is in fact no such conflict as the user requirements deals with the finished delivered system in production while the testability requirements are concerned with your development and test environments.