Spoilers are coming! Please be advised that this blog post will include details of major events that take place in season 8 episode 3 of Game of Thrones.

This weeks episode of Game of Thrones saw the long awaited Battle of Winterfell. This was easily the biggest battle ever seen on TV, rivaled only by the Battle of Helms Deep and the Battle of the Pelennor Fields in Lord of the Rings.

During the last week, there has been a discussion on the Ministry of Testing Club about the testing pyramid. I guess the excitement of Game of Thrones, and the test pyramid discussions, caused me to mix the 2 together. During the battle, I noticed how the strategies used could be compared to the different levels of testing and the testing pyramid.

Software Application/Winterfell

Let’s start by looking at the way the battle is setup. We have the castle of Winterfell, and the battleground outside the castle. If the castle represents the user interface of the software application, the area outside the castle represents all the code and modules that make up the application. Inside Winterfell we have the crypt where civilians who are unable to fight are hiding, and the Godswood where Bran Stark is. These areas represent the live environment. The opposing army, made up of Wights, White Walkers and the Night King, represent software bugs. The bugs must not reach the live environment.

Unit Tests/Dothraki

The battle starts with the Dothraki charging towards the opposing army. They are fast. But, there are limits to this tactic. Some Wights are killed off early, but the majority make it through.

The Dothraki represent unit tests. They are quick and cheap to run and, just like the Dothraki, are usually the first tests to be run. They normally only cover individual units within the application. This is demonstrated by the fact that the Dothraki were only able to attack a small number of Wights at a time.

Integration Tests/ Trebuchets, Fire Trench, Northern Armies and Unsullied

The next line of defense contains a combination of armies, trebuchets and a fire trench.

These are a little more successful than the Dothraki, but that success is still limited. The armies are forced to fall back and light the fire trench. This holds the attacking wights back for a short while, but they soon find a way past the flames.

This second line of defense represents the integration tests. They test individual combined units and are run after the unit testing. Unit and integration tests are meant to catch bugs as early as possible. Bugs are easier and cheaper to fix the earlier they are found and fixed.

UI Tests/ Walls and Castle of Winterfell

The Wights have now reached the Castle, and attempting to gain entry. They are defended by several characters who were positioned inside the walls, but there are not as many defenders as there were outside the walls. Those defending the Winterfell are positioned around the north gate and on top of the walls. These are identified as the 2 areas most at risk. These are where the Wights are most likely to enter the castle. The Wights eventually succeed in breaching the north gate.

The castle of Winterfell represents the user interface (UI), and this phase of the battle is where the UI testing takes place. The UI is part of the application that the end-user will actually see and interact with. There are fewer tests at this stage (as shown in the testing pyramid), and the cost of running these tests is also greater. There are areas of the application that are at greater risk, and this is where testing has the most focus on. This is the last opportunity to find bugs before the application is released to live.

Regression Defects/ Resurrecting the dead

The Night King eventually makes it into the castle and is able to resurrect the dead, turning them all into Wights. This includes the dead buried in the crypts, where the helpless civilians are hiding.

These represent regression defects, bugs introduced to the application as a direct result of bug fixes and changes. Crucially, these regression defects have now found their way into the live environment (the crypt).

Live environment/ Crypts and Godswood

The whole purpose of the battle has been to stop the Wights, White Walkers and Night King from making it into Winterfell. It is especially important that they don’t make it to the crypts or Godswood. We already have several Wights in the crypt, and the White Walkers and Night King are making their way to the Godswood.

If the wights and white walkers represent bugs, the Night King is a critical one. The aim of testing is to allow as few bugs as possible to make it to live. We certainly don’t want any critical defects making it this far. The result of the Night King finding his way into the castle was the death of several people hiding in the crypt, and anyone who was in the Godswood defending Bran.

The cost of fixing defects drastically increases the later they are found. A critical defect can be devastating to both the user and the company that released the software. For the customer, there can be fear, concern and loss of confidence in the product that they have purchased. For the company, even when the bug has been fixed, the damaged reputation can take years to heal.

The importance of early testing and defect detection

It is important to test early and test often. Don’t just rely on one level of testing. There should be multiple layers so that bugs can be caught and fixed as early as possible. Fixing bugs early reduces development costs, and improves confidence in the product.

The critical defect/Night King made its way to the live environment. Fortunately, a large number of Wights/bugs were killed before making it to Winterfell. This reduced the overall impact, allowing Arya Stark to kill the Night King and save Winterfell at the last minute.

Testing pyramids

 

The testing pyramid model demonstrates the ideal balance of various automated tests. Unit tests are usually the most reliable, require little maintenance, and are quick and cheap to run. UI tests tend to be slow to run and require a lot of extra maintenance, which can be costly. In theory, we should be automating more unit tests and fewer UI tests. 

In the Battle of Winterfell, the main fight effort took place in the second phase of the battle (Integration tests). The number of Dothraki (unit tests) involved in the first charge was low. The Dothraki charge was impressive, but had little effect on the attacking army.

As previously discussed, the earlier bugs are found the cheaper they are to fix. Unit tests should not be neglected. They can help detect bugs earlier, reducing project costs, and improving the overall quality of the application.

 

What are your thoughts on this comparison to the Games of Throne’s battle? I would love to hear in the comments below!