How to organize qa process in agile speed
Upcoming SlideShare
Loading in...5
×
 

How to organize qa process in agile speed

on

  • 1,951 views

 

Statistics

Views

Total Views
1,951
Views on SlideShare
1,949
Embed Views
2

Actions

Likes
1
Downloads
33
Comments
0

1 Embed 2

https://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    How to organize qa process in agile speed How to organize qa process in agile speed Presentation Transcript

    • “How to organize QA process in Agile speed: Scrum and QA. Part II” Prepared by Svetlana Dubyk 06-07-2011
    • Agenda 1. Project and Team structure 2. What we do and how we work 3. QA activities in Scrum team4. Problems QA and Scrum team are faced to andways to solve them
    • Project structureKiev CopenhagenTeam 1 Product Owner BusinessTeam 2 Product Owner Product OwnerTeam 3 Core team Release managers
    • Team structure Kiev CopenhagenTeam ScrumMaster/ Product Owner PHP developerPHP developer PHP developer BusinessPHP developer PHP developer FrontendPHP developer developerPHP developer QA
    • What we do- Support a set of newspaper sites on differentplatforms- Make re-design/ re-factoring ofexistent functionality- Create new features, develop newprojects BOND
    • How we work What is the leght of the sprint? - Sprint length = 2 weeks; How often releases are pushed to live environment? - Releases are twice per sprint;What types of testing are done? - Functional testing; - UI testing; - Confirmation/ regression testing; - Smoke testing; - Acceptance testing;What is average length of the tasks? - The average length of the tasks/ tickets are 5 hours;
    • How we workWhat environments do we have?Different environments: - localhost; - labmanager environment; How often environments are updated? - demo (staging) environment; - live environment. - localhost/ labmanager environment are updated several times per day; - demo(staging) and live environment are updated twice per sprint.What browsers are supported? Supported browsers: - IE 7/8/9; - Mozilla 3.6/ 4; - Chrome; - Safari.
    • QA activities in Scrum team- Negotiation quality with the business;- Clarification of stories/ tasks/ tickets;- Make sure that acceptance tests verify the qualityspecified by customer; - Make accurate estimates for both programming andtesting tasks- State the alternative strategies, give a forecast of costs- Form an integral part of the continuous feedback loop- Help the team produce quality product
    • Problems QA and SCRUM team are faced to- Release issues (e.g. frequent releases)- Demo issues (no demo with business)- Communication issues- Sharing knowledge problems;- Tasks (tickets) are not described well;- Tasks are added after sprint starts;- No definition of Done (when to fix found defects);- No time to test all tickets from the sprint;- No time for regression testing;- QA work is not tracked in sprint;- Too large tasks;
    • Releases issues - Frequent releasesRelated problems: - Developers spend their time on tickets preparation and testing on demo (staging) and live environments twice per sprint. This effects team velocity; - QA spends time on tickets confirmation and regression testing on demo (staging) environment and live environment twice per sprint. - Hard to plan demo for business;Solutions: - Use separate branch for tasks that are made during sprint. Release tasks once per sprint; - Critical tickets release as fast tracks;
    • Releases procedure issuesRelated problems: - Release document is new each time; - Commit deadlines are new each time; - Staging environment and live environment are set up at different time each time;Solutions: - Create template for release document; - Assign person from the team responsible for communication with release managers;
    • Demo issues No scheduled demo with businessRelated problems: - No visibility for business what is done during the sprint; - No or late feedback from the business;Solutions: - Schedule demo once per sprint; - Plan demo scope with team and product owner in advance;
    • Communication issuesRelated problems: - Product owner dont see when the tasks are finished; - Product owner waits for answers from team members that are AFK; - Product owner doesnt get answer immediatly;Solutions: - Estimations for time left to finish the tickets are given on daily morning scrum and put into sprint backlog; - Inform Product Owner about impediments immediately; - Inform Product Owner when somebody is AFK; - Inform team members about questions from Product Owner; - Using of different means of communication: skype, email, gtalk, phone, “remote windows”;
    • Sharing knowledge problemRelated problems: - Documentation is absent; - Wiki is supported weakly;Solutions: - Sharing knowledge sessions are organized inside team and between teams; - Test documentation (test reports, test check ists, test cases) is created and shared to the team; - Add information to the wiki; - Add information to the respective tickets; - Create all documents as google docs and share them inside team;
    • Tasks/ tickets are not described wellRelated problems: - Tickets are misunderstood by developers; - Not all cases to be fixed are described in the ticket;Solutions: - Details from private conversations/ chats/ e-mails are added to the ticket; - Instructions how to set up environment are added to the ticket; - Tickets are viewed before/ on estimation session by the team. Ask for details in ticket description as early as possible ; - Create subtasks when additional information arrives and it needs time to fix - Instructions how to describe problem are created for the business ;
    • Too many tickets (tasks) are added into sprint after it actually startsRelated problems: - Added tickets into sprint are not estimated; - Priority are changed;Solutions: - Leave a buffer in sprint for tickets that will be added during sprint; - Assign 2 persons from team who estimate tickets during sprint; - After new ticket is added into sprint and estimated, discuss with Product Owner what should be unfinished/ out of sprint;
    • Definition of DoneRelated problems: - When to fix found issues on tasks in progress; - When task can be marked as Done;Solutions: - Add testing results into the ticket, create test reports; - Split tickets into several tasks (when new information is arrived); - Issues that wont be fixed before task is pushed to production are created as separate ticket; - Task is done when it is fixed and on pushed to production;
    • No time to test all tickets from the sprint Related problems: - No time for full regression testing (and no time for automation);Solutions: - Test tickets starting from the top of sprint backlog with Ready for test status; - Developers prepare each environment for testing; - Developers test their own tickets; - Smoke tests of supported sites on demo (staging) and live environment; - Use separate branch for developing new features/ fixing; - Developers test each other;
    • QA work is not tracked in sprint backlogRelated problems: - QA work is not visible to Product Owner;Solutions: - Estimated time for testing and time spent on testing are added into sprint backlog; Tasks are too large Related problems: - Not possible to finish task in time; Solutions: - Break down tasks into several tasks;
    • Materials usedwww.testingexperience.comHenrik Kniberg "Scrum and XP from the trench"http://www.slideshare.net/VLDCORP/agile-7905985http://www.slideshare.net/VLDCORP/agile-4134064
    • "Ever Tried. Ever failed. No matter. Try again. Fail again. Fail better." (Samuel Beckett, "Worstward Ho")"Testing a product is a learningprocess."Brian Marick
    • THANK YOU