Quality is the Responsibility of the Whole Team

Originally this article was postet on trendig.com English & Deutsch

Since 2001 we have the agile manifesto in place and since then the whole industry is learning to use agile principles and values in their daily work of software development.

 

agile manifesto

The Agile Manifesto guides teams through agile transition and in their daily work of software development.

One of the problems I see, is that many who claim to be working in an agile environment have never read or really understood the agile values. While consulting teams or giving trainings, I’ve heard countless times that the Agile Manifesto says everything that is on the right side is what we should not do, e.g. in agile we have no plans, no contracts, no documentation or processes. I got to know a team who lost their software architect in agile transition because architects are not mentioned in the Agile Manifesto. Now they struggle with huge technical issues and there is no one who can help them… But it is not meant to be like this! The Agile Manifesto states that value is in items on both sides, but if we have to choose, we are choosing items on the left over the ones on the right. Logic says we have to have all items of the Agile Manifesto if we want to deliver sustainable software and improve our delivery cycle. The aspect that agile methods wants to highlight is, that documentation, plans or contracts are not the aim of the project, but are supporting tools. The aim of agile projects is always to deliver working software, have valued team members, and promote collaboration with customers and value responding to change.

 

the whole team approach

The way in which we achieve the values and the principles described in the Agile Manifesto is using the whole team approach. Since it changes fundamentally how we work together in a project, you can say it is a new style of project management in which everyone on the team is held equally responsible for the quality and success of the product.

The Whole Team Approach supports the 5th principle behind the Agile Manifesto.

Professionals in software development know that each development decision is a quality decision as well. The Agile Manifesto sets it as a top priority. Software quality does not depend on the software development model that we use, but on the method how we all together as a team structure the whole software development process. Together, we use tools and activities which support the achievement of high software quality. One of these activities is testing.

 

what does testing mean?

Everyone around the world knows or can imagine what “software development” or “project management” are, but very few can say what software testing is, how do you do it and, most importantly, why?

10 years ago when I started my career in testing, there was the statement: “everybody can test” with the meaning that you do not need special skills to test. Today I often state myself: “everyone can test software”, – meaning everyone: developers, software architects, product owners, support people and operations – everyone, who can analyse information and build a mental model of it, to discover invisible strings and deviations between software and requirements, business regulations, standards, norms and legal regulations. Testing is an intellectual sport. But we are more used to say: Testing is the process of how we collect information about our product with the aim that, based on this information, the team is able to decide what to do next.

Two types of testing are very important in an agile context: automated regression and exploratory testing. With regression tests we collect information about software features which are already in use by users, and with exploratory tests we are learning about software features that we are currently developing.

If you run tests and your team cannot make decisions based on information your tests collected, your tests are not adding value. If you write weekly reports and nobody on your team reads those, your reports are not adding value. If there are 12,000 automated tests and no one can articulate what they cover, the automated tests are not adding value.

You may still have a tester on your agile team that acts as a coach for testing techniques and does some of the testing, but on an agile team, everyone should be able to collect information about the current state of the software. Remember: quality is the team’s responsibility.

the challenge of change

The essence of the whole team approach lies in the testers, developers, and the business representatives working closely together at every step of the development process. Because the whole team is responsible for success and quality, the whole team or at a minimum, representatives from each specialty – see three amigos  – is involved in every consultation or meeting in which product features are presented, analyzed, or estimated. For many organisations and individuals, it can be a struggle.

The first attempt to switch to an agile software development, in my experience, in 90% of cases looks like a 2-week-waterfall development. It is hard to change a person’s way of thinking or collaborating, a company culture or processes already in place. People and companies have to break deep-rooted processes, e.g. working in silos or not listening to junior members. Give it time and recognize people’s fears – it is scary to change! Some fears that people have expressed to me are:

  • “How exactly should I support my team members?”,
  • “If everyone should be able to test, what should I, the tester, do?”
  • “If the whole team decides on issues, what should I, the project manager, do? Is there still a job for me?”,
  • “According to our HR guidelines and my job title, I am a senior developer, but I never really understood testing. What will happen if others find out?”

All of those are valid questions and should be addressed.

Janet Gregory and Lisa Crispin were two of the pioneers in agile testing. Many agile testers call their book “Agile Testing” the Bible, because it was the first comprehensive book about testing in an agile context. Today they have the extension “More Agile Testing” and the 3-day hands-on training “The Whole Team Approach to Agile Testing and Quality”, for whole software development teams, with games and exercises on collaboration, planning and agile testing quadrants. I train this course myself because I am convinced that I can give many team members valuable knowledge for the implementation in their daily work. But whether it’s a book or training or reading blog posts or just trying things out for yourself: I encourage everyone to take a look at the whole team approach, because it is an important step forward when the entire team feels responsible for success and quality.

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.

