Test Retreat

Welcome to the homepage of Kris Corbus

Archive for the category “trainer notes”

Let’s Talk About Certifications

I am trainer*. I train people for ISTQB, IREB and other certifications. Company, where I work, offer practical sessions as well, but very few buy them. It is cool to have a paper, not a skills. Everyone who tries to prove me wrong, I ask, when did that person last time invested own money in own professional skills.

Partly this is the reason why I became a trainer: to change understanding of software quality for people, who are pushed to get certifications. I am trying to show, that training paid by company can be valuable and interesting. Another reason is, to inform new people about online resources. I know Rosie Sherry for some time, two years ago we did business together and I admire her vision and job she had done with building platform for testers. One day she shared that many testers say they wished they found out about Ministry of Testing earlier and we thought how to achieve it, because many testers I met never heard about testing community. Myself – I am still looking for requirements people group, no idea where they hide… Anyway, I chose my way – to be a trainer, to train for certification and to teach about software quality, about people behind scenes, to share book titles and addresses of blogs, online tools and platforms.

I like to challenge my trainees and ask why they choose this training. What expectations they have. What will happen/ change if they will get a certificate. I also like to talk about alternative certification, by building up their own brand and letting their whole work be a guaranty of good job. Do not wait until somebody will certify you, do it yourself! Take Mark Tomlinson as example. In his workshop Mark told us stories about his reputation as “something with performance guy”. If something happens which could be related to performance and no one in a company knows what to do else, he gets a call from business people and question “what to do?”, sometimes he has only an hour or so time and one chance to suggest an action. If it works, he gets the job, if not, he is out. James Bach sums it up : Reputation = opportunity = money.

So why people do not brand and certify themselves? If we try to name testers in automation, how many names will you know? Maximum 5-10? The same with any other aspect of testing. Why? Because branding is not testing and if you want to brand your testing you need to learn new skills. What is your message? How do you present your topic? Who is your target audience? Those are just few questions you should be able to answer.

I have different results with different target groups. When I left my previous company (400 people), CEO was surprised that everyone knows my name and my subject. I worked there for 2 years and my name meant QA and opposite. Today, 2 years later, when I meet somebody on a street or swimming pool (…) they greet me and start to talk immediately about testing tools or practices. It may sound simply, but it took a lot of energy and I talked literary with everyone, not only with developers and managers. Based on that I would say I know how to brand myself in local group. In testing community my name is unknown and I have not brand it really yet.

For those who come to training only to get certification, I say that I am very good in training people for certification, but I also say that certificate will not make them better testers. Certificate is a proof that they could answer 40 (45) questions in 60 (75) minutes and at least 65% (70%) of those answers where correct. Thats all. I also remind that one training does not cover ALL topics about software testing or requirements engineering.  ISTQB Foundation level syllabus had paragraph “code of ethics”, which talks about public interest and includes also following statement: “certified software testers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession”.

* one taxi driver looked at me very critically and said: you and trainer? It turned out that the address I named has gym in a basement, he knew it and he thought that I am saying that I am fitness trainer.

Trainer Notes

Agile Testing Quadrats

Weeks after Agile Testing Days were pretty intense. Every week another training. Business as usual? No. I do not know why… was something in the air or was it my students, or myself. We tackled agile and dig really deep. To experienced and guide it, made me very vulnerable.

To learn means to leave comfort zone and to realised that what we did so far was not OK. Learning can make you feel big discomfort. That feeling is not a good feeling, so sometimes to get it go, people turn the anger to the messenger. Trainers and coaches need to learn how to deal with it. Another thing next to anger is struggle. I see struggling people, who want to be really agile, not only on paper, but they have no idea how to do it in their environment. Sometimes I do not know which situations are harder – anger or struggle, but definitely since I attended Agile Couch Camp this summer it is easier to deal with situations like those.

