Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

STLDODN - Agile Testing in a Waterfall World

Everybody seems to be talking about agile these days, but most companies are still using a waterfall based methodology. Often, the team delivering the code uses a different process than the team responsible for software quality. In this presentation, Angela will discuss which agile tenets are worth incorporating into your daily testing activities in this situation and the impacts, both positive and negative, that you should expect. You will learn tips and tricks for introducing agile concepts into a waterfall environment slowly and successfully; methods that incorporate not just application lifecycle management tools, but a look at strategies for process improvement and in some cases good, old-fashioned psychology. Join Angela to find that low hanging fruit you can address quickly to become more agile, understand how to recognize and mitigate common pitfalls, and learn tools and techniques for managing an agile-under-waterfall testing effort.

STLDODN - Agile Testing in a Waterfall World

3.
It is plan-driven, and plans are good right?
Pert charts, Gaant charts, Critical paths, OH MY!
Rules with an Iron Fist (A.K.A Microsoft Project)
Pre-defined Start Dates & End Dates
Teams operate in silos (Centers of Excellence)
It is not the devil, but it CAN be evil if its
prescribed techniques are abused

4.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

5.
Embraces uncertainty, software IS
uncertain
Empirical (based on experience and
observation)
Continuous improvement
“Forecast” rather than “commitment”
Self-organization and estimation by
the “do-ers”
It is not the devil, but it CAN be evil
if its prescribed techniques are
abused

6.
Daily standup INCLUDES people from multiple disciplines
Agile estimation leverages INSTINCT and EXPERIENCE to provide realistic
expectations and more confident forecasts
Backlog grooming focuses team’s efforts on customer’s current PRIORITIES
An iterative process fueled by customer FEEDBACK ensures the team delivers
the right functionality
A constant FOCUS ON QUALITY ensures that quality is built-in, not tested in
Retrospectives foster CONTINUOUS IMPROVEMENT by inspecting outcomes,
sharing of best practices and honing the process

8.
Waterfall
Agile
Test cases created from
Specifications
Acceptance criteria
Test cases are created
Manually
Manual
Automate stubs from acceptance criteria
Test cases are created
Up front
Started up front, continually refined
Time commitment
Large
Still a lot, but a huge improvement
Text execution is
Well defined steps
Some automation
Near end of project
Some defined steps
Scenario-based/Exploratory
Automation
Executed early, often, continuously
Tests executed by
QA Team
Everyone
Weaknesses
Documentation overhead
Regression often squeezed
Sensitive to change
Coordination can be challenging
Requires skilled automation resources

9.
More collaboration
Better overall visibility of status, progress, quality
Less bureaucracy to get in your way
Less impact from requirement churn
Testing is EVERYBODY’S concern, ALL the time!
Reduces resource bottlenecks
Less focus on output, more focus on quality
Everyone feels IS invested in the deliverable

10.
More meetings (kind of)
Less (perceived) accountability
Less (unnecessary) documentation
More requirement churn
Shorter runway for writing tests
May require a new “toolbox”

11.
Change is hard, and this could be a BIG one
FAR greater levels of discipline required by
EVERYONE on an agile team (yes, really)
Far more responsibility on Stakeholders and endusers
Management support can be difficult to achieve &
maintain, and it is CRITICAL for success!
Agile shines a light on existing dysfunction

13.
Agile testing starts with requirements (ATDD)
Continues throughout development (TDD, Unit Test Automation, CI)
QA validates delivered functionality every day (Scenario/Exploratory Testing)
Culminated with customers (UAT)
Testing is not a practice, it is an attitude!

14.
Teams may struggle to adapt to changes because significant effort has already
gone into the initial requirements development and testing a.k.a “Throwing good
money after bad.”
Engineers may not be used to being “responsible for quality”. QA should never
be testing code that has not already passed unit testing in the development
phase.
QA is still logically the last task in marking a user story done. Delays in
development tasks still impact QA timelines.
QA may not be used to inspecting requirements and asking questions up front.
Addition of new user stories into the current iteration impacts EVERYONE.
Include QA to ensure appropriate commitments and estimations are built in

15.
Collaborate: daily stand-ups should include
testers
Adopt a process (if it’s all ad-hoc today)
Adopt an integrated ALM tool (if you don’t have
one)
Shorten delivery cycles
Question anything that “smells”
Continuously improve, even if it is just the little
things

18.
Read what Forrester and Gartner have to say, then sh*t-can the reports and make your
own decision
Focus on tools that foster collaboration
Many tools can fit the bill, use what feels good
Best fit is not always “Best of Breed”
Tools can foster efficiency and collaboration
Tools cannot fix your people or process issues, they just automate them :-
Expensive tools and fancy practices are useless if they aren't supportive of the
approach you are willing to adopt.