Test Retreat

Welcome to the homepage of Kris Corbus

Archive for the tag “processes”

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!

 

 

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.

Post Navigation