An introduction about Software testing, testing types, and some tips when testing (and coding in general)

1. TESTINGI FIND YOUR LACK OF TESTS
DISTURBING

2. WHAT IS TESTING?
YOU SAY WHILE YOU NAIL IN MY PUPIL YOUR
PUPIL IN BLUE.
WHAT IS TESTING?
AND YOU ASK TO ME? TESTING… IS YOU.
To the unknown developer…
INTRO

3. INTRO
1. The Dark Side
2. Padawan’s path
3. Use the Tests
4. Test practices

4. THE DARK SIDE

5. THE DARK SIDE
▸Companies
▸Want to reduce costs
▸Saving time -> reducing plans
▸Saving money -> reducing salaries
▸Developers
▸feel pressured and don’t have time to test
▸don’t want to test or to learn how to test
▸I’m not going to talk about salaries so let’s talk
about technical things

6. LIFECYCLE
MANAGEMENT

7. WATERFALL
LIFECYCLE

8. SOFTWARE LIFECYCLE MANAGEMENT
WATERFALL: A TRADITIONAL ENGINEERING APPROACH
REQUIREMENTS
ANALYSIS
SOFTWARE
DESIGN
IMPLEMENTATION
TESTING
INTEGRATION
DEPLOYMENT
MAINTENANCE
https://en.wikipedia.org/wiki/Software_development_process
DOCUMENT IT !!

9. V-MODEL
LIFECYCLE

10. SOFTWARE LIFECYCLE MANAGEMENT
V-MODEL: AN EXTENDED WATERFALL
REQUIREMENTS
ANALYSIS
SYSTEM
DESIGN
IMPLEMENTATION
INTEGRATION
VALIDATION
MAINTENANCE
CONCEPTS OF
OPERATIONS
INTEGRATION
VALIDATION
MAINTENANCE
TESTING
UNIT
INTEGRATION
FUNCTIONAL
https://en.wikipedia.org/wiki/V-Model_(software_development)
TIMELINE

11. SPIRAL
LIFECYCLE

12. SOFTWARE LIFECYCLE MANAGEMENT
SPIRAL: CYCLES OF MINI-WATERFALLS
SOFTWARE
DESIGN
CODE
TESTING
INTEGRATION
IMPLEMENTATION
OBJECTIVES RISKS
PLAN
https://en.wikipedia.org/wiki/Software_development_process

13. AGILE
LIFECYCLE

14. SOFTWARE LIFECYCLE MANAGEMENT
AGILE MANIFESTO
▸Based on 12 principles
▸Individuals and interactions
▸Working Software
▸Customer collaboration
▸Responding to change

15. SOFTWARE LIFECYCLE MANAGEMENT
AGILE MANIFESTO
▸Working software is the principal
measure of progress
▸Welcome changing requirements,
even in late development
▸Continuous attention to technical
excellence and good design

16. SOFTWARE LIFECYCLE MANAGEMENT
AGILE MANIFESTO
▸Working software: How do you assert
that?
▸Changing requirements: How do you
verify you don’t break existing things?
▸Good design: Are you able to easily
test it?

17. PADAWAN’S PATH

18. PADAWAN’S PATH
▸Include Testing activities the
soonest
▸Developers HAVE TO write tests
▸Do not treat QA as the next team
in the line

19. TEST EARLIER
AND MORE
BEST PRACTICE 1

20. PADAWAN’S PATH: WRITE TESTS EARLIER
▸Removes fear of changes
▸Executable examples/documentation
▸Enables refactoring
▸Helps you understand design
▸It’s not slower: faster and more robust
▸Visual feedback: red & green

21. DEVELOPERS
WRITE TESTS
BEST PRACTICE 2

22. ▸Unit, Integration and functional tests
▸Do not fall in the fallacy of automate
everything: Automate critical things
▸This is not removing QA team: they
automate things and specialise in
Exploratory Testing
PADAWAN’S PATH: DEVELOPERS WRITE TESTS

23. TREAT QA NOT AS
“THE QA GUYS”
BEST PRACTICE 3

24. http://sauceio.com/wp-content/uploads/2016/08/blog-post-600x451.png

25. ▸Otherwise, QA finds bugs when it’s
expensive
▸QA are team members
▸Spread the knowledge with them:
involve them in daily meetings,
demos…
▸Result? Enables Exploratory Testing
PADAWAN’S PATH: THE IMPORTANCE OF QA TEAM

26. USE THE TESTS

27. UNIT
TEST TYPES

28. UNIT TESTS
▸Isolated code
▸Executed fast
▸Always automated
▸I.e.: utility classes, POJO’s
▸Book: “Effective Unit Testing” Lasse Koskela

29. UNIT TESTS: MOCKS
▸Mocks
▸Isolate code
▸Speed up test execution
▸Simulate special conditions

30. UNIT TESTS: MOCKS
▸Stub: objects which return a specific value.
▸Fake Object: simpler than real implementation
but more elaborated than a stub.
▸Spy Object: registers what is being executed
in a test.
▸Mock: a more powerful spy object.

31. UNIT TESTS: MOCKS
▸Mocks
▸Increase complexity/
maintainability
▸Careful with wrong behaviour
▸Too much expectations
▸Corporate mocks

32. INTEGRATION
TEST TYPES

33. INTEGRATION TESTS
▸Code depending on other
(module, component, service…)
▸Not executed that fast
▸I.e. database, file system,
modules..

34. END-TO-END
TEST TYPES

35. END-TO-END TESTS: PROS
▸Loved by management
▸Simulates user behaviour
▸Black-box testing

36. END-TO-END TESTS: DRAWBACKS
▸Difficult root cause analysis
▸Small errors can hide real problems
▸Slow execution
▸Report bugs that could have been
fixed before
▸Super hard maintenance

37. MANUAL TESTS
UI TESTS
INTEGRATION
UNIT

38. MANUAL TESTS
UI TESTS
INTEGRATION
UNIT70%
20%
10%

39. SMOKE
TEST TYPES

40. SMOKE TESTS
▸Define critical paths on
your end-to-end tests
▸Execute it as a minimal
proof of working software
▸Always automated

41. EXPLORATORY
TEST TYPES

42. EXPLORATORY TESTING
▸You need knowledge of the system
▸Knowledge increases while you test
▸It’s not automated
▸Relay on human experience and
knowledge
▸Use test methods
▸Book: “Explore it!” E.Hendrickson

43. PERFORMANCE
TESTING TYPES

44. PERFORMANCE
▸Stress or capacity testing
▸Physically separated machines
▸A typical configuration:
▸Injector, Database, Application, Console
▸Very hard or specialised
▸Periodically executed
▸Tools: jMeter, Grinder, LoadRunner

45. OTHER TESTS
TESTING TYPES

46. OTHER TESTS
▸Behaviour (BDD)
▸Usability
▸Security
▸Comparison
▸Alpha/Beta
▸…

47. TEST PRACTICES

48. TEST PRACTICES
▸A @Test should have only one
reason to fail
▸A @Test should check just one
thing
▸A good commentary explains
why, not what

49. TEST PRACTICES
▸Avoid conditional logic in tests
▸A constantly falling @Test is useless
▸A @Test that cannot fail has no
value (false sense of security)
▸A @Test promising more than it
delivers is untrustworthy

50. UNTRUSTWORTHY TESTS
// does not test anything
public void testFoo() {
MyStaticClass.foo();
}
// does not do anything
public void testFoo() {
//new MyClass().foo()
}
// promise much more than expected
public void testSendEmailAfterLogin() {
new MyClass().foo()
}

51. TEST PRACTICES
▸Write platform independent tests
▸Flaky tests that fail intermittently as
usually related to I/O
▸Do not hardcode test-dependencies
▸Delete/close resources in @Before/
@After methods

52. PREMATURE OPTIMISATION
AND DUPLICATION ARE THE
ROOT OF ALL EVIL
Lasse Koskela. “Effective Unit Testing”
TEST PRACTICES

53. DUPLICATION IN TESTS COULD
BE GOOD IN FAVOUR OF
IMPROVED READABILITY
Lasse Koskela. “Effective Unit Testing”
TEST PRACTICES

54. MAY THE TEST
BE WITH YOU