1 of 49

��A Dragon Lesson of�Software Testing

Kari Kakkonen

5.2.2021

Version 1.0

2.3.2022

2 of 49

About this presentation

3 of 49

About this presentation

This presentation compares the facts of Information Technology, coding and software testing into the world of fantasy stories.
This presentation is meant to support teaching at schools, either for 1 or 2 lessons.
This presentation is Creative Commons licensed, i.e. you can use it freely for non-commercial purposes.
The presentation will be updated from time to time, and it is located here:

https://www.dragonsout.com/p/presentation-for-teachers.html

Improvement ideas can be sent to:

feedback@dragonsout.com

Let’s make software testing familiar to new generations!

2.3.2022

Dragons Out - a dragon lesson of software testing PowerPoint by Kari Kakkonen, is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.

4 of 49

About the book ”Dragons Out!”

This presentation is based on the world and the characters of Dragons Out! book.
The book complements the learning experience, but it is not required for using this presentation in teaching.
Author Kari Kakkonen
Illustrator Adrienn Széll
Text and illustration rights Dragons Out Oy
More info: www.dragonsout.com

5 of 49

About the exercises

Drawing exercises

You need paper and pencils.
You can take a photo of the drawing and upload it e.g. to a service https://padlet.com

The teacher needs to create a Padlet “board” for the lesson’s sharing purposes.
A fun interactive part of the lesson.

You need a mobile phone for taking the photos.

Testing exercise

You need your own phone or tablet, and any app that you want to test.

You can share the phone with a friend and do the exercise as a pair.

You can run the exercises as 5-minute speed exercises or you can use as much time for them as you like.

2.3.2022

6 of 49

Dragons / Defects

7 of 49

What is software?

There is software everywhere, in games, online stores or car steering systems, in the same way as a fantasy world is full of castles and villages.
A software can also run a device.
Also called a program, although actually many programs make up a software.

2.3.2022

Software = computer code that allows a person to do something, such as play a game. Also, the software product.

8 of 49

What is a defect?

Every software has defects, as it is human to make mistakes.
Defects make the use of software more difficult, in the same way as dragons harass castles and their inhabitants in fantasy stories.
Defects are in the software by accident, and they must be removed, preferably before a software user finds them.
A defect is often called a bug.

2.3.2022

Defect = a problem in the software code that causes a failure in software. People sometimes call it an error, even though, strictly speaking, an error is a human act that results in a defect in the code.

9 of 49

Exercise 5-15 mins:

Design your own defect –�draw your own dragon

// What you need

Paper and pencil

// Task

1 Think of a defect you have encountered.

Write down the name of the defect and a few words to describe it.

2 Think of an equivalent dragon.

Write down the characteristics of the dragon.
If the defect was bad, the dragon is big etc.

3 Draw the dragon.

The main thing is to carry through your idea of how the dragon can represent the defect.
No need to aim for a perfect picture.

4 Show the picture to others as agreed.

E.g. use a Padlet.

10 of 49

What is testing?�What is software development?

11 of 49

What is software development?

You need to decide what you want the software to do.
You have to code it.
You have to test how the software works.
In a fantasy story, you have to design and build the walls around a village and at the same time vanquish the dragons that trouble it.

2.3.2022

Software development = all possible tasks required to make the software work. Tasks include defining requirements, coding, and testing.

12 of 49

What is testing?

You must find defects so that they can be fixed.
Testing is looking for defects and finding them, just as in a fantasy story you watch for dragons on the wall.
As a result of testing, you sometimes find defects.
Testing actually doesn’t find a defect, it finds a software failure that is caused by a defect in the code.

2.3.2022

Test = to try, check or test with different values, in a different order, in different ways whether something works at all or how well it works.

13 of 49

Exercise 5-15 mins:

Design your own software –�draw your own castle

// What you need

Paper and pencil

// Task

1 Think of a software that you have used.

Write down the name of the software and a few words to describe it.
Write down how this software tolerates defects.

2 Think of an equivalent castle that would withstand an attack of a dragon.

Write down the characteristics of the castle.
Small, large? Walls? Weapons?

3 Draw the castle.

The main thing is to carry through your idea of how the castle can represent the software.
No need to aim for a perfect picture.

4 Show the picture to others as agreed.

E.g. use a Padlet.

14 of 49

Test techniques

You can test in many ways – these are different test techniques.

Try to use the software correctly.
Try to use the software wrong.
Explore how the software works.
Observe when someone else uses the software.

