Test Retreat

Welcome to the homepage of Kris Corbus

Archive for the tag “agile”

Test Software Guide

In the last decade test software development has moved from being a cult technique to an increasing part of the mainstream. I was lucky enough to be at the beginning of this story, with early experiences on the ‘birth project’ of and a co-author of the Manifesto for Test Software Development. Trendig started using test techniques in 2000 and we’ve since successfully used them on our projects world-wide. We’ve learned a huge amount about using test methods in enterprise settings and are committed to sharing this learning to help foster their intelligent adoption.

The Essence of Test Software Development

It’s been over a decade since the developers of test methods first started to talk about their approaches. In this time test thinking has changed from a niche activity to an approach that is widely used. However, like any popular technique, test software development has suffered from semantic diffusion, so much of what we see under the name of test doesn’t bear much resemblance to what the early pioneers were doing. So I think it’s important to revisit the essential elements of test thinking.

I’ve always seen the essence of test thinking resting on two contrasts with traditional code-driven software engineering:

Test Development

      • is adaptive rather than predictive

      • is quality-oriented rather than process-oriented

Code-driven engineering expects us to come up with a predictive plan that precedes development. The plan lays out the people, resources and timelines for the overall project. Software design is also done up-front, with implementation expected to conform with this design. Success is measured according to how well development follows this plan.

Test plans are a baseline that we use to help us control changes. Test teams plan just as carefully as traditional teams, but the plans are constantly revising to reflect the things we learn during a project. Success is based on value delivered by the software.

Code-driven engineering seeks a process which provides enough structure to reduce individual variations to insignificance. Such an industrial process is more predictable, copes better when people transfer, and is easier to define skills and career paths.

Test engineering sees software development as a primarily human activity, where the people involved and how they bond as a team are the primary driver behind success. Processes (and tools) can enhance a team’s effectiveness, but are always second-order influences.

 

April April

As you may be guessed by now – there is no such thing as Test Software Development and I am not the author of this text. Original title is “Agile Software Development” and it was written and published by Martin Fowler. My creativity was only to replace some of words, like “agile” with “test.” 

Stay healthy and stay funny!

 

 

Real Time Online Training With Kids

Just like everybody else, I am at home and trying to work. Why trying? Because I have my husband here and my three kids, and everyone of them has different reactions to physical distancing. We try to go for a walk each day, but… let’s be honest – we fail, just because we hate the idea of limitations. Some of us suffer a lot, because they can not do their favourite thing, like gliding, canoeing, graffiti, meeting with friends or going to school, and then they make me suffer by complaining and whining. I am doing my best, but I am only a human!  Talking about school… – they send us tasks and homework every single hour!!! I am overacting, but this makes me so angry! I was looking forward to homeschooling my kids (in Germany it is forbidden), but this is not homeschooling – we cannot choose the topics, depth of it nor speed. 

I am in the middle of all this – calming down others and myself, helping with school stuff, cooking and yes – working. Why am I telling you all of this? 

Because of all this craziness I cannot work more then 4-5 h/day and any time anyone can interrupt me with something (signs don’t help, angry faces don’t help as well). So I thought – I am not alone in this! The whole world is physically distancing, so there could be people, who still want to use time and learn something, but have similar challenges to mine. So the idea was born – I am offering trainings in agile (Agile Testing for Whole Team), software testing (ISTQB FL) and requirements (IREB) for people, who take care of somebody, but still can arrange to study real time, in small groups in 1-1,5h sessions, totally 4-5h/day. If it was usually a 3-day training, which is around 20 h, then we will stretch it over 4-5 days. We will have small groups. something between 3-4-5 people, that we agree on sessions and breaks.

I am running this offer together with trendig, we call it Parents Special. Of course if you do not have kids, but would prefer to have shorter training sessions, you are welcomed to join. Only condition – be nice if another participant or the trainer gets interrupted and we have to make an unplanned break. We are doing our best, but this is not normal HomeOffice. This is CHO (short for CoronaHomeOffice)! Life happens while we are on video call and sometimes we cannot postpone it. 

If you have any other questions, I am here to answer them all.

