Vojtech Barta's talk at SQA Days EU

Our QA Manager, Vojtech Barta, attended and delivered a talk at the event SQA Days EU, which took place on 22 and 23 March, in Riga, Latvia. Read his testimonial and keep wired in the world of software Quality Assurance!

A few days before…

“Before this event, I had attended several SQA Days as a speaker, both in Russia and Belarus, and I really enjoyed the experience. I was excited about the first SQA Days in EU, so I submitted my talk almost a year before the conference.

I arrived in Riga two days before the Conference, to have some time for sightseeing. The city center is quite small but nice. There are many narrow streets, churches, bars… and of course, beer! I met with a few other speakers and we went to something called Latvian beer tasting. Interesting concept. Some of these beers were really good. But let’s talk serious now.

As always, I have collected some ideas below or sometimes quotes, sometimes my own associations. I never remember exactly the categories after the conference.

A parallel of Rally Dakar and Agile – the rediscovery of DoR & DoD – Vojtěch Barta

I really enjoyed my talk. There was a good atmosphere in the room and many interesting questions.

Day 1

My talk was scheduled for the second day of the Conference, so I had an opportunity to attend other talks on Friday. Here I have summarised what was interesting for me.

Reinvented Regression Testing – Gjore Zaharchev

His talk was a good summary of regression testing, but there was no reinvention at all, and that was a bit disappointing. He did, however, offer some food for thought:

Some things are useful, some things are useless. It is hard to decide before you try it.
Why is the effort of regression testing growing sprint by sprint? Does it have to grow?
Do we need tests which do not find any defects? Or are they a waste of time?
A “Retest all” approach is, in a simple word, crazy.
Defects become immune to the same tests rather quickly. It is like bacteria with antibiotics.
Is the overhead of regression testing really needed? Does it pay back?
There are heuristics for regression testing which can help:
- Recent = what is new and what is affected?
- Core = what is really critical?
- Risky = beware of things which are or could be risky
- Configuration = what is environment specific? Why?
- Repaired = what do I need/want to test due to bug fixes?
- Chronic = common, solve it!
- Data migration = new things need to work on old data. Do not use new data for testing if not necessary.

A final advice by him: Do not mix normal testing with regression!

Strategic Agile Thinking – Michael Pilaeten

I enjoyed this talk very much. It was on a good topic, quite relevant for me and my job. I would just welcome a bit more examples. Here are a few notes about his speech

Many companies are in transformation but many are not transforming.
Agile is a mirror which shows you both, achievements and problems.
In general, people are not happier in Agile.
Even on so-called Agile projects we often do the following mistakes over and over

We start too late
- The lead time is much shorter than the process time.
- We should get focused and start sooner.
We do not know when to stop
- Concord example = from the start they knew it is and will be a negative margin project. But they continued for a very long time.
- Sunk cost fallacy – The money you already invested is gone. Do not get trapped.
- Making software is like playing poker – you only have the chips you have now, nothing less, nothing more.
We do not know what we want
- The survival of the fittest does not always work.
- We all make bad choices, sometimes very bad ones.
- Minimum viable product = there is a wrong negative feeling about MVPs, and there is also a problem to understand what that “V” means.
We cannot predict Quality
- He recommended a Book by Ben Linders – What drives quality.
- Requirements need a commitment from the entire development team.
- The sprint backlog has to be stable, so the team can work with it.
We do not like change
- Welcoming change requires being out of your comfort zone
- Developers should test, testers should code. We should get rid of roles and focus more on the activities and on understanding each other at least on a basic level
- There is no democracy in a change
- It is enough to motivate 25% of people to start with a change = do not wait for the rest!
We start too big
- Make your sprint backlog as simple as possible, to make it achievable and not unrealistic.

Help! We have a QA problem – Niels Malotaux

I liked to content of the talk but it was difficult to follow the slides – they had a lot of text, bullet points, etc. These were some of his advice:

If intuition were perfect, we would not make mistakes
Testers, whenever you are a bottleneck, imagine you have an entire company at your disposal to help you and act like that. What would be your plan then?
For whom are we delivering? Is that particular customer really important and does he really need it? Choose your fights carefully.
Empower your testers.
You cannot change history! If a match is over you cannot score a goal.
Never ever work overtime, we should work less, not more.
You cannot fight with reality, you have to work with it.
We do not have enough time, but we can save it.
Feature boxing is opposite to timeboxing.
Deadlines are important because we need boundaries.
Quantify everything.
Any data people put into the computer means people lose control over them. Whiteboards are under control.
If somebody is watching over your shoulder to help you, you make fewer mistakes and you are more productive.