Week before Christmas I had a group of people who had especially big emotional debt. No matter which topic we were discussing, it went back to the old stories about orders, ignorance (from managers) and silence (from employees because it does not matter if they say something). This group was special with another thing – there was one of managers sitting with them. She is one of the new managers, who joined the company not so long ago, but still – a manager. First day she was all about denial. Everything, what group said about bad practices, missing communication or management, was not true. On second day she started to listen and at the end of the day she said: “now I see that we have communication problem”. She realised that to talk or to share ideas is not enough with people, who were misused for a very long time. They do not believe you and they listen to something else. On third day the manager was missing for the first part of the day. I used the time and asked the group to reflect on training and how the manager reacted. It was interesting to observe that they collectively realised that maybe there is real change coming. The training they got, the manager, who listens when they complain and reacts when she realise something wrong. I felt very privileged to guide them through this moment. Felt like real transition to new level.

At the very end of the training group asked me for tips how to stick to ideas and how to keep agile spirit vivid. Maybe because of approaching Christmas or because of this something in the air, this time I chose to share story of my own vulnerability, my own struggle and my own insecurity and my tricks how I keep going and where they could look for tools what would help them to create a positive agile habit.

Sometimes giving a training can be exhaustive… but I still like it.

Dare To Question!

More then month ago together with Lisa Crispin we run a workshop “Questioning requirements: improving quality for everyone”. The reason why we came up with this workshop, was to teach and to empower people to question requirements. As a tester I know how important is to question statements, ideas, requirements, designs etc. As trainer I know that with a lot of confidence you can run for presidency.

This is the story how we did that (without particular details in case you want to take the workshop in some other event ;) ).

Setting up

We had some challenges: we did not know how many people will come to our workshop and our time block was less than 2 hours. We took those restrictions and created a workshop, which we could easily scale. At the SwanseaCon we had around 32 participants, which we divided into 6 teams. Each team had a particular context to role play in a simulation. We emphasised that we wanted people to experiment and have fun. We tried to build safe space to learn and to try new things. We presented several tools that participants were invited to use to explore stories and to structure conversations with stakeholders (you can download them here). They were also free to use any other tool or framework they prefer.


We explained that we as “stakeholders” wanted to create an app and gave each group a list of desired features. In our background story we used words like “deep analysis” and “market research”. User stories were written in ambiguous way with aim to provoke the need to ask questions. The task was to create a release plan, creating stories for the features. Especially noting what feature they would like to start with.

how it went

All groups were extremely motivated, except one. There were lively discussions within the table groups and it was interesting to observe team dynamics. Especially interesting was to see that the group which struggled the most – none of them left the table or whole workshop. They were struggling together till the end. Another interesting thing – we as stakeholders got not so many questions as we expected to get. Just like in companies, our fictional teams were so busy working that they forgot that stakeholders are there in the room… We tried to interact with the teams, but nobody wanted our help and it looked more like we are disturbing them.

After simulation was accomplished, each team presented their release plan. or the process they come up with. After that we started debrief and our attendees exceeded our expectations when they started to reflect on their working experience in their fictional team and usage of tools we presented. It was great atmosphere in the room and we all learned from each other.

I think we managed to create a good workshop and would like to do it again at future conferences or other events.

Some things what workshop attendees learned.

Happy creators

How To Create A Workshop: Follow-up


End of the last year I wrote about starting to create my first testing workshop. This is follow-up with details how I did it and results after the workshop.

Ash’s MindMap

As I know Ash and loved his workshop in TestBash Brighton, I took his mindmap as a proved recipe. It helped me to tune it and to have an overview. Especially helpful was everything under “Principles”. Small adjustments from my side – I added a node “Emails/Communication” for the “Checklists” section.

Creating Mental Model

With map in the hands, first thing what I did, was to create a mental model of the workshop. I spent more than week to build it. Very classy with pen and paper – my two favorite thinking tools. Some of the ideas what went through my head during that time: why company asked me to do a workshop? What kind of problems do they want to solve? What are possible solutions? What would be my solution? What background has people who will attend the workshop? What kind of skills they have? What kind of skills they need to have? What is the main, core thing to be able to solve their problem? How can I teach it? Can I teach it? How to build it up in small stages/ containers?