Agile Testing For The Whole Team: An Interview

I am one of Agile Testing Fellows. The books on Agile Testing are well known, but the training developed by the authors are still unknown. We get many questions about it, so we decided to run an interview with most asked questions. Originally this article was posted on trendig.com English & Deutsch

None

Hi Kristine, since April 2018 you are a trainer for a course called “Agile Testing for the Whole Team”. What’s the course about?

It is about how we – as a team, in a structured way – can approach the topic “software quality” in an agile context.

I have already conducted the training “Agile Testing for the Whole Team” (ATF) many times. The interesting thing is that my participants say the same thing I did when I first got to know the course: you can immediately see that someone with hands-on experience has designed this course, someone who comes from the real world, someone who brings a breitband of project and consulting experience.

Everything that we learn in this training is immediately applied in group exercises. The training is accompanied by many practical examples, many stories and illustrations, which illustrate the whole thing. There are several small tasks where teams of 3, 4, 5 or 6 people are formed. The other thing that makes this course so specific is a task that runs and grows throughout the course.

 

Can you briefly compare it to a classic course from ISTQB?

Short answer: you cannot really compare those two very different trainings. A slightly longer answer: ISTQB is a pretty dry theory training where the focus is on methods and procedures that we use for testing: white-box, black-box and experience-based. It is very important for getting started with software testing and quality, but that is not enough. The “Agile Testing for the Whole Team” training focuses on quality as an integral part of software development. How do we get the best possible result for the team and the customer with what we have.

 

Source: Janet Gregory and Lisa Crispin from their ATF course

 

Why is the course called “…for the Whole Team”? Who is meant by that, not just the testers on the team I suppose?

The training is really meant for the whole team. All the people involved in the success of the project, not just testers and developers, but also sales, support, operations, maybe a software architect, in other words, everyone who has an influence on the project. I use a surgery team as an example: surgeons, nurses, anesthesiologists – they all have to work together. It’s not enough if just one of them does a good job, the whole team must collaborate in the best interests of the patient.

We know from the past that software development has not so many challenges when developers work together with developers or testers with testers. Problems typically arise where one team passes work results to the other team, e.g. developer to tester or tester to operations. This is an important part of agility, not to go back to the original professional teams and continue to practice mine and yours, but understand: that is all of us who are in this boat. What is the fastest way to move forward? It is about teams, team decisions and team cooperation. The whole team is responsible for software quality. That is why in agile we build cross-functional teams and train them to work seamlessly together. Collaboration means more than just sitting together in a room or working on the same project.

We all want to create useful software for our customers, we want to deliver quickly and we want to add value. We can only do this if we have a common understanding of the individual parts as well as the overall result.

 

Source: Janet Gregory and Lisa Crispin from their ATF course

 

Is it an advantage if the whole team attends the course or is it not enough if only one person attends the training?

Saving costs is a very important factor. I always ask: how much does success cost? How much is it worth that this team is successful? What does team responsibility mean to you and how important is software quality in this project/company? How does communication and knowledge transfer work in the team/company? Are these individual experts or teams with equal members and built in knowledge sharing? Answer those questions and you will have an answer to your question who should attend the training.

After almost every training I gave for a whole team, the participants almost always said, yes, now we see testing and software quality with different eyes and also understand team cooperation much better. I also gave training where only a part of a team or only one team member was present. Typical feedback in those groups is: it’s a pity that the whole team wasn’t there. It’s not uncommon that these companies book a training session for the whole team afterwards.

In the training the focus is on testing and quality. But by doing that we have to address unpleasant, maybe even painful topics in the teams experience as well: Why didn’t it work out so far? If this is structured, moderated and targeted, we can also see it as a team-building activity.

 

At the end of the course there is an online assessment. I’ve heard that you “can’t fail” this. How does that work?

The assessment is another good example how much thought the creators put in this training. It is not punishment oriented, you cannot fail!

