Encouraging Children into Testing paper for EuroSTAR
I wrote this 10-page piece for EuroSTAR 2020 conference to go with my presentation at that Europe's largest conference. In spring 2021 they published it as a EuroSTAR book. You can get it from this link.
1
Software Testing for Children
Society needs IT and
testing skills. There is a persistent lack of both programming and testing
skills on the job market. The lack becomes worse as our societies include more
and more software. We need ever more programmers, and testers, too. You need to
test your software.
2
How Children Learn
Children learn in
numerous ways, as adults do[ii]. It is said that the more learning strategies
that children can use appropriately, the better they can be in problem-solving, reading, text comprehension and in memorizing.[iii] I have discussed with a multitude of teachers,
testers, and children to understand how children learn, to be able to teach
software testing to them. Let me share my learning with you.
Stories and examples generally work better than memorizing lists, terms or difficult concepts. If you can turn your idea into a story or a parallel, do it. It will be easier to learn. Some say that storytelling is the most ancient of learning techniques, practised before people knew how to write. Storytelling usually offers a possibility to use another powerful learning technique: identifying with others. A child can step into the shoes of a child or hero in the story. The child can then start imitating the behaviour learned from the hero in the story. I'm sure you have noticed children doing this, e.g. after seeing a movie. My son, for example, always goes to his room after a movie and starts varying the story of the film with his lego bricks. Fascinating to see.
Games, or playing in general, are a good source of trying out new things into practice and learning through them. As you put in some goals or perks as game objectives and try to reach those goals through playing the game, you learn without even noticing it. This is gamification. Taking a more abstract level into playing games, we can talk about exploring, seeing how something works, trying to do something. Exploring is about doing things and through trial and error, learning how things work and how they don't work. Testing is really about exploring, too – learning by doing.
Then we have simplicity and clarity. While these are not strategies of their own, they are an important element in any learning. If something can be explained as simply as possible, it becomes clear. Learning can happen.
Finally, we can learn through boundaries, or rather, learn within safe boundaries. It is about knowing what is and what isn't, or what is right and what is wrong. Within proper limits, a child can learn anything safely, try the other learning strategies, especially explore, try and err. So, setting boundaries and letting a child loose is an intense learning strategy.
I've tried to utilize all these learning styles in my book. However, one thing is above all else – storytelling. As it turns out, storytelling is also useful for different types of learners. Some people learn through eyes, others through ears, others through bodily movement. All of these people can learn through storytelling. Visual learners like the mental pictures they get from storytelling. Auditory learners connect with the words and the storyteller's voice. Kinesthetic learners can hook into the emotional connections and feelings from the story.[iv]
Then there is the question of at which age children best learn concepts like software testing. When are they ready to take in that sort of ideas? There is research that says that children start to learn more abstract concepts around the age of 11 or 12.[v] This would be when you begin to think about philosophy or the meaning of life. Understanding what is thinking itself is one of the most significant skills of all. It is quite abstract, and I'd wager some people don't ever fully grasp that, but they keep trying. The continuous search is actually one of the great things in life. Then, if you think about the core of software testing, you realize it is all about thinking. It is about thinking of what we know about software and what we don't, it's about deciding what to learn about the software. So, through this chain of deduction, I would say that software testing is best learned when you are a "tween", so around 11-12 years old. Of course, everyone is different and can learn about things at their own speed and time. You can learn more throughout your life. But when to start learning to test? I'd say 11 years is a good number.
3
The book project
I had the privilege of
attending James Whittaker's Storytelling and Creativity class some years ago.
His Storytelling manifesto[vi] is saying it well: "Every person has a
story. Every cause needs a storyteller. Learn to be a storyteller because
unless you are a candidate for a reality show, no one else is going to tell
your story for you. So tell us a story. Tell us a good story. And let that good
story be one part of a symphony of stories that makes this world a better
place." I couldn't agree more. I had a spark to author a book at some
point, but hearing out James's ideas about storytelling turned that spark into
bright flames. But what type of book exactly? What is my story? I want to tell
a story.
In 2014 a Finnish author Linda Liukas released "Hello Ruby", which is a book about coding for children at about kindergarten age. It drives in the logic that is at the core of all programming. The news about the book got me thinking. There should also be a software testing book for children. That could be my angle for authoring a software testing book.
I wrote blogs for different purposes around software testing, specifically for our company Knowit's blog[vii] and the most significant Finnish IT magazine Tivi's blog[viii]. Writing gave me fluency in explaining software testing and trying different analogies to software testing. I found out I was good at creating analogies.
Then the opportunity arrived. Our family decided to take a year off from work to spend time in Lapland, enjoy the eight seasons of North, breathe, dream, think about the future and spend time as a family. We set many goals for that year. One of my goals was to write a book.
I wrote the first chapter several times from different angles and asked for feedback from a few people. All the drafts included dragons, but without hesitation, I decided the dragon will represent a defect. I could then have a chapter for different types of defects or of varying levels of severity. It was a good analogy, but also it provided the structure for the book.
Then there was a question of what will represent the software that has the defect. In the first chapter, I started with a dragon harassing a village. So, the village, with all its surroundings, was the software. In later chapters, I added analogies of building the software, and the focus narrowed a bit to the defences of the village to describe the software. In the end, I used different examples of which part of a village doesn't work because of dragons. Similarly, the software comes in different shapes and sizes, and the defects they have are also of numerous types.
Software testing was naturally to be the act of finding the dragon and the act of removing a defect would be killing or vanquishing dragons. This choice offered a natural fit to the real world, as all kinds of people can find defects, but it takes the development team to remove the defect. So, the villagers, and this would include children, could find dragons or the knights could both locate and banish dragons. Setting children in the scene made the story more attractive for young readers – they could identify with the children in the story.
So, chapter after chapter, I added different examples of software testing. In some cases, the maintenance team could remove defects, and so I put hunters in the villages to try to banish the dragons. Any software will be programmed for the first time, and new software would have all kinds of small defects. Most software would be updated later, and this means different types of defects. Similarly, the varieties of villages would differ. Information technology would also need experts of various sorts, so sages came in handy as an analogy.
I was going through this list of different angles into software testing and checking them off from my list. That concept covered in that chapter, great. Check. Using an excel list for both testing concepts and characters was of great help. Utilizing a timeline picture helped keep the consistency of the story, as at times it was necessary to tell a story about past times (a story within the story), to explain how a village was first built – how the software was built for the first time. Utilizing a map was also necessary, as the fantasy world has many villages to represent the different types of software, and it was necessary to use mostly the same characters so that readers can identify better with them. Continuity. Besides, all fantasy stories need a map, right? I remember me poring over the map of the Lord of the Rings with great enthusiasm back when I was around the age of 11.
After several chapters, I would always send the new chapters for pilot reading to some more people. I kept asking if someone had children that could read an interesting story and give feedback. I contacted adults of three different backgrounds from which I need input: teachers, testers, and people who don't know anything about either testing or teaching. The pilot reader feedback was excellent. All encouraged the idea of the book a lot. Some said the story was great, and they would like to read more of the same. Some said the testing concepts are a bit difficult to understand. Some commented on wording and clarity of sentences, some about another angle into testing in general. All feedback over the course the half a year of writing the Finnish version was precious, including the review by testing colleagues in the end. I had the book in one piece now but kept asking for more feedback as there would still be time before I needed to give the manuscript to the publisher.
I'd like to mention the diversity of characters. I wanted to write very equally, talking about girls and boys, women and men, in big and small roles. I checked that I have women in all kinds of roles, including positions of power.
Around that time, I was trying to choose the illustrator for my book. I found Adrienn Széll, and we worked on different looks for the dragons and other characters. We found the look and feel that I had dreamed and planned. It was something a bit cartoon-like, something versatile enough to come alive in whatever future needs there could be, other than the book.
The illustration created two challenges. First, I would need to fund it. Second, I would need to consider the copyrights as I already imagined a whole world of other learning products around the book characters. The first challenge I could manage from my own pocket but only to a certain extent. So, I decided to start a crowdfunding campaign. The second challenge was solved by me founding a company and negotiating with my illustrator about illustration rights moved into the company. Suddenly, I had lots more work than the core tasks of writing a book. However, I soon shouldered this work and set to it. As I was at the same time going back to a full-time job from sabbatical leave, this extra load of work created problems with time or at least with my perception of time. After a few sleepless nights, I agreed with my employer Knowit that I'd take as many days off the paid work as I need for the book project. Very kind of them, but they've always been the good type of employer that wants to support the society and the employees and not only care about business.
The crowdfunding campaign at Indiegogo brought enough funding to have a great illustration in the book. It didn't create enough funding to take care of the publishing on my own, so I would need publishers to help there. Then again, I wanted big publishers with an extensive marketing network, anyway, so in the end, it all happened nicely. The campaign also gave me a deadline to translate to the English language. Part of the campaign approach had been to donate books to schools, so I also got the first good set of donation promises. The donation campaign would continue closer to publishing dates.
In December and January, I took more time off work to translate the book into English. It was quite a straightforward experience – I would say slightly faster than writing the book. A bonus in doing the translation before the publishing of the Finnish version was that I had another review perspective. I was able to clarify some Finnish content, too. I engaged several English pilot readers from my network and got valuable feedback, comments and encouragement. Janet Gregory, the co-author of many agile testing books, reviewed the text for the back cover blurb of the book. Paul Gerrard, the awarded testing guru, wrote the foreword for my book. I'm very grateful for both.
I had started looking for publishers for the book in the autumn. As I embarked on that journey, I soon realized it is going to be a much longer journey than I thought. The timescales of publishing houses to consider manuscripts to publish are always at least several months long. With some, you can have a dialogue about book content, but for all, you need to have the full, well-iterated manuscript available before they decide to publish. It took over half a year to get the publisher negotiations to the conclusion. Finally, though, I was able to choose from four good English offers and three good Finnish offers. I chose ones that would have the best possible quality of the production process and marketing services. Both deals required, however, some investment of my own, but I had prepared for that eventuality with some savings. The Finnish publisher is Avain[ix], and the English publisher is Austin Macauley[x].
My Finnish publisher Avain did the tech edit and layout for the Finnish edition of the Dragons Out book. It was published on Dec 1st, 2020. I organized a nice publishing event online. The English publishing date is yet to be announced, but it shouldn't be too long anymore. I have already reviewed the tech edit and layout and I’m waiting for the final version to arrive for my review. Having the book project in such a good state has made it possible for me to focus on the marketing of the book and on the concept of teaching software testing to children. Indeed, it is quite much required for authors to share their ideas of the book content to aid the publisher marketing, especially if the target group is special. The publishers reach the book stores and libraries, which are very much needed. But they lack a direct connection to readers. With the Dragons Out book, the word about the need for software testing for children must spread out through the testing community, IT community and the school community. This is my task. I ran a second round of the donation campaign in late January ending up with donations to 60 schools in Finland. I simplified the message to that you could preorder books through me for any purpose and optionally donate a portion of those books to schools. Additionally, I personally donated one book for every three sold books (which I can afford to do for Finnish books).[xi] So, currently I’m preparing for the English publishing date, talking to lots of people, surveying the Finnish readers, being present in social media and many events.
4
How to use
fantasy to teach software testing
The book tells a growth story of two 10-year old children, Laura and Tom, from kids into knight apprentices. They learn about dragons and knights fighting those dragons, and get into real action themselves, too. They get help from male and female knights and a wise old sage. The stories take place in a setting resembling medieval Europe. As these fantasy stories unfold, I explain to the readers the software development and the testing world in analogies or parallels.
The structure of the book is straightforward. In each chapter, I first tell a fantasy story of a new dragon, and how it is banished from the village. My storytelling is complemented with the amazing illustration from Adrienn Széll. I explain the analogy of the story into software testing and development in side-boxes that are available for reading as one reads the story, or afterwards. How is this kind of software defect found through testing? Why is it harmful to software? How can it be removed? As new computer, testing or development terms are mentioned, I explain them as simply as possible in a vocabulary. At the end of each chapter, there are a few exercises for learning the software testing topics a bit better.
Below I use a few extracts from the book to describe how a fantasy concept turns into a software testing concept.
4.1
Dragons
are defects
The red dragon of the story is a defect, which is the cause of the memory leak. So, the memory leak is a failure in the behaviour of the software. The defect in the code causes the failure. The developer has made an error in her coding, thus creating the defect. The developer can remove the defect by writing the code in a better way. Respectively, the dragon can be killed or vanquished. Defects are sometimes called bugs.
4.2
Team of
knights consist of developers and testers
The software development team has divided the tasks of software development in a way that everyone gets to use their unique skills. Yellowbeard can design and build the palisade. He is a typical developer, exceptionally able to design and code software. Swanlake also knows how to find dragons. Out of all team members, she has the most testing skills. She can find defects.
4.3 Villagers spot dragons, users are testers, too
Swanlake turned her horse around and rode quickly back to the fortification. She said to the knights who had been helping her and to Master Aidan that the dragon was coming. Villagers should immediately gather all sharpened logs at the palisade opening. Whoever had spears or swords should hasten to get them. People should reserve as much water as possible in buckets. Then she went looking for Yellowbeard in the castle. Tom took over the task of informing the villagers. He ran around the village, shouting, "A dragon is coming, water, spears, and swords are needed!"
Users often help the
software development team. They can find defects that developers and testers
can't find. They can also tell which of the defects are most important to fix and
what to do to them. In the story, Tom warns people of the dragon and emphasizes
the importance of defeating it by spreading the word of water buckets, swords,
and spears.
4.4 Ladies and Lords request battlements, like product owners
On a beautiful spring afternoon, a pair of armoured men, Knights Amberhat and Strongrabbit, arrived in the village. The knights were offered an unusually spectacular meal at the castle, after which they listened to Margaret's suggestion. "Stay at my castle and build a great wall for us!" Margaret asked. "We have a lot of wood in the forest for building material." He promised the knights, "You get a double reward, plus you may live a full year here in the village."
Lady Margaret is the product owner of the software. She asks for a wall. In the world of software, the product owner often has, respectively, a rather vague requirement, which the software development team must clarify.
4.5
Different
ways defeat dragons, or remove defects
Be that as it may, the knights were right about the dragons. As soon as they had erected the first ten meters of the palisade, little dragons appeared to bother the construction team. The dragons were green and glittering creatures, about the same size as dogs. They had large leathery wings, with which they flew around with ease. They were breathing fire all the time. Albert was the first to notice them, for he had taken the habit of observing the construction on the roof of a nearby house. He guided the knights by shouting, "Dragons out!" Albert thought it would be better to drive the dragons away rather than kill them.
People notice that there are many different ways to defeat dragons. You can anticipate their activity. Similarly, many defects in software can be expected and prevented by considering them ahead of time. Albert notices the dragons first. This testing done by a user is acceptance testing. In many cases, the developers of new software rely on user testing, especially if the software is for a single company.
4.6
Different
types of dragons, or defects
All you
could see were flames. One barn was in flames and about to collapse. The wall
of the house was burning, too. Then the wall began to burn at a different spot,
with an intense burst. And right after at a third spot. The roar intensified,
and they saw a small black figure floating in front of the wall. As it moved
closer to the burning wall, its black bat-like wings and long, snaking tail
were visible. A white glow came out of its mouth, which again lit a new spot on
the wall in flames. Dragon! Laura was sure, even though this one looked
different from the Sheep Valley dragon, which she had seen slain.
A security defect
allows an attacker to gain access to the system. Similarly, the darkness and
black colour help the dragon remain unseen to blast its flame into the walls to
get access to some food. Malicious attackers, in the world of security testing,
are called black hats, and so the dragon in the story is black.
4.7
Experience
helps in finding dragons, or defects
At breakfast, Laura and Tom began talking over each other as they hurried to say, "What if the dragon ...", "It flies ..." "The bars disappear ...". Ted calmed them down: "Kids, kids, one by one." Tom said that they thought the bars disappeared in the afternoon as they cooled behind the smelter. Laura explained that dragons know how to fly and that they like gold. Together they said that the dragon is the thief! Uncle Ted was a bit sceptical, but Laura's father, Wayne, said the kids might be right. He reminded them about the events of Sheep Valley and Fish Lake. Tom's father now also remembered Tom's earlier stories about the visit to Forest Castle.
In the story, Laura and Tom have encountered dragons before and are, therefore, able to help solve the theft of metal bars. Experience also helps in the real world. Performance defects are often straightforward to detect when you have experience in performance testing.
Comments
Post a Comment