Quality and Transparent ALM

Using transparent ALM to achieve quality code without constant attention to the next step


November 07, 2008
URL:http://www.drdobbs.com/architecture-and-design/quality-and-transparent-alm/212001273

Grant Lammi is a senior software engineer at Seapine Software and can be reached at http://blogs.seapine.com/grant. Keith Vanden Eynden is a technical communicator at Seapine Software and can be contacted at [email protected].


Application lifecycle management (ALM) encompasses all the steps of developing software -- from gathering requirements and writing functional specifications to regression testing and defect tracking.

An ALM process is essential to producing quality software. However, repeatedly consulting process documents to determine what to do next takes time away from other valuable activities. Automating as much of the process as possible reduces the amount of time spent performing mundane tasks like organizing and reviewing priorities and lets you spend more time on more enjoyable activities like designing and coding.

Your ultimate goal when designing an ALM process should be to create a transparent process that keeps you on track but doesn't distract you from activities that require more focus.

The Benefits of Process

Before your process can fade into the background, you have to accept the fact that process is good. To many developers, the word "process" suggests rigidity and an endless list of required actions and procedures that crush their creativity.

Developers all want freedom and autonomy. Yet what we want is not always good for us. In an environment where it is every coder for himself and nothing is documented, you may find yourself wondering if the person in the next cube is following the same rules you are. You fix the same problems again and again and live out your own version of the movie 50 First Dates. The right balance of process and empowerment makes all the difference in the world.

ALM Processes: They Come In Different Flavors

Everyone has a different impression of what process means, usually due to previous experiences. If you work at a company that requires you to check in your code and document changes nightly, your reaction to the word "process" will be much different from someone who works in a two-coder shop where design meetings take place in the kitchen while re-heating leftover pizza.

You can look at three types of processes:

An ad hoc environment is the wild, wild west. If you've ever worked in that type of environment, you've probably had the good sense to flee before your nerves were shot.

Working in a formal environment can re-assure you that all the bases are covered, but it can make you feel like you can't make a move without getting sign off.

What you want is a good balance, where you can complete tasks without feeling like you're being pulled out of the zone by dozens of administrative interruptions.

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.

Transparent Defect Tracking

Defects are a fact of life, and working on them can take up a large portion of your day. One way to become more efficient is to automate the routing of defects from one person to another.

If you work for a medium-to large development organization, you probably have guidelines for defect turn time. You also have policy documents that define different severity levels and what constitutes a bug versus an enhancement. If you have multiple customers, the turn time and the review process might vary from project to project.

If you work on several projects, you can waste lots of time reviewing procedures and prioritizing your work instead of working on code. Face it, if you wanted to route action items and manage timelines, you would have become a project manager, not a programmer.

To spend less time organizing and routing items, you can create an auto-assignment rule to route new defects to the appropriate development lead based on client. You can take this a step further and automate the workflow so that defects are escalated to right person based on the severity, open date, and other criteria. You are automatically notified when you need to take action on a defect so you can keep working rather than mulling over your to-do list.

Another way to reduce manual defect tracking tasks is to link defects together to create contingencies. Several defects may add up to fix a larger problem or to constitute a block of functionality. You can save yourself headaches and rework by creating links between items to prevent you or someone else from fixing defects in the wrong order.

You can also create separate workflows for individual clients. This is especially helpful if a customer must review your changes before they are implemented. You can define a customer review state in the workflow that automatically assigns the defect to the appropriate person. The defect moves through that review process without your involvement while you work on issues for other clients. If the customer contact changes, you update the name in one place and all the defects are directed to the new person.

True Transparency: Automating Across Processes

Automating one function or area is great, but true transparency and improved efficiency comes from fully integrating the different areas of your development process. Defect tracking and source code management are perfect candidates for integration.

When you fix a defect with a code change, you make a note in the defect about what files changed. You also enter a comment when checking the files in. Making these types of notes in two systems is a waste of time. If the two systems are integrated, you speed things up while improving your audit trail.

If defects drive your daily activities, you want to do as much work in the defect tracking system as possible. Being able to check out and attach source code files from within the defect tracking system can make a huge difference. It is also easier to see exactly what code changed to fix the defect. From the defect system, anyone can see a description of the problem, the different workflow events, and the files that were affected by the change. Because the code and defect are linked, you can see the defect activity just as easily from the source code system.

Conclusion

Without a doubt, an ALM process is essential, but none of us would get much done if we had to spend our days concentrating on the next step in the process. When your process is transparent, you're not aware that it's there. The right things happen at the right time. Instead of managing action items, you are free to focus on designing and coding.

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.