Application Quality
What is it? How to create it? How to maintain it?
Why should I care?
@ KaunasPHP v.7
Slide 2
Slide 2 text
Who are we?
Artūras Šmorgun
http://asm.lt
@asarturas
Marijus Kilmanas
http://about.me/mkilmanas
@mkilmanas
Slide 3
Slide 3 text
Why are we here?
• Because quality matters;
• Because we care about the reputation of our
craft and the craftsmen;
• Because there is a way to sleep calm at night.
Slide 4
Slide 4 text
Software Quality?
What is quality?
Slide 5
Slide 5 text
No content
Slide 6
Slide 6 text
No content
Slide 7
Slide 7 text
No content
Slide 8
Slide 8 text
No content
Slide 9
Slide 9 text
No content
Slide 10
Slide 10 text
No content
Slide 11
Slide 11 text
No content
Slide 12
Slide 12 text
No content
Slide 13
Slide 13 text
No content
Slide 14
Slide 14 text
No content
Slide 15
Slide 15 text
What if we ignore quality?
External Quality
Slide 16
Slide 16 text
What if we ignore quality?
Internal Quality
Slide 17
Slide 17 text
“But it slows us down”
Slide 18
Slide 18 text
“But it slows us down”
Slide 19
Slide 19 text
Are we responsible?
• We are professionals
• quality is expected
• We are craftsmen
• we should do our job to the best
• Quality = recommendation
• trust of customers
Why we need tests?
• Refactoring without tests is...
• Pain
• Insane
• Suicide
• Refucktoring
...
Slide 22
Slide 22 text
External Quality
Slide 23
Slide 23 text
Cycles of life
External
Internal
Slide 24
Slide 24 text
Let’s speak Gherkin!
Slide 25
Slide 25 text
Let’s speak Gherkin!
In order to cooperate
As developers / agency
We need to have a common language
• States the business value;
• Defines the beneficiary;
• Gives an idea of what is needed to achieve value.
Slide 26
Slide 26 text
Scenario: Customer understands Gherkin
Given I produce feature specification
When customer reads them
Then they should understand what we agree upon
• Lists assumptions and preconditions;
• Defines what action triggers the behavior;
• Tells how to verify if behavior was correct;
Let’s speak Gherkin!
Slide 27
Slide 27 text
Scenario: Gherkin can be tested
Given customer confirmed the feature
When when we implement them
Then we should be able to verify they conform
to the agreed requirements
• Defines exactly how much functionality is needed;
• Automates acceptance criteria;
• Guides development process;
Let’s speak Gherkin!
Sessions
• Used within a single scenario;
• Represents state of the browser;
• Page object is a sub-property;
• Allows different browser for separate
scenarios.
Slide 37
Slide 37 text
Common pitfalls
• Too technical;
• Too enterprise’y;
• Coupled with dataset / environment.
Slide 38
Slide 38 text
Internal Quality
Slide 39
Slide 39 text
Cycles of life
External
Internal
Slide 40
Slide 40 text
Motivation
• Wo do make mistakes;
• Integration testing is expensive;
• Testing afterwards is boring;
• “Test last” encourages to skip it;
• We want to code, not to debug.
Slide 41
Slide 41 text
TDD
Telecommunication Device for the Deaf
Test Driven Development
Slide 42
Slide 42 text
What TDD is not:
• It’s not about verifying;
• It’s not about “waterfall”;
• It’s not for fast hacks.
Slide 43
Slide 43 text
What TDD is:
• It’s about communication;
• It’s about being agile;
• It’s for long term relationships.
Slide 44
Slide 44 text
3 rules of TDD:
• Do not write production code unless
there is failing test;
• Do not write more test than it is
sufficient to fail;
• Do not write more production code
than it is sufficient to pass failing test.
Slide 45
Slide 45 text
TDD cycle
Slide 46
Slide 46 text
No content
Slide 47
Slide 47 text
Problems?
• A lot of scaffolding have to be done in
order to write test;
• Mocking is expensive (time = money);
• Misleading terminology.
Slide 48
Slide 48 text
TDD v2.0
TDD Done Right
Slide 49
Slide 49 text
Spec BDD
It’s not about verification,
it’s about emerging design.
Slide 50
Slide 50 text
TDD ⇾ BDD
• Test Case ⇾ Specification
• Test ⇾ Example
• Assertion ⇾ Expectation
Slide 51
Slide 51 text
No content
Slide 52
Slide 52 text
PhpSpec
• Easy to use:
• does boring stuff for you;
• mocking & stubbing is very easy;
• TDD cycle oriented;
• Behavior oriented:
• encourages specification by example.
Inviqa provides training
• on Professional PHP and OOD
• on Agile development
• on collaborative BDD approach
• on full stack BDD in use
• on git & git flow
• and many more
Slide 93
Slide 93 text
We are looking for
team mates!
Senior Software Engineers,
passionate about their job.
(but we mean it!)
Kaunas, London, Liverpool, Sheffield, Manchester, Edinburgh, Leeds.