This document discusses implementing team wide testing to improve quality and reduce bugs. It describes current problems like developers feeling pressure to deliver code quickly without proper testing. This leads to bugs found later by testers, wasting time on rework. The team analyzed root causes like lack of test automation and testers. They decided to break down silos between developers and testers. The new process involves test-driven development, continuous testing, and demos at quality gates. While not all user stories were completed, the delivered stories had no bugs found by clients, showing the new process improved quality.
5. Tester A:
• Look at that bug; it’s pretty
straightforward that the
functionality doesn’t match
our test case. Why can’t
somebody do a quick smoke
test before checking in the
code?
Developer A:
• Well, yes I agree that’s a bug.
But we didn’t have enough
time, you know, the schedule
is tough, we did as much
verifications as we could
before we checked the 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 conversation
6. Tester B (Test Lead) :
• But that costs a lot, we
spent a whole day to
manually execute all the
functional test cases and
found at least 5 obvious
bugs. They could be
identified even without
looking at the test cases.
Now we need another day
for regression test after
your team gets them fixed.
Developer B (Develop Lead) :
• But that’s the reality, isn’t
it? It’s normal to have bugs.
We cannot avoid delivering
bugs together with the
code. That’s why we have a
testing team.
A real conversation
7. Find
A BUG
1 h 2 h 4 h 2 h
1 d
1 h2 d1 d0.5 d
AT LEAST 1 week
Fix
This Bug
Smoke
Testing
Generate
A Dev Build
Push
To Test
Bug
Verification
Regression
Testing
Push
To Staging
UATPush
To Production
Rework/Cost
16. 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
17. 80%
20%
• 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
18. Team decisions before kicking off
• Break the team silos – Team Wide Testing
• Do things right the first time – Create fewer bugs
19. Team
• Developers to be involved into all QA activities
• Let the only Tester organize the whole team
20. Process
• We don’t do waterfall
• We don’t do small waterfalls iteratively either
22. 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
26. 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
29. But for those stories we delivered,
the client couldn't find even
ONE BUG
30. Takeaways
A new Team Model integrates Developers and Testers
A new Lifecycle Model integrates Development and Testing
New Development activities driven by Tests
http://blogs.perficient.com/multi-shoring/blog/author/ehuang/
View my posts on Perficient official blog: