Quality Assurance often has two sides. On the one hand, team leads always encourage us to be faster than the speed of light when we talk about feature delivery. On the other hand, QA's dream of spending less time on regressions and more time doing automation, non-functional testing, etc. Come along to learn the success story of how we gained time for interesting tasks by moving to flows with little or no manual QA, but still managed to save our jobs.

1. How we improved iOS delivery speed
from QA side
Kateryna Sprynsian ● 19.12.2018

2. About

3. About

4. iOS

5. Weekly releases including:
● 3 - 8 features
● 9 -24 bug fixes
● 3 - 9 technical tasks
iOS releases

6. ● Fast, faster, the fastest
● iOS Testing Mind Map
● QA=NO tickets
● Automation_QA=YES tickets
Agenda

7. Fast, Faster, the Fastest

9. The first word a child learns
is usually ‘ma-ma’

10. The first word of iOS features
team lead was ‘faster’

11. ● High reopen rate
● Small level of involvement into automation
● Manual regressions
What problems we tried to solve?

12. We decided to work harder on
our reopen rate

13. Profit
Ready for
release
2*Y
Takes only “X + Y” time to complete
A perfect world without bugs
Development
X
Testing

14. TestingDevelopment
Reopened and
waiting for a
developer
X Y Z
(unknown)
Reality

15. Context
switch and
bug fixing
A
TestingDevelopment
Reopen and waiting
for being picked up by
developer
X Y Z
(unknown)
(unknown)
Reality

16. Context
switch and
bug fixing
A
TestingDevelopment
Reopen and waiting
for being picked up by
developer
X Y Z
(unknown)
(unknown)
Reality
Waiting
in review
queue
B
(unknown)

17. Waiting
in QA
queue
Context
switch and
bug fixing
A C
TestingDevelopment
Reopen and waiting
for being picked up by
developer
X Y Z
(unknown)
(unknown) (unknown)
Reality
Waiting
in review
queue
B
(unknown)

18. Waiting
in QA
queue
Context
switch and
bug fixing
Retes-
ting
A C D
(unknown)
TestingDevelopment
Reopen and waiting
for being picked up by
developer
X Y Z
(unknown)
(unknown) (unknown)
Reality
Waiting
in review
queue
B
(unknown)

19. Time to master with 1 reopen
X + Y + Z + A + B + C + D =

20. X + Y + Z + A + B + C + D =
Time to master with 1 reopen

21. iOS Testing Mind Map

22. We decided to show developers a guide
for testing their own features - the
iOS testing mind map
Mind Map

23. It consists of 10 sections:
Mind Map

24. Section 1: Functionality
Mind Map

25. Mind Map
Section 1: Functionality

26. Mind Map
Section 1: Functionality

27. Section 2: User Interface
Mind Map

28. Section 2: User Interface
Mind Map

29. Section 2: User Interface
Mind Map

30. Section 3: Navigation
Mind Map

31. Mind Map
Section 3: Navigation

32. Mind Map
Section 3: Navigation

33. Section 4: Billing
Mind Map

34. Section 4: Billing
Mind Map

35. Section 4: Billing
Mind Map

36. Section 5: Statistics
Mind Map

37. Section 5: Statistics
Mind Map

38. Section 5: Statistics
Mind Map

39. Section 6: Network
Mind Map

40. Section 6: Network
Mind Map

41. Section 6: Network
Mind Map

42. Section 7: Automation
Mind Map

43. Section 7: Automation
Mind Map

44. Section 7: Automation
Mind Map

45. Section 8: Consistency
Mind Map

46. Section 8: Consistency
Mind Map

47. Section 8. Consistency
Mind Map

48. Section 9: Other
Mind Map

49. Section 9: Other
Mind Map

50. Section 9: Other
Mind Map

51. Section 10: Communication
Mind Map

52. Section 10. Communication
Mind Map

53. Section 10. Communication
Mind Map

54. The full picture
Mind Map

55. The full picture
Mind Map

