Create a regression test plan. This is to be done in two steps: First, identify a code change that can be made in the code-base. Second, create a set of test cases which will verify the change.
Identify a Code Change
With your partner(s), identify a code change that can be made in the code-base previously selected. This change should not alter the functionality of the project, but rather modify an implementation detail. In other words, the functionality of the code should not change. The following are examples of code changes:
- Encapsulate:
Take a data structure that was created with built-in data types
and turn it into a class.
For example, turn a Sudoku board created from a 9x9 array of integers
into a
Boardclass. - File Format: Adjust the file format from one format to another. For example, consider a Sudoku file format that consisted of 81 numbers. Turn this file format into JSON.
- Algorithm. Oftentimes, more than one algorithm produces the same result. When this is the case, swap out one algorithm for another. For example, swap a bubble sort for an insertion sort, or a linear search for a binary search.
Regression testing can be performed on code changes of any size. This includes major changes like swapping out data base technology in an enterprise application, to minor changes such as renaming a variable. For the purpose of this lab, our code change must be somewhere in between. The code change must be about one or two dozen lines of code.
Note that if your code change is not expected to alter functionality but it does due to an unforeseen implementation detail, then your regression testing should catch that change. In other words, it is OK if the regression test fails because it caught a real bug you unintentionally introduced.
Create a Regression Test Plan
Now that you have identified the code change that you are going to make, create a plan for how you will validate that the change did not impact functionality. To do this, you are going to generate an "appropriate" number of test cases to fully cover the change.
Remember you are not testing the code change, but everything around the code change. You are testing that the change in the code did not effect the rest of code. For example, if you were testing a change in a web page, you would write tests that about the webpage before the change. You would then get the newer version and run the same tests again to make sure the change didn't cause any effects or did cause effects.
Exactly how many test cases will be required? This depends on the complexity of your change. For example, if your code change was in how a tic-tac-toe board is stored in memory, then you will have to verify the file-save code, the display code, and the board edit code. Each of these three points will probably require a half dozen test cases.
Don't worry if you think that the change will cause any one of the tests to fail. That is the purpose of the regression test to identify the changes. In the report, in the next assignment, you identify the issue and on a development project you submit the report back to the programmers to fix.
Each test cases should be comparable in detail to what we produced last week.
Submission
Your team will submit a single document for your test cases. The document needs to be in the PDF format. It must consist of the following components:
- Project: Provide a two or three sentence description of the project in which the code change will be made.
- Code Change: Describe in detail the code that will be changed. This includes the actual code that will be change (just the fragment that will require a change, not the entire program), and a description of what the code will look like after the change.
- Test Cases: All the test cases that will be used to verify the change.
Assessment
Your submission will be evaluated according to the following rubric:
| Exceptional 100% |
Good 90% |
Acceptable 70% |
Developing 50% |
Missing 0% |
|
|---|---|---|---|---|---|
| Code-base Selection 10% |
The code base selection is an excellent choice | The code base is of an appropriate level of complexity | It is possible to complete this lab with this code-base, but it will be more difficult than necessary | The code base is not appropriate for this lab | No code base was described |
| Code Change 20% |
It is easy to see how this code change can be made and tested | All the required information is present to visualize the proposed code change | The code change is too simplistic or too complex to be reasonably verified | The proposed code change will not be appropriate for this lab | The code change was not described |
| Test Cases 60% |
There is no room for improvement in the test cases | Each test case is well-defined and will completely cover the change | A few minor errors or missing information exists | Insufficient detail or insufficient test coverage | No test cases are present |
| Professionalism 10% |
The report is professional, easy to read, and all the ideas are clearly communicated | The writing style is "professional:" there are no grammar, spelling, or formatting errors | There exists an instance of a spelling error, grammar error, overly verbose wording, poor formatting, or poor writing | Multiple spelling, grammatical, formatting, or writing errors | Gross spelling/grammar errors or other aspects of the writing that make the report difficult to read |