You can use many test techniques at the same time, in the same way as in a fantasy story a knight can both draw a map and ask people where they have seen the dragon.

2.3.2022

Test technique = a way in which you choose the appropriate number of tests for testing with good coverage. There are a wide variety of techniques for different needs.

15 of 49

Exercise 5-30 mins:

Test a software �on your mobile phone

// What you need

Mobile phone,

tablet or

or computer

// Task

1 Choose a software.

E.g. a game

2 Think of different angles into the software.

What works correctly?
What works wrong?
What is slow?
What is strange?

3 Use the software with these angles in your mind.

Write down what you found.

4 Share your findings with others.

Discussion!

16 of 49

Knights – coders and testers

17 of 49

Who tests most?

Usually the coder (software developer) codes the software, and also tests a lot.
There are also testers who are specialized in testing. They find problems easier.
Together the coders and testers form a software development team, like in a fantasy story there are many knights.
A larger software always has a full team instead of just one developer.

2.3.2022

Software development team = a group of people who build and test software together. In short, the development team.

18 of 49

When a dragon arrives, you need…

Story

Swanlake turned her horse around and rode fast back to the palisade. She called to the knights and building master Aidan that the dragon was coming. All the sharpened trunks needed to be moved urgently to the hole in the palisade. Spears and swords, whoever had them, should be fetched immediately. All available water should be poured into buckets. Then she went to find Yellowbeard at the castle.

Explanation

In the story the dragon arrives to a village in the middle of the repairs of the palisade. Similarly, most of the defects are found in software during software development, before the software is released. Then the people who look for defects (testers) and fix defects (coders), are always available. Usually a tester finds the defect, so doesn’t wait for a user to find the defect later. In this story Swanlake was a tester who found and identified the defect, that is the dragon. As a tester she couldn’t this time fix the defect but needed coders (developers) to help.

19 of 49

Other testers

20 of 49

Users

Anyone can test, but the expectation is that coders and testers test the most.
Software users can participate in testing, as in a fantasy story villagers, children and adults alike, find dragons.
This kind of testing is acceptance testing.
Users can also help to build software.

Tester = a person who tests. A person with testing skills. The tester can be a full-time tester, programmer, administrator, or user.

21 of 49

Maintenance team

Maintenance team monitors the software and keeps it running. They maintain it.
To do this they both test and fix defects.
They also help users.
Maintenance team often tries to manage on their own, but they will ask for help from developers when needed, just like in a fantasy story a hunter can ask knights to help him in killing a dragon.
Sometimes the maintenance person is in the development team (the development team becomes a DevOps team).

Maintenance team = the administrators, the people who take care of the software operation when people use it. It is also called the operations team.

22 of 49

DevOps – Continuous Delivery

Sometimes, an operations person is within the development team. In this case, the team is a DevOps team, just like in a fantasy story hunters sometimes work together with knights.
This kind of team develops and tests the software all the time, delivers new functionalities to users and at the same time supports software users in using software.

2.3.2022

DevOps = Combining software development and operations of the software. The same team builds and maintains the software.

23 of 49

Product owners

Product owners order software and systems from development teams.
They can be specific product owners or management of a company.
They define what the software should do, but listen to the development team, just like in a fantasy story Lords and Ladies order castles from knights and plan with them.

Product owner = a person who asks to build a software product, or software. The product owner can also be a company that, of course, is represented by a person.

24 of 49

Experts help

Development teams don’t know everything but need support from experts in specialty areas, just like in a fantasy story sages help villagers and knights.
Typical experts include specialists in usability, security and performance. They help the development team.
For example, a usability expert often performs or guides usability testing.

Usability expert = a person who specializes in designing information systems with good usability.

25 of 49

Exercise 5-15 mins:

Design your own tester –�draw your own knight

// What you need

Paper and pencil

// Task

1 Think about what kind of tester would be a good tester.

Curious? Handsome? Fast? Patient?
Write down these characteristics.

2 Think of an equivalent knight or other character that can find dragons.

Write down the characteristics of the knight.
Harnessed? Weapons? Attentive?

3 Draw the knight.

The main thing is to carry through your idea of how the knight can represent the tester.
No need to aim for a perfect picture.

4 Show the picture to others as agreed.

E.g. use a Padlet.

26 of 49

Different kinds of defects

27 of 49

There are different kinds of defects

You can’t find all the defects, but you should try to find them.
Some of the defects are bad, some small, some you can remove easily, some are harder to remove, just like in a fantasy story there are different kinds of dragons.
A severe defect must be fixed quickly.

2.3.2022

