Test Retreat

Welcome to the homepage of Kris Corbus

Archive for the category “software sustainability”

Meaningful Agile Metrics

People like to set deadlines and to measure things, this is how we roll. In my classes, I hear many questions about how to measure software quality in an agile context. Many teams who switched to agile continue to measure quality like they used to do it before: number of found bugs, number of closed bugs, number of automated tests, stories rejected by PO etc. But after some time they found it was not helpful.

I am very cautious with metrics. First of all, because out of context they are misleading. Secondly, people tend to focus on what they are measuring, because they want to improve that thing. If we focus only on the numbers, it can be very dangerous. 

If you measure “stories rejected by PO” you will work with those numbers, but not address the real reason behind the problem, so in the majority of cases, it will not change. Just like in Dilbert comics or more current issue with Trump who did not want to test people for Corona, because then the numbers will sky rocket. He “likes the numbers where they are”.

OK, let’s assume I convinced you – metrics are tricky. But what can we do? My first suggestion is to evaluate if we really need a metric. If yes – for what and why? Sometimes the answer to those questions can give the solution. “Because we’ve always measured something!”, “Our management / stakeholders want to know it!”, “Our boss wants to know to whom he should pay a bonus”. Some of those are indicators of bad management, others of bad agile approach and I hope you understand that no metric will solve those problems.

If your challenge is nothing like this, then for the second round, I have a story to tell. Two years ago I took an Agile Testing Fellowship TrainTheTrainer course. I had two major highlights in the training, two things that changed my agile approach. I remember so vividly the moment when Janet Gregory announced: “forget about traceability in agile! We don’t need it”!

It came as a shock. How?! Why?? No traceability??? But, but, but… how will I work without traceability? Traceability always was a part of software development – starting from requirement elicitation until support and maintenance. I needed some time to process it. In the end I had to agree with Janet. If everything from beginning to end works, if testing is a part of development, if the team is the one who leads, if stakeholders support the team and give freedom of a decision then of course we don’t need a traceability. It becomes one and the same as the process.After reevaluation of traceability, I started to revise other old “religions”. As you can guess, one of them was metrics. My idea was – if I would remove everything I used to know about measuring quality and assume that it is baked in, what would I like to measure then? I will save you the whole rethinking process. At the end, I decided to focus on the whole team. For that I use 5 values of eXtreme Programming: Simplicity, Communication, Feedback, Respect, Courage. There are several ways to measure each of them. I will give you few examples that you know what I mean: simplicity besides known methods can be measured by checking if everyone on the team can read and understand code from somebody else. Respect I prefer to measure with closed team dot voting. For courage I find it very important to monitor how strong a team feels about pushing back or questioning (unnecessary?) user stories. 

It took some courage (ha -ha) to leave old practices in the past and I must admit not with every team and company this will be possible. If you practise fragile (bad agile), if the company does not really live by agile values, it will not work.     

For a dessert I want to share a video of a TED talk about missing baby dinosaurs. Maybe it gives you another perspective on known things.

 

Ethical Dilemma #MachineLearning #AI

Everyone talks about AI, I am ready to give you my 5 cents.

I started to study IT 20 years ago. In my circle AI was a thing, I thought I want to belong to the cool gang make it as my topic as well. But my enthusiasm did not last for a long time. I gave up when I realised in what early stage is it and how hopeless it is. I gave up on AI after I learned about ethics dilemma – train out of control, switch and decision whom to kill. My professor was amused about our reaction, but I got depressed by finding puzzle which I cannot solve. Now 20 years later, being a mother and raising three children, I see unsolvable puzzles everywhere. I can only hope that my three natural intellects will learn the “right” ethics, but there is no guarantee.

My oldest daughter yesterday watch a horror movie for the first time in her life. She is twelve & we are such a vanilla family who usually watches Peppa Pig or biathlon welt cup. We didn’t watch all Harry Potter movies yet, because she was too scared! She thought that the movie is named Walking Dad. When she realised that dad is dead, she felt that it is tool late and did not want to let her friend down (her friend has mental health issues). So she stayed there and watch it… It is long story how and why, but one of topics what we were discussing yesterday – if you cannot help your friend anymore, maybe it is time to end the friendship if it takes too much from you. I never ever thought that I will suggest my child to think about leaving her friend in trouble. So unethical! I am strong supporter of staying together in good and bad times. Not this time, because my child is involved.

Humans fail to make ethical decisions and machines will fail, because humans programmed them.

 

We created the reality of big data. We created this artificial problem, now we need solution. For me the solution looks like we are creating next artificial problem…  This is why I like love letter written by Smita. It is about data & algorithm and our ability to see behind it. I hope we will question our own algorithms (human behaviour) as well.

You may also want to read “Ethics and Artificial Intelligence: The Moral Compass of a Machine” written by Kris Hammond.

Kate Gregory: Code Quality

As a trainer I give a training every week, another group of people and one of 3 topics: testing, requirements, quality with or without agile. To entertain myself, each time I tell another stories and mention another resources. There are no identical trainings. To keep an overview, I decided to create collection of sources I usually mention.