Strategic Retrospectives – Mette Bruhn-Pedersen

She delivered a very interesting talk, where I grabbed three interesting sentences:

Retrospectives are much older than Agile.
An interesting Tool – Menti.com
Do surveys before Retrospectives or even more often.

Mission Possible – Olivier Denoo

I attended only half of the talk and it was a good one, in my opinion. Here are some highlights:

A team is a collective intelligence.
Society and mentalities evolve and should be the most important investment = People first, not technology, business or visions.
Most of your customers know nothing about IT, most of them do not even care about it. But they are people and they care about people.
Communicate openly inside a team = taboo free.
Perceptions are real = you have to integrate and work with them.
Allow catharsis.
Think different, be different.
Envision future.
Disapproval can be active or passive. Passive is much more dangerous because you cannot react.
Create a “Like, do not like” board at the office. Then whoever wants to can fix it
Rephrase everything = express your understanding. Sometimes you think you understand it but if you try to rephrase it you find new things or the others will correct you
Activity – news / fake news sharing and proving over an entire company
Almost any activity requires moderators or facilitators.

Bug Hunting – Szilard Szell

A lot of nice ideas but also fun, as always.

There should be regular bug hunting sessions in every company
Reliability is always in context. In Nokia, it means max 4 minutes down per year, including maintenance.
Exploratory testing is goal-oriented wandering.
In the exploratory mode, you test something, not everything.
Game – Story Cubes
- Create your own cubes and make test cases by randomly throwing them.
- How crazy do you have to be? Again, context!
- There is also software for this game.

The system has to tell you what is wrong when something is not working
Bug hunting should be done after it is already tested normally and fixed. Otherwise, it would be crazy.
Bug hunting is also about motivation and team-building. It has to be fun.
You then have to deal with the findings.
Issues is not a bug, you have to confirm and verify issues before you have a bug. Approx ½ are not bugs.
Do a bug hunting after a training, workshop, etc. to apply your learning immediately
Transparency = doing bug hunting with your customers.
Automation gives you more time for exploratory and other valuable activities.

Day 2

I had my talk in the afternoon so I could not attend all of the talks, but I visited at least a few of them.

How to improve your organization with TMMI – Karolina Zmitrowicz

It was a good introduction to TMMI. However, it would have been much better with real examples and lessons learned.

If you think you are right, you are wrong.
Things we are used to could be wrong.
If you are planning but not doing, you are dying.
Standards are not bad if used in the way they were created for.
Every higher level of any maturity level have to really aim higher than the previous one, and it should not compromise things which have already been achieved.
Glossaries are a very important tool because then everybody uses the same language.
If you use “more-less” always understand both “more” and “less”
A User Story is ready when the team agrees and is ready
The first step of any improvement is to understand the current situation and why to improve it.

User Experience (UX) Testing is not Rocket Science! – Baris Sarialioglu

This was an excellent talk. The speaker was great and some of the ideas and jokes were brilliant.

Life is a test and every human is a tester.
The first testers were Adam and Eve and they were not scared – they ate the apple and got expelled from paradise. Test passed and God was not a lier – it worked as promised.
The most important UX Rule = value > pain
Everything hurts.
What users do is not what they say.
UX testing is always grey, it is never black or white.
Admit it! You are not a user and they are often far away from your understanding.
There is not a single tool (so far) to evaluate confusion.
Users are strange and not always right, but they always have a point.
Users do not hate change. They hate you if the change you bring does not make their life easier.
The assumption that more features bring more freedom is wrong.
Freedom is dangerous in software.
If you are promoting some group of users, make sure the others are not offended.
Silly questions usually do not have meaningful answers.
UX is bigger than usability.
At first, it needs to work, and then it could be usable.
Select your users for UX sessions based on behavior. Nothing else matters.

AI for Testers: the future today – Joel Oliveira

It is hard to be just a tester, but that is what we should be sometimes.
AI is not an intelligence, it imitates it.
It starts to be exciting when computers do things which are usually performed by humans.
AI is not yet real, but the hype is.
C-levels talking about AI are often the same guys who told you to go Agile because it is faster, cheaper and cool.
Machines cannot explain their thinking, they might have an answer but they cannot explain why.
Sometimes things are too smart, especially AI can think its idea is better because it is smarter, but people would work in a different way because we are not so smart.