Quality has always been a “hot” subject in software engineering, and several good development practices used in Agile development, unit testing for example, have been created to improve the quality of the softwares developed.

Programme Managers, Project Managers and Assurance Quality Managers haven’t just been looking for techniques to improve quality, they’ve also been looking for ways to monitor the quality of the projects and the application of these techniques.

This has lead to the development of numerous tools to check the unit testing coverage, the style of the code and its compliance to well accepted rules. Plus, of course, dashboards that gather all that information and present it in a user friendly way.

One of the most commonly used metrics is the code coverage of the unit tests. We often see in Agile teams rules like, “the line coverage should at least 80%”, or “the branch coverage should be at least 70%”. But…herein lies the hidden trap.The code coverage is not enough to verify the quality of the tests. Recently, I saw some unit tests that were exercising the code, but did not have real assertions. The test would only check that the data received was not nil. Something like:


/**
* Example of a useless test.
* As Mashooq Badar explained in a previous entry
* of this blog, tests should have explicit names.
*/
public void
testThatTheCodeRunsWithoutCheckingTheReturnedValue() {
// Prepare Context
// create mock object for instance using Mockito
AnInterfaceToMock mockObject =
mock(AnInterfaceToMock.class);
// Create instance of class under test
// and inject mock objects
ClassUnderTest anInstance = new ClassUnderTest();
anInstance.setInterfaceToMock(mockObject);
// Run code to test
List result = anInstance.operationUnderTest();
// Assertions
assertNotNull(result);
}

This test is almost useless, as it does not check the list of data it received. We do not know whether or not the ‘operationUnderTest’ performed its job properly. The only thing this test shows is that the ‘operationUnderTest’ did not throw up an exception. A change in the code of the class under test will probably not affect this test. However, the quality dashboard will present a healthy project with a high level of code coverage and instil a false confidence in the managers’ minds. There is no tool that can perform that extra check, for now.

This is one of the reasons why code reviews have to be performed, published and monitored as well.

By Jorge Migueis

When a team adopts Agile processes, they can sometimes forget to retain the good practices from the “old” processes. One of these forgotten practises is Risk Management. People are going to rightfully argue that Agile will ensure that the constant feedback loops of daily stand-ups, demonstrations and retrospectives make issues more visible and can often raise them earlier than in other processes. However, this discussion is about risks not problems. A risk is a potential issue that has not occurred yet. A problem is an issue that happened and that you need to solve. Agile processes will help you identify problems early, they will not help detect risks. To detect risks and manage them, you need a proper risk management process within your Agile project process.

So, what risk management process can we utilise? Risks, by definition, have to be discovered before they become problems. Therefore, we need proactive actions to find them. When the team is gathered to discuss the product backlog and the iteration backlogs, each member of the team should ask themselves:
• What are the business risks linked to these stories/tasks (e.g. lack of knowledge of the business rules even on user side);
• What are the financial risks (e.g. may require acquisition of an expensive product, or help from consultants);
• What are the technical risks (e.g. performance concerns, unknown technology);
• What are the organisational risks (e.g. dependency on another external team).

The same questions should be asked again during the planning meetings. This is an active process. Everybody should think about these questions and try their best to answer them.

Just answering these questions and identifying risks is not enough. You then need to move to the next step of this process, which is to define a mitigation plan for each risk discovered. The plan does not need to be a full document; a simple sentence can be sufficient, but it must always be completed with a dead line date. The dead line is very important. It defines the time when your risk becomes a real problem. If the risk has not been mitigated by the date specified, then you have a problem that will probably be difficult to solve. You then need to define and apply a resolution plan. In Agile processes, a common way to mitigate technical risks is to define spikes (investigation by prototyping). Once a spike has confirmed a technical solution, this solution can be used in a future sprint/iteration.

For each risk, you can also specify three more very useful piece of information:
• Impact on project if it becomes a problem. It can be a sentence and a grade (e.g. severe, medium, benign);
• Probability of occurrence (e.g. likely, unlikely);
• Cost to mitigate it.

These data will help you assess whether it is worth mitigating the risk. You probably do not want to mitigate a benign risk that is expensive to mitigate and is unlikely to happen.

As for every action and sub-process applied in an Agile project, do not forget to review your risk management process during the retrospectives.

See a new article on Agile tools by Jorge Migueis here.

We work in the IT industry where we build tools with the aim of helping our clients or company to be more efficient. However, sometimes we forget to do the same for ourselves. It is often said that Agile methodologies such as XP, SCRUM and Kanban quickly reveal any problems in a project. It is true and I would add that they quickly highlight the need of tools to improve the team’s efficiency, reduce the waste and reach a good level of quality.