simulation

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 You Measure Success In Testing?

Very early in my testing career I understood that this will be tricky: it is hard to say when you are successful as a tester. Even worse,  it is hard to be proud of anything in testing.

There was time that it was cool to write many as possible test cases or to find many as possible bugs. That was success. But now those times are gone. Now testers question stuff and support teams.

I raised 10 questions yesterday, today I asked 12 – yeay, I am pretty good at this!

OK. Let’s assume for the moment this is how you measure quality of a tester. If asking more questions shows success, then we will want to ask more questions to be more successful. 15. 20! 35? And suddenly questions becomes a noise and distraction for a development team.

My current answer how to measure quality of a tester is following:

Testing is a service. If tester brings value to the development team with what s/he does than s/he is a good tester.

Food for thought – what kind of testing team would you call successful?

 

My personal success

I wanted to answer the question for myself – am I successful?

For a long time I thought I wasn’t. I am an autodidact in testing. I even cannot say that I learned on the job, all learning happened in my free time. There was no manager or senior colleague at any point of my testing career who would guide me through the subject. Google was my friend. Developers around me did not like testing, managers around me always wanted me to do manual checking. It took time and mental strength to understand that there is more. From that moment on I started to practice selling and explaining testing. I had very different results. I started to doubt myself. I looked up to big names in testing, compared myself to them and though I paled in comparison. I was sure that on my self-education way I missed the turn and miss some existential  information. I felt like a fraud…

But then something happened. I attended an open space, run a session and apparently my statements annoyed one of the biggest names in testing. He got angry, we started to argue and then he asked me whether I knew what a state chart was. I said no, causing him to raise his voice and to ask me in front of the group how I dare to call myself a tester. That was it! Somebody was calling me a fraud, but instead of being ashamed, running away and hiding, I answered him with confidence: Yes, I am a tester!

Suddenly I understood that I am very special kind of tester. There is only one of me. My experienced shapes how I test software and how I communicate with people. It will not work for every team or every manager and that is OK. There is no one universal answer to a question. BTW, I looked up immediately after our dialog what “state chart” is. I realised that I knew it, but only in Latvian.

If I do consulting and my client wants me to automate UI tests in two weeks and then leave, I could do a few things:

  1. I could start to explain what testing is, how it works and what you can do with testing. And I will crash and burn, because the client will be frustrated and overwhelmed with this information, which will turn around everything they know and how they work. How do I know it? I experienced it.
  2. Or I could “shut up and simply do the job” (greetings to Mark ;) ) that I was contracted to do.
  3. Lately I choose to combine both. I do the job, but I involve other people to whom I explain what I am doing and why, so that after I am gone they could carry it out by themselves.

Is this the only possible solution? No. It is my current one. Next year it will probably look completely different, because I am continuously learning and improving my methods.

Now, when I look back to when I thought I was a fraud, I can not understand why I felt that way. I always had a job offers and I got mostly good feedback from the teams I worked with. Why I did not recognise this as success? I have a page on this site for speaking engagements.  Average only two appointments per year. To some it could look very empty. But for me it is OK. I have a day job, I have a family, I have hobbies and I am member of several local groups. Two to three talks a year is what I am comfortable with.

As I get older, I find the strength not to compare myself to others. I compare me with me. If I read one of my old blog posts and feel ashamed – this is good thing, because it means I learned something in-between.  

 

 

Attracting Girls To Engineering

Statement “girls are not interested into engineering” is wrong.

Take me as an example. I had loving parents, but they had strong opinion what kind of toys are meant for girls. I beg them, but still never got a car or train to play with. Never understood why I cannot wear pretty dresses AND play with the trains?

Later at school we had craftsmanship lessons. Girls did cooking, knitting, crochet, weaving, boys could build something from wood and they took plumbing lessons. One thing I was interested in, but never were allowed to try. Because I was a girl.

At university one of my professors once told me: no way you wrote this code yourself!

It was so frustrating… I did not get chances to show what I am capable of OR every time I delivered something, my work got questioned just because I have no penis!

