Release to Software Quality Assurance

Once your code has been tested, reviewed, and checked in the issue is ready for SQA (Software Quality Assurance) testing.

Documentation

As part of passing an issue to SQA for testing you should consider what you have done, and what impacts that will have on the environment and user interface of the application. As developers we often will do things like stopping and restarting a service, or registering a COM control, or installing 3rd party drivers, that the SQA testers will not just know to do. Document these steps that they will need to perform to ensure that development and testing cycles are not wasted. Make sure to attach the FogBugz case numbers for the issue being sent to SQA for testing.

Defect Tracking Cycle

In the defect tracking tool you can forward an issue and mark it ready to test. This will allow SQA to pick it up and begin testing.

In person follow up

While not a requirement it is recommended with any significant change that you follow up in person with the SQA testers that are testing your code. Answer any questions they have, address any concerns. We are all part of the same team and it is all of our jobs to release the best software we can.

Candidate Builds for QA/Production

The build for QA testing (i.e. any candidate for production release) will include building from the VCS. The option Build without Comments will be used to remove comments from any documentation in the applications.

Because of the way Omnis Studio is tokenized and structured and how the VCS operates, this will also have a supplementary effect of removing any commented test PAN’s and or other text based security information that may be present in the code.

Separation of Environments

The Studio VCS is used to help control and separate the Development, Test and Release functions.

  • Developers test on their own machines, and at the end of the building and unit test processes, must place code into the VCS.
  • The QA Test team builds candidate release from the VCS and uses their own test databases and test suites to prove the bug fixes or enhancements
  • Code designated as a production release will go through the final build and testing process