Quality from the start
Filipe Freire
15 February 2018
Slide 2
Slide 2 text
Learner, tester, developer, husband
2.5y work as a “coding” tester
1y work as a developer
OSS contributor
Quick intro
Currently @
2
Slide 3
Slide 3 text
“Job application, public ”
Ex.: hospital
Story time
3
Slide 4
Slide 4 text
4
Slide 5
Slide 5 text
5
Slide 6
Slide 6 text
6
Slide 7
Slide 7 text
“Inspect the code!”
“Use the Dev-tools!”
Nope.
7
Slide 8
Slide 8 text
8
Slide 9
Slide 9 text
The pizza problem #1
9
Slide 10
Slide 10 text
1st pizza: 2nd pizza:
The pizza problem #2
10
Slide 11
Slide 11 text
In the team I’m part at
>10mil messages/day
+ tons of data & logic and flows
If something fails for 10 mins:
11
Slide 12
Slide 12 text
What if :
Your bank’s software fails?
Your doctor’s medical device fails?
Your country’s defences fail?
12
Slide 13
Slide 13 text
“It’s the user!”
“It’s the tester!”
“It’s the developer!”
13
Who’s to blame?
Slide 14
Slide 14 text
Why do we test?
14
Slide 15
Slide 15 text
“To verify something
can work”
–James Bach & Michael Bolton
15
Slide 16
Slide 16 text
What prevents software from
working?
16
Slide 17
Slide 17 text
–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
Slide 18
Slide 18 text
“ (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
Slide 19
Slide 19 text
Remember
“who’s to blame”?
Answer: anything and
everything between our
code (incl.) and the user
19
Slide 20
Slide 20 text
–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
Slide 21
Slide 21 text
Everyone makes their
own shared bed.
“What can I do help
make a better bed?”
21
Slide 22
Slide 22 text
-9999. “Do you know the value
of your tool?”
- Tooling!
22
Slide 23
Slide 23 text
BTW, the following, credit goes
to:
http://www.yegor256.com/
2015/06/08/deadly-sins-
software-project.html
23
Slide 24
Slide 24 text
1. Can I be sloppy?
- Anti-Patterns!
24
Slide 25
Slide 25 text
- 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
Slide 26
Slide 26 text
2. How do I keep track of stuff?
26
- Traceability!
Slide 27
Slide 27 text
Use tickets.
Reference them.
Don’t hit delete.
27
- Traceability!
32
@rita: #12 - add
patient list as table
@ana: #13 - delete
patient list
Don’t hit delete.
- Traceability!
Slide 33
Slide 33 text
3. How can I package my work
- Release and version!
& not work nonstop?
33
Slide 34
Slide 34 text
“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
Slide 35
Slide 35 text
“some work done:
tell a bot or script
to create + publish
a package. Repeat.”
- Release and version!
35
Slide 36
Slide 36 text
- Release and version!
36
Best advice here: learn!
Slide 37
Slide 37 text
4. “How can I keep my stuff tidy
all the time?”
- Static-analysis!
37
Slide 38
Slide 38 text
- Static-analysis!
38
Slide 39
Slide 39 text
Find some static analysis software for
the language you code…
Then, make it fail your builds, always.
- Static-analysis!
39
Slide 40
Slide 40 text
5. What are my numbers?
- Coverage!
40
Slide 41
Slide 41 text
Do everything necessary to put
this badge on your project
- Coverage!
41
Slide 42
Slide 42 text
- Coverage!
42
You’ll need:
- Unit tests (Learn and make’em)
- Configure some coverage lib
- Paste the badge on README
Slide 43
Slide 43 text
- 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
Slide 44
Slide 44 text
6. “What does your stuff do?”
- Document!
44
Slide 45
Slide 45 text
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 :-)
Slide 46
Slide 46 text
Best-case scenario
Year 1:
“Ana and Miguel do class
assignment for X: it’s maintainable,
well documented”
A + M
Work
46
Slide 47
Slide 47 text
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
+
Slide 48
Slide 48 text
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
+
Slide 49
Slide 49 text
Worst case scenario
Maintainable garbage
Still better than most real-life scenarios :-)
49
Slide 50
Slide 50 text
And like in OSS:
You’re not just setting the bar for
the next year student on your class.
50
Slide 51
Slide 51 text
Wrap-up
51
Slide 52
Slide 52 text
Example: Porto Testers Meetup
52
Learn, share ideas & knowledge. Go out there!
Community!
Slide 53
Slide 53 text
Pst… There’s more @Porto!
53
Slide 54
Slide 54 text
Thank you. Questions?
filfreire filrfreire
filfreire.com
54
Follow me @