Page 1 of 14

Issue Tracking Roll Out Plan

How to remember not to forget

Page 2 of 14

Version Date Author Reason Change

1.0 4/14/2016 Scott Sweeting Initial Draft n/a

Page 3 of 14

Table of Contents

Issue-Tracking Objective ........................................................................................................................................ 4

Collaboration....................................................................................................................................................... 4

Efficacy ............................................................................................................................................................... 4 Testing and Continuous Improvement ................................................................................................................ 4 Issue-Tracking Roll Out Process ........................................................................................................................ 4

Roll Out Plan Stage 0: You Are Here ..................................................................................................................... 5 Roll Out Plan Stage 1: The Fancy To-Do List ........................................................................................................ 6

Stage 1 Objective ................................................................................................................................................ 6 Stage 1 Plan......................................................................................................................................................... 6 Stage 1 Conclusion ............................................................................................................................................. 6

Roll Out Plan Stage 2: Formal Software Development Process ............................................................................. 8 Stage 2 Objective ................................................................................................................................................ 8

Stage 2 Plan: Software Tester Issue Reporting ................................................................................................... 8 Stage 2 Conclusion ............................................................................................................................................. 8

Roll Out Plan Stage 3: Source Code Integration .................................................................................................. 10 Stage 3 Objective .............................................................................................................................................. 10 Stage 3 Plan....................................................................................................................................................... 10 Stage 3 Conclusion ........................................................................................................................................... 10

Roll Out Plan Stage 4: Code Review .................................................................................................................... 12 Stage 4 Objective .............................................................................................................................................. 12

Stage 4 Plan....................................................................................................................................................... 12 Stage 4 Conclusion ........................................................................................................................................... 12

Roll Out Plan Stage 5: Test Automation............................................................................................................... 14

Stage 5 Objective .............................................................................................................................................. 14 Stage 5 Implementation .................................................................................................................................... 14

Issue Tracking Roll Out Plan Conclusion ............................................................................................................. 14

Page 4 of 14

Issue-Tracking Objective Our objective is to increase collaboration and efficacy of software group by using an issue-tracking system.

Collaboration

By collaboration, it is meant that it is clear for the entire department and any other concerned observers (read:

managers, field application engineers) which software engineer is working on which issue, what issues’ priorities

are, which issues are in the queue, how many issues are unresolved for a particular release, the steps to reproduce

a particular issue, which issues are known, and which “issues” aren’t even issues and won’t be addressed. When

tester- and customer-oriented interfaces are brought on-line, we will also have formal collaboration with

departments at other stages in the software development cycle.

Efficacy

By efficacy, it is meant that when issues are identified they are resolved completely. For example, if a tester finds

an issue in software the steps to reproduce the issue are documented, the issue is reported to the software manager

who assigns the task to a software engineer, the software engineer resolves the issue, managers and field

application engineers can stay up-to-date on the engineer’s progress on the issue, the issue is recorded in the

change log for the release it goes into, and the tester verifies that the issue is resolved. This is effective issue

tracking, as opposed to a system where a tester verbally informs a software engineer of an issue and the software

engineer promptly forgets about the issue during a post-lunch food coma.

Testing and Continuous Improvement

When issues are entered by testers and software developers into issue tracking, the steps to reproduce the issue

naturally become the steps to test that the issue is fixed. Web-based issue-tracking systems also localize all test

and development communication and segregate this communication on a per-issue basis. That is, test

procedures, error logs, screen shots, code changes can be developed while an issue moves through the

workflow. This nexus of information facilitates orderly development and testing.

Issue-Tracking Roll Out Process

Recognizing that transitioning from a software development process without issue-tracking to one with issue-

tracking is a significant technical and social under-taking, the roll-out process is divided into stages. Stage 1 will

accommodate issue-tracking into the current process. Stage 2 will improve the software development process

leveraging features inherent in issue-tracking. Stage 3 will integrate the code repositories into the issue tracking

system and use the association between code revisions and issues to improve the quality of the software and the

process to develop the software.

Page 5 of 14

Roll Out Plan Stage 0: You Are Here At the outset, the issue-tracking system has already been selected for us. We will use an issue-tracking system

called Redmine. IT has installed Redmine on a supported, backed-up production server. IT has added a project

for our project’s issues. Currently, no one in engineering is using Redmine to track software issues.

Figure 1 - Stage 0

Engineers

Engineering Manager

Redmine

?

Software Testers

Page 6 of 14

Roll Out Plan Stage 1: The Fancy To-Do List

Stage 1 Objective

Stage 1 will accommodate issue-tracking into the current process.

Stage 1 Plan

1. Preparation: Modify the access control in Redmine so that only the appropriate users are allowed to

view or optionally modify issues as relevant to their particular role. Namely, we want that only engineers

and their managers are allowed to view and modify software issues, and only IT helpdesk users can view

and modify helpdesk issues.

2. Familiarity: Give every engineer a Redmine account. Give every engineer a tutorial on the concept of

issue-tracking and basic feature-set of Redmine. Get every engineer to create a test issue and assign it to

the roll-out coordinator.

3. Integration: Get the software engineering manager to write up and assign issues using issue-tracking

system. Enter new issues into issue-tracking system during strategy and status meetings until it becomes

routine. The test procedure for the given issue should be referenced if it already exists, or a proposed test

procedure should be written along with the issue description.

Stage 1 Conclusion

The development process will be largely unchanged from how it currently exists. Issues will simply be recorded

in the issue-tracking system, assigned to engineers, and closed when resolved.

Page 7 of 14

Figure 2 - Stage 1

We will then modify the software development process to take advantage of the features available in the issue-

tracking system in Stage 2.

Engineers Engineering Manager

Redmine

Issue Description, Assignment

Page 8 of 14

