Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Design

Quality and Transparent ALM


The Different Levels Of Transparency

Suppose that every morning before you leave for work, you want to verify that the systems in your car are working properly. Using an ad hoc process, you look at the car, confirm it still has four wheels, hop in, and give it the gas. It's full steam ahead -- until something blows up.

With a formal process, you follow a checklist that includes metrics which indicate if it is safe to drive the car. The checklist might include checking oil level and pressure, coolant level, the battery, brake fluid, and transmission fluid. Each component has a minimum acceptable operating level. For example, you need four tires, each with a pressure of 35 psi before you can start the car.

If you had to follow the checklist, it would take you an hour to get on the road. This is where process gets a bad reputation because it impedes progress instead of facilitating it.

Luckily, you don't have to manually verify your car's systems every morning. When you turn the key, the computer performs a pre-ignition test of all the vital systems and reports back any issues in the form of warning lights. How long does it take? 15 seconds and you are on your way. This is the beauty of a transparent process.

You can see that a formal process improves your safety, but can be time consuming. A transparent process provides the same safety in less time and with less involvement from you.

Let's apply this to an ALM process. You have source code for your product and you have a system for tracking defects and feature requests. You may even have test plans and test cases to ensure that the end product does what it is supposed to do. Now the question is: Do all those things work together automatically?

In a transparent ALM process, all the data and artifacts are integrated. When reviewing a defect, it is just a click to see what source code fixed it. From a test case, it is another click to see what defect it verifies. All of these things are tracked automatically, and the system captures who did what without you having to step in and do anything.

When working toward a transparent ALM process, your mantra should be "automate and integrate." You want as many tasks as possible to run without your involvement. Even more importantly, you want the different tools you use to talk to one another. Interactions between systems should work as seamlessly as the actions within the individual systems.

Let's look at some common source-code management and defect tracking activities to see how this works.

Transparent Source-Code Management

As a developer, source code is the key to your job. If someone overwrites your changes or the source-code management (SCM) application crashes, you're in for a world of hurt. Yet it is surprising how many varied approaches there are for source code management.

Large organizations may develop documentation for common processes like merging, creating builds, unit testing, and code reviews. These processes may also include checklists and metrics to ensure quality at certain milestones. If you have ever had to work on a team responsible for process management, you know how tedious this can be.

Test Cases

While test case management may be the realm of QA, you should still consider ways of integrating it with other development processes.

The first step is to invest in a test case management system. If the test cases and results are stored in a spreadsheet, it will be next to impossible to automate and integrate them.

Storing test cases in a single location allows you and other developers to see how QA will evaluate your code. A test case management system also enables you to create an automated workflow similar to the one used for code review and issue resolution. Test cases move through the review process and test runs are executed with a minimum of manual interaction with the system.

The workflow provides the automation but do not forget about integration. Automated testing, test case management, and defect systems must talk to one another. A failed test run should automatically generate a defect. QA should also set up testing contingences within the system so that if one of the tests in a series fails, the subsequent tests also fail.

With a test case management system, QA can automatically build a suite of regression tests from the tests accumulated from previous releases. Regression testing can go on continually using automated tests, scripts, and triggers that run based on different events. When test case and defect management are integrated and automated, test runs can generate defects and vice versa so testers and developers can spend more time resolving problems rather than collecting data.

—G.L. and K.V.E.

You can escape the burdens of a formal process by embedding the process into your tools. Create triggers in your SCM application that kick off the appropriate unit test scripts when a file is checked in. Unit tests are important for quality, but no one says you have to perform them manually.

Another possibility is to design an automated workflow so the review process continues without human interaction. For example, put lead developers in charge of different functional areas. When a file is checked into the database repository, it is routed to the appropriate project lead for a code review. If the lead does not review the file within three days of check in, a reminder email goes to him and the development manager.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.