Oct 7, 2014

Software QA and Testing SUMMIT 2014

I participated in a Finnish QA and Testing conference. It was actually my first related to this subject. Never the less, I found the presentations to be really interesting. (The conference would actually last two days, but unfortunately I can't attend the second day.)

IT Quality from the Management point of view - Quality Assurance is much more than testing


The first keynote presentation was given by Reni Waegelein and Karri Kolehmainen from Veikkaus. Veikkaus is a Finnish provider of gambling services. The only one of its kind, they have a monopoly. Maybe the main topic was that the business is moving in ever faster pace. Earlier things happened weekly, like the Finnish lottery (Lotto-arvonta) and the main co-operation partner was post office. Now playing and transactions happen almost every second. There are 300 million gaming events per year.

So is it worth investing in quality (assurance)? It depends. One should always consider what we can achieve with the testing and what we could lose if we don't. What and how big are the risks? According to Waegelein it's not necessary to have the site always accessible. But keeping people's transactions secure is a must.

The perceived quality or the impression of it is more important than the actual level of quality. A lot of it is psychology. People usually remember from their experiences three things: the worst thing, the best thing and the end. Essential part is to find the critical situations where the quality needs to experience good quality. For websites it's usually the arrival and departure from the site.


Usually failures make good stories. They told about a time when after the Keno lottery broadcast was already over, one the official administrators found a ball outside the lottery system. In essence that meant that for customers who had played with that number there had been absolutely no change of winning. So they decided to redo the lottery. But because official results had already been announced they couldn't help but give out the winnings for the past lottery. They took a big financial hit and had to make a lot of manual work, but I think it was indeed the best choice all things considered.

Another thing they wanted to clarify was that testing doesn't produce quality. During their last big release efforts before jumping into more agile way of doing things they spent 25 thousand hours on testing a release! And when they wanted to do things differently some people thought this safety net was taken away.

But to be fast, the focus needs to move to an earlier stage. Quality assurance needs to start already during the development and even before. It needs to be part of every project. When testers are involved already at the planning it more easily means that only the necessary parts are implemented. Usually normal Product Owner would specify the product up to 130% and end up adding even more. With the testers are involved in this it's easier to stay focused.

They don't have people separately responsible for test automation. Everyone knows how it works and everyone is responsible for it. The cases are written in Gherkin which is easy to understand even for non-coders.


The Agile Project Model of Veikkaus is a combination of different methodologies. It combines selected practices Lean, Agile, Scrum, Kanban and XP. They were also aware of the Scaled Agile practices and familiar with the things happening at Spotify. Many of the things sounded really familiar. We have been studying and experimenting the same practices.

After the presentation there was a round table around the vision and future trends of testing and QA. One comment was that QA seems to nowadays be almost a synonym for all the other software development activities except testing. People had also noted that in some places people have widened their job descriptions. They aren't anymore test engineers or development engineers but just engineers. Reminds me of Scrum and everyone in the team being a Developer. The importance of (test) automation is increasing.

After a coffee break there were a couple of short presentations by tool providers. I'm not going to advertise those here, except I want to share a couple of cool pictures. Ulf Thornander talked about the tightening pace in development. We are moving from Continuous Integration to Continuous Operations. But I think this is a bit hard to reach for certain types of business, but anyway a good Roadmap for the future.


James Fenton talked about how we should integrate testing into Continuous Delivery. There were a couple of good slides, but I personally liked the one about moving testing to the left best. It's so much cheaper and productive to find the defects when the product hasn't reached production. A no-brainer, but still somewhat hard to do in real life.


How to get Quality Assurance included from the beginning of the Project?

Maija Sanisalo from UPM concentrated on the human part of QA. She told that a good QA person is visible. That's how (s)he gets involved and hears things. Having people with great skills isn't enough. They will need to be able to work together. And the quality assurance needs to be part of people's daily work. As an amusing side note she mentioned how it's important to decide that 'today is going to be a great day' and start your day with a Peter Pan or a Winner pose. It will affect your mood and consequently your whole day. (People might also think you are crazy, but you shouldn't care about such petty details.)




CASE Nokia: HERE Maps for Windows story: How to adopt changes without scarifying quality

The last presentation I had time to enjoy was held by Tatiana Smekhnova from Nokia, Germany. She's the QA Lead of the HERE maps. According to what I heard, Nokia has done some remarkable improvements on the empowerment of people. Or maybe HERE Maps is just so small unit that things are easier to change there.


The quality of the application is the responsibility of everyone. Processed should help in this. They had a challenge with regression testing. It could have taken five days to complete. But when you create software in short sprints, five days is way too long. So they set a challenge to shorten the time to one day.

They seem to really live according to agile values. Team makes decisions together, they review their Definition of Done regularly and they have working Retrospectives. One particular example of team making decisions about their own ways of working was that they decided that meetings should take a maximum of one hour. From the principles Tatiana showed in her slides I found also lot in common with the Management 3.0 principles. Face to face meetings, setting goals together, improving everything. I guess many people have read the same books. Maybe they are indeed good books. At least I personally believe so.

All in all as a conclusion Software QA and Testing SUMMIT was a good investment of my time. In addition I had opportunity to speak with interesting people and find out new things. Actually this left me hungry for next year. :)

No comments:

Post a Comment