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 ExploreTalent.com 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.

1 Answer 1


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.

  • 1
    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.
    – ljs.dev
    Dec 16, 2012 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 :)
    – ljs.dev
    Dec 16, 2012 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, 2012 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.
    – ljs.dev
    Dec 17, 2012 at 12:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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