The assessment is built as a summary of what we have learned during the training. For example, my training looks different from the one that my colleagues give. We have different training styles and different experiences in software projects. So it is logical that I share different stories and we have a different atmosphere in the room. But what is important is that the core information reaches everyone, every participant, and is the same in every training. This is what we is checked during the assessment. Janet and Lisa have no interest to make you fail, but to make sure that you got most out of the training. That is why after the assessment participants have the opportunity to see the right answers for their wrong answers. To learn from it and to recognize the potential for improvement.

 

Source: Janet Gregory and Lisa Crispin from their ATF course

 

What is the agile testing fellowship that I will be accepted into once I have completed the course? What is in it for me?

After the assessment, each participant receives an invitation to join the Agile Testing Fellowship. This is a slack channel, with different rooms for different topics. You have the possibility to talk directly to Lisa or Janet or other participants who did the training from all over the world. Of course I am there as well and will be glad to help you even after the training. Quite often people in very different companies and domains experience the same tricky situations. On Agile Testing Fellowship we come together and support each other. Sometimes it is simply compassion, sometimes an experience story or a link to a blog article or a book title. It is a community where you can address your questions and get answers.

 

P.S. It is few weeks since we did this interview. Time has change, we have Corona now. We are about to start trainings on-line. No video recordings, real-time training in a small group. I will give them as always In German and English. Let me know if you are interested in.

Set Achievable Goals

In almost every agile training or consulting sooner or later we talk about slicing user stories. Over the years I had many interesting discussions and I hope I could help my clients to find their way. But I always had a feeling that I am missing something. That feeling guided me until last autumn when I changed the way how I track my daily steps and learned a lesson myself.

2019 I set a target to improve my physical condition. I bought step tracker, I rolled in into fitness class and … nothing happened! yeah… steps I had to do myself and that is where I failed. My fitness tracker as daily target set 10 000 steps. Some days I achieved that target, but mostly my week overview looked like this:

November 2019 I had an idea to try out with less. To set the bar lower. I decided to set the target to 8000 steps per day. That was good decision and it changed everything! I achieved the day target 6-7 days/ week, to compare 2-3 days/week before.

I kept observing this for few weeks to be sure it is not some kind of coincidence (I had one or two good weeks with 10 000 as well). Of course it is just a target, I do not stop if I achieve 8000 steps. By setting bar lower it helped me to overcome low activity days and motivated to get up from a sofa and walk around the block. It is SO simple! In days when I got only 5500 I will get up if my target is 8000, but if it is 10000 I give up and even do not try. So at the end I move more (my goal for the year) and in total I achieve more, even if the day target is lower!

That is the secret behind thin user stories and committed story points per sprint:

Set achievable goals!

ScanAgile

I realised that I did not write a blog post about a conference where I spoke in March, 2019. I am talking about amazing ScanAgile. I had great experience there and very interesting, thought provoking discussions. You know, that moment when you connect with someone on meta level, everything else leaves your thinking space and even all that travel trouble suddenly makes sense.

ScanAgile is community driven and the audience is everyone involved in work in progress. What said – it was unusual for me, that so many business people were there and I have the feeling that I met all of them. It changed my perspective and gave new ideas how to approach this group with my topics.

During the conference I gave my workshop “Questioning requirements: improving quality for everyone” and no matter that we had technical difficulties (abstract of the workshop was not visible on conference website), we had very good session and some participants staid much longer(1h+) and we had deep conversation about the topic.

So why I remembered about this great event? Because they just announced Call for proposals and if you are from Europe, I think you should submit!

“The theme of ScanAgile 2020 is “Everyone is a Change Agent” and event will be bigger than ever with 500 participants. Our special 2020 focus group is people from companies in transformation. ScanAgile 2020 conference will be held on 1st and 2nd of April 2020. A separate workshop day will be held on March 31, 2020. The venue is the same as this year, Clarion Hotel Helsinki, Finnland.”

ScanAgile

I plan to be there in 2020 as well. This photo was taken shortly after I won free ticket for 2020 :)

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.

Communication Links

AgileCommunic

Few years ago Gojko Adzic tweeted following:

https://twitter.com/gojkoadzic/status/482506004102672384

 