Some answers I knew, for the rest I decided for two possible versions – positive and negative. As a next step – I simulated dialogs with me and workshop students, where the students where unwilling to learn, disagreeing with my ideas or frame of work, not cooperating and simply not understanding what I say because of different background and level of information about software testing. May be it sounds silly, but it helps me to prepare and to deal with potential situations. With every simulation I check my model – does it work? Should I improve something?

Test The Workshop

When the mental model is done and tuned, than I started to test it. First I tested it with two of my colleagues. One of them has test management background, never did test automation before and shortly started to learn it. She liked some of my ideas, but her main comment about the subject in general was: it is so difficult and it is not possible to learn in one day; people will block them out because of amount of information.

That gave me a lot of thoughts. I went through my mental model again, cut all advanced level stuff, noted that I need slides for basics and changed the structure.

After I was done, I looked for people outside my company with whom to test the idea. Got very valuable feedback and some tips.

Only then I started to create the slides. When slides were done, I gave a short presentation of it to my colleague, who said that it is not possible to learn TA in one day. My heart singed, when she said, that now I build a good workshop.


So what was my plan? I started with fusion of “Test Automation with Lego” by Richard and “Mob Testing” by Maaret. The goal was to write script how to build a tower and they had to write it in the team, where one was a driver and everyone should had a posibility to be a driver. After that we “run” the scripts. Next step – to analyse the scripts and think about modularity. First learning block we would end with a little theory about testing and test automation, just to assure that we are on the same page. Before the lunch I wanted to start practical scripting in the teams, which we would continue in the afternoon. I planned to end the day with second theory part with lessons learned and suggestions and to wrap it all with another mob-test-automation-lego to acknowledge what we learned.


How it went? Like in the life – unpredictable :) Lego as an ice-breaker and illustration of test automation worked very well. Light problem was with mob testing – drivers did not want to give away their positions. All my effort went unheard. I stopped pushing and paid attention that everyone is envolved even if as contributer.

The idea to analyze the scripts and try to modulyse them did not work, because scripts did not work. I switched to back up and we analsed one of their test cases.

My light theory part raised a lot of questions and took much more time as I planned. That is why before the lunch we managed only to share the files and set up for practical part.

As we started practical part, team required to change the planned setting and instead of team work they wanted to connect one laptop to the beamer and have a shared understanding how to start scripting. I agreed and than problems started… first two students could not connect their laptops to the beamer, with the third it worked, but again we lost the time. After basics were covered I asked to join their groups. Mob part we skipped, because it just did not work for them. The technical problems kept following. One students keyboard did not work. I suggested to get an external keyboard, but it was ignored. A second student in that team had too old browser version and did not have admin rights to update it. I suggested several times to change the teams but it was ignored as well. On another team driver had a mac book and he missed some files as we diagnosed afterward. I have to be honest – I was not prepared for any of those situations. Who comes to the workshop about test automation with broken keyboard?! But I think the thing which disturbed me the most was – that was OK for them!

At one point it stopped to be an organized workshop in teams. Everyone, except one, tried to script the test case on their laptops, shoutting around, sharing excitment and frustration. I was running from one to another and helping to fix problems. For a moment I saw one blinking word in my mind. Disaster. I had to skip second theory part and lego wrap up, all students wanted to make their scripts to work. We used every minute till the end of the workshop. And you know what? They did!

That moment I switched off that blinking word in my mind. The technical problems were OK for my students, they hit the goals of the workshop and all of them were smiling when they let the workshop. And yes, before we cleaned up, it looked like a workshop. Mission accomplished!


I am glad that I had a chance to create (in less than a month) and run a workshop. I am happy how it turned out. I realized how spoiled I am with technology at work (new keyboard or mouse is never a question). The students said it was interesting and usefull.

What I will do differently next time? I will put more effort to make sure that there is less as possible technical issues. I heard it before, but did not really understand until experienced myself. Another thing – Andrei has a list of skills what he expects from his students and if they do not cover part of it, he refuses to give a workshop. It sounded a little bit overacted as I talked to him about it, but now I think it would be good to draw a line, to set up basic knowledge level for participants.

Post Navigation