Code Test Release Cycle

This is intended to be high level overview of the coding / testing / release cycle of software development. The primary target of this reference is newer developers, as well as teams that have not solidified their development process.

This resource is not meant to give a set of hard rules that must be followed. Instead it is meant as a general description and guide to assist teams in improving their coding process. Due to the general nature of the workflow, it may be adapted to apply to both Waterfall and Agile development methodologies.

Development Workflow

Workflow Description

Click on expansion arrows where available for additional detail of the step.

1. Coding Phase

1. Create new code and corresponding unit tests / update old code and old unit tests.

   The Coding Phase is where we take the defined features and requirements, and implement them in code. Note that the Code Development step includes not only the code, but the unit tests verifying the code as well.

2. Code review to verify code and unit tests work correctly, and all coding standards are met:

   Once the code and units tests are completed, a code review needs to occur. The purpose of the review is to ensure that the code meets the necessary requirements and standards.

3. Did the code pass unit tests and code review?
   1. If any unit tests fail or the review does not pass, return to step 1.
   2. If everything passes, continue to step 4.

4. Testing Phase

4. Update the test environment and install the new code.

   The first part of the system testing is placing the new code into the testing environment. This environment should mirror the production systems as closely as possible. The goal is to have any behaviors the code exhibits in the testing environment be the same in the production environment.

   Is extremely important to note that the test environment should not be updated without the tester being informed. Surprise changes to the environment may very well invalidate any or all work a tester has already done. Possible effects are that the tester may need to redo a lot of work, or even that bugs will slip through the process.

5. Create System Tests for the new code.

   After the test environment is ready, the person in charge of the testing may begin the actual testing. In this case, the tester will be creating, updating, and executing tests that will concentrate not only on the new code, but also on how the new code works within the the system as a whole. Each test should reflect how a user would would interact with the system in production.

   When dealing with changes to an existing system, the tester will most likely have to update or remove previously existing system tests.

   All of the system tests will need to be reviewed.

6. Run the System Tests.

   If any of the system tests fail, then the reason for the failure must be assessed, and the next appropriate action will be taken. If the test environment is not set up correctly, then it must be corrected, and the tests run again. If there is an error with the tests, then tests need to be corrected. If there is an error in the code, then everyone needs to go back to the beginning of the Coding Phase, and correct the code.

   Note: all of the possible back paths are not shown in the graph. This was done to keep the graph clean.

   1. If an environmental issue causes a test to fail, return to step 4.
   2. If a test is invalid, return to step 5.
   3. If the code is not meeting the requirements, return to step 1.
   4. If everything is passing, continue to step 7.

7. Regression Phase

7. Update regression tests with new tests from the Testing Phase.

   One the above testing phase has been completed, the new tests need to be merged with the existing regression tests.

8. Run regression tests.
9. Did all regression tests pass?

   If a regression tests fails, then everything needs to be looked at with very careful consideration.

   If the failing test was created in step 5, but passed in step 6, then the issue may be in how the test was added into the regression suite.

   If another test failed, but it was due to an environmental issue, then the environment needs to be updated.

   The worst case is when a test fails, but it was one of the tests that covered an area that was not supposed to be touched. In this case, a very through examination of the code may be needed to isolate the issue.

   1. If a new test is invalid, return to step 7.
   2. If an environmental issue causes a test to fail, return to step 4.
   3. If the code is not meeting the requirements, return to step 1.
   4. If everything is passing, continue to step 10.

10. Release Phase

10. Release the code to production.