56. The full picture
Mind Map

57. Do we really need to test ALL THAT?
Mind Map

58. Do we really need to test ALL THAT?
How much TIME would it take?
Mind Map

59. NO :) Only those parts that
may be applicable to your
ticket
Mind Map

60. QA=NO tickets

61. Tickets that go to master without being tested
by manual QA on any stage.
QA=NO tickets

62. QA=NO tickets

63. QA=NO tickets Feature branches with QA = YES

64. QA=NO tickets Feature branches with QA = NO

65. QA=NO tickets

66. QA=NO tickets

67. Automation_QA=YES tickets

68. Tickets that go to master without being tested
by manual QA on any stage, but are fully
covered with tests
Automation_QA=YES

69. Automation_QA=YES. The process

70. Automation_QA=YES. The process
Feature is chosen
1

71. Automation_QA=YES. The process

72. Automation_QA=YES. The process
Feature is chosen
Dedicated
QA assigned
21

73. Automation_QA=YES. The process

74. Automation_QA=YES. The process
Feature is chosen
Dedicated
QA assigned
21
Documentation
review
3

75. Automation_QA=YES. The process

76. Automation_QA=YES. The process
Feature is chosen
Dedicated
QA assigned
21
Documentation
review
3
Kickoff
4

77. Automation_QA=YES. The process

78. Automation_QA=YES. The process
Feature is chosen
Dedicated
QA assigned
21
Documentation
review
3
Kickoff
4
Test scenarios
creation
5

79. Automation_QA=YES. The process

80. Automation_QA=YES. The process
Feature is chosen
Dedicated
QA assigned
21
Documentation
review
3
Kickoff
4
Test scenarios
creation
5
Choosing level
of implementation
6

81. Automation_QA=YES. The process

82. Automation_QA=YES. The process
Feature is chosen
Dedicated
QA assigned
21
Documentation
review
3
Kickoff
4
Test scenarios
creation
5
Choosing level
of implementation
6
Feature
implementation
7

83. Automation_QA=YES. The process

84. Automation_QA=YES. The process
Feature is chosen
Dedicated
QA assigned
21
Documentation
review
3
Kickoff
4
Test scenarios
creation
5
Choosing level
of implementation
6
Feature
implementation
7
Functional tests
implementation
8

85. Automation_QA=YES. The process

86. Automation_QA=YES. The process
Feature is chosen
Dedicated
QA assigned
Documentation
review
Kickoff
Test scenarios
creation
Choosing level
of implementation
Feature
implementation
Code
review
& fixes
1 2 3 4 5 6 7 8 9
Functional tests
implementation

87. Automation_QA=YES. The process

88. Summary

89. We invested time in improving testing
from developer’s side ->
Our path

90. We invested time in improving testing
from developer’s side ->
Which led to better quality features in
branch QA
Our path

91. We invested time in improving testing
from developer’s side ->
Which led to better quality features in
branch QA
And we started experimenting with
QA=NO tickets
Our path

92. Firstly we had a few bugs with QA=NO tickets
Our path

93. Firstly we had a few bugs with QA=NO tickets
In a month or so we saw the first results -
huge time savings ->
Our path

94. Firstly we had a few bugs with QA=NO tickets
In a month or so we saw the first results -
huge time savings ->
We invested saved time into automation.
In a while the Automation_QA=YES concept
was tested
Our path

95. Result
1,5 years ago we had hardly any tickets
merged without QA

96. Result
1,5 years ago we had hardly any tickets
merged without QA
Now ~90% of features, tasks, bugfixes and
sub-tasks are done as QA=NO

97. Result
1,5 years ago we had hardly any tickets
merged without QA
Now ~90% of features, tasks, bugfixes and
sub-tasks are done as QA=NO
Not only we managed to deliver features
faster, but iOS QA team is now stronger in
automation as never before.

98. Thank you!
MIND MAPS: FOR FAST AND EFFECTIVE TESTING http://bit.ly/QAmindMap

99. Q&A