Last week, my first graders developed their Scratch code, and their game designs started to take shape. They learned a little more code, and a lot more about communication and collaboration! This week, my aim was to support the students in developing their groupwork skills by ensuring that each group member had a specific role.
Today’s learning: Software engineers test their code
Last week, the students added a lot of code to their programs. Problem was, most of it didn’t work. Although the students had picked up the Scratch interface very quickly, simple mistakes prevented their games from being playable. I wanted the students to understand that just as good writers re-read and edit their writing, good coders test their code to check that it achieves what they originally intended it to achieve. If you missed them, click the thumbnail to download all of our learning outcomes for this unit.
Step 1: Testing
After explaining the importance of ongoing testing, I divided each group into ‘testers’ and ‘coders’ and discussed the specific responsibilities of each role. Testers would be responsible for finding out whether the code worked as intended, and reporting their findings back to the group. Coders would be responsible for listening carefully to the testers, fixing any problems found by the testers. The coders went off to work on a different activity, while the testers received their ‘tester checklists’ and got down to work testing their groups’ code and recording their findings.
Step 2: Reporting
Armed with their checklists, the testers and coders met to discuss the testers’ findings. This was where communication in the class got really interesting. Some of the testers immediately saw why the code was not working, and wanted to fix it straight away. Some of the coders wanted to ignore the bugs and just work on adding more code. However, the clearly defined roles of tester and coder helped the students to work together without too much conflict over who should do what. Click the thumbnail to the left to see some of the great feedback the testers gave to the coders! Once the testers had reported their findings, they went off to work on another activity, leaving the coders to do their jobs.
Step 3: Bug-fixing
Following the testers’ feedback, the coders got to work making sure that all their sprites were a good size and had a set starting position. Having a specific, finite task helped the coders work together in groups of 2 or 3 without too much conflict. We continued using the ‘turn tokens’ for some groups to make sure that everyone got a turn adding some code. As a reminder, the printable commands that students need to set the positions of their sprites can be downloaded here. By the end of the hour, all groups had a working game, and were able to move their sprites around using the arrow keys on the keyboard. We met as a class at the end of the lesson to test everyone’s games. They were all different! While most of the groups had chosen an animal or person as their main sprite, we did have one game featuring walking bunch of bananas as its main character – got to love kids’ imaginations!