Even today, several year after the tweet, people do not understand why agile team has to be small. The answer is communication links! Take a look on picture above. The dots are symbol of person in the team, and lines shows communication links in team. Example on the left is for team of five (10 communication links), example on the right for team of nine (36 links). Formula is very simple:

Connection Links=n (n-1) /2n , where n=Number of Team Members

In a team of 15 you will have 105 communication links(15*14/2=105).

Agile is about team, not about isolated knowledge of some individuals.

In trainings I still hear team members complaining about management, who placed timers on each desc, that people time their conversations and do not talk too much. But that is not about communication anymore. It is about company culture. There is a reason why they talk too much, find out what it is, instead of to forbid to talk.

Quality is the Responsibility of the Whole Team

Originally this article was posted 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.

Women In Agile

atd_womenleancoffee

Agile testing days organized this year something new: “Women in Agile Summit”. Great idea, difficult subject, wrong conference day – night after the conference has been closed. Not enough public information that without men, discussions are meaningless. And in fact, the person, who closed the conference, forgot to mention the upcoming event!

I arrived late but brought seven men with me. They had a hard time between choosing to drink a beer and guiding me to something-with-women-thingy. All of them chose to be brave and face the difficult topic. Bravo! But it is getting better – as we started our lean coffee session we got another member. We collected our topics, voted and as we just started our discussions, time was suddenly up and all teams were asked to present their results. So we did not really have a chance to discuss our topics as a team, but to our surprise, we got unexpected feedback to our presentation:

  • first of all because of men: women ratio in the team
  • gender of the person, who presented the team results
  • discussion topic “beer bet”
  • usage of the word “female”

No matter that the conference was extremely friendly and Maaret as Women-In-Agile facilitator was very inviting, the atmosphere was intense and spiky. Yes, we were late and yes, we did not have a lot of time, but as I talked to Garreth afterwards, we both had a feeling that no matter what would our team present, we would do it “wrong”. Even during open discussion about women role in tech, we still try to mould participants in old stereotypes.

Before I continue to share my personal views about this difficult topic, I need to share some background facts:

  • I am a woman
  • companies where I worked and work, male are a majority. In two companies I was the only woman with ratio 1:15 and 1:50.
  • the most terrible thing what can happen to a woman in tech, that she is invited/promoted because of her gender, not because of ideas she present

For example, my personal aim for this year was to become a testing conference speaker. I accomplished it with the talks at Belgium Testing days and Agile testing days – both are women friendly conferences. I am very proud of myself, but in the same time, because I know about women-in-tech-promotions I cannot be sure that I got my chances because of my stories or because of my gender. My hope is that time will show what is what. But for now, for 2017 I set another aim – to talk in non-testing conferences. Till now – only rejections.

The thing about diversity is the same with excess weight, you close the eyes and hope that one day it will disappear just like that, without any effort. But deep inside you know that if you want a real change, you will have to work hard and disciplined. And it will take some time until first results become visible.

Conferences are mostly organized by men and mostly men are invited to present. They speak in one language and have a similar set of values. But men are not only one to blame. Women need to lean in more and not get scared by the first decline. I know what I am talking, I heard a lot of NO’s. But the only way how to keep going is to keep going.

This is my pattern how I do it:

  1. do not wait for permission
  2. do not think what others will think of you/your work
  3. do not give up

Some of the companies, where I worked, had no-feedback-is-good-feedback policy, in other rules of procedures. In both of the cases you can get old while waiting for permission to work on something. So I started the following pattern: inform the manager about solutions or ideas and if there is no immediate feedback, like “NO, DO NOT DO IT!”, then I proceed with implementation. With a time I learned that that was exactly what was expected from me after informal part. No feedback is approval!

Other two things mostly are supporting the first one. To imagine what others will think about my actions takes too much time and energy. Time and energy which I need to proceed with my aims. Reduce the waste, get rid of everything what is holding you back. And just keep doing what you love to do.

At the end, dear men, do some fact checking from your past and present and recall when did you last time thank or praise your women colleagues for a good job?

Found On Internet

Excellent read about developers and some paradoxes Agile Methodology Breast Feeding

 

Post Navigation