DevOps Diary: The Ministry of Testing

Boris in a circle.gif

Boris Levanov describes himself as a "bug finder", but his real title is Test Engineer. He has worked in software engineering for over a decade. He moved to Scotland in 2005 from Latvia. When not plugged into his laptop you can find him cycling across Europe.

Ministry of Testing Meet Up.jpg is a website for people with all kinds of interests and hobbies to find groups of local people who share their passion. Since I’ve moved to Edinburgh quite recently and I’m always keen to meet other developers and testers, I decided to attend The Ministry of Testing Meetup group, which was just five minutes away from our office.

It is always a slightly nervous experience to arrive alone in a room full of strangers, and I was completely unsure what to expect, but I went with a positive outlook, with prospects of gaining new insights into testing techniques and procedures.

I got to the venue about 10 minutes before it started. However it took me a good 5 minutes to find the actual entrance. Thankfully, one of the organisers of the event, Craig from Aberdeen Standard Investments, saw me wandering about and pointed me in the right direction. I got there just in time for the mingling to start. I met quite a few different testers from other companies, all of which turned out to be very friendly. A few people mentioned hearing of E Fundamentals; our new User Interface is already well known around as being really good!


How to make the best of an interview with a tester?

With cold refreshments and slices of pizza in our hands, we gathered in front of the presentation screen. Simon from Scott Logic hosted the presentation, which focused around how difficult it is to interview a new tester for a company, while being limited in time. He then offered us to participate in an event, which focused on choosing a set of activities to identify the qualifications of an interviewee.

The event consisted of trying to identify the traits necessary for a tester, who is being interviewed for a specific position. For this activity, Simon had a set of playing cards prepared, which he designed himself.

The rules of the event were as follows:

  • Each team had to pick a type of tester they were interviewing: Junior Tester, Senior Tester, Automation Tester and Testing Team Manager

  • All tester types have had the same subset of cards with skills we could interview about, but we could only pick three skills

  • Each team had 10 minutes to select three most appropriate skills

Our team has made their choice within the first couple of minutes. For the rest of the time, we discussed which skills could serve as a backup, in case something goes wrong (i.e. internet/electricity goes down during the interview, or the interviewee is uncomfortable doing a specific task, etc.)

This particular exercise was quite useful to understand the set of skills needed for a specific tester role. It also made us appreciate people who have to make a difficult choice of whether the interviewee is a good candidate for a position in question.

Once ten minutes were elapsed, each team presented and justified their choices. Since our tester type was the Automation Tester (depicted by an android), we made the following selections:

devops diary - cards.png


Lean Coffee

Lean coffee is a type of conversation that teaches people how to use Agile Methodology for discussions. It involves creating a set of “user stories”, which are then pinned onto the mini-agile board with the three lanes: To Do | In Progress | Done

The stories can be about absolutely anything, as long as it facilitates a friendly discussion within the team. Each member then gets two votes to pick which of the user stories they’re interested in. Each story gets exactly 5 minutes of discussion.

For this event, we’ve decided to mix things up: the group composition was different from the first event. After writing up the stories and performing votes, we ended up with the following topics:

  1. Python vs JavaScript for Selenium testing

  2. RPG Video Games

  3. Continuous Integration and Delivery

  4. Team Cultural Diversity

Each of these topics facilitated quite interesting discussions, and each team member has gained something valuable from all of them.


Testing as a Part of DevOps

After enjoying meeting the Edinburgh software engineering community at my first Ministry of testing event, I was excited to return for another presentation,  which was titled “Testing as a Part of DevOps”.


DevOps Doughnut

The main speaker of the event was Alister Aitken, principal consultant from Edge Testing. The focus of his lecture was the constant change of the modern technology: how it keeps evolving, and how some software development companies are struggling to keep up with the change, demonstrated through visual representation of the DevOps Doughnut.

devops diary -donut.png

(image courtesy of Edge Testing Solutions)


This diagram outlines how some of the successful modern companies operate using a continuous integration cycle: it’s a continuous development process, and each member of the team can contribute to each part of the cycle.

devops diary - Alister Aitken.png

In the past, says Alister, testers used to operate within the “on-demand” type of scenarios: developers complete their code, compile it and release into the testing environment, at which point the testers are starting to use their skills. However, this could create the situations where testers would be unable to perform any work, especially between larger release cycles. Alister even mentioned that they used to play dominoes during some of those “downtimes”.




Alister Aitken and DevOps Doughnut (courtesy of Edge Testing)

T-shaped people

Modern, agile IT world isn’t as forgiving to such waterfall-like development environments; users want high quality software, and fast. This is where the so-called “T-shaped people” come into play.

devops diary - tshaped.png


The idea behind this concept is that every person within the development team not only specialises in their core discipline, but they also know a little bit of everything: i.e. a developer can sometimes test, and a tester can sometimes plan or write code. This makes the entire team able to constantly contribute and work on something, even if their core area of expertise is “blocked” by another part of the development process.

Such approach allows the entire team to function as a single, well-oiled DevOps machine, which constantly self-synchronises between the different sub-departments. Thus, they are able to release quality software faster, and identify any potential issues before or during the development process, rather than at the User Acceptance Testing stage (in which case the deadline can be significantly affected).

At the end of this presentation Alister encouraged the participants into a few discussions, which were quite enjoyable and made people think outside the box. After speaking with Alister and other participants, I came to a conclusion that our teams already (and almost subconsciously) operate using a principle similar to the presented one, which really surprised me!



devops diary notes presentation.png

After the presentation, Ali Hill (co-organiser of the event) asked everyone to participate in an activity. We were split into 3 teams, and each team was given a drawing board with a DevOps Doughnut on it. Each of the teams then had 20 minutes to identify:

How would a tester be able to contribute to each stage of such development process?

Each member of our team participated in the discussions, while I outlined all the points on the board. At the end of 20 minutes, we all presented our conclusions to the rest of the teams. Listening to other teams and asking them questions made us aware of any potential gaps in our understanding of the presentation, which everyone welcomed.

In the end, everyone left with a whole range of new ideas and a new determination to make their DevOps teams even better!




This set of activities and presentations at the Ministry of Testing Meetups were very useful to broaden my understanding of testing as a whole, and allowed me to make new friends within the software engineering community in Edinburgh. There are more events that are coming up which I will definitely attend.

When discussing the T-shaped people concept, I realised that in the spirit of developing “broad ability to work outside of core area”, that everyone could benefit from these events, not just testers! To join any of the Ministry of Testing events in Edinburgh, just go to the following URL:

More from the blog

EF Marketing