Based on my experience here are seven simple suggestions how you can attract girls to engineering:

  1. give chances to girls to try
  2. do not question results what they deliver. no comments that they could do better. they will do better after some time of practice
  3. invite not just one girl, but all her girlfriends. it is safer to fail, if your friends are around you
  4. find a role model. tell stories about women, who was the very first programmer, did very first debugging, wrote code to fly to the moon etc.
  5. listen when a girl talks
  6. make no suggestions if she does not ask for those. let her figure it out for herself
  7. if you see somebody doing opposite what I wrote in 1-6, call him/her out, tell that it is wrong. tell to the girl, that it is wrong

Today I Learned

Last September I joined trending and became one of the ISTQB trainers. I have a whole story “why?” and I plan to share it one day, but today I want to talk a bit about learning.

How I see learning from the trainer side is pretty ugly – mostly students do not want to learn. It is trendy to talk about learning and training should be safe place where to learn, but in many cases ISTQB is something where they have been sent by a boss or something, what they think they have to do, to get a next shiny job title. I try hard to make trainings entertaining (I carry different testing games with me) and informative (learning materials, stories from the past), but sometimes it is simply not working. Sometimes I am happy that at the end of the day everyone simply memorised what negative test is and why we should do it. Most challenging are the ones who refuse to understand some definitions or concepts, for example, difference between validation and verification. Most frustrating if this is a person who has 20 years of experience in IT. In those moments I ask myself, is this really for me? But then I remember my “why?” and everything is OK again. Part of that “why?” are students, who are engaged and eager to learn everything I can share with them. They did some research upfront and have clear vision what they need. It is highly rewarding to work with that kind of students. Discendo discimus – while teaching we learn.

In trainings I invite people to embrace failures, to share experiences, to learn from each other, to use synergy. To help them to do that, I point to my own mistakes. Something like the picture on the top of this post. Few month ago I put whiteboard into our home kitchen. We use it as drawing board, as shopping list, as design board for next game we will program and sometimes I write citations. I guess, now till end of my days, I will spell “intelligence” correctly. Not always I was so cool about my mistakes. Few years ago I would feel ashamed and embarrassed, would try to hide it, put a lot of energy to deny it. Today I share it with the world. I know who I am and spelling mistake will not make me less me. I better put my energy to think why did I spell it wrong? Am I writing too less on an analog information carriers? Do I assume that software will catch all my spelling mistakes?

Since this month we have new colleague Dani. One thing what he did, he created channel in our company slack #todayilearned to share our learnings. It has became simple but effective training for me to identify what did I learn new today. Sometimes it is simple stuff, like, how to spell “intelligence” or that I am afraid to sit in the car which moves faster than 210kmh on busy autobahn, or that people who smell lavender fragrance make less typos and are more productive (I sent this fact immediately to my colleague with whom I used to share an office and passion to lavender). Or sometimes it is realisation that not everyone reads and spends on learning about a software as much as I do. I moved away from digital transition because I was sick of explaining software development basics again and again. Now I explain them on weekly bases :D . I like to think that I can assume correctly about previous software development experiences of my respondent and explain missing parts accordingly his/her level of understanding. And almost every second time I fail, because of aiming too high. People try to write an essay without knowing the alphabet! Yes, even in 2018 you have to explain, with patience and empathy, what is a smoke test, what is a negative test and regression test to a developer with 10 years of experience in software development. And this is OK. We all make mistakes, take wrong decisions and can use it as learning possibilities.

 

 

You Are Next

November 18 is the special day for all Latvians. It is our independence day. This year(2017) we celebrated 99th and Latvian community in Berlin organized a very nice party with a variety of musical performances. The club was quite small, there was almost no backstage, in-between performances singers were among the listeners.  I was holding up my 4yo that she can better see the stage. At one moment she turned to me and said to me: “you are going up next, right?”

Amazing how simple is 4yo life… If you know what you do (I was singing along whole night) and like what you do, you go up on the stage and do it there.

Why am I tell you this story?

At conferences, I meet a lot of amazing people and we share a bunch of stories. Many people, who I met, shared their secret – they would like to share their stories from the stage, but think that no one will be interested. My answer to this is: “do not decide for me”.

If you need help to find your topic, prepare your abstract or presentation, then mentors and team behind SpeakEasy will help you. I know, because I was SpeakEasy mentee myself. Now I am helping to match mentees and mentors. Do not let your fear limit your potential.

You are next, right?

 

State Of Testing 2018

This is a time of year when “PractiTest” and “TeaTime with Testers” invites all the testers to fill a survey to find out who we are, where we come from and on what kind of subjects we are working on. This is 5th year in a row and I am already looking forward to the picture we will get this time.

