Quality from the start

Transcript

1. 1.

   Quality from the start Filipe Freire 15 February 2018

2. 2.

   Learner, tester, developer, husband 2.5y work as a “coding” tester


   1y work as a developer OSS contributor Quick intro Currently @ 2
3. 3.

   “Job application, public <service>” Ex.: hospital Story time 3

4. 4.

   4

5. 5.

   5

6. 6.

   6

7. 7.

   “Inspect the code!”
 “Use the Dev-tools!” Nope. 7

8. 8.

   8

9. 9.

   The pizza problem #1 9

10. 10.

    1st pizza: 2nd pizza: The pizza problem #2 10

11. 11.

    In the team I’m part at 
 >10mil messages/day
 +

    tons of data & logic and flows If something fails for 10 mins: 11
12. 12.

    What if : Your bank’s software fails? Your doctor’s medical

    device fails? Your country’s defences fail? 12
13. 13.

    “It’s the user!” “It’s the tester!” “It’s the developer!” 13

    Who’s to blame?
14. 14.

    Why do we test? 14

15. 15.

    “To verify something
 can work” –James Bach & Michael Bolton

    15
16. 16.

    What prevents software from working? 16

17. 17.

    –Yegor Bugayenko “A software bug is an error, flaw, failure,

    or fault in a computer program or system that causes it to violate at least one of its functional or non-functional requirements.” 17
18. 18.

    “ (Testers are) the headlights of a project”! –James Bach

    Testers dispel the illusion 
 your code is good.
 
 Our main job: find and report tons of bugs using any means necessary 18
19. 19.

    Remember
 “who’s to blame”? 
 Answer: anything and everything between

    our 
 code (incl.) and the user 19
20. 20.

    –Pedro Tavares (@ordepdev) “No one is perfect, neither our code,

    but what matters most is our software craftsmanship attitude of making sure that our code works properly.” 20
21. 21.

    Everyone makes their 
 own shared bed. “What can I

    do help 
 make a better bed?” 21
22. 22.

    -9999. “Do you know the value of your tool?” -

    Tooling! 22
23. 23.

    BTW, the following, credit goes to: http://www.yegor256.com/ 2015/06/08/deadly-sins- software-project.html 23

24. 24.

    1. Can I be sloppy? - Anti-Patterns! 24

25. 25.

    - Anti-Patterns! God objects Temporal coupling Magic numbers Utility classes

    NULL references ORM… really? Poltergeists Lasagna code Spaghetti code Shotgun surgery Error hiding Ravioli code Macaroni code Be skeptical. Read. Learn.
 Google DuckDuckGo it. 25
26. 26.

    2. How do I keep track of stuff? 26 -

    Traceability!
27. 27.

    Use tickets. Reference them. Don’t hit delete. 27 - Traceability!

28. 28.

    Use tickets. 28 - Traceability!

29. 29.

    Use tickets. 29 - Traceability!

30. 30.

    Reference them. 30 @filipe: asdfasdf. @roberto: add function discussed yesterday

    @bob: - Traceability! @agnes: fix problem.
31. 31.

    Reference them. 31 @filipe: #3 - add login page style

    rules @roberto: #7 - refactor nurse page unit tests @bob: #2 add how-to-build info - Traceability! @agnes: #4 - fix report input warning
32. 32.

    32 @rita: #12 - add patient list as table @ana:

    #13 - delete patient list Don’t hit delete. - Traceability!
33. 33.

    3. How can I package my work - Release and

    version! & not work nonstop? 33
34. 34.

    “put your work in a zip and send an email

    to the teacher at midnight, on the last day to deliver” - Release and version! 34
35. 35.

    “some work done:
 tell a bot or script to create

    + publish a package. Repeat.” - Release and version! 35
36. 36.

    - Release and version! 36 Best advice here: learn!

37. 37.

    4. “How can I keep my stuff tidy all the

    time?” - Static-analysis! 37
38. 38.

    - Static-analysis! 38

39. 39.

    Find some static analysis software for the language you code…


    Then, make it fail your builds, always. - Static-analysis! 39
40. 40.

    5. What are my numbers? - Coverage! 40

41. 41.

    Do everything necessary to put this badge on your project

    - Coverage! 41
42. 42.

    - Coverage! 42 You’ll need: - Unit tests (Learn and

    make’em) - Configure some coverage lib - Paste the badge on README
43. 43.

    - Coverage! (What does the badge tell me?) “High coverage

    is not a guarantee of high quality. (…) But, unknown coverage is a clear indicator of maintainability problems.” –Yegor Bugayenko 43
44. 44.

    6. “What does your stuff do?” - Document! 44

45. 45.

    45 - Document! The tip here is: Write down, clearly,

    everything a user would need to know to use your software.
 Bonus point: when report time comes, you’ll have some sections ready :-)
46. 46.

    Best-case scenario Year 1: “Ana and Miguel do class assignment

    for X: it’s maintainable, well documented” A + M Work 46
47. 47.

    Best-case scenario Year 2: “Rui and Tiago do class assignment

    for X: 
 they pick were Y1 colleagues left off and still deliver maintainable, well documented work” A + M Work R + T Work 47 +
48. 48.

    Best-case scenario Year 3: “Rita and Marta do class assignment

    for X:
 they pick were Y2 colleagues left off and still deliver maintainable, well documented work” A + M Work R + T Work R + M Work 48 +
49. 49.

    Worst case scenario Maintainable garbage Still better than most real-life

    scenarios :-) 49
50. 50.

    And like in OSS: You’re not just setting the bar

    for the next year student on your class. 50
51. 51.

    Wrap-up 51

52. 52.

    Example: Porto Testers Meetup 52 Learn, share ideas & knowledge.

    Go out there! Community!
53. 53.

    Pst… There’s more @Porto! 53

54. 54.

    Thank you. Questions? filfreire filrfreire filfreire.com 54 Follow me @