Now that you have determined the types of testing needed and who is going to manage the effort, all you need is what type of documentation to send the team to execute testing. What you send is determined by two main factors:
● Testing Type
● Validity (is the information current)
You may still have work to do if you are expecting the testing service to perform testing you do not do. For example, if you have decided to outsource security testing the tests required are unique. In this case, you will need to have the testing service team create the documentation or test cases for you as part of their deliverables. If you are outsourcing functional regression testing and you have existing tests, then it makes sense to provide them to the testing service team for use. Testing service teams can write and update tests, but you will need to provide them with training and support until they are familiar with how the application functions.
It boils down to either doing the work beforehand internally or doing the work with the testing service team by providing training and issue support. Either way, you will need to ensure the testing service team has the current information necessary to give you the best value for your testing dollars.
Help or End User Documentation
Many companies prefer to re-use their existing Help or end-user documentation as the source documents for testing. The advantage to using existing Help or end-user documentation is both the application and the documentation, are tested during the project. In other words, the application functionality will match the end user documentation. You will get your Help documentation updated, and the application tested.
Keep in mind, however, if you are having the testing service provide non-functional types of testing like load and security testing, providing the Help or end-user documentation is not useful for test execution. It may be useful for training purposes and providing general knowledge for the testing service team to create specialty test cases from.
Existing test case suites
Providing existing test case suites is the most direct option. However, the effectiveness of re-using existing test case depends on a few factors:
● If tests are automated, does the testing service team have the software to execute them?
● If manual, are they in a human-readable format? Sounds odd, but many times manual test case is written in a code-like structure that can be difficult to read directly.
● Are the test cases up to date?
Providing test cases for functional, regression, smoke, integration and acceptance testing is typically achievable without extra work. Security and Load type tests make require special tools or access rights. You will need to determine how to best provide the test cases to the testing service team, or have them create a set for you based on current application specifications. Be sure to factor in the additional cost, if any, of having the testing services team create your specialty type test cases for execution.
If you are providing existing test cases, decide whether to allow the testing service team to make changes or edits. Make certain the team understands the application functionality before they do test case editing on their own. Many times what is believed to be understood,is not, and you will end up losing valuable test case data, or the test will be simplified to the point of being useless. Test case information is a development team asset. Make sure you keep a backup copy of test case data before sharing it with another team. Another option is to implement version control that retains the original test case copy.
Training course materials
Using existing application training course material is another option for providing the testing service team documentation to test from. Similar to providing Help or end-user documentation, the training course materials get reviewed as well as the application functionality during the project. However, it is important to verify the training course materials are updated and written clearly before providing them as testing source documentation. Otherwise, you will generate more issues for the project manager or SME assisting the testing service team.
It seems like a simple concept - what you put in, is what you get out. Still, many software development companies skip this step and expect the testing service team to fill in the blanks. They will create the documentation as they see it, but you may end up with issues that aren’t real, and a lot of wasted time trying to answer questions that would have been answered if quality, updated documentation was provided. In order to get the best quality out of the project, deliver high-quality documentation for a testing, in the chosen format, and you will get a higher quality result from your testing services project.