Severity = you often classify defects by severity. A defect can be severe, which means it is expensive or very damaging. A defect can also be less severe.

28 of 49

Annoying dragon

Color: Red
Size: Medium
How difficult to find?: Difficult
How difficult to get rid of?: Easy
Flies?: No
Wings: Small
Breaths fire?: Yes
Favorite thing: Eating lambs

2.3.2022

29 of 49

Annoying dragon

Defect name: Memory leak
Severity: Medium
Defect symptoms: The computer gets slower, until it can’t function at all, and it shuts down
Cause of the defect: Memory is reserved for use of the software, but it is not freed after usage
Root causes: Developer is not careful in freeing the memory. May not know how, may not remember.
Testing: You measure used memory as you use the software. If the amount of used memory increases all the time, it is probably a memory leak.
Fix: You run the software one line of code at a time, until you find the spot that should be fixed. Memory is released with a proper piece of code.

2.3.2022

30 of 49

Robbing dragons

Color: Glittering green, or gray
Size: Small to large
How difficult to find?: Easy to difficult
How difficult to get rid of?: Easy to difficult
Flies?: Some fly, some don’t
Wings: Small to large
Breaths fire?: Yes
Favorite thing: Stealing food and treasure

2.3.2022

31 of 49

Robbing dragons

Defect name: Functionality defects
Severity: Low-Medium-High
Defect symptoms: The software doesn’t do what it should do. Calculation gives wrong result. User sees information in the wrong place.
Cause of the defect: The functionality has been coded wrong.
Root causes: Developer has not understood what the user has meant. Or the defect exists due to carelessness, or hurry.
Testing: You use the software normally, based on tester experience or requirement definitions.
Fix: Code is changed to work correctly.

2.3.2022

32 of 49

Mean dragon

Color: Black
Size: Small
How difficult to find?: Difficult
How difficult to get rid of?: Medium
Flies?: Yes
Wings: Medium
Breaths fire?: A lot
Favorite thing: Stealing food and treasure without being detected

2.3.2022

33 of 49

Mean dragon

Defect name: Security defect
Severity: High
Defect symptoms: Information from the software is found outside the system (e.g. bank card information). It could also be just software functioning wrong.
Cause of the defect: A criminal has used security defect to break into the system, and then has stolen or destroyed something.
Root causes: Developer has not followed the latest secure coding principles. Maybe doesn’t know these.
Testing: You look for known vulnerabilities in the software by using it, or via a security testing software. You can also review code. Checklist of known defects helps.
Fix: A known vulnerability has also a known fix. It is fixed in the code or system settings.

2.3.2022

34 of 49

Fast dragon

Color: Purple
Size: Small
How difficult to find?: Difficult
How difficult to get rid of?: Difficult
Flies?: Yes
Wings: Large
Breaths fire?: A little
Favorite thing: Stealing gold in secrecy

2.3.2022

35 of 49

Fast dragon

Defect name: Performance defect
Severity: Medium
Defect symptoms: Software is slower than it should
Cause of the defect: Part of the code works inefficiently or plain wrong. Settings could be wrong, too. Software then tries to do something unnecessary. This takes time.
Root causes: Performance wasn’t considered during coding. Developer may not know all possibilities of the coding environment. May not have access to rest of the software.
Testing: You use software normally, one or many users at a time, often with a performance testing software. You measure speed, that is response time.
Fix: You change those parts of the code that work slowly. You try a fix and test the speed again.

2.3.2022

36 of 49

Showy, troublesome dragon

Color: Green
Size: Large
How difficult to find?: Easy
How difficult to get rid of?: Difficult
Flies?: Yes
Wings: Large
Breaths fire?: A lot
Favorite thing: Stalking gold and protecting its territory

2.3.2022

37 of 49

Showy, troublesome dragon

Defect name: Usability defect
Severity: Low
Defect symptoms: Software is hard to use, but it can be done.
Cause of the defect: Coding is done with only functionality in mind, possibly in the easiest way.
Root causes: User needs have not been taken into account in design or coding. Usability may not be understood.
Testing: You use the system normally. You gather opinions about what is easy and what is hard to use.
Fix: You change the code so that the system is easier to use, respecting results from usability testing.

2.3.2022

38 of 49

Underground dragon

Color: Brown
Size: Large
How difficult to find?: Easy
How difficult to get rid of?: Medium
Flies?: No
Wings: Small
Breaths fire?: A lot
Favorite thing: Finding easy food and eating

2.3.2022

39 of 49

Underground dragon

