Presentation is loading. Please wait.

Presentation is loading. Please wait.

Walking dead. How to save project?

Similar presentations


Presentation on theme: "Walking dead. How to save project?"— Presentation transcript:

1 Walking dead. How to save project?
Pavlo Zhuk 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 US (PO) Requirements (BA) Review Requirements (QA Lead) Design (UX) Technical review (Tech Lead) Grooming Backlog

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 TC Bug Improvement Story/Tasks Epic

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
Manual QAs Automation QAs Create/Update TC to all sprint Stories/Tasks Execute Testing by finish of development. Create Bug Reports. Story/Task is verified by fixing all medium/high priority issues Run regression cycle Update all tests with new APIs Creation new tests for stable FE/BE Create Smoke Test Design for Prod env. Run Tests during regression QA LEAD Creation Release Notes for previous Sprint Review and set priorities for existing Bug Reports Review all blocked functionality Review Stories for future Sprints Review TC (OR NO?) Create new Regression Cycle . Regression cycle scope: All FE automated tests BE automated tests API manual tests All Sprint related Manual TCs

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 BE automation 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?
Freeze code on 8 day of sprint Backend Postman API collections E2E as highest priority Frontend 200 hundred of automated test E2E flows as highest priority Manual tests

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?

14


Download ppt "Walking dead. How to save project?"

Similar presentations


Ads by Google