全民QAAn IntegratedDevelopment and Testing Lifecycle Ethan Huang
黄方 (Ethan Huang)
It’s about DEVELOPMENT
A real conversationTester A: Developer A:• Look at that bug; it’s pretty • Well, yes I agree that’s a bug. straightforward that the But we didn’t have enough functionality doesn’t match time, you know, the schedule our test case. Why can’t is tough, we did as much somebody do a quick smoke verifications as we could test before checking in the before we checked the code code? in; but we didn’t have enough time to cover that functionality. It’s great that the testing team found that bug, we can fix it later.
A real conversationTester B (Test Lead) : Developer B (Develop Lead) :• But that costs a lot, we • But that’s the reality, isn’t spent a whole day to it? It’s normal to have bugs. manually execute all the We cannot avoid delivering functional test cases and bugs together with the found at least 5 obvious code. That’s why we have a bugs. They could be testing team. identified even without looking at the test cases. Now we need another day for regression test after your team gets them fixed.
Rework/Cost 1h 2h 4h 2h Find Fix Smoke Generate Push A BUG This Bug Testing A Dev Build To Test AT LEAST 1 week 1d 0.5 d 1d 2d 1h Push UAT Push Regression BugTo Production To Staging Testing Verification
And this conversations ishappening everywhereon this planet…
Why can’t we do things right the first time?
What does Do?
The REALITY• 6 Developers : 1 Tester• Non-structured narrative requirements• Huge amount of legacy functionalities• Few tests automated• 13 weeks to deliver
The PROBLEMAfter the planning the whole team wasfeeling upset because of the predictableBAD QUALITY
Team did root cause analysis
Team did root cause analysis• 1 Tester cannot complete all testing work• We might have to shrink testing phase• Big, complicated features - long Dev cycle needed to deliver one feature• Huge Regression Testing effort needed to cover legacy features as well• Has no Requirements details , only mockups• Don’t know what details to implement/write test cases• Lots of dependencies – hard to test
Team did root cause analysis - voted• 1 Tester cannot complete all testing work• We might have to shrink testing phase 80%• Big, complicated features - long Dev cycle needed to deliver one feature• Huge Regression Testing effort needed to cover legacy features as well 20%• Has no Requirements details , only mockups• Don’t know what details to implement/write test cases• Lots of dependencies – hard to test
Team decisions before kicking off• Break the team silos – Team Wide Testing• Do things right the first time – Create fewer bugs
Team• Developers to be involved into all QA activities• Let the only Tester organize the whole team
Process• We don’t do waterfall• We don’t do small waterfalls iteratively either
A newV Model
Activities• Represent Requirement using UAT Cases• Write Automation Tests before development• Test Driven Development• CCR + Local Verification• Check-In, CI + Continuous Automated Testing• Daily Verification/Daily Demo• Do UAT every Iteration
Break feature down to small stories
Every single storyis a developmentcycle
Every Sprintdelivers some stories
Two Quality Gates• Represent Requirement using UAT Cases• Write Automation Tests before development• Test Driven Development• CCR + Local Verification - Quality Gate 1• Check-In, CI + Continuous Automation Testing• Daily Verification/Daily Demo - Quality Gate 2• Do UAT every Iteration
What we achieved12 Sprints for Development,1 Sprint for Testing
What we achievedWe didn’t complete all the User Stories
But for those stories we delivered,the client couldnt find evenONE BUG
SummaryA new Team Model integrates Developers and TestersA new Lifecycle Model integrates Development and TestingNew Development activities driven by Tests