Use approvals to enforce test driven development, code reviews and integration testing in Rational Team Concert

Deepa Saini shows how the approval process can be leveraged in Rational Team Concert to enforce Test Driven Development (TDD), code review and integration testing as part of project process. TDD, reviews, and integration testing put in practice ensure quality software development. For users new to project process implementation, this article assists in getting started with this implementation in Rational Team Concert right away. For users who are familiar with processes and would like to implement these quality practices, this is the right pointer on how to get them set up in their project process.

Deepa Saini (deepasai@in.ibm.com), Software Release Manager, IBM

author photoDeepa has more than 13 years of software industry experience with almost half of it in software process implementation. She is well-versed in all of the software processes needed to develop quality software products and successfully completed PMP certification in September 2012. She is responsible for all process implementation in her current project role.



20 August 2013

Also available in Chinese

What is Test Driven Development?

Test-driven development (TDD) is a software development process that requires the developer to write an (initially failing) automated test case for the desired functionality, then add the minimum code required to pass the test case and finally refactor the code and ensure the automated tests still pass.

Adding TDD to the project process puts the focus on development through testing the requirements. In traditional development, code is written and then test cases are developed to test the code. In TDD, test cases to satisfy the requirement (generally called unit tests) are written before the implementation is begun.


What are code reviews?

Code review is systematic examination (often known as peer review) of computer source code. It is intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers' skills.

This is a very important code quality practice that is often lacking in practice as formal code reviews have required a considerable investment in preparation for the review event and execution time. Here I describe how the review effort (code review metric) can be set up as part of project process to gain insight into what the gain is compared to the investment.


What is integration testing?

Integration testing, sometimes called Integration and Testing and abbreviated as I&T, is the phase in software testing in which individual software modules are combined and tested as a group. It is implemented to verify functional, performance, and reliability requirements after unit testing is complete.

This article describes how to get your project process set up to implement these processes effectively using an IBM® Rational Team Concert™ scrum template. In this article I describe the customizations done in our project process and how Rational Team Concert processes are used to enforce TDD, code review, and integration testing in the development process.


Typical software development project process

A typical project process workflow using Rational solutions can be described as:

  1. Product requirements are split into development tasks and captured in Rational Team Concert work items. The work items are assigned to developers by the manager.
  2. Testers develop test cases for these requirements in Rational Quality Manager. These test cases are linked to the work items via the Development Items section for traceability links.
  3. Developers capture all implementation details and work artifacts in the Rational Team Concert work items.
  4. The approval process in Rational Team Concert is used to ensure that TDD is enforced in the development process, i.e. test cases are developed before the implementation begins.
  5. The code review process is tightly integrated in the project process for quality management purposes. The review process in Rational Team Concert is used to ensure that this code quality practice is enforced in the project via the creation of review records for every change set. The work item cannot be resolved unless code review records are approved.
  6. The integration testing completes the development cycle. Rational Team Concert verification records are used to enforce the integration testing process in the project. Work items cannot be closed until the verification records are approved.

The next section, Project area customization, details the customizations done in the Rational Team Concert scrum template to enforce the above process.


Project area customization

Here we use a Rational Team Concert scrum template to define the project process. Following are the project area customizations done to add TDD and the review process to the default scrum process. New work item attributes are defined.

TDD
Ensures test case development before beginning the actual implementation. This attribute is an enumeration with values 'Not Done', 'In Progress', 'Completed' and 'Not Required'. The values indicate test case development status. These values can be customized as per project needs.
 
Review Effort
'Time Duration' is used to track the effort spent in reviews. This is a useful metric to track whether the project is really gaining from quality reviews. We have seen drastic reduction in defect leakage from development to integration testing once the review process was enforced in the project.
 

Create the TDD enumeration and add attributes

  1. Go to Project Configuration > Configuration Data > Work Items > Enumerations in the Project Area: Process Configuration tab.
  2. Add a new Enumeration ID for the TDD along with defining the literals it can contain as shown in Figure 1.
Figure 1: Define TDD Enumeration
Create new enumeration for TDD
Figure 2: Define TDD Enumeration literals
Add the enumeration literals for TDD

