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.
- 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.
- Stakeholder: Anyone who’s life is touched by your code.
- TDD build confidence of programmer, but BDD build confidence for Stakeholders.
- Acknowledges several Stakeholders
- Discussed acceptance criteria from outset
- Scenarios start as an enabling constraint to guide design
- There’s a difference between scenarios and automated testing.
- Scenario: tests what the general case is, how to gain confidence into that scenario, and what stakeholders have we not yet served.
- Acceptance tests: gains confidence other stakeholders (eg security, devops, stability etc).
- Cucumber was not designed for testing -it has bad logging, is removed from actual code (via steps), a good testing framework is near the action.
- Python is better for testing! (as it is still easily readable by non technical people).