Tales From The World Of Java Development And Security

Agile Testing & BDD eXchange 2016 (Part 1)

A few months ago I had the opportunity to go to the Agile Testing & BDD eXchange 2016 conference (https://skillsmatter.com/conferences/7428-agile-testing-and-bdd-exchange-2016). I’ve finally had the chance to write up the notes I took (if any of the speakers are reading this and feel that I’m ‘stealing their lunch’ or infringing on their rights, please let me know and I’ll remove the offending content.)

The notes below reflect my own jottings down and interpretations, and not necessarily the views of the speakers.

Repeated Themes and Standout Points

Focus on concrete examples and outcomes rather than abstract user stories (See Dan North And Jenny)

Confirm scenarios with data and experimentation

BDD is for helping the team understand what a system actually should be doing, not for testing the system in detail (Dan North and other speakers)

Agile has become a ‘tribe’ and a buzzword, relying on certification and ‘one size fits all’ solutions rather than experience and good judgement.

User story mapping is a very powerful way of splitting your application into ‘open, mid and end game’ stages; this allows you to get confirmation at the early ‘opening’ stage (Jenny and Cosmina Bradu).

Agile lends itself to an Adhocracy, where action, experimentation and achievement is valued, rather than a meritocracy, where knowledge and mutual agreement are valued or a bureaucracy, where position and business hierarchy are.

Adhering to Agile, and sharing stories/scenarios, doesn’t meant that the team and stakeholders are sharing understanding. Test the shared understanding of your system.

A decoupled, modular, contract based approach to unit test, integration tests and acceptance tests is essential. The worst thing you can do is rely on many long integration tests that take hours to run, and test everything from the UI to the database. A suite of many, quick, single concern, isolated unit tests that take milliseconds to run, coupled with a few long integration tests is a much better way.

For mobile development:

Adopt a more server-side approach, similar to MVC, and separate the UI from the business logic, testing them separately; the UI is susceptible to much change, the logic not so much so you don’t want to tie them together (Paul Stringer).

Wireframes do not capture requirements.

Dan North

Testers feel left behind with Agile

BDD is a tester driven movement

Cucumber and BDD in general shouldn’t be used for integration/acceptance tests

BDD should really be BGD -Behavior Guided Development

BDD captures and constrains business scenarios, with feature files serving as a description of the systems behaviour.

After a certain point, you can throw your scenarios away. They should not be used for integration testing.

Definition of testing: increasing confidence of Stakeholders through eveidence.