Once the vendor is chosen, it is time to get down to testing. Setting up project workflow or framework is the key to success. Here are some tips on getting started:
Test a low risk area.
If there are some serious concerns about outsource then try a low-risk area. Choose a project piece that will not disrupt the schedule if there is a bad experience. As there are success experiences, then outsource as needed.
Establish a Primary contact on both sides.
If work is being done offsite, it is important that communication is done frequently and consistently. The only way to do this is establish a single point of contact on both sides. This will help eliminate miscommunications and keep the workflow going. Email is good for keeping track of every exchange. Phone calls are OK, but do not leave an audit trail. In some cases, ask for a business contact. This person can handle the non-testing issues such as the contract or personnel.
Have entire team meet face to face.
It is important for the team get to know each other, especially if the work is done offsite. By getting to know one another up front it helps build team unity once testing begins. If this isn’t possible, then try to get the key contact out to the site.
Provide Documentation to the lab
Any and all documentation should be given to the lab. They usually do not have any prior knowledge of the environments or application. If the project has already started, then they will need to come up to speed quickly. If you cannot provide documentation, then have someone from the team travel out to the lab to help bring the testers up to speed. This technique can really bring a team along quickly. In providing testplans or testcases to the lab, be as thorough as possible. It is important that testcases clearly layout what to test and what the expected outcome should be. Try to not leave any test outcomes open to interpretation.
Review their Testplans / Testcases.
If the lab is going to provide your group with testplans, review them thoroughly. Make sure the level of detail is enough to alleviate any chance of misinterpretation. Once again every test case must have a defined result. Test case outcomes cannot be open to interpretation. Look for some basic areas to be covered such as positive, negative, boundary, and documentation test cases.
Establish daily / weekly progress meetings.
Set up a regular time to get updates from the testlab. Use the time to answer questions they may have come up with, or problems they may have uncovered. In addition, be sure to get a weekly written update. These updates include defect reports, testing status and any other issues. Get a pager, in case the environment goes down while they are testing. Testers should never be idle.
Establish defect-reporting mechanism.
If possible have the testers enter defects directly into the defect database. A web based tracking system may be a best bet. Another method is to send issues via email, but these can sometimes get lost. Have someone from your staff verify the bugs before they are reported to development. Be sure the bugs are reproducible before getting development involved. This will also help get development buy-in to outsource test. Developers do not like hard to reproduce bugs. If the vendors are sending the defects this way, this will reduce confidence in the vendor ability.
Project End Deliverables
As the project comes to an end there should be clearly defined project end deliverables. The deliverables may include the following:
- Project Summary Recommendations
- Completed testcases with results
- Copies of all correspondence Bug / Incident reports.
