From Technical Director's Perspective 

I am very fortunate to have spent time on many projects/products with lots of customers and so I wanted to write a series of articles to go through my experiences and what I have seen. This blog is the first in the series and will look at modern development, quality assurance and quality control.

The Modern Development World

Development today looks very different to 20 years ago, with many organisations switching to the agile development methodology and it can feel like the whole world is moving very quickly. In reality, though, it’s the individuals who come up with ideas, and determine how an organisation and its projects develop, and the Agile methodology is better at allowing these individuals to pull the organisational ship in the right direction, it’s these individual “tug boats” that are able to move around quickly that help change the directions of the big ships.

Agile together with emerging new technologies, techniques and practices are changing (I believe for the better) not only what software we produce but also how we produce it. Beware though, it is not all plain sailing.

Agile software development dominates the software lifecycle these days; but I think people don’t necessarily understand how it came about and what it’s purpose is.

I am genuinely interested in how people are developing software when I am visiting organisations and in the main most people say they are doing some mix of Agile. There’s a lot of different ways that people can go here; I find most people say they’re doing Scrum but they don’t really follow what is inside the Scrum guide. While I don’t think this is necessarily bad, what I do think is a 'smell' or a dysfunction is that most haven’t even taken the time to read the Scrum guide. The Scrum guide is 17 pages with 3 pages of intro and outro, so content wise it is only 14 pages, really there can be no excuse. While I am not fixated on it, I do think Scrum is good because it’s designed to help solve complex problems which is something we face all of the time when we’re doing software development. Unfortunately, my little brain can’t deal with big, complex problems, so I have to break problems down into smaller parts and deal with those smaller parts individually which is just one of the things that Agile and Scrum is encouraging us to do.

The agile methodology was born out of the minds of evolutionary design thinkers who, whilst at a ski lodge came up with the concept, which has moved us from a world of software built as monoliths to focusing on breaking things down into smaller pieces and delivering continuously (or at least more regularly). However, it is notable that of these design thinkers only one was a tester, and this has kind of translated into the modern development lifecycle, with the need to release regularly, and quality assurance being the responsibility of everyone, developers writing unit tests, many adopters took this to mean there was no longer the need, or time, for testing.

Our process and how we adapt it is where we can adopt different practices, such as TDD, BDD and how we move to a more DevOps world and get things into the pipeline, quickly and efficiently and still do testing; quality, efficient testing. I will cover some of those practices in more detail in subsequent blog articles.

Testing’s Place in the Modern Development World

Two important concepts come into play here, Quality Assurance and Quality Control. Much like the 2001 slogan “Dr Pepper, so misunderstood” (coincidentally the historic meeting at “The Lodge” at Snowbird ski resort was held on February 2001), I find that people start to get a little confused when they start to address Testers as Quality Assurance Engineers. Through my job and my work I’m very clear on the differences but what do they really mean and who are these Quality Assurance Engineers?

Quality Assurance is about how to achieve the right levels of quality by attention to every stage of the process. Quality Control is about maintaining standards by checking parts of the output. So, Quality Assurance is preventative in its nature while Quality Control is about detection.

I often hear the phrase “Quality Assurance is the responsibility of everyone in the team”, so isn’t everyone a Quality Assurance Engineer? And if so, is there a role for the “Tester”?

These teams are supposed to be cross-functional, self-organising teams. By cross-functional we mean that we have all the disciplines necessary to be able to deliver the increment. The necessary skills on a database heavy product might mean that we need DBAs, developers and testers. A developer might improve the process by suggesting the implementation of Code Reviews or Pair Programming, a tester might improve the process by suggesting a different type of testing or implementing some form of test automation. So, yes! We all are or should be Quality Assurance Engineers because Quality Assurance is about looking at processes and the practices that will help us produce higher quality or the right level of quality increments.

To answer the second question about the need for a “Tester”? A developers’ code is much like his baby, and everyone thinks their baby is perfect, so it is hard for a developer to test their code in an open, unbiased way. A tester is more objective and can point out the flaws, defects and suggest ways of improvement, plus make sure its fulfilling the requirements.

Testers can look at what testing needs to be done and the skill levels required, it isn’t all about automating the testing. When I am in a team and we are discussing the future stories for subsequent sprints, I am performing with the team on the fly “Static Testing”. This is where I am looking for defects in the requirements specification in its form as a user story and acceptance criteria, here I am trying to prevent bugs that could be coded in due to incorrect, vague or incomplete specification. When the developer has built enough of the RESTful API, I am using exploratory testing to call those APIs to thrash out any issues before we move too far down the line. So, yes! I think that the “Tester” is an absolute must when it comes to situations that need double checking.

In the next blog article, I’m going to be delving into this in more detail along some of the practices that can be used, their pros and cons…