Now add the new work item attributes to the work item types.

  1. Go to Project Configuration > Configuration Data > Work Items > Types and Attributes in the Project Area: Process Configuration tab.
  2. Select the work item type for which these attributes need to be defined. In our case these would be defined for Defect and Task. In the Attributes section, select Add to create the new custom attributes Review Effort with the type of Duration and TDD with the type of TDD (Enumeration) as shown in Figures 3 and 4.

Figure 5 shows the new attributes in the Attributes list.

Figure 3: Add Review Effort in Work Item custom attributes
Creating new attribute – Review Effort
Figure 4: Add TDD in Work Item custom attributes
Creating new attribute – TDD
Figure 5: TDD and Review Effort in Work Item custom attributes
Newly added TDD and Review Effort attributes shown

Process implementation

TDD process implementation

The project requirements are broken into development tasks for which corresponding work items are created in the project area.

  1. The project manager assigns the work item to the developer.
  2. The developer initiates the test development with the testing team when beginning the development work. This is done by creating an approval record for TDD (i.e. test cases development) and adding the tester as the approver.
  3. The tester receives email notification from Rational Team Concert on the approval creation.
  4. The tester identifies the test cases and scenarios in Rational Quality Manager to ensure testing coverage of the requirements detailed in the work item and links these test cases to the work item in the Development Items section.
  5. The tester changes the TDD attribute value in the work item to 'In Progress' to reflect the test case development progress.
  6. Once all the test cases are identified and reviewed with the developer, the tester changes the TDD attribute value to 'Completed' and approves the TDD Approval record. Setting the precondition for Require Work Item Approval on Deliver (client) from the Source Control operation ensures that any change set for the work item can only be delivered when the TDD Approval record is approved. This enforces TDD before any code changes are allowed. .
Figure 6: Precondition to enforce TDD approval process
TDD approval precondition

Code review process implementation

  1. The developer completes the development based on the work item inputs in the form of requirements and test cases.
  2. The developer executes the test cases identified in Rational Quality Manager as part of functional verification tests.
  3. Once the implementation and testing is complete, the developer attaches the code change sets to the work item.
  4. The developer initiates the review process.
    Note:
    Code delivery is done only after the code review.
  5. As part of the review process the developer creates an approval of Review type for the change set that needs to be reviewed, with the approver set to the person who should review the changes.
  6. The reviewer is notified of the review request via an e-mail or an event in his/her event feed.
  7. The reviewer goes to the work item and looks at the change sets in the Change Explorer view. Sometimes the reviewer will accept the change sets into his workspace so he/she can have a closer look, but looking at them in the change explorer is usually good enough.
  8. The reviewer adds any comments from the review to the work item and approves or rejects the approval.
  9. The developer reviews any comments and restarts the process until the reviewer and developer are in agreement on the code changes.
  10. When the review record is approved, the developer delivers the changes for integration testing.

Setting the precondition for Required Approvals on Save Work Item (server) from the Work Items operation ensures that work items can be resolved only when the Review is approved. If the work item is reopened, a new approval of the Review type is created in the pending state. This ensures that any further code changes are also reviewed.

Figure 7: Precondition to enforce code review approval process
Review approval record states defined

Integration testing process

After delivering the changes, the developer creates a new approval of Verification type in the pending state and assigns it to the tester when resolving the work item. The verification process completes the integration testing process.

The work item is closed only when the Verification is approved. This is achieved by setting a precondition for Required Approvals on Save Work Item (server) from the Work Items operation.

Figure 8: Precondition to enforce integration testing process
Verification approval record states defined

The process customizations required to effectively implement TDD with code quality and integration testing in the project are now complete.

Resources

Learn

Get products and technologies

  • Download Rational Team Concert from Jazz.net and try it free with up to 10 developers for as long as you want (requires registration). You can also try it in the sandbox instead, without installing it on your own system.
  • Evaluate IBM software in the way that suits you best: Download it for a trial, try it online, use it in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement service-oriented architecture efficiently.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational, DevOps
ArticleID=940416
ArticleTitle=Use approvals to enforce test driven development, code reviews and integration testing in Rational Team Concert
publish-date=08202013