Big thank goes to contributors in the review team: Jerry Weinberg, Derk-Jan de Grood, Maria Kedemo, Helena Jeret, Alan Page, Brent Jensen, Eran Kinsbruner, Bas Dijkstra, Erik Proegler, Kristel Krustuuk, Gerie Owen, and Nermin Caluk. If you have any suggestions how to improve it, you are invited to join the review team.

The organisers estimate that the survey will take only 10minutes of your time. For me, it took more time. Why? In this year’s survey, there are few questions where you have to think and/or recall what did you learn last year. Hier are few questions for you to get a feeling:

Have you attended any conferences or training sessions in the past 3 years?
Have you started using any new tools to support your testing (Exploratory testing or in general) in the last year?
Have you made any important changes in the way you are testing during the last year?  

 

Those are few good questions, right? Be part of it! You can find the survey here.

Dictum – Factum

I am the doer. I see a problem/aim/thing I want and I go for it. If I have obstacles, I will put my mind around it, I will make compromise, but I will get a results.

I have put my finger on several key processes along my employee career and for a looong time I thought that I do not need to label my ideas and/or results as mine. Mainly because I believe in following two things:

  • an idea is more important as human who brought it to the life. If my idea/work lives and developes without me, than that was really necessary for the world and not just for my ego.
  • everyone who works together with me, knows what I am capable of and which parts of work was delivered by me.

Mostly it worked well. Everyone in the company knew QA=Kristine, even if I was not part of the project. If people needed help with testing or quality related issue, they were looking for me and I helpe as best as I could. I am also very good in puzzles – from small information bits I like to create big picture – that comes handy if you work on big projects or big companies where people do not know each other. Than one day I organised feedback workshop with my old team. We had small, but cool team and I thought it could be perfect to exercise on self-introduction and feedback giving the same time.

Nice and easy, right? To my surprise I got one negative (and 4 positive) feedback about my introduction! I was so surprised. I shaped my introduction to people with whom I work together, I was assuming that they all know who I am, what are my topics and how I am working. In this case I could excuse myself with the fact that the person, who gave that negative feedback, was working remotely. But frankly it shocked me that even people on my team can misunderstand me so greatly.

I started to rethink it all and to pay attention what is my message, what do I say. Besides other things, I noticed that in most of the cases I use “we”. One example – since almost two years I organise TestParadies – a meet-up for testers and QAs. Alone. I have no team, no sponsors, all the fees I am paying from my own pocket. Year ago I was lucky to get Petra on team to write retrospective blog posts about the meet-ups, but generally I do the whole thing alone – looking for speakers, looking for locations, maintaining platforms, writing emails, moderate discussions, deciding on topics. And still when I talk about TestParadies I say “we did…”, ” we plan…” no matter that there is no “we”. An outsider could think that I am ashamed of running a meet-up! Why I do not take the credit for my work?

Why and How Testers Should Act Like Marketeers” was talk by Rosie Sherry on European Testing Conference 2017. I was not lucky to attend it, but found her slides on slideshare. Many good ideas there! Marketing and selling testing seems not to be those things testers are familiar with. Currently I am trying to shape my blog as my portfolio and I struggle on first page – how to design it that the message is clear? I decided to visit blogs/websites of test people who do consulting to collect some of ideas. Almost everyone I checked had a personal bio, but I was very surprised to found just a few business oriented introductions. 

Some time ago I was working together with a developer on contract. He was working 3 days/week on the project and 2 days/week managing his company. At the beginning I thought that it is only an excuse, he is working on some other project and does not want to admit it. Now I see it from different angle and believe that being great developer or tester is not enough. I expand that old Latin saying to:

Dictum – Factum – Signum – Explicatum

Find Courage – A #TestBash Story

tb_utrecht

On January I was on a trip to the Netherlands. I had an honour to support Rosie and Huib – people, who made another incredible Test Bash event.

I had much, much fun to run registration both days. I love to see new faces, to see the expectations in their eyes, I love to be the first one who meets, greets and guides them into TestBash world. I am kind of staying in the gates to the new knowledge and encouraging people to come forward. I met a lot of new people, had very interesting discussions and good laugh. But let’s start from the beginning.

Meet-Ups

In good old TestBash tradition there were a pre-TB event and pre-pre-TB event, a game night!

If you do not know what is TestBash meetup, then imagine crazy loud tester gatherings in some local bar, where over a drink you have a chance to have a word with a speaker or another cool testing personality. Sooner or later you will realise that all TestBash talks are keynotes and all testers who attend TestBashes are really cool testing personalities. Even yourself! Another very cool thing about TestBash meet-up is, that if you are in the area and can not make to attend the conference, you still have a chance to meet the test people.

