Test Retreat

Welcome to the homepage of Kris Corbus

Archive for the tag “software”

Goodbye 2018

I love to write yearly roundups! It is the time when I put numbers to my feelings and celebrate my personal development. So, here it goes! 2017 was an amazing year, a lot of change and most of it positive. To compare, 2018 was much calmer year. Real working bee year.

What did go well

trainings/work

In 2018 I gave 29 trainings in 2 languages (DE & ENG, still hoping to give a training in LV) in 4 countries – Germany, Austria, Finnland and Rumania. I gave trainings around software quality, more specific testing and requirements, with and without agile dimension. From those 29 trainings, 17 was in-house trainings (in-house are not displayed on trendig website). I like to think that I helped 17 teams to become better with software quality. One team was special because all 9 students were developers. Some of them were giving trainings (agile, TDD etc) themselves. Their thank you for the testing training I gave them is one of my highlights this year. This training was special in another context as well. One of developers scored 100% in certification exam. This happened for the first time in my training career. I build trainings on stories and put more focus on discussion and less on exam questions, many of my students get 90something %, only 5 did not make it with first try. Anyway if I managed to bring just one team of developers closer to testing world, I mark 2018 as successful year.

I also worked on improvements and creation of new training material and wrote two articles. My first trendig article was on quality assurance, written mostly for managers and executives. Second article is addressed to whole delivery team about transition, testing and working as a team. In first whole team article I could scratch only the surface, stay with me others will follow soon.

speakeasy

In summer 2018 Anna-Marie and Fiona due involvements in other projects decided to handover SpeakEasy. Abby and me, we were mentees and after delivering our talks supporting SpeakEasy already for some time, so for us it was only logical to take over. But because we are heavily involved in several other projects we were cautious to commit. In that situation Maaret came as saver, she overtook organisational part and takes care of communication with conferences. We were lucky to have Ash on team as well, she enriches our start team with perspective and gentle push to find the focus and round up.

conferences

I am pretty happy with my two appearances in conferences. For the first time I did a workshop and for the first time I paired with someone. This someone was Lisa Crispin and I am still amazed how easy it was to work with her together. Working together with Lisa is my conference highlight of the year. I also like the workshop we created a LOT and hope to be able to give it as much as possible in upcoming conferences. I have already some confirmations, but need to wait until organisers will announce the program.

blogging

I wrote few blog posts less then previous year, but got more traffic (see the picture on the top). I am still searching how to shape my website and blog. I am writing for myself, but I am aware that others are reading as well. By look on topics where the traffic goes it gives me strange feeling and reveals delta between what I want to write about and what seems you want to read about. This is top 3 of most viewed posts:

  1. AM I A SEXIST?                                                                  with 941 views

  2. HOW YOU MEASURE SUCCESS IN TESTING?   with 308 views

  3. EXPLAINING SOFTWARE TESTING                        with 212 views

Unfortunately, articles which are important to me, like Attracting Girls To Engineering(71 views), Words Has Meanings – QA(51 views) and Today I Learned(47 views), are not under top 14. To serve readers, but to stay true to myself I decided to improve my blogging and to share more everyday stuff, things what I do as a trainer, consultant and speaker ( I thought it is boring, but after some private conversations discovered the opposite).

I notice other bloggers to put information about advertisements, paid products or affiliate programs. I guess this is the right time to say that I am not using any of it and everything I write, I write because I want to share or because I wanted to understand it better myself, did little research and then wrote a summary. Yes, I work at trendig and they pay me salary, but they pay me for being a trainer and not for writing my personal blog.

What did not go well

I got sick and could not really get well again. I had to cancel several events and despite of support of my team, I felt like I am letting them down by not carrying out with my commitments. Only after longer break, reflections to my last working years and acknowledgement what I did wrong, I could rejoin my team. Thank you, Jana for being there for me when I needed. I am happy to work for CEO, who cares for people so much.

meet-ups

TestParadies was project which suffered the most. To compare with 9 events in 2017, in 2018 I managed to organise only 3. Unfortunately due my current work situation there is no improvement to expect. I am calling for support. If no-one will be willing to help or overtake, I will have to close the meet-up.

 

Wishes for 2019

First and most important one – I want to get my health under control. By “health” I mean physical, but everything is connected, so… whole health.

Second,  to keep my believe system strong and keep changing world to be a better place by changing myself to be a better person. Leading by example works, I verified it.

Update: just noticed that this is my 100th blog post! Another reason to celebrate tonight, juhuu! 💃💃💃 Happy New Year, everyone!

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.

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.

Explaining Software Testing

Michael Bolton is good in summarising fundaments of software testing in a tweet. In my eyes this piece of information deserves a little blog post.

The last sentence is something what I teach my ISTQB Foundation Level students – you cannot assure that there are no bugs, but you can collect information about bugs you have found. You can analyse them e.g. with aim to create set of actions how to secure your software developing process from reappearance of that type of bugs.

Most of developers want to know if a feature does work or not, but we as testers can only say that Version A did work on Machine B under Circumstances C.  Project managers and customers want to know if it will work on production. We as testers cannot assure it, because we did not (and we should not) test on production environment with production data. Based on tests on similar environments and under similar circumstances we can suppose that it can work.

Sounds very logical, but it can escalate very quickly, because DEVs, PMs and customers think that testers are there to save the word and to give certificates that the software they are working on, works perfectly as described.

What to do if you still get asked:

– “What do you do whole day long if you cannot tell me will it work or not?!” 

In heated situation like this it is too late to explain semantics, fundaments of testings or why software development process is complex. You should done it as soon as possible, when you started to work on a new feature, on new project, in new team or new company.  Remember – one of most important skill of a tester is communication skills. We need those not to be able to talk about the weather, but for explaining what is testing and how testing can help to DEVs, PMs, customers and all others. Daily.

Michael suggests 4 step plan how to learn fundaments of software testing:

  1. Learn how to test: How can a trainee improve his/her skill sets in testing?; To The New Tester
  2. Declare your commitments: A Tester’s Commitments
  3. Recognise that all testing is heuristic: Heuristics for Understanding Heuristics
  4. Learn to tell the testing story: How is the testing going?

Looks simple, but as you start to read the linked resources you will understand that studies can take years. Take deep breath. To be able to explain testing to others, you have to learn it first for yourself. Do not panic if it does not work on a first try. Make experiments, try new approaches, improve your skills. One day you will master it!

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 actions 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