Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm a Product Manager, not ideally tasked with but enjoying directly managing a new SQA team.

AdHoc testing has covered a lot of quick ground, but I think it's now time to implement better exploratory, functional and usability testing.

To do so, I feel the need to have functional specifications for each module of our website. We are launching a new version of and so I'm aiming to have an idle SQA Engineer map all functionality per module for the old site to use in testing for the new site. The new site has not introduced more features, per se, but URL structure and navigation has been altered, meaning there are differences.

If anyone has been through a similar experience or could point me towards some suitable templates / guides and offer their advice, I'd appreciate it.

share|improve this question
up vote 3 down vote accepted

Comparing old versus new is often quite a testing challenge, particularly without deep documentation. The basic, obvious parts will likely be fine. But the edge cases, the hidden dependencies, the more subtle parts, and the fixes and patches applied to the old system over the years, all can easily get lost in the transition.

A full Functional Spec would go a long way here. But having an idle QAer whip one up would only work well if that person has deep domain knowledge of the existing system.

Does the current system have any documentation? Any automated regression tests? All input like these can help.

Do you have domain experts you can call on to review documentation, contribute additions, and help with the testing? That would be useful, too.

Plan a significant period of parallel testing if you can, where all input to the old system gets put into the new system. And plan a significant Beta Testing period too, if you can.

Good luck with your challenge.

share|improve this answer
Thanks @Joe good advice. I went with this product requirements document as an outline to be used per site module and have started on the most pressing one myself, realizing that it's not really something anyone else has the product knowledge and oversight to really do to my standards. I am realizing how important this is and investing into it so that SQAs, technical marketing team, etc can really use it to know how to do their part of the job. Anything which is included should not be missed & stakeholders will buy-in. – Leon Stafford Dec 16 '12 at 18:32
above comment may have sounded a bit dictatorial, but I will be devloping this first module's documentation with collaboration from stakeholders (product owner, marketing manager, customer service manager) and then will consult with experienced but new to our company SQA Engineers :) – Leon Stafford Dec 16 '12 at 18:34
@LeonStafford I would also leverage the knowledge of your SQA Engineers. Any who have been around to test the old site will be able to point out areas of high risk. Combine this with business risk and you will have a prioritised list of which requirements to get written and signed off first. That way, when testing does start, you can maximise your testing time on those areas while bringing in the lower risk pieces of work at a later date. – SheyMouse Dec 17 '12 at 8:59
Thanks @SheyMouse, unfortunately, there was never any SQA done on the old site by engineers, but seeking input from the Customer Service Manager should highlight what the former first line of defense dealt with most. – Leon Stafford Dec 17 '12 at 12:51

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.