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.

Story Behind My Logo

The logo for my website is not coincidence. It has a back story and deep meaning for me.

Story

Many of you associate me with Germany. Sometimes people speak broken German to me with aim to connect on personal level, but the thing is I live in Germany only because my husband is German. I am born, grew up, studied and worked in Latvia. Next week my small, but brave country will celebrate 100th anniversary. I am huge patriot of my country and in my local circles well known for distributing tourism information about this green and untroubled place on earth.

We Latvians are very proud of our culture – locally (dances, songs) and internationally (music, science, sports). Big part of our cultural heritage are signs, known and used since Middle Stone Age. My logo is one of those signs.

meaning

Sign of Laima (fortune) is proved to be one of the oldest known signs in Latvian (Baltic) culture. Laima is known as peoples life path giver, fortune. Displayed a fire needle – symbol of nature, evergreen as omen of not giving up. Another explanation is based of feathers of birds, which symbolises the soul.

Sing of Laima has a branching – Swab of Laima. Placed horizontally and extended.

Meaning: A soul keeper. Sweeps away the undesirable.

Why it is important to me

When I moved to Germany I faced many struggles: alone without family, friends and business contacts, I had to start all over again. Of course my husband was supporting me all the way, but he is from different domain and his friends and family are his, not mine. Especially hard it became when my mother got sick and died.  I felt like i was loosing my roots. I felt torn between two families, two countries, two cultures, two realities. I felt lost in translation. Belonging really nowhere, except my safe place – my little family around me.

What helped me, was reading Latvian literature, listening and singing Latvian songs. Reconnecting, rebuilding with my origin, but this time without my mother.

On the way I rediscovered Swab of Laima and gave another meaning to it:
>>>   all my stories in the past. everything what made me – me
<<<   everything, what expects me in the future. the person I will become
|||       living now and here. me as connection node for two stories, two countries, two cultures, two realities

Mini Test On Production

Yesterday I changed my Twitter handle, today I want to test, what happens if I do not update the change on WordPress and publish a blog post.

I expect to happen one of these:

  1. cannot publish blog post
  2. cannot publish blog post, error message that there is no such handle
  3. can publish blog post, but no tweet on Twitter
  4. can publish blog post, there is tweet on Twitter for ghost account with old handle
  5. can publish blog post, tweet on Twitter with new handle
  6. something else

UPDATE after the test

Test was successful. Blog was published with right Twitter handle.

What I like a lot, that WP updated automatically to the new handle. If I choose to write another blog post than it is already filled with the new handle. No human interaction necessary! 

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

Being Only Woman In Men Company

Over 20 years of work experience in IT only in few companies there where gender balanced teams. In two startups I was the only woman in whole company (size of company 20 & 50 heads). Even secretary was a man. So you can imagine what I felt when I read this thread of Patricia.

I hope somebody would tell me this 20 years ago. I had to put this together that it does not disappear into information space. 1-20 is from Patricia (see the thread in tweet) with some my comments, 21+22 are my own 50 ct.

  1. Don’t try to be “one of the guys” you’ll never be able to bring your full self to work.
    • not the cloth, not the way you move or talk, even not a swearing will make you happy. one day you will wake up and realise you were fooling yourself.
  2. Document all your work. It’s hard to steal credit for public work.
    • make your work visible and label it distinctively
  3. HR is not your friend
    • HR works in interests of company only.
  4. Avoid everyone who is really enthusiastic about you being a woman.
  5. Leave functions before your colleagues are drunk. Neither you nor them want you to know their inner thoughts
    • do not get drunk yourself (drink less or lighter drinks)
  6. Try to convince yourself when you begin to doubt yourself; “it’s not me, it’s them”
  7. On Bad Days try to loose yourself in the work, try to remind yourself why you’re in this business
  8. Find good people and bake them cakes just for being great people. Great people should get cake.
    • in one company I was baking and bringing a lot cakes, but the reason was, I wanted that they accept me as a part of the team. they never did.
  9. Make lunch dates with other women in tech.
    • search for your community, support each other
  10. If you have a great idea, call a meeting and send out your slides in advance (See Hard To Steal Public Work)
  11. If you have a great idea, make a demo. Hard To Argue With Running Code
  12. Never participate in any “team building” activity that involves you dressing differently
  13. Don’t be afraid to quit. Don’t sacrifice your mental health for Bad People
    • or bad culture
  14. Introduce Rules for Communication, like praise in public, criticize in private
  15. Try to make it possible to choose who does your code review
    • or any other reviews. get feedback regularly.
  16. Learn. Learn. Learn. Knowledge is power
    • create your own skill map. add each year new skill or new level of a skill.
  17. Try to make the team more diverse in any direction. That changes the tone. But get more women devs, if not in the team then at least in adjacent teams. It is hard being alone.
  18. Walk out at any Locker Room Talk. It’s easier than discussing it. And they’ll get the message.
    • if you cannot walk out, make non-verbal statement. I placed poster with a man in seducing pose close to posters with mini bikini women models.
  19. Get a Powerful Ally and plot (literally plot) to compensate for social power being unequal when it really matters. Like having them back you up in important meetings.
    • was not possible in my startups
  20. Don’t waste time catering to people that won’t give you the time of day.
  21. Learn about emotional labour. If you are doing it, stop immediately. No one is appreciating it and it makes you feel empty.
  22. Do not tolerate. If you tolerate, you worry.

Learning Lessons

To escape old thinking and behaviour patterns will try some new things. First two I will print out on handy cards, carry with me and will use every waiting moment when I would usually check my mobile, to check my learning cards. For my-needs-card I have another idea. Tomorrow starts our team-summer-work-camp and I want to do it as a team exercise to raise awareness how different we are and what do we need to deliver better results.

Command Line

CRITICAL THINKING CHEAT SHEET

My Needs card by Angie Doyle

#TestBash Germany Ticket zu verschenken

Hallo!

Genauso wie letztes Jahr, auch dieses ich habe ein TestBash Germany (TBG) Ticket zu verschenken und ich suche immer noch den glücklichen die/der das bekommen wird! Ich verstehe dass es ungewöhnlich ist etwas geschenkt bekommen, deswegen hier paar Fragen und Antworten:

Was ist eigentlich TBG?:  es ist eine Tester Konferenz die nur ein Track hat und nur ein Tag dauert. Alle Vorträge werden auf English gehalten, während Pausen es kann auch Deutsch oder Bayrisch vorkommen. Vielfalt von Speakers mit sehr unterschiedlichen Erfahrungen und interessanten Fragestellungen. Mehr Details unter  https://www.ministryoftesting.com/events/testbash-germany-2018 

Wann wird TBG stattfinden?: 14.9.2018

Was muss Du tun:  email an kristine.corbus@gmail.com schicken mit folgendem Satzanfang: “Ich möchte das TBG Ticket haben weil …”

Was erwarte ich von Dir:  absolut nichts 

Warum tut jemand so etwas verrücktes wie Tickets verschenken?!: weil ich an „Tue Gutes und Dir wird Gutes widerfahren“ glaube (also bin ich am Ende sehr egoistisch :D)

Am 12.8.2018 ich werde bekannt machen wer wird am 14.9.2018 bei TB dabei sein. Also – nicht lange überlegen, einfach schreiben und gewinnen!

Viele Grüße –

Kristīne

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.  

 

 

Giveaway: #TestBash Germany

I have one giveaway ticket for Test Bash Germany – write me an email/ message (mailto:Kristine.Corbus at gmail.com)  , why you should get it and if you will convince me – ticket is yours!  #PayItForward #SimplyLikeThat