Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Shift left as first transformation step into Quality Assurance

417 Aufrufe

Veröffentlicht am

Do you work in a company which has established effective testing process, which ensure high quality and support Agile methodologies? Can your testing process be used as a model for other companies? Fortunately, we were in that place a few years ago and had to ask ourselves a question about the next step. The answer was: Let’s be Quality Assurance Engineers rather than Testers. But what should we do? How can we do this transformation?

At the same time, I got feedback from my colleague – Head of Java practice: “Your testers found defects in areas / scenarios which weren’t included in development scope / my devs didn’t know that should cover those edge cases. What can we do with that?”

I had to agree with him. There is no sense to test scenarios which weren’t implemented. This was the starting point of our transformation. We decided to implement Shift left model as it looks like the most promising one. But when we implemented it not everything worked as smooth as we wished. New challenges appeared, but more in my presentation.

Veröffentlicht in: Ingenieurwesen
  • Your wife will never find out! .. Just send me a message and ask to F.U.C.K. ■■■ http://t.cn/AiuWSRdj
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier
  • I made $2,600 with this. I already have 7 days with this... ♥♥♥ https://tinyurl.com/realmoneystreams2019
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier
  • I went from getting $3 surveys to $500 surveys every day!! learn more... ●●● https://tinyurl.com/realmoneystreams2019
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier
  • Gehören Sie zu den Ersten, denen das gefällt!

Shift left as first transformation step into Quality Assurance

  1. 1. Shift left First transformation step into Quality Assurance 1
  2. 2. Intro 2
  3. 3. Agenda 3 01 Context 02 Test-based process 03 Introducing shift left 04 Mindset switch 05 Summary
  4. 4. Context ▪ Project-based company ▪ Mostly Web, where the center of the galaxy are Content Management Systems ▪ Delivered by Adobe or Sitecore ▪ Which are Customizable ▪ And Integrated with everything (even black hole) ▪ In addition, we do Digital Transformation of our clients 4
  5. 5. Testing process principles ▪ No test case managment, no reporting, … –No test managers ▪ Testing process inside of feature development –Task flow ensures that each task is tested –Easy to visualise ▪ Task status is connected with test status ▪ Exploratory testing, –Extended by Session Based Testing idea 5
  6. 6. Test process as workflow 6
  7. 7. Acceptance criteria status 7
  8. 8. Testing process achievements ▪ Task reject ratio below 50% ▪ Which means that each task is tested two times: –Rejected, defect raised, back to dev for fixes –Retested and Accepted ▪ The above testing process works very well for Scrum and Kanban –Allows to avoid mini waterfall trap 8
  9. 9. Ping pong is sport not development methodology Reject ratio metric ▪ Reject - task moved from Testing in progress to Reopen state ▪ Accept - task moved from Testing in progress to Resolved state 9
  10. 10. CALM before the storm ▪ Stabilization (it’s boring when there are no changes) ▪ Trends & Fashion - more and more discussions about Quality Assurance vs Testing 10
  11. 11. Internal feedback Your testers found defects using scenarios which weren’t included in development scope or my devs didn't know that they should cover them. What can we do with that? 11
  12. 12. TDD The new meaning of Test Driven Development 12
  13. 13. Shift Left principles ▪ Agree scope of test beforehand ▪ Discover requirement issues and gaps early ▪ Discover impact of change ▪ Share with developers how story should be tested –Empower devs to do testing work ▪ Identify and minimise duplication in testing ▪ Minimise “Won’t fix” issues ▪ No excuse ;-) 13
  14. 14. QA activities inside software development lifecycle 14
  15. 15. Impact on project resourcing 15
  16. 16. Shift Left Activities - Prior to project start ▪ Project Plan assumes QA & Testing activities as part of the project scope ▪ QA Plan which contains activities executed by all team members – Cross-practice cooperation 16
  17. 17. Shift Left Activities - before The first line of code ▪ Requirement Testing –Before sprint –3 Amigos –Backlog Refinement –Completeness & common understanding (Developable and Testable) –Do not be afraid to extend Acceptance Criteria ▪ Test Hug / Test Ideas –How can I help you deliver the feature? –QA - dev meeting inside sprint, before coding starts –Do not forget about feature architecture –How the feature should be tested? –List of test ideas 17
  18. 18. Shift Left Activities - are we done? ▪ QA Demo –Dev demos feature for QA Engineer (other team members are welcome) –Demonstrate what feature does and doesn’t –Demonstrate how feature was tested –Talk about edge cases –What’s next? – Does feature require additional testing? – If yes, what should be tested? – If not, are we done? 18
  19. 19. Selfreject http://bit.ly/thebesttestingever 19
  20. 20. There is always someone to save your skin ▪ Old workflow implementation: –Action for developer: submit to testing / QA. –Task statuses: Waiting for Testing, Testing in Progress. –Summary: our workflow said to send task to someone else to execute an action (in our case testing) ▪ Developers reception: Why should I spend my precious time on testing if there is always someone else who did it? 20
  21. 21. Change the mindset - Confirm your work ▪ Why statuses and buttons (actions) say what I have just done, not what action is required next? ▪ Actions are the confirmation of your work, –Implemented & tested on feature branch, merged to integration branch, sanity tested / automated tests passed. ▪ Workflow status describes the actual status of task on board from business perspective (what has been done so far). 21
  22. 22. Acceptance criteria status - restore responsibility among developers 22
  23. 23. Be lean ▪ Why makes you decide that story is DONE and is not going to be tested after QA demo? –Restore the responsibility among developers –Less duplication in project –It takes time to build trust between Dev and QA 23
  24. 24. Reminder: Test process 24
  25. 25. Quality Assurance process as a workflow 25
  26. 26. Standardization trap ▪ Standardization process –Create process from scratch for each project –Gather best practices, which comes bottom - up –Set those best practices as standard –Start project with standard process and customize it for your need ▪ Result: –People lost freedom because official standard appear ▪ Why? – Nothing new, all best practices used in projects earlier – Just new starting point – They still has a freedom and can change standard – But each changes need a reason 26
  27. 27. Unexpected reward ▪ Reject rate only about 10% ▪ Continuous Delivery approach introduced in our project very smoothly 27
  28. 28. Summary Transformation to Quality Assurance is not only about the introduction process but mostly about change in our minds. 28
  29. 29. 29 Thank you

×