I give trainings but I also continuously learn. My newest discovery is Kate Gregory. Thank you Patricia that you tweeted during Kates keynote and afterwards shared link to the recording.

Kate is developer and it is her keynote on developer conference, but do not get scared by it! In her talk she explains how to find emotions in code and gives some ideas what to do with those. For me she talks about code quality. Many aspects, what she touches in her talk, deeply resonates with me. This is exactly what I think everyone in QA should talk about.

In her speakers requirements Kate says she prioritize events who publish and gives free access to her talks (wow!), so you if you like this one, you can easily find other talks of her (I am trying to watch all of them). Kate also writes, mentors, develops software and give trainings.

What does QA stand for?

Two letters – QA – and only a few knows what it means.

Some time ago I read an interesting blog post “Accept misnomers – The bigger picture is helping, not correcting language” written by David. I agree with the title, I like the list of misnomers (did not know about peanuts) and example with drop down menu, but in my opinion, explanations are necessary.

Here is my story

In last 11 years, I had a chance to participate in some crazy projects. Once I was on the project where nobody wanted me to be. I struggled a LOT. Everything what I offered was refused because it did not fit to their understanding of QA. The thing what they asked me to do – to make sure that developers work overtime – was wrong for me. Another aspect – they wanted to have have someone, who would be responsible for quality on paper and if something goes wrong they could blame that person. That was told me in plain text after I tried and failed for very long 4month. I was speechless. I thought it is some kind of bad joke, because during interviews I had the feeling we share understanding of QA. It was not a joke and I started to question myself: why I did not see it during interview process?? I had too less experience to deal with this situation and to save myself I quit the job without backup plan.

I learned a lesson hard way: not to assume that companies and experienced software development people share my understanding of QA or software quality in general. I learned to have a conversation about it and to recognise deviations and toxic environments.

Unexpected my crazy story had an ending : around a year after I left the company, I met one member of that project. He was laughing hard as he told me that after I left, the project was looking for another QA for a long time. They found one, but what a surprise to the technical leader, the new one asked the same questions which I asked. Only difference: he was a veteran and he did not accept answers I was given. Short time after that I got another message, that person to whom I was reporting (CTO), has been fired. It was good to know how it ended and it gave me hope and also motivation to carry on.

 

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.

Words Has Meanings: QA

Words matter. Words are the way we transfer ideas from person to person. Shared words do not guarantee shared understanding. I understand 4 languages and I try to understand 4+ cultures. Time to time I experience situations where I cannot express myself in none of the languages and my motives are misunderstood in all the cultures. At the moment I try to help my son with his Latin studies, it means I am kind of studying it as well. And it is quite fun because grammar is very similar to Latvian, but words to English and/or Italian.

You may wonder why I am writing about languages and what it has to do with quality assurance (QA)? You see, I really like quality assurance in software. I am very into processes, responsibility about the software and improving quality of an end product. If I would need to name one thing what I am good at, it would be seeing links/ matches/ connections. When I see a bug in the software, I see that it comes from a bug in the process. You can fix the bug in the software, then write and maintain 10 regression checks to get information when it happens again, but for me, more sense is to fix the bug in the process which caused the bug in the software.

One illustrative example. Imagine bakery. Good recipe does not guarantee tasty cake. Bad recipe does not mean that a cake will not taste. Testing in all this is trying the cake – quality should be baked in, if it is not in there, for this particular cake you can not change (improve) the quality. QA in bakery would be observing processes, identifying bottlenecks, questioning actions in place, analysing end products, which does not meet quality standards, with an aim to find a source, talking to customers and then decide what to do – to improve a recipe, approach, method, marketing or selling strategy. Another thing, I hope you all agree with me on this: if we call a bread as a cake, it is still a bread.

I really like to work efficiently and remove a cause instead of effects, so I applied for jobs with title “QA Manager”, “Head of QA” etc, but always at the end, thing, I was asked to do, was software testing. Don’t understand me wrong, I have nothing against software testing, I think it is great method to collect information about a software. But I kept wondered why companies and clients use “quality assurance” incorrectly. I broke it down and asked people what “quality” means to them and how they measure it; mostly got no answers and puzzled looks. How you can assure something you cannot describe and do not know how to measure? So I came up with this idea:
a) that they do not know about QA as a discipline;
b) it is some kind of strategic game played by companies: let’s put “QA” in our job openings and use the word “quality” few times on our website, then our customers will think that we care about it!

Let me tell you this – you can add sugar coating and glitters to your pastries, but everyone, who will eat it, will see that it is bread and not a cake.  If you call a bread as a cake, it is still a bread, right?

What Is Quality Assurance?

Note: This article originally was published by trendig in English and Deutsch.

Are you in charge of software projects at your company and facing problems with your software? Do you want to improve the quality and have no idea where to start? Then this article will help you to start implementing QA processes!

qa

QA stands for Quality Assurance and is a very important subject in the complex world of software development. We observe our software and find that it has discrepancies with customer expectations. A discrepancy in software is called a bug. If we remove the bug from the software, it does not automatically mean that it now works flawlessly. A requirement is the term for customer expectations for a system and it could be that the bug hides there as well. Sounds difficult, right? That is why we need dedicated QA engineers!

Assurance

Let’s start with the assurance part in QA. Spoiler: Nobody in the industry can assure that your software is flawless. Every software application has at least one bug, the question is: Do we know what it is, where it is and do we want that others (end-users, competitors, hackers) find it? Now that we accept that, we can move on. How can we ensure that we know about all the relevant bugs in our software? We test the software! We can also test all kinds of documents, design and code. Testers have a comprehensive toolbox on how to collect information about the system in test.

After some time of testing you will notice that there is a pattern of some kind (testers are really good in discovering hidden patterns) on how bugs appear or reappear. When you discover that pattern, one thing you might want to do is to reduce the number of known bugs or bug types from your product in the future. We can divide this process into two steps:

The first step is to analyze bugs in a software with the aim of finding the source. Why and how did a defect find a way into the software? Possible questions to ask: Is our system architecture too complex? Bad (or no) technical documentation? Vague or contradictory requirements? Do our people have the necessary skills to design/implement/test the software?

Second step: To define a set of actions and procedures to avoid appearance of the same bugs in the future. A typical approach might be: define a set of guidelines and standards to prevent this type of failure in the future, improve the quality of requirements by creating a checklist of what good requirements should cover, or use a specific tool to help us.

To summarize, with the help of analytical techniques we collect information about the software, with the help of constructive software quality assurance methods we prevent reappearance of bugs from a known source.

Quality Assurance requires processes and structure in order to analyze and improve software quality.

quality

Now we need to talk about the quality part of QA. To better understand the topic let’s use the analogy of a chair. If we need new chairs for our dining room, we go to the store, see 20-30 different types of chairs and feel lost. How to find the right model? Which chair can we describe as having good quality? Different people mention different things. For me, it is important that the chairs fit with the rest of the interior decor, and that they are stable and easy to clean (because of my kids). For my son, it is important that he can swing on it without the fear of falling backwards. The best way to address these needs, is to create a list of requirements. Do we need armrests? Should they be stackable? What kind of material/style/colour?

We do the same with software. We create a list of requirements and measure the degree of compliance. The biggest problem is that software development is a very complex process and many customers lack an understanding of it. Customer requirements influence up to 50 % of project success. That is why we talk about quality attributes. One way to classify quality attributes and metrics is the standard ISO/IEC 25010:2011.

Like testing, quality aspects can be applied to all kind of sources: software, subsystems, documents, single requirements, design and code. When starting a project, consider which quality aspects you will cover and what you will use as measurement. Choose it wisely, because what you measure, you will improve.

To illustrate the idea of quality, I used an example of finding a set of chairs, but software is a very complex system, more like a house. Quite often in development teams we hear customers saying: “We do not have the final set of requirements, but you can start and implement what we have so far.” This is wrong for many reasons, but I will mention just two of them. Firstly, a requirement baseline is part of the contract between customer and service provider and should be synchronised with a SLA (service level agreement). Secondly, imagine building a house and, when your constructors are halfway done, you have the idea to put a swimming pool in the basement. Will it work? No. It is the same with software. If you cannot read the source code and see software architecture yourself, it does not mean that it does not exist. Your software has a structure and developing it requires you to follow certain rules.

Conclusion

Software development is a complex process which involves specialists from different domains. Quality Assurance is a discipline which shadows SD starting with the gathering of requirements and ending with testing rollback scenarios, with the aim of finding errors as soon as possible, analyze them and improve the process to reduce or eliminate those types of bugs.

Find and fix errors as soon as possible to keep costs as low as possible.

Why do we do all this? Because prevention and reduction of errors as early as possible cost less than the rework involved in fixing the bug. In this case we can talk about build-in quality. It is a smart business decision to invest in effective software quality assurance.

If you want to read more about QA processes, we suggest you blogs from Janet Gregory and Anne-Marie Charrett.

Willful Blindness

I watched very interesting talk about willful blindness by Margaret Heffernan and it made me think about software development. Are we – testers – IT whistleblowers?

 

1981: How Computers Will Affect Our Future

TV story from 1981 about computers influence on daily life. Please ignore Steve Jobs name in YouTube title. Yes, he gives an interview, but he is not the only one.

In 2017 we can say that this is the future they were talking about. Interesting that in 1981 they stated: as the society, we are used to computer problems. In 2017 computers and software is really everywhere and each company is a software company today. Even schools depend on software. The high school, where my son goes, was hacked and suddenly everyone realised that for some of the things there are no offline alternatives anymore.

I listened to the next Quality Remarks podcast with Mark Tomlinson and there are many things what resonates with me. Will highlight just one: “if students of software development do not learn about testing and students of management do not learn about quality, then we are in big trouble“.

Post Navigation