One critical aspect of test management involves completing the loop with defect fixes and source code control. It’s all very well raising bugs as part of the QA process. And it’s good to know that those bugs have been fixed. To be totally in control though you need to know what and how it was fixed. Typically this means linking your issue tracking system into your source code control system. In the example below we look at an example of how to integrate QAComplete/ALMComplete into SubVersion.
Specifically we see how you can.
For many development and QA teams this essential link is never made. There is never the ability to see what exactly was changed to resolve a bug. When you make this link, tying test management and defect management to a tool like Subversion you complete the traceability circle.
Most of this process can be covered with a test management tool or application lifecycle tool. The part that is usually difficult in all of this is connecting to the source code control repository. Essentially the part where the developers changes to the files are checked into a tool like Subversion. When you have the capability to link source code file changes directly to the original defect you have a powerful traceability capability.
For example when a developer comes to modify a file in the future, they see the source code comments and get visibility of the issue that resulted in the last change to the file. When they view the defect record they get full visibility of why the change was made. When they modify the file again they even have traceability to testcases used previously that can now be used as regression checks again.
How does this work in practice? The following video takes you through the full work flow.
First, we start off with our test management system. Here we execute some tests and then raise a defect. In our example we’re using QAComplete. In the video you can see this execution means we raise a defect. Secondly, that defect is assigned to a developer who then makes a fix and updates the source files. Thirdly, after the developer has updated the source files, he/she will check the files into SVN. During the check in he/she will add a check in comment along these lines…
svn ci -m "D::123456 another ci" file1.txt
Where D::123456 refers to the bug in QAComplete that the changes relate to.
Fourthly, the integration tool (OpsHub) used to link SVN and QAComplete will now reference those files that were checked in against the defect. In the video you’ll see the original issue record with traceability to all of the files that were checked in. The developer then moves the defect to a resolved state and assigns to the QA engineer so that a re-test can take place. Lastly, the QA engineer picks up the fix and can quickly create a test to check the fix has worked. This can then be added to a regression suite to run as part of a set during the next cycle.
In conclusion then you link your test management and defect tracking tools into Subversion to provide all round traceability. With this level of traceability people working on the project can see exactly what and how issues are resolved from all angles.
