Quality from the start

Talk about software quality and testing for students, given at Helloworld Conference 2018.

Transcript

1. Quality from the start
   Filipe Freire
   15 February 2018
   

   View Slide

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

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

   View Slide

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

   View Slide

4. View Slide

5. View Slide

6. View Slide

7. “Inspect the code!”

   “Use the Dev-tools!”
   Nope.
   7
   

   View Slide

8. View Slide

9. The pizza problem #1
   9
   

   View Slide

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

    View Slide

11. In the team I’m part at
    

    >10mil messages/day

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

    View Slide

12. What if :
    Your bank’s software fails?
    Your doctor’s medical device fails?
    Your country’s defences fail?
    12
    

    View Slide

13. “It’s the user!”
    “It’s the tester!”
    “It’s the developer!”
    13
    Who’s to blame?
    

    View Slide

14. Why do we test?
    14
    

    View Slide

15. “To verify something

    can work”
    –James Bach & Michael Bolton
    15
    

    View Slide

16. What prevents software from
    working?
    16
    

    View Slide

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
    

    View Slide

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
    

    View Slide

19. Remember

    “who’s to blame”? 

    Answer: anything and
    everything between our 

    code (incl.) and the user
    19
    

    View Slide

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
    

    View Slide

21. Everyone makes their 

    own shared bed.
    “What can I do help 

    make a better bed?”
    21
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

28. Use tickets.
    28
    - Traceability!
    

    View Slide

29. Use tickets.
    29
    - Traceability!
    

    View Slide

30. Reference them.
    30
    @filipe: asdfasdf.
    @roberto: add function
    discussed yesterday @bob:
    - Traceability!
    @agnes: fix problem.
    

    View Slide

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
    

    View Slide

32. 32
    @rita: #12 - add
    patient list as table
    @ana: #13 - delete
    patient list
    Don’t hit delete.
    - Traceability!
    

    View Slide

33. 3. How can I package my work
    - Release and version!
    & not work nonstop?
    33
    

    View Slide

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
    

    View Slide

35. “some work done:

    tell a bot or script
    to create + publish
    a package. Repeat.”
    - Release and version!
    35
    

    View Slide

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

    View Slide

37. 4. “How can I keep my stuff tidy
    all the time?”
    - Static-analysis!
    37
    

    View Slide

38. - Static-analysis!
    38
    

    View Slide

39. Find some static analysis software for
    the language you code…

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

    View Slide

40. 5. What are my numbers?
    - Coverage!
    40
    

    View Slide

41. Do everything necessary to put
    this badge on your project
    - Coverage!
    41
    

    View Slide

42. - Coverage!
    42
    You’ll need:
    - Unit tests (Learn and make’em)
    - Configure some coverage lib
    - Paste the badge on README
    

    View Slide

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
    

    View Slide

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

    View Slide

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 :-)
    

    View Slide

46. Best-case scenario
    Year 1:
    “Ana and Miguel do class
    assignment for X: it’s maintainable,
    well documented”
    A + M
    Work
    46
    

    View Slide

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
    +
    

    View Slide

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
    +
    

    View Slide

49. Worst case scenario
    Maintainable garbage
    Still better than most real-life scenarios :-)
    49
    

    View Slide

50. And like in OSS:
    You’re not just setting the bar for
    the next year student on your class.
    50
    

    View Slide

51. Wrap-up
    51
    

    View Slide

52. Example: Porto Testers Meetup
    52
    Learn, share ideas & knowledge. Go out there!
    Community!
    

    View Slide

53. Pst… There’s more @Porto!
    53
    

    View Slide

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

    View Slide