Workshop day

Huib picked some very good workshops for the first TestBash Utrecht conference. I heard only good or excellent references.

After registration was done (and it took some time…) I participate in the afternoon workshop about exploratory testing by Jean-Paul. As a person, I am quite impulsive, but since I live in Germany and work as a tester, I work really hard to make me more organised to not to fall out too much. That is why I was expecting to get some practical tools how to do my exploratory testing. And I got them. Thank you, Jean-Paul!

Besides that, Jean-Paul gave me permission to think. This was so unusual, I am too much used to deliver, that I forget how it is to take a time and think. Explore slowly, for example, the room where you are sitting. In fact, everything in the workshop was a little bit like Zen. We tested applications, wrote test cases, documented our findings and let them go. No one wanted to know what exactly we found, what we thought. Very confusing and in the same time healing, because the process was the thing, not the result. Inspired by all that, in February I run my very first exploratory testing mini workshop.

img_20170126_180336

The day ended up with setting registration area and desks with swag. We learned from mistakes and rearranged place that people move faster to the rooms and do not stay in cold. It worked out good and in the next day there was no jam.

The conference day

My day started after 5 am. Very first thing was to move the car. Then I headed to the old church – TestBash Utrecht location. Punctuality is not my thing, that is why for important stuff I work hard to break my habits. As the result I was the very first one, the church was locked, no lights to see, freezing cold. Ha ha, next time I will take it easier on myself.

The conference started with Alans talk about misuse and fun, which unfortunately I did not hear it in Utrecht because people were coming in late for registration. Luckily my boss got for us Dojo access, talks are now uploaded and available for watching. Jipī!

The second highlight of the conference for me was Gitte talk about courage to be yourself. I met Gitte shortly during ATD and she heard pieces of my trust talk, we share similar values and some of experiences as well. I was thrilled to hear her talk. I can imagine that some felt uncomfortable and some could think that it is not a proper talk in tech conference. But it is proper and it is important! It is the blessing that we have people among us, who dare to remind us – we are humans, we are different and it is OK.

All other speakers were amazing too, but I will highlight only one more – Mary. Her talk about “Just enough security” had huge amount of information and I will rewatch it on Dojo to make some notes. Mary, you gave me the push to participate in #30daysofsecuritytesting. Thank you!

I like to talk to speakers after their presentations and take photos of them. The atmosphere of sharing is amazing!

I also like to take group photo of all lady speakers to show role models and inspire more women submit their stories, but in Utrecht they were too many to organise in one photo. Good job, Huib!

99 sec talks

Another tradition of TestBash is 99sec talks. Never participate? You should! That was first stage experience for several presenters, me including. The idea is to give a 99 seconds long (short) talk about testing related subject. As I first stand on the TestBash Brighton stage, I was surprised that the lights are not so bright as they seem to be and I could see all attendees. Before that, in my imagination, I thought it will be like a crowd of wolfs starring on me from the darkness. But instead of that I saw bunch of friendly faces, some carefully listening, other checking or typing something in their digital devices.

Utrecht

Usually, I do not have a lot of time to see a place where a conference is happening. This time I came by car and had no time pressure for leaving.

At the end…

In few days TestBash Brighton will start. If you are going – I wish you joyful learning journey! If you just got to know about TestBashes – I guess there are still some tickets left – invest in your future, you can afford it yourself, if your boss does not see value in sending you to the conference. I fund most of my activities myself and look where it brought me!

Becoming Mentally Strong

Last week was emotionally hard for me. I had a strong disagreement with a person, who’s opinion means a lot to me. It seemed that there is no way out and it made me ill. I hade a feeling I am losing a very dear friend over stupidity. Except that it was not stupidity, but very important part of my believe.

What to do?

As always I asked the question: why? Why it is so important to me and why am I feeling sick? And as always those questions lead to the past. I remembered my personal struggle many years ago, several very unpleasant situations and my actions, who lead me to be a person, who I am today. I had very emotional moments and decided to open up to my friend – introduce the elephant in the room, explain myself and ask for work around.

It looks like that it worked.

When relief and joy came down, I realised what happened. Some kind of summary line between then and now, things I have learned and the self-building journey I have made. I learned a lesson, paid the price and moved on. OK, it was a little bit different: stopped to blame circumstances (because it did not help), understood which exactly lesson I had to learn to be able to move on, learned it, stopped paying the price, which I paid during avoiding to understand the lesson and moved on.

It is good, time to time open up, show the scars and person behind them.