1. Page 1 of 14
Issue Tracking Roll Out Plan
How to remember not to forget
2. Page 2 of 14
Version Date Author Reason Change
1.0 4/14/2016 Scott Sweeting Initial Draft n/a
3. 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
4. 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.
5. 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
6. 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.
7. 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
8. 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.
9. 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
10. 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.
11. Page 11 of 14
Figure 4 - Stage 3
Software Engineers
Redmine
Statistics
Best Practices,
Process, and Standards
Updates
12. 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.
14. 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.