Roll Out Plan Stage 2: Formal Software Development Process

Stage 2 Objective

Stage 2, will improve the software development process by leveraging features inherent in issue-tracking.

Specifically, we will introduce issue-tracking to stakeholders outside the software engineering department.

Stage 2 Plan: Software Tester Issue Reporting

1. Preparation: Add testers to the software projects in Redmine with permission to report new issues within

that software project. The process flow in Redmine will be modified to assign any issue reported by a

tester to the engineering manager. The process flow will also be modified to allow assignment of an issue

back to a tester once the potential fix has been implemented to verify independently that the potential fix

does in fact resolve the issue.

2. Implementation: Testers will train on using Redmine to report issues. It’s important that testers

reference an existing test procedure if one exists that tests the issue, or write a new test procedure to be

added to the test plan.

Since new issues will be assigned to the engineering manager by default, the engineering manager will

have the responsibility to weed out redundant or inappropriate issues, decide issues’ priority, decide

which software release the issue will target, and assign the issue to a software engineer. The software

engineers or the software engineering manager will alter their workflow to assign potentially resolved

issues back to the pool of testers. Testers will verify that the issue has been resolved using updated test

procedures to do so, if necessary.

Stage 2 Conclusion

By the end of Stage 2, we will have closed the loop on issue reporting. That is, issues reported by testers will be

documented thoroughly, validated by software engineering, resolved by the appropriate software engineer, and

verified resolved by a tester. Firmware engineering managers can create software development schedules from

the issues using the estimated time to implement.

Page 9 of 14

Figure 3 - Stage 2

Software Engineers

Issue Description, Test procedure

Software Testers

Software Testers

In Testing

New Issue

In Progress

Run Test Procedure

In Progress (rejected)

Update user manuals,

requirements, software design

documents if required.

Resolved (accepted)

Software Engineers

Closed

Update test plan & procedure if required

Page 10 of 14

We will then use issue-tracking to improve the software development process within the software engineering

department in Stage 3.

Roll Out Plan Stage 3: Source Code Integration

Stage 3 Objective

In Stage 3, the primary objective is to improve software developer and manager understanding of how software

changes relate to issues through issue-tracking/code repository integration.

Stage 3 Plan

1. Preparation: Link each Redmine project to its corresponding source code repository.

2. Implementation: Train software engineers on using Redmine’s source-browsing and issue-tagging in

their normal software development workflow. It is crucial that software engineers tag each commit with

the issue that it addresses.

Stage 3 Conclusion

The association of issues to revisions of code reveals a wealth of information for software engineers and software

engineering managers. Software engineers can now look at a given line of code and find out what revision it was

changed in, look for the issue associated with that revision, and see what issue the change was intended to fix and

how to reproduce it. Software engineering managers will have a high-level concept of software engineer activity

as it relates to issues. Software engineering managers can create metrics measuring frequency of bug incidence,

issue turn-around time, etc. to improve the quality of changes.

Page 11 of 14

Figure 4 - Stage 3

Software Engineers

Redmine Statistics

Best Practices, Process, and Standards

Updates

Page 12 of 14

Roll Out Plan Stage 4: Code Review

Stage 4 Objective

Per http://smartbear.com/products/software-development/what-is-code-review/ : Software is written by human beings. Software is therefore often riddled with mistakes. To err is, of course, human, so this is an obvious correlation. But what isn’t so obvious is why software developers often rely on manual or automated testing to vet their code to the neglect of that other great gift of human nature: the ability to see and correct mistakes ourselves. Consciously and systematically convening with one’s fellow programmers to check each other’s code for mistakes is known as peer code review, and has been repeatedly shown to accelerate and streamline the process of software development like few other practices can.

In Stage 4, the primary objective is to improve software quality by using collaboration tools to conduct code

reviews. Reviews are to be conducted during the “In Progress” phase of the issue lifecycle. We will evaluate

SmartBear’s Collaborator.

Stage 4 Plan

1. Preparation: Install Collaborator on an IT-supported server. Add the software project’s new, supported

repository to Collaborator. Integrate Collaborator with Redmine using the Automatic Links feature as

described here: http://support.smartbear.com/viewarticle/20036/.

2. Implementation: Train software engineers on using Collaborator in their normal software development

workflow. When a potential resolution is ready to be integrated into the main code repository, software

engineers and software manager(s) with expertise or authority in the change set’s domain will be included

in the review through Collaborator. The concerned parties will evaluate the change set against a set of

formal and informal criteria for code acceptance.

Stage 4 Conclusion

Collaborative code reviews will improve code quality and prevent costly in-field fixes by resolving issues before

they ever leave the software engineering department.

Page 13 of 14

Figure 5 - Stage 4

Software Engineers

SmartBear Collaborator

Code review invitation

Change set feedback

Implementing Engineer

Page 14 of 14

Roll Out Plan Stage 5: Test Automation

Stage 5 Objective

The objective of Test Automation is to automate the test as much as possible. Test automation allows

comprehensive testing (e.g., assign a UUT every possible combination of ASCII characters as its name) that

would not be feasible with human testing. It also allows a quick go/no-go bench test before software developers

send an issue to be tested by testers, who will also use test automation.

Stage 5 Implementation

1. Automate firmware builds

2. Update existing Test Manager to automatically pull in new firmware builds, and note firmware versions

in test results.

3. Update issue tracking to facilitate adding new test procedures to automated testing

Issue Tracking Roll Out Plan Conclusion After completing the issue-tracking roll-out, we will have a vastly improved software development process with

minimal disruption in the day-to-day work of software engineers. The improvements will increase the amount of

collaboration between software engineers as well as between software engineering and other customer-facing

departments. We will also have significantly reduced the number of issues that “slip through the cracks” – that is

issues, once identified, are always resolved.