1 / 14

Walking dead. How to save project?

Learn valuable tips and strategies to save a dead project, including preparation, test strategy, selective regression, manual testing secrets, automation management, risk management, and more.

sking
Download Presentation

Walking dead. How to save project?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Walking dead. How to save project? Walking dead. How to save project? PavloZhuk Senior QA Engineer, Intellias

  2. Agenda • How to start build process in the dead project • Preparation phase. Roadmap as tool of project management. • Test Strategy. What the expectation? • Selective Regression. Is it possible to run regression each sprint? • Manual testing. Secret in TC • Automation process. Manage of automation scope. • Risk management. How to choose correct quantity of QAs • Scrum as it is: stop improving process means lost a project.

  3. What means ‘Dead project’ ? • 450 bugs in backlog • 80% of blocked functionality • Unstable sprint scope • Unstable requirements. A lot of improvements to each story • 40% Pass Rate of regression

  4. Where to start? Definition of weaknesses and targets to achieve • Requirements scope for a few sprint • Broken sprint scope • QAs aren’t a part of a scrum team • Definition of middle/long term vision • Freeze code & Start of regression on 8 day of sprint • Regression results is too low Waterfall inside of Scrum: • Decide responsibilities of each position • Build process of preparation team

  5. Preparation phase. Roadmap. Target: build process with clear understanding of documentation. Prevent pesticide paradox for testing. • Remove all requirements that aren’t in scope • Create relationships between each issue type: Epic-Story/Task-improvement-bug-TC • Prioritization: New Scope vs Old fuck-ups (battle is started) • Prevent pesticide paradox

  6. Selective Regression. Is it possible to run regression each sprint? Selective Regression strategy which select a subset of the original tests for regression testing, have been proposed recently. Yet, the basic assumptions supporting selective regression testing have not been fully examined. The paper first introduces the notion of scope for change to represent the regression testing focus. • Definition of what should be in exit • Stable Freeze Code (8 day of sprint) • Run regression up to one day • All high priority bugs should be created in one hour • Fixes and verification on the end of 10 day of sprint

  7. QA process. Sprint responsibility

  8. Manual testing. Secret in TC Target: Small quantity of TC that will cover all functionality. TC contains steps that fully describe all related functionality. • TC should be created to Stories that are in status 'Ready for Sprint' • Each Story should contain only one TC that described flow of appropriate business need. • TC to separate Story should contain steps that described flow only separate Business need. Relation TC-Story one-to-many 3.1 In case if TC need some additional steps Pre-Conditions should be added. 3.2 Pre-conditions should contain a brief descriptions and link to TC that described flow of Pre-conditions 3.3 Pre-conditions shouldn't be tested in scope of TC during regression cycle • In case if TC don't contain steps to reproduce a new bug it should be updated • 'Change Request' should be linked to all Stories it's effect. TC should be modified to all effected Stories but not created to separate Change request.

  9. Automation process. Manage of automation scope. Target: Only stable requirements should be automated. E2E flows should be defined and automated FE automation • Scope of automated flows decide QA Lead • Stable functionality vs e2e flows • Marked steps that are automated BEautomation • In case if API TCs where updated automated Tests should be updated as well • New API should be automated • e2e flows

  10. Risk management. How to choose correct quantity of QAs Target: reduce resources (time&costs) without lost of quality • Automation vs Postman • Passive and active results of regression • Ignore of old mistakes means time&costs in future • Technical solution doesn’t mean the best solution. Let’s think about end users

  11. Regression. Do we have regression in one sprint?

  12. Scrum as it is: stop improving process means lost a project • TC should be created during requirement analysis • Let’s get back API automation • 98% Pass rate of regression is passive result. How to improve? • Selective regression is extra strategy • Let’s collect our documentation in Confluence

  13. Thank You! Questions?

More Related