Defect name: Hardware defect
Severity: High
Defect symptoms: Some part of or all of the computer doesn’t work.
Cause of the defect: A part of hardware has broken over time.
Root causes: A part of hardware may be of low quality, so it doesn’t last as long as it should. Possibly the part doesn’t work well with other parts, so it breaks.
Testing: You use the system normally. You observe the hardware. Test environment uses similar hardware than the users will have.
Fix: You change a broken part to a new one or change to a part that better fits other parts.

2.3.2022

40 of 49

Shadow or dragon?

Color: Grey
Size: Small
How difficult to find?: Easy
How difficult to get rid of?: Easy
Flies?: No
Wings: Small
Breaths fire?: Yes
Favorite thing: Confusing people

2.3.2022

41 of 49

Shadow or dragon?

Defect name: Testability defect
Severity: Low
Defect symptoms: It looks like the functionality works wrong, e.g. wrong result from a calculation.
Cause of the defect: Tester may have wrong test data or test environment.
Root causes: Tester may be too enthusiastic to find defects. Test environment and test data may not have been planned properly.
Testing: You use the system normally, but you observe the environment and data. Always consider if the testing is the cause of the defect.
Fix: You define test environment and data better. You learn from false alarms.

2.3.2022

42 of 49

Nice dragon

Color: Glittering green
Size: Medium
How difficult to find?: Easy
How difficult to get rid of?: Easy
Flies?: Yes
Wings: Medium
Breaths fire?: Yes
Favorite thing: Eating animals and helping people

2.3.2022

43 of 49

Nice dragon

Defect name: Defect seeding, mutation testing - a defect created on purpose
Severity: Low
Defect symptoms: It looks like the functionality works wrong, e.g. wrong result from a calculation. So, the defect looks like a functionality defect.
Cause of the defect: Tester or coder has created the defect into the code on purpose.
Root causes: The idea is that when all seeded defects have been found, all defects have been found.
Testing: You use the system normally and try to find all seeded defects. You will also find real defects. When the last seeded defect is found, you can stop testing.
Fix: Remember to fix the code also for the seeded defects, in the same way as for real functionality defects.

2.3.2022

44 of 49

Stubborn dragon

Color: Glittering green
Size: Large
How difficult to find?: Easy
How difficult to get rid of?: Difficult
Flies?: Yes
Wings: Small
Breaths fire?: Yes
Favorite thing: Harassing people repeatedly

2.3.2022

45 of 49

Stubborn dragon

2.3.2022

Defect name: Version management defect
Severity: Medium
Defect symptoms: A defect, that was already fixed, appears again. This could be a functionality defect.
Cause of the defect: Version management has failed. Coder uses an old part of software, where a newer part should be used. This new part includes a defect fix by another developer.
Root causes: Hurry and too big number of people produce defects. Version management may be missing altogether.
Testing: You use the system normally. If a defect is found, you check if such a defect is fixed already. If so, you investigate how the version management works.
Fix: You improve how version management works. Start using a version management software.

46 of 49

Confused dragon

Color: Glittering green
Size: Small
How difficult to find?: Easy
How difficult to get rid of?: Easy
Flies?: Yes
Wings: Medium
Breaths fire?: Yes
Favorite thing: Harassing large dragons

2.3.2022

47 of 49

Confused dragon

Defect name: Documentation defect
Severity: Low
Defect symptoms: Functionality works in a different way than the documentation says.
Cause of the defect: Plans and guidelines are not aligned with the software.
Root causes: There have been decisions or changes during coding that have created a different software than planned. Documentation has been created based on old plans.
Testing: You use the system normally. If a defect is found, you consider if the software or the documentation is wrong.
Fix: You change either the software or the documentation, so that they match.

2.3.2022

48 of 49

Exercise 5-15 mins:

Design your own good defect –�draw your own good dragon

// What you need

Paper and pencil

// Task

1 Think of a defect that has helped you understand something about the software (or you can think of any defect if you like).

Write down the name of the defect and a few words to describe it.

2 Think of an equivalent dragon.

Write down the characteristics of the dragon.
If the defect was bad, the dragon is big etc.

3 Draw the dragon.

The main thing is to carry through your idea of how the dragon can represent the defect.
No need to aim for a perfect picture.

4 Show the picture to others as agreed.

E.g. use a Padlet.

49 of 49

Thank you!

If you are interested in the book, too, you can order it here:

https://www.dragonsout.com/p/order-dragons-out-book.html

Follow and share the book project:

https://www.dragonsout.com

Ask questions:

kari.kakkonen@dragonsout.com