Ask who has done agile testing, who’s heard of it, who hasn’t
Who we are
what we will be covering today
Since many are not familiar with agile testing, I’d like to set the context – what is Agile and how is it different ( I think better). We’ll go over what I have seen on many teams that are starting to embrace agile – these are both technical challenges – how to accomplish agile testing, as well as organizational challenges – team and people issues. I’ll then outline what I have observed as keys to successfully moving the team to agile testing and becoming efficient and effective at short iterations and rapid releases
There are many different but similar agile methods. Some of them you might have heard of or about. They all focus on …
Underlines are what we’ll focus on today
Do Features- generalized – could be Stories, Use Cases, Other Requirements, Defects. We have the concept of Story Cards – the specification of the work to do, that is further elaborated by a UC, Req, etc Shows how features get done through multiple iterations leading to a release. At Rally, we have settled into 4 dev iterations, a 1 week hardening and Releases every 2 months or so. This also illustrates the Define, plan, iteration and accept rhythm that we get into doing agile development.
Within an iteration you definitely want to get into a good rhythm. There needs to be just enough elaboration ahead of time so that the team can accurately estimate dev, doc and testing tasks. An iteration planning meeting is held at the beginning to go through what is planned. The team then tasks out to get a detailed level of estimation. This allows the team to know what can fit into the iteration. Based on previous velocity, you can determine what fits. A rank order for the story cards gives the order in which a feature needs to be developed. The goal is to get the most you can but it is better to get some all over the goal line as opposed to working on all of them at once. In this illustration you would get Feat one developed, tested and accepted before moving onto the next feature. At the end you can go over the features and demo the results. You can also hold a retrospective to talk about things to change – to start doing and to stop doing
Let the fun begin!
Good to have mock-ups, Use Cases with main success scenario, a few Extensions, some other requirements that help to explain the functionality of the feature. Reality with 2 week iterations, there is minimal time to have the team review before the start. Further elaboration continues in the Iteration as Dev, Test and Doc start to examine what needs to be done. Further elaboration continues in the Iteration as Dev, Test and Doc start to examine what needs to be done.
Testing Architecture to Avoid at all costs
Evil rabbits Good News: The whole team became highly motivated to do it differently, and to find a better way
FitNesse it is the great bridge between Dev and Test, GUI tests and Unit Tests
Team needs to figure out what they want to try, what they want to fix, what they want to stay the same Don’t feel like you have to everything all at once. Can change some things, and not others. Just keep learning and adapting – hold retrospectives at least every Release to keep moving the bar Don’t feel like you have to everything all at once. Can change some things, and not others. Keep learning and adapting – hold retrospectives at least every Release to keep moving the bar
Synchronizing Software Testing with Agile Requirements Practices Jean McAuliffe, Dean Leffingwell May 2005
Agile requirements practices generally defer commitment to artifacts such as requirements until the “last responsible moment.” This challenges the test team to stay continuously synchronized with the product owners and developers as they have little lead time, if any, from the time requirements are available until the time the test artifacts must be in place.
This presentation describes the organizational and technical challenges associated with just-in-time agile requirements practices and techniques test teams can use to address them.
Popular Agile Methods Agile Rational Unified Process (RUP) Scrum (Ken Schwaber) Feature Driven Development (Jeff DeLuca) Crystal (Alistair Cockburn) Lean Software Development (Mary Poppendieck) Adaptive Software Development (Jim Highsmith) XP (Kent Beck) Dynamic System Development Method (Dane Faulkner)
No SRS-level waterfall documents to drive testing plan
Requirements and Test Cases developed in parallel or test first strategy
More Frequent Iterations, More Frequent Releases
Testing needs to happen Early and Often
Frequent to continuous regression testing
High need to automate nearly everything
Everyone needs to Test
Two Levels of Testing
Iteration Vs. Release testing patterns
Technical Challenges Requirements are changing fast. How does test keep up? Test early and often. How exactly do we move testing forward? Need to move off manual testing and more into automation. How does this happen? Different kinds of testing need to happen at different times. How do these get managed?