Format: Simulation, interactive presentation
Duration: 120 minutes
Abstract
Testing should be an integrated part of agile development. It is included in development of each feature to build quality into the software. One of the most radical changes in testing is, that it is no longer test engineer's territory, but a shared responsibility of the whole team.
In this interactive presentation we implement and test real features in front of the live audience. We simulate one sprint including planning, development, demo and retro. The focus is in testing activities. We develop with ATDD approach and demonstrate testing tasks, such as test automation, exploratory testing and non-functional testing. The participants will learn how to apply good agile testing practices by seeing a cross-functional team in action.
The purpose is to provide answers to the following questions:
What kind of testing tasks should be included in sprint?
How developers contribute to testing tasks?
How tester's contribute to non-testing tasks?
How testers and developers communicate?
How to handle tasks beyond functional acceptance testing, such as found bugs, exploratory testing and non-functional testing?
Detailed description
Timetable:
00-05 Introduction
05-35 Planning (Planning in ATDD style: decide features, specify tests, plan for testability)
35-105 Sprint: 3 * ~20min days (Daily scrums, Programming, test automation, bug fixing, Exploratory testing, load testing)
105-120 Demo & Retro
The idea is to demonstrate how to do things in practice and at the same time explain the concepts and ideas to the audience. Discussion and questions are encouraged. We write the code from the scratch in the session, but we have written the same code before the session to make it possible to implement the features smoothly in such short time.
We two act as a cross-functional team including a tester and a programmer. In addition we have separate product owner present all the time.
Introduction
The idea of the simulation, encouragement to discuss and comment, introduction of our Definition of Done.
Planning
We discuss & distill the features and define the test cases for test automation. Then we plan tasks for the iteration. Tasks include programming tasks, test automation, exploratory testing and performance testing. In discussion we consider also testability requirements.
Sprints
We implement the tasks as a cross-functional team. During implementation we discuss about the details of the tasks and do both testing and development tasks in pair. Bugs are found and fixed immediately to demonstrate fast feedback. Every "day" starts with a daily stand-up meeting.
Demo&Retro
We demonstrate the product to the audience and discuss about successes and failures. Audience will participate actively to the retro.
- We need two projectors
- Max 50 participants
Bios
Tiina Kiuru works as a QA specialist at Reaktor. During the seven years she has been working in software quality field she has had different roles ranging from technical test engineer to test manager. She has been a team member in several cross-functional agile teams. She also helps Reaktor's other teams to succeed in testing by training and participating in their testing activities.
Methodology Specialist at Reaktor Innovations, Markus has been in the industry for over nine years with experience from various technologies. Certified Scrum Master with extensive experience on agile methods and a long-time active participant in process improvement wherever he's worked at, Markus kick-started the local Coding Dojo events in Finland back in 2005. He is one of the pioneers of the Finnish agile community, speaks frequently at international conferences.
Comments (3)
Jul 21, 2009
Vasco Duarte says:
This seems to be quite an interesting session if you can pull it off in such a s...This seems to be quite an interesting session if you can pull it off in such a short time. Since the key of the session seems to be the actual discussion around tests (ATDD) as a way to "drive" what is done and how it is done in the session it would be cool if you could demonstrate this as an example of what a "pull" system would look like. Meaning: the testers get a card with the feature, then they discuss the tests with the developers, and each test (AT) is then a card for the developers to implement. Test driving the development could be seen as a form of (real) Kanban because you give the production schedule (ATs) to the last station in the value chain (testers) and they pull the work from the previous stations through visual cues (cards).
This may not be what you are looking for, but in my view it would be a very cool demo of what (real) Kanban can be like when done right (pulling value starting from the last station in the value chain).
There you go, now you got me interested in this session
Jul 31, 2009
Markus Hjort says:
Interesting suggestion. However, our main focus is in testing. Also, I do think ...Interesting suggestion. However, our main focus is in testing. Also, I do think we got enough submissions related to kanban anyway. I think there is lot of misunderstanding about what is the role of a tester in agile project. In this mini-simulation we show it in practice. Of course, people learn best if they can also participate. Unfortunately that is not possible in this short time frame. However, I have been in coding kata sessions and see that format works pretty well also.
Aug 03, 2009
Vasco Duarte says:
Your comment and the addition to the page help understand better the session.Your comment and the addition to the page help understand better the session.