Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Testing in Scrum

What, how and when we test in the Scrum process

Max Wenzin

on 27 August 2012

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Testing in Scrum

Process 21 Test
Strategy A subtask is completed and moved to "Test" OMG... how is this going to end!? The tester tests the sub-task... Ooooh noooo Tester FAILS the sub-task! How hard can it be? I will be done in 5 minutes... A developer picks a sub-task and starts working on it... Haha, this was so easy! Yep, we do this already... What's new? Sub-task is returned to "In Progress" and the fix-test loop continues until "Done" Product Owner is responsible for the Product Backlog Many Stakeholders contribute to the Product Backlog Product Backlog is... A prioritized TODO list Items in PBL are... Well-defined on top of list...
...and rough ideas at the bottom. Sprint Planning Meeting Team goes through top of Product Backlog and commits to the amount of work they think they can complete in a Sprint Estimations Are done by the TEAM The Product Owner is there to answer questions and possibly reprioritize Every PUSH to source repo will trigger ALL the automated tests to be run Jeez... good thing I am not a machine... A Continuous Integration machine near you... Hudson Dashboard Hudson job history Let's take a look at "testing" in the context of... Sprint Backlog Outcome of the Sprint Planning meeting is a... Sprint starts! Every day glorified Daily Standup
meeting I am going to start a new Story!

Let's all talk about it! Yeah! Let me help you
help me!

Let's make sure I can start testing today! into small pieces We break stuff down Sprint ends Sprint Demo DONE OK! Now this is DONE! Great!
What's your Definition of Done? "The definition of done is orthogonal to user acceptance criteria (functional acceptance) for a feature. It is a comprehensive checklist of necessary, value-added activities that assert the quality of a feature and not the functionality of that feature. Definition of done is informed by reality where it captures activities that can be realistically committed by the team to be completed at each level (feature, sprint, release)."
--Scrum Alliance
http://www.scrumalliance.org/articles/105-what-is-definition-of-done-dod What? Or... a DoD example: Designed
Improved UnitTest coverage
Test passed
Deployed to Test environment Another sub-task in the same story is picked up, worked on and moved to "Done" "Story A" Subtask A1
Subtask A2
Subtask A3
Subtask A4
Subtask A5 "Story A" Subtask A1
Subtask A2
Subtask A3
Subtask A4
Subtask A5 "Story A" Subtask A1
Subtask A2
Subtask A3
Subtask A4
Subtask A5 "Story A" Subtask A1
Subtask A2
Subtask A3
Subtask A4
Subtask A5 "Story A" Subtask A1
Subtask A2
Subtask A3
Subtask A4
Subtask A5 ? What about testing the whole Story? Tester tests
the STORY... Yep, this means we test the sub-tasks again, but now TOGETHER... Push often! Yeah, every day! Don't create
feature branches! Big merges - big problems! Automated test
FAILS in Hudson Shit. I should have run those tests locally first... "STOP THE LINE" Stop the line: Nobody is allowed to push new code that is not intended to fix the broken test
Everybody focuses on fixing the broken build/test Why? That sounds stupid and unproductive... Why? Because it's cheaper!
...and easier!
Quality Assurance Deploying to production more often helps to reduce the risk of any individual release;

When you deploy to production more often, you're practicing the deployment process more often. Therefore, you'll find and fix problems earlier (and hopefully in deployments to preproduction environments). Releasing Frequently Feedback from users
Reduce risk of release What is Continuous Delivery? What is quality? Code Coverage/Unit Tests Stop the line... helps us be able to release
on demand Credits to ThoughtWorks for graphic A couple of days before release... Focus on the release Remove unstarted stuff from Sprint Backlog Make sure we have Feature Toggles ...for unfinished stuff playtech.multi.currency.enabled=false
perform.stream.enabled=true service.properties Branch by Abstraction Use Application Interface Implementation New
Implementation Team demonstrates working software
PO approves
Stakeholder feedback Teams should be: Static
5-9 people
Co-located Real-world example Regression Testing Structured, using Test Cases Exploratory, using Release Games Manual Hey! The Demo is also a test!
Sort of... Release to production! The ultimate test... Canary Releasing ...or "Hidden Live Testing" A/B testing ...or "Multi-variant testing", "split testing", "bucket testing" But breaking down, and releasing gradually is better! Another scenario... Oh no! We have a serious bug in production! Let's fix it
and make sure it doesn't happen again! Ok, sounds great! TDD Test Driven Development First write a failing test,
then write code to fix the test. Bugs are perfect to get started with TDD! TDD will increase our test coverage, mainly on new code and bad code. Iterative Development Fail Fast UnitTests run faster than Selenium tests.

UnitTests are easier to maintain than Selenium tests. Thanks for listening!
Full transcript