Explaining why we should move testing before implementation

1. TESTING
Move test planning before implementation

2. PREVIOUS WORKFLOW
Draft Feature Develop
Code
Review Deploy
P
E
Q
Implementation
Planning
E
P
E
Test
E
P
Assume 10 blocks for each team
Use case
Review

3. PREVIOUS WORKFLOW
Draft Feature Develop
Code
Review Deploy
P
E
Q
Implementation
Planning
E
P
E
Test
E
P
Assume 10 blocks for each team
Use case
Review

4. PREVIOUS WORKFLOW
Draft Feature Develop
Code
Review Deploy
P
E
Q
Implementation
Planning
E
P
E
Test
E
P
Assume 10 blocks for each team
Use case
Review
Every miss of target will significantly increase workload

5. WHAT ARETHETARGETS
• All use cases
• Implementation Plans and Code Review
• All test cases

6. WHAT MAKE A “MISS"
• All use cases
• Implementation Plans and Code Review
• All test cases
Engineers misunderstand requirements
“New” use cases after implementation
Engineers come up “new” ways to do tasks
Inevitable code refactoring
BUGS !

7. WHAT WE WANT
Accurate and Direct
Ideal case NEVER exists in real life
Human errors are everywhere
ACCEPT IT

8. INACCURATE and SHORT Review cycle
ACCURATE and SHORT Review cycle
INACCURATE and LONG Review cycle

9. LOWERTOTAL
DEVELOPMENT EFFORT
ACCURATE and SHORT Review cycle

10. HOWEVER
# of. Reviews
Resources
consumption
More accurate
Work
Resources
consumption

11. THE BALANCE
Extra workload
for reviews
Extra Workload
of a “miss”
BIG mistakes
Extra workload
for accurate work

12. WORKLOAD EQUATION
Extra workload
for reviews
Extra Workload
of a “miss”
BIG mistakes
- - = -ve
Extra workload
for accurate work
+

13. WORKLOAD EQUATION
Extra workload
for reviews
Extra Workload
of a “miss”
BIG mistakes
- - =
More
-ve
Extra workload
for accurate work
+

14. LET’S DO IT
If you agree to this concept

15. NEW WORKFLOW
MORE SCRUM
Draft
Feature Develop
Code
Review Deploy
P
E
Q
Implementation
Planning
E
P
E
Test
E
P
Use case
Review
Feature
Planning
E
P
Q
Daily Sync-up

16. FEATURE PLANNING
DEFINE ACCEPTANCE CRITERIA
P
E
Q
We want to
let the users set some
variations of a
product
How can we test
a variation is set ? Will
it affect the listing of
products?
We may need to
update our data structure
for this. It takes days
Acceptance
criteria

17. ACCEPTANCE CRITERIA
✔
✔
✔
✔
✔
✔
Task finished

18. ACCEPTANCE CRITERIA
Acceptance
criteria
=
Test case
MOST of the time

19. WHENTHETEST CASE IS
BORN
Draft
Feature Develop
Code
Review Deploy
Implementation
Planning Test
Use case
Review
Feature
Planning
Draft Feature Develop
Code
Review Deploy
Implementation
Planning Test
Use case
Review
Original
New

20. Draft Feature Develop
Code
Review Deploy
Implementation
Planning Test
Use case
Review
Original
1. Everyone has his own way to interpret “done”
2. All test cases are drafted just before testing
3. The test cases list is used in too few phases
WHENTHETEST CASE IS
BORN

21. Draft
Feature Develop
Code
Review Deploy
Implementation
Planning Test
Use case
Review
Feature
Planning
New
1. Cases are defined at Day 1
2. All parties can contribute to test cases.
3. Developers can review their works on their own
4. Have a standard way to mark down all the failure scenarios, the
development process can “learn” from failure
WHENTHETEST CASE IS
BORN

22. WHY “LEARN”
Avoid the same errors happen again.
At the same time, increase the test coverage

23. WHY “LEARN”
WHERETEST CASES COME FROM
Test case
Requirement Learn from Bugs
Expected Unexpected

24. WHY “LEARN”
HOWTEST CASES COME
Your face when you try hard toTHINK of something UNEXPECTED

25. WHY “LEARN”
HOWTEST CASES COME
Test case
Requirement Learn from Bugs
Expected Unexpected
LEARN
Last time UNEXPECTED, this time EXPECTED

26. WHY “LEARN”
THINK-TO-PREVENT IS NOT EFFICIENT
Prevention
Learn

27. NEW WORKFLOW
MORE SCRUM
Draft
Feature Develop
Code
Review Deploy
P
E
Q
Implementation
Planning
E
P
E
Test
E
P
Use case
Review
Feature
Planning
E
P
Q
Daily Sync-up

28. DAILY SYNC-UP
FAIL FAST
P
E
Q
Demo
The error
message seems not that
good. I would like it to
be….
There is no such a
criteria here. Let’s update it
When the user
login successfully…When
the user login fail…OK, I will
update it.
Learn
Make reviews more accurate

29. IT’S EVERYONE
RESPONSIBILITYTO STOPTHE
GROWTH OF

30. QA IS ALWAYSTHE
BOTTLENECK
Q
Testing is tooooo “SLOW”
Test coverage is tooooo “HIGH”

31. QA IS ALWAYSTHE
BOTTLENECK
Inevitably Slow
test steps
=
Growingly High
test coverage
x
Time spent
/
Q Q Q
Q Q Q
Expensive ResourcesWe want it to
be much higher
Tell me. How can it be small ?

32. QA IS ALWAYSTHE
BOTTLENECK
Q
AutomatedTest to help the scale-out problem.
Yet it needs more time

33. QA IS ALWAYSTHE BOTTLENECK
VALUES OF QA
Q
Draft test cases
Manage test cases
Monkey-testing
Run test case

34. EVERYONE CAN BETHE
MONKEY
P Q E

35. DETAILTEST STEPS
WHEN QA OVERLOAD (SHORT-TERM SOLUTION)
QQ Q
PE
E P
NEW
TASK
XMEANINGLESS
MEANINGFUL

36. DETAILTEST STEPS
AVOID OVERLOAD(LONG-TERM SOLUTION)
QE P
Well-written
test steps
Q Q Q Q Q
Q Q
Monkey testing
Implement
automated
testing

37. CODE REVIEW
Code review is like using pigeon post
E E
coooooo !

38. CODE REVIEW
PROBABLY BE MORE COMPLICATED
E E
Review done
PR
PR
Review done

39. CODE REVIEW
#. of re-review
Time spent for task
E
test your own stuff easily

40. CONCLUSION
The magic file. Our 1st step.