An updated version of my original QAI Quest talk

1. Chicago Code Camp 2014
Angela Dugan
Angela.Dugan@PolarisSolutions.com

2. ALM Practice Manager
Certified Scrum Master
ALM MVP
15 years in the software industry
8+ years as an architect, BA, PM, developer, and team lead
5+ years with Microsoft as an ALM evangelist
2+ years with Polaris Solutions as ALM Practice Manager
Shameless self promotion
Polaris Solutions- http://www.polarissolutions.com/
Chicago Visual Studio ALM User Group - http://www.chicagoalmug.org/
Twitter: @OakParkGirl, @ChicagoALM, @TeamPolaris
Blog - http://www.tfswhisperer.com/

3. Of course this has NEVER happened to you... Right?

4. 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

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. Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

7. 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
Requirements documents Just-in-time, informal requirements
Occasional “customer” involvement Frequent “customer” involvement
Start-to-finish Project Plan Plan for Sprint.
Details are sketchy beyond that.
Priorities shift based on new data.
Tasks are assigned Assigned tasks are a bottleneck
Potentially large team size Teams of 3 – 9 people
Multiple phases, eventual delivery Working software each Sprint / Iteration
Resistant to change Change is expected
Contract says what we build, deliver Contract is a lot closer to T&E

9. 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

10. 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

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

12. 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 end-
users
Management support can be difficult to achieve &
maintain, and it is CRITICAL for success!
Agile shines a light on existing dysfunction

13. Starting over is hard, and there is NEVER a good time to do it. 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 will always impact QA timelines.
QA may not be used to inspecting requirements and asking questions up
front.
Addition of new user stories at ANY point impacts EVERYONE. Include QA
to ensure appropriate commitments and estimations are built in

14. No more Magna Carta Requirements documents
Manual and exploratory tests created and managed in MTM
Test automation in VS (Unit, Functional, Web performance Load)
Load Testing in the Cloud
Automated CI builds
Lab Management
Rich bugs, OMG
Web tools
Release Management

15. Microsoft Test Manager
Exploratory Testing
Record and Playback Manual Tests
TFS Web Tools
Agile Planning Tools
Test Hub
Visual Studio
Cloud based load testing

16. Get your developers involved early and often in gathering feedback and
building quality into the product (TDD, unit testing)
Automate regression tests as soon as appropriate
Scenario based testing
Generate test case scripts whenever possible (from exploratory tests or
acceptance criteria)
Involve stakeholders in testing (UAT)
Adopt a good toolset to assist with collaboration and automation

17. Gartner’s “Magic Quadrant” 2012 Ovum Decision Matrix for ALM 2013

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.

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

20. Drive: The Surprising Truth About
What Motivates Us
Daniel Pink
Under $10 on Amazon
http://www.amazon.com/Drive-Surprising-Truth-About-
Motivates/dp/1594484805/

21. Agile Testing
Lisa Crispin
Janet Gregory
$40 on Amazon
http://www.amazon.com/Agile-Testing-Practical-
Guide-Testers/dp/0321534468

22. Visual Studio Team Foundation
Server 2012: Adopting Agile
Software Practices: From Backlog
to Continuous Feedback
Sam Guckenheimer
Neno Loje
$30 on Amazon
http://www.amazon.com/Visual-Studio-Team-Foundation-
Server/dp/0321864875

23. Agile Software Testing in a Large Scale Project:
http://www.slideshare.net/Softwarecentral/agile-software-testing-in-a-largescale-
project
Great Testing Blog: http://blogs.msdn.com/b/anutthara/
Another Great Testing Blog: http://www.clemensreijnen.nl/search.aspx?q=testing
Forrester ALM Blogs: http://blogs.forrester.com/category/alm
Load Testing in the Cloud:
http://blogs.msdn.com/b/visualstudioalm/archive/2013/11/13/load-testing-with-
visual-studio-online-launching-commercial-preview.aspx

24. Free ALM Images with HOL: http://blogs.msdn.com/b/briankel/archive/2013/04/17/list-
of-all-visual-studio-alm-virtual-machines.aspx
ALM Summit Video: Testing and Agile: The Team Approach -
http://channel9.msdn.com/Events/ALM-Summit/ALM-Summit-3/Testing-and-Agile-
The-Team-Approach
ALM Summit Video: Agile Testing: http://channel9.msdn.com/Events/ALM-
Summit/ALM-Summit-3/Agile-Testing
ALM Summit Video: Exploratory Testing: http://channel9.msdn.com/Events/ALM-
Summit/2011/Exploratory-Testing