Abstract: There has been a great deal of talk about the role of testers especially in agile teams. With many people questioning whether there really is a need for professional/dedicated testers in agile. Large amounts of effort and discussions have taken place regarding the use of 'automation' to replace manual testing and how testers can be replaced by this in agile teams.
During this session we will discuss some of these, and other, common misconceptions of testing and testers by means of audience participation to see how many of these misconceptions/myths are prevalent in the software testing industry.
Some examples of this include:
Testing is a bottle neck
Testing happens at the end of the sprint.
We do not need to test we can get our users to test it.
We then look at what happens during a typical software development iteration, with a focus on the software testing activities. We will discuss the problems with automation and why it may not be the 'golden goose' that is typically promoted as being able to replace testing. The discussion will introduce the test execution model and show what can and cannot be automated. The test execution model will introduce the concepts of tacit and explicit knowledge and looks at what we learn from philosophy. As part of this discussion/debate we will look at what is it that makes us unique as human rather than as automatons.
Following this we will focus on what the future holds for testers and that path they can follow. We will look at different roles that a tester can take responsibility for in agile teams, roles that utilize the unique skills of testers. During the talk John will introduce roles such as quality advocate and testing coach and draw from his own personal experience how these roles can be incorporated into agile teams. At the end of the talk as a group we will create an action plan of ideas we want to take away and trial within our own agile teams to show that testing is far more than ticking boxes.
Learning Outcomes: - The future role of testers will become more flexible and adaptive
- Not everything can be automated nor should we automated everything we can.
- There will be less hands on testing and more supporting/consulting.
Attachments:
