Product Owner perspective on Software Project QA

A talk I gave to students of Information Processing Science in University of Oulu about software project quality assurance (software testing)

Transcript

1. P R O D U C T O W N E R P E R S P E C T I V E O N S O F T WA R E P R O J E C T Q A T E S T I N G I N S O F T WA R E P R O J E C T S
2. E V E RY N O W A N D T H E N , A N I S S U E I S B O R N
3. W H AT I S A N I S S U E ? • Issue is a unit of work to accomplish an improvement in a system • The word "issue" should not be misunderstood as just a synonym for "problem," as in other English usage • Issues are stored into issue trackers • Issues can be categorised into bugs, user stories, enhancements, tasks, epics, etc…
4. T H E L I F E C Y C L E O F A B U G • Bug is born when QA person finds an error and reports it into a issue tracking • Issue has a description and steps how to reproduce the error • Issue gets a priority (blocker, major, minor, trivial) • New code is written to fix the error by developer • QA person verifies that the new change fixes the problem • Issue is closed by QA person
5. T H E L I F E C Y C L E O F A U S E R S T O RY • User story is born when product owner writes a short story, describing a desired functionality • Issue has a description and other useful information (i.e. UI specs) • Priority is set by product owner (blocker, major, minor, trivial) • Depending on the issue complexity, it may be split into smaller issues by development team • Once the functionality is implemented, QA person verifies that the new functionality works are specified in the user story • Issue is closed
7. W H E N S O M E T H I N G D O E S N O T W O R K A S S P E C I F I E D , M A K E A N I S S U E O U T O F I T F I R S T R U L E O F S O F T WA R E T E S T I N G
8. F O L L O W T H E F I R S T R U L E S E C O N D R U L E O F S O F T WA R E T E S T I N G
9. W H E N S O M E T H I N G D O E S N O T W O R K A S S P E C I F I E D , M A K E A N I S S U E O U T O F I T
10. S P E C I F I C AT I O N S • In order to perform useful software testing, you need to know how to system is supposed to work • Specifications must contain enough details so the project personnel understand what kind of software system they are building
11. A B E L O V E D C H I L D H A S M A N Y N A M E S • The specifications of the system are usually spread in many types of documentation • User Interface specifications • Requirements • User stories • Customer Journeys • Use cases • …..
12. I T ’ S A B O U T C O M M U N I C AT I O N
13. The more you have specified how the system is supposed to work, the harder it is to change the system
14. C A N Y O U P R O M I S E T H AT T H E W O R L D D O E S N O T C H A N G E D U R I N G T H I S S O F T WA R E P R O J E C T ?
15. THE ONLY THING CONSTANT IS CHANGE
16. R E A L - L I F E E X A M P L E
17. Customer Journey User Stories Tasks
18. Customer Journey User Stories Tasks
19. Customer Journey User Stories Tasks
20. Customer Journey User Stories Tasks “Ready for testing”
21. T E S T I N G T H E F U N C T I O N A L I T Y • Specifications vs implementation • Does it work? • Does it follow the specifications? • “Test case” - Step by step instruction for testing the functionality
22. Customer Journey User Stories Tasks
23. Customer Journey User Stories Bug Bug Bug
25. Customer Journey User Stories Bug Bug Bug
26. U S E R S T O R I E S & T E S T C A S E S • User stories can have several test cases • Happy case, empty state, error state • Test case is focused for testing one thing • Test cases are grouped in to a test suites
27. A C C E P TA N C E T E S T S S H I P P I N G N E W V E R S I O N Each new release goes through a acceptance test If tests are green, release the new version Releasing new version should be routine, not drama.
28. M A N U A L A N D A U T O M AT I C • Test case can be tested manually or automatically • Automatic test is a piece of code that tests another piece of code that it works as specified • Leave the simple cases for test automation • Run automatic test cases every night to fight the regression
29. T O P I C S W O R T H R E A D I N G A F E W B L O G P O S T S • Integration tests • When two systems are integrated to work together, how can you be sure it works as intended? • Performance Tests • How many users your system can handle? What are the most performance intensive operations?
30. T H A N K Y O U ! http://tuom.as twitter.com/tuomasj ! ! ! All pictures from unsplash.com