Collaborative Testing: Why We CAN Have Nice Things. How to bring agile acceptance test driven development to the front of the development cycle

Transcription

1 Collaborative Testing: Why We CAN Have Nice Things How to bring agile acceptance test driven development to the front of the development cycle

2 ATDD and BDD sound great, but how does a team that is more used to traditional methods of development and testing make the transition? We ll talk about some practical steps to get there, plus some very important shared values that the team must posses before attempting this type of development. We ll talk about how this can be done in a greenfield project, plus how to evolve a legacy project under this type of test-first process.

3 Who we are Aaron Ruhnow Principal Engineer Jeanine Rust QA Architect

4 and where we come from Microsoft shop -.NET / C# Back office, services-oriented applications Agile-ish Some cross-functionality within teams Not in control of our release schedule Somewhat silo d teams

5 So Driven Behavior Driven Design (BDD) Acceptance Test Driven Design (ATDD) Build functionality incrementally Guided by expected behavior Focus is language and interactions used in development Build functionality traced to business goals Guided by tests written collaboratively by users, testers and developers Focus is early collaboration with business users

6 Testy Testy Testable Architecture We have a clear and distinct layered architecture UI layer contains some validation rules, but is mostly pass-through Business layer does all the heavy lifting Data layer merely sets and returns data there is as little logic as possible here Tools We test at different layers We use a SpecFlow wrapper around CodedUI tests to test through the UI Developers write unit tests in all the layers Here s the magic: we do acceptance testing at the business layer, too

7 Team Dynamics What you want Support from the entire team Cross-functional friendliness Openness to collaboration and experimentation What you don t Rigidly defined job expectations QA as a last step in development process Non-cooperative attitude Majority of team members spread across many teams Competing priorities

8 There s no such thing as a FREE test-driven process Acceptance testing requires investment you just don t get anything for free But would you rather have the tests drive the development, or have the tests only prove what was developed after the fact?

9 What s the point? This presentation is going to be focused on Acceptance Testing That does NOT mean that there shouldn t be UI testing, load testing, or any other testing

10 A Purpose Driven Life... The tests are a collaboration point for the team The tests are started before development begins on a story The tests help the team refine the requirements They help to know when development has reached a stopping point: passing tests The functional tests for this sprint become part of a regression suite next sprint

11 Greenfield Projects When you have the luxury of starting with a clean slate

12 This sounds bad Strangulation But it isn t. This is the concept of increasingly removing functionality from an existing system because it is being replaced in a new system. This allows the teams to write Greenfield code within the context of existing legacy applications M.Fowler s Strangler Pattern : Strangling Legacy Code by Mike Thomas:

13 Layered Architecture Separation of Concerns Keep each section clean and focused. Have business logic in the business layer not in the UI or the database.

14 Testable Layers! Testability is a Code Quality Layers are good, but if they are still coupled or hard to test, they don t do any good. Testing from the start proves the design is testable.

15 FULL Team Buy-in You ve gotta drink the koolaid The entire team has to be working toward the same goals, because doing something new is hard.

16 Tools Choose Wisely You want to standardize on one or two tools, to maximize efficiency. That way, you don t have to reinvent the wheel.

17 Start Simple, and Evolve Design the Process Start with the stories. Groom them as a full team, with everyone contributing. Then start to flesh out examples.

18 An Example Would be Handy Right About Now

19 Simplest Thing vs. Goldplating Tests ARE NOT Goldplating Do the tests first (acceptance test driven development)! When considering the work to be done for a story test automation needs to be a part.

20 Timing is Everything! Tests are written before and during development Sketch initial tests as a team. Flesh out the tests as more is discovered during development. Be sure the person responsible for the tests is not the same person who is coding the story.

21 Future Growth What happens next The tests that are originally written to test functionality become part of the regression suite. New tests are written as new code is written. These become regression, in a beautiful cycle.

22 Legacy Applications Sure it s ugly and no one knows how it was put together, but it works!

23 Step 1 - Get It Under Test Tests First! Before changing the application, whether that be refactoring, bug fixes or new features, first get it under test. This becomes your baseline and regression.

24 Step 2 - Find the Seam! It s not Unseamly In legacy applications, there is often a point in the code where you can send inputs and examine the outputs without changing the code. It may not be the top layer, but it should cover the most mission-critical parts of the code You may have to add a small wrapper to allow automation

25 Step 3 - Test the Hell Out of It With as few changes to the actual code as possible, write as many automated tests as you can, covering as many scenarios as you can think of: This is the safety net for refactoring It can also uncover insight into how the application really works and what it can and can t do These should be Agile tests run relatively quickly, red/green feedback to the testers and developers.

26 Step 4 - Refactor with Impunity Be Fearless Now you can make changes without fear of breaking anything (assuming you took the advice given in step #2).

27 That wasn t so bad, was it? You ve breathed new life into that crusty old application!

28 Questions?