Når det handler om at levere hyppigt uden at gå på kompromis med kvaliteten, så kræver det en teamindsats. Det dur ikke, at udviklerne bare koder løs, og derefter regner med at andre, måske endda et helt andet (test)team, sikrer at alt er ok - både før og efter ændringerne er kommet i produktion. Udvikling og kvalitetssikring skal gå hånd i hånd, men som udvikler ved jeg, at det kan være en udfordring at få til at ske i praksis, da vi udviklere kan have en tendens til hellere at vil skrive kode end at hjælpe med at teste det vi lige har lavet. Men det kan lade sig gøre! I dette oplæg vil jeg komme med eksempler fra hverdagen, på hvordan vi får det hele til at rulle på skinner. Hvordan gensidig respekt mellem forskellige roller, og bedst udnyttelse af hinandens kompetencer, spiller sammen med den automatisering, der er en væsentlig parameter for at få det hele til at lykkedes.

1. Kvalitetssikring i et high performance team
DSTB Årsmøde, 2015

2. ebay Classifieds, Denmark
• DBA, BilBasen og BilInfo
• Mobiludvikling
– DBA og BilBasen
– iPhone, iPad og Android
2

3. 3

4. Organisering
4

5. Organisering
• 3(,5) iOS udviklere
• 1 arkitekt (DBA platform)
• 1 backend
• 1 QA ekspert
4

6. Organisering
• 3(,5) iOS udviklere
• 1 arkitekt (DBA platform)
• 1 backend
• 1 QA ekspert
4
• Produktejere
• UX/Design
• Andre interessenter

7. High performance team
5

8. High performance team
• Åben og ærlig kommunikation
5

9. High performance team
• Åben og ærlig kommunikation
• Samarbejde og innovation/kreativitet
5

10. High performance team
• Åben og ærlig kommunikation
• Samarbejde og innovation/kreativitet
• Samme værdier
– Høj faglig stolthed
– Respekt for hinanden
5

11. High performance team
• Åben og ærlig kommunikation
• Samarbejde og innovation/kreativitet
• Samme værdier
– Høj faglig stolthed
– Respekt for hinanden
• Leverer
– Til tiden / forudsigeligt
– Konstant høj kvalitet
5

12. iOS releases 2014
6
5.2.1
3.53.3.1
3.2.3
3.2.2
3.1.1
JAN
DBA versioner
BilBasen versioner
FEB MAR APR MAY JUN JUL AUG SEP OCT NOV DEC
3.0.1 3.1 3.2.1 3.4 3.4.2
5.0.3
3.2 3.3 3.4.1
5.0.4 5.0.5 5.0.6 5.1 5.2 5.2.2
3.5.1
3.5.2
3.6
4.0
5.2.3
5.3
5.3.1

13. Fra en udviklers perspektiv…
7

14. 8

15. Kommunikation
9

16. Kommunikation
• Åben og ærlig
9

17. Kommunikation
• Åben og ærlig
• Respekt - både fagligt og personligt
9

18. Kommunikation
• Åben og ærlig
• Respekt - både fagligt og personligt
• Mundtligt fremfor skriftligt
– Hvor mange (nær)læser de lange mails, (forældede)
dokumenter m.v.?
9

19. Kommunikation
• Åben og ærlig
• Respekt - både fagligt og personligt
• Mundtligt fremfor skriftligt
– Hvor mange (nær)læser de lange mails, (forældede)
dokumenter m.v.?
• Slack (skriftligt) har afløst mange mails
9

20. Alle bør skal teste
10

21. Alle bør skal teste
10

22. Alle bør skal teste
10

23. Alle bør skal teste
• Team / holdånd
10

24. Alle bør skal teste
• Team / holdånd
• Udviklere og Test eksperter tænker forskelligt
10

25. Alle bør skal teste
• Team / holdånd
• Udviklere og Test eksperter tænker forskelligt
• Udviklere tester andres kode
– Ikke sin egen
– Øger forståelsen for kvalitetssikring
10

26. Alle bør skal teste
• Team / holdånd
• Udviklere og Test eksperter tænker forskelligt
• Udviklere tester andres kode
– Ikke sin egen
– Øger forståelsen for kvalitetssikring
• Test eksperter tager sig af største risiko områder
10

27. Test automatisering
En væsentlig forudsætning for at vi:
11

28. Test automatisering
En væsentlig forudsætning for at vi:
• Leverer forudsigeligt
11

29. Test automatisering
En væsentlig forudsætning for at vi:
• Leverer forudsigeligt
• Kan arbejde kontinuerligt med at refactor / rydde
op i teknisk gæld
11

30. Test automatisering
En væsentlig forudsætning for at vi:
• Leverer forudsigeligt
• Kan arbejde kontinuerligt med at refactor / rydde
op i teknisk gæld
• Ikke bruger alt vores tid på trivielle gentagelser
11

31. Test automatisering
En væsentlig forudsætning for at vi:
• Leverer forudsigeligt
• Kan arbejde kontinuerligt med at refactor / rydde
op i teknisk gæld
• Ikke bruger alt vores tid på trivielle gentagelser
• Har levende dokumentation
11

32. Teknikken skal være i orden

33. Feature branches
13

34. Jenkins jobs pr. branch
14

35. Jenkins jobs pr. branch
14

36. Jenkins jobs pr. branch
14

37. Stabile tests
15

38. Stabile tests
• Rerun fejlende tests
15

39. Stabile tests
• Rerun fejlende tests
• Løbende vedligehold / optimering
– Timing issues
– Test data
– Nye OS versioner
15

40. Stabile tests
• Rerun fejlende tests
• Løbende vedligehold / optimering
– Timing issues
– Test data
– Nye OS versioner
• Daglig buildserver ansvarlig
– Fælles ansvar
15

41. Buildserver vs. TestCloud
• Build server afvikler kun tests på iOS simulator
– Android på vej (måske på et device)
• TestCloud tester på rigtige devices (og mange af dem)
16

42. Test Cloud
17

43. Test Cloud
17

44. Test Cloud
17

46. Tillid til QA ekspert
19

47. Tillid til QA ekspert
• Overblik over hvad (og hvor meget) der skal testes
– Risikovurdering
– Styrer evt. “papirnusseri” :-)
19

48. Tillid til QA ekspert
• Overblik over hvad (og hvor meget) der skal testes
– Risikovurdering
– Styrer evt. “papirnusseri” :-)
• Grundig kendskab til forretningsregler
19

49. Tillid til QA ekspert
• Overblik over hvad (og hvor meget) der skal testes
– Risikovurdering
– Styrer evt. “papirnusseri” :-)
• Grundig kendskab til forretningsregler
• Bruger (meget) tid på exploratory tests
– Finder det andre (inkl. automatisering) har overset
– Lange brugs-sessioner
19

50. QA har tillid til automatisering
20

51. QA har tillid til automatisering
20
Feature
Scenario
Step
Page object
iOS Android

52. QA har tillid til automatisering
20
Feature
Scenario
Step
Page object
iOS Android

53. QA har tillid til automatisering
20
Feature
Scenario
Step
Page object
iOS Android
QA Review
Scenario: I can only send a valid report of a listing once
Given I am logged in as "UniqueSeller" using quick login
And I am on the VIP for "iPhone"
When I go to report listing
And I try to send the report
Then I see the validation error for "Årsag, Beskriv din anmeldelse"
When I close the system message view
And I select report listing cause "Annoncen er ulovlig"
And I set report description text to "Den er billigere end min!"
And I send the report
Then I see the report listing VIP
When I close the system message view
And I touch the report listing button
Then I am informed that I already has reported the listing

54. QA har tillid til automatisering
20
Feature
Scenario
Step
Page object
iOS Android
QA Review
Dev Review
def assert_listing_already_reported_by_user
wait_for_no_page_activity_indicator
#TODO: Not sure how to verify this...maybe we'll do it later
end

55. Hvad dækkes af automatiseringen?
21

56. Hvad dækkes af automatiseringen?
• Brug et værktøj der også fungerer som dokumentation
21

57. Hvad dækkes af automatiseringen?
• Brug et værktøj der også fungerer som dokumentation
• Brug code-coverage
– Fokuser ikke kun på % tallene
21

58. Hvad dækkes af automatiseringen?
• Brug et værktøj der også fungerer som dokumentation
• Brug code-coverage
– Fokuser ikke kun på % tallene
21

59. Bedst udnyttelse af kompetencer
22

60. Bedst udnyttelse af kompetencer
• QA finder ud af at genskabe crashes fra logs
– Udvikler hjælper med at forstå stacktrace og pege i den rigtige retning
22

61. Bedst udnyttelse af kompetencer
• QA finder ud af at genskabe crashes fra logs
– Udvikler hjælper med at forstå stacktrace og pege i den rigtige retning
• Udnyt test automatisering til ad-hoc fejlsøgning
– Eksempel: Manglende billeder i BilBasens app
22

62. Fejl i produktion
23

63. Fejl i produktion
• Overvåg kvaliteten
– Team ansvar
23

64. Fejl i produktion
• Overvåg kvaliteten
– Team ansvar
• Det vil altid kunne ske
– Uanset hvor meget/længe der testes
23

65. Fejl i produktion
• Overvåg kvaliteten
– Team ansvar
• Det vil altid kunne ske
– Uanset hvor meget/længe der testes
• Reager hurtigt
– Kan det fikses på serveren?
– Gør en ny version klar til upload
23

66. Fejl i produktion
• Overvåg kvaliteten
– Team ansvar
• Det vil altid kunne ske
– Uanset hvor meget/længe der testes
• Reager hurtigt
– Kan det fikses på serveren?
– Gør en ny version klar til upload
• Tving evt. brugerne til at opdatere
23

67. Fejl i produktion - lær af det
24

68. Fejl i produktion - lær af det
24

69. Fejl i produktion - lær af det
24

70. Fejl i produktion - lær af det
24

71. Minimer risici
• Undgå “Big bang” releases
– Start f.eks. med ny infrastruktur i et lille hjørne
• Continuous deployment (web) / Hyppige releases (mobil)
• Feature toggles
– Evt. kun åbne for X% af brugerne først
25

72. Gør automatisering virkelig en forskel?
26

73. Gør automatisering virkelig en forskel?
26
JA

74. Gør automatisering virkelig en forskel?
• Fanger fejl hurtigt
– Husk at fejre det
26

75. Gør automatisering virkelig en forskel?
• Fanger fejl hurtigt
– Husk at fejre det
• Giver en herlig følelse som udvikler
– Modig og tryg
26
Undgå dette fænomen

76. Gør automatisering virkelig en forskel?
• Fanger fejl hurtigt
– Husk at fejre det
• Giver en herlig følelse som udvikler
– Modig og tryg
• Kan ikke stå alene
– Manuel exploratory tests
26
Undgå dette fænomen

77. Opsummering
27

78. Opsummering
• Alle på et team hjælper til med kvalitetssikring
– Accepter at vi har forskellige måder at arbejde på
– Tekniske udfordringer er sjove for udviklere
– Udnyt alles kompetencer bedst muligt
27

79. Opsummering
• Alle på et team hjælper til med kvalitetssikring
– Accepter at vi har forskellige måder at arbejde på
– Tekniske udfordringer er sjove for udviklere
– Udnyt alles kompetencer bedst muligt
27

80. Opsummering
• Alle på et team hjælper til med kvalitetssikring
– Accepter at vi har forskellige måder at arbejde på
– Tekniske udfordringer er sjove for udviklere
– Udnyt alles kompetencer bedst muligt
• Automatiseret tests er nødvendigt
– Det giver bedre kode (mod til at refactor)
– Det skal ikke ses som en besparelse
– Det fanger ikke alle fejl
– QA får bedre tid til fordybelse og fokus på ikke-trivielle
regressionstests
27