A presentation on software testing. Covers best practices, terminology, and role responsibility (QA/Developer)

1. SOFTWARE TESTING
Everyone’s Responsibility
Kurt Bliefernich

2. How can you know your code
works? That’s easy. Test it.
Test it again. Test it up. Test it
down. Test it seven ways to
Sunday.
~ Clean Coder Robert C. Martin
(Uncle Bob)

3. Isn’t Software Testing Expensive?
• Long Regression Cycles
• Time to write tests
• Lack of feature development

4. Cost Savings
1,000 hours of up-front
implementation without TDD.
TDD saved 623 man hours, or,
for a team of 4, about a month
of development.
Here are the assumptions made:
• Production bugs without TDD: 100
• Production bugs with TDD: 40 (60%
fewer, middle ground between 40%—
80%)
• Average time to fix bug at
implementation (TDD) phase: 1 hour
(this number is only used to derive the
production bug fix cost)
• Average time to fix a production bug:
~15 hours

5. Testing Saves Money
• Automate Regression
• Write lots of smaller tests
• Retire redundant tests
• Less code rewrite because of bugs
• Easier to refactor, grow code

6. The Testing Ice Cream Cone
• This is an Anti-pattern
• Sometimes called Testing
Cupcake.

7. The Testing Pyramid
• Write lots of fast tests,
near 100% coverage
• Push exception testing
down the pyramid
• Automate your happy
path, full stack tests
• Let QA specialists do
what they do best
(AdHoc, Exploratory, etc.)

8. The Testing Pyramid
• Technology Facing Tests
== Developer
Responsibility
• Business Facing Tests ==
QA && Product
Responsibility
• Best, QA and Developers
cross pair and write tests

9. Unit tests are low-level, focusing on a
small part of the software system.
Unit tests are written by the
programmers themselves using their
regular tools - the only difference being
the use of some sort of unit testing
framework.
Unit tests are expected to be
significantly faster than other kinds of
tests.
https://martinfowler.com/bliki/UnitTest.html

10. A component test is a test
that limits the scope of the
exercised software to a
portion of the system
under test.
https://martinfowler.com/bliki/ComponentTest.html

11. An integration test takes
a small group of units,
often two units, and
tests their behavior as a
whole, verifying that
they coherently work
together.
https://testing.googleblog.com/2015/
04/just-say-no-to-more-end-to-end-
tests.html

13. Contract/Consumer Tests
Contracts should be about catching:
• Bugs in the consumer
• Misunderstanding from the consumer
about end-points or payload
• Breaking changes by the provider on
end-points or payload
https://docs.pact.io/best_practices/contract_tests_not_functional_tests.html

14. Automated
GUI Testing

15. Automated UI Testing
• Should cover sunny day scenarios
• Testing through the UI is slow,
increasing build times.
• Most importantly such tests are very
brittle.

16. Test DrivenDevelopmentDesign
1. You are not allowed to write any production
code until you first written a failing unit test.
2. You are not allowed to write more of a unit
test than is sufficient to fail – and not
compiling is failing.
3. You are not allowed to write more
production code that is sufficient to pass the
currently failing unit test.

17. Use Expressive Tests

18. JUnit & AssertJ

19. Testing Terminology - Doubles
Test Double is the generic
term for any kind of
pretend object used in
place of a real object for
testing purposes.

20. Testing Terminology - Doubles
Dummy objects are
passed around but never
actually used. Usually they
are just used to fill
parameter lists.

21. Testing Terminology - Doubles
Fake objects actually have
working implementations,
but usually take some
shortcut which makes them
not suitable for production.

22. Testing Terminology - Doubles
Stubs provide canned answers to
calls made during the test, usually
not responding at all to anything
outside what's programmed in for
the test.

23. Testing Terminology - Doubles
Mocks are objects pre-
programmed with
expectations which form a
specification of the calls they
are expected to receive.

24. Testing Terminology - Doubles
Spies are mock objects, as
they record what is called.
They allow for real methods to
be called when they are not
mocked.

25. Recommended Books

26. References and Links
• https://en.wikipedia.org/wiki/List_of_unit_testing_frameworks
• https://martinfowler.com/articles/mocksArentStubs.html
• https://www.amazon.com/Clean-Coder-Conduct-Professional-Programmers/dp/0137081073
• https://docs.pact.io/best_practices/contract_tests_not_functional_tests.html
• https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html
• https://watirmelon.blog/
• https://www.researchgate.net/publication/255965523_Integrating_Software_Assurance_into_the_Software
_Development_Life_Cycle_SDLC
• https://medium.com/javascript-scene/the-outrageous-cost-of-skipping-tdd-code-reviews-57887064c412
• https://www.thoughtworks.com/insights/blog/introducing-software-testing-cupcake-anti-pattern

27. Questions ??