Exploratory Development

Software quality assurance is usually understood as ensuring that a process is adhered to. But does just following a process guarantee sufficient quality? Perhaps, if a process contains focus on quality and means to maintain it. And there are right people.

Of course, theorists would say that a process guarantees quality, that all problems are caused by violation of procedures or the project is “wrong” or all mistakes because of people not of the process. But in reality people are the most important part of success and even thorough formal adherence to the process can result into failure. Therefore software quality assurance is a misleading term. It doesn’t ensure quality of a product; it merely ensures compliance with the process.

Let’s focus on ensuring quality of a product, not just adherence to a process. Quality can be controlled or it can be built into the process of product’s creation. These approaches complement each other. If there is only control then a company will have to spend much resource on rework of low-quality stuff, if there is no control at all then risk of producing a product of inadequate quality is higher.

To increase quality the team can use some tools and techniques. It’s important to assure that we know what is to be built, how to build it properly and how to test that a product built is what the customer needs.

Quality assurance is quite a big topic. There is lots of information about each of tools mentioned below; this article is aimed at providing brief overview. Bearing in mind focus on quality one should pay attention to at least the following areas:

• Requirements gathering and analysis
• Development
• Preventing problems in the future

Requirements gathering and analysis

The project should achieve right goals; not only build things properly, but build proper things. The team should help client understand what needs to be built. If the customer has provided vision of the product then the team can analyze features bearing in mind overall concept. And point out potential problems or drawbacks early thus reducing customer’s expenses and increasing satisfaction of all parties involved.

Sometimes customer doesn’t want to give even a vision (e.g. they think it’s a commercial secret). You can try to explain disadvantages of lack of vision but it should be a customer who makes the final decision. Of course, in this situation the team will create its own vision but it may be different from customer’s one (and most likely it will differ).

Customer may not have enough time to discuss requirements. Again, that’s their decision and the team can only warn customer about potential problems.

To increase quality the team can provide their expertise in solution space – user interface (especially by specialists in user experience and information architecture), technical details (e.g. platform, potential requirements to scalability or performance) or even some help in domain field if the team has had experience with similar projects in the past.

Development

Let’s assume that the team has done its best trying to figure out what should be created. Next question – how to do things right? First of all, the team and customer should understand that quality has its price. Although in short term quality costs more, in the long term lower quality can cost more (and usually do) than high quality – the team has to fix many problems, code is not maintainable, it requires much time to change something or add new feature, etc.

It makes sense to decide what level of quality is needed for a project on hand. As soon as it is decided the team should ensure that this level of quality is maintained throughout the project.

To support needed level of quality the team can use:

• Architecture
• Definition of done
• Peer code review
• Refactoring
• Testing (unit, integration, manual, performance, etc)

Architecture

There was a lot of buzz about architecture in agile world. The most radical agilists said that architecture should emerge without any special planning and design, simply as result of ongoing development and design. It is likely to be an overstatement as with almost any extreme position. Sometimes sum of parts is not the same as the whole.

In fact attention to the architecture depends on complexity of your system – for small system in well-known domain the team has already defined default architecture, while for complex system with specific non-functional requirements the team should plan for additional time for designing architecture. But again, don’t take extreme position – usually there is no point in defining all details in advance, only the most critical and difficult to change elements matter.

Sometimes people forget about architecture after they have designed it. And architecture deteriorates over time. Periodically or when new requirement doesn’t fit into existing design the architecture should be reviewed and redesigned if necessary.

Definition of done

In Scrum there is a very good concept of “done”. Story is either done or not. It can’t be “done but…” or “almost done”. How to decide that story is really done and there is no any “but”? Introduce definition of done.

Definition of done is a simple checklist. There are several conditions in it which have to be met in order to consider a story completed.

If we want to build in the quality it makes perfect sense to include quality requirements into definition of done. For instance, to avoid the most trivial problems the team can add condition that results of static code analysis don’t get worse - “No new warnings from PMD or FindBugs”. Idea of using definition of done can be suggested by anyone, but it should be the team (not project manager or ScrumMaster) who decides to introduce definition of done and follow it. If the team doesn’t believe that definition of done is an important part of ensuring quality then they will find the way to circumvent done criteria.

It’s possible to extend definition of done beyond story – the team can introduce definition of done for sprint or for release (e.g. performance testing is executed and the system works well on Linux and Windows). It helps to ensure that the product meets non-functional requirements.

Peer code review

One of powerful tools to ensure quality is peer code review (in addition it helps to transfer knowledge and build common understanding and standards, develop skills and learn more quickly). Sometimes people forget about it, sometimes deadlines are close (deadlines are very often quite close ), and as result code review is often left aside. To avoid this problem have team members agreed to include code review into definition of done – and the team can’t move further until code review is performed.

In one team my suggestion to include code review as a part of definition of done was discussed by the team and then they agreed that it would be useful. It helped to detect several serious problems and to create common style. In another team such suggestion was rejected. But some time later they changed their mind and included code review into definition of done.

Refactoring

Code is being eroded over time due to constant changes. Refactoring is one of the most popular and effective tools for reducing entropy thus making code maintainable and easier to understand and change. It can be a part of definition of done. Or you may plan for special time for refactoring (e.g. last day of a sprint).

Testing

Unit and integration tests increase stability and reduce number of bugs by identifying errors very early. In addition such tests help to think over different situations therefore making system more robust.

Manual testing happens at different steps: when a developer tests, when a tester tests and when product owner performs acceptance testing.

There are many other types of testing – performance, automated smoke, stress, etc.

But before introducing any type of testing analyze whether the project will profit from such tests.

Preventing problems in the future

Ok, we have fixed some problem. But a little later the team struggles with similar problem. Again and again. The lesson is not learnt. To learn lesson the team needs to identify the problem, identify root cause, analyze the cause and fix it. Actually, that’s what retrospective is supposed to do. And it’s one more way to increase quality.

Build quality in

All described above can be shortly summarized as simple checklist:

• Validate that requirements are correct enough
• Build quality into development
  • Unit/integration tests
  • Definition of done
  • Refactoring
  • Peer code review
• Test
• Verify that what is built is what was requested
• Verify that what is built is what is needed
• Learn your lessons

Actually, it looks like a procedure . It is not. The main difference – you may apply these practices separately taking into consideration your context. Some practices can be useless or even harmful in specific project’s context.

And the most important – don’t forget about people. Have team members understand how these practices help them. And you need consensus about practices to be used. As Jean Tabaka put in her book “Collaboration Explained” consensus is when everybody involved in decision making can live with and support the decision. So have the team come up with a set of practices which everyone on the team can live with and support.

And then enjoy your high-quality product.