0

First off let me confess that I am not a Quality Assurance person and I've only tested my own code as a developer (we all know what that means) so I have scant knowledge of the technologies and processes that occupy this discipline.

We have a third party workflow solution that interfaces with a back-end accounting system and we frequently get hotfixes and version upgrades which are either not thoroughly tested by the vendor or not tested on a system like ours so bugs get into our production system. Our current QA department (1 person) is pretty lame. BTW, if anyone would like to take a step in their careers and build a QA process from the ground up I'd like to talk to you!

In the meantime, we are hard-pressed to find a solid way of doing testing when we get an upgrade. There are so many actions that can get jacked up and so far we've just been following a standard path through the process manually, which, so far anyway, has been missing stuff.

0

As a sole tester I can offer you some suggestions here. You may already be on this path.

You have your manual standard path through the process: have you documented this? If not, document it first. Tribal knowledge can disappear very quickly when the one person who really understands the thing leaves. It doesn't matter how you document at this point.

Next, anything you miss you add to the document. I've seen some astonishingly complete test case listings that were built by adding in anything that got missed for each release or patch. What will happen is that your basic regression test will grow - sometimes quite quickly.

Your third major focus happens next: work with your QA department to identify a path to automating your regression. Since you have a QA department of 1, there's a good chance they won't have bandwidth to automate without a whole team effort (that's QA and dev working together).

If the third step can't happen, the fallback is to use as many people as you need to to perform your regression tests. Sooner or later that time investment will convince someone to allocate time to build test automation - but depending on your environment, it's much more likely to be "later" rather than "sooner".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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