Testing software

Butters · 14 Jan 2008 at 11:46

Does anyone here test software for a living (or part time).

I know there are quite a few MS testers but what I am looking for is people who use the system and record their findings in a proofing document. Also, I guess you are given the means to try and break the software or hack it too?

Can you give me some guidelines on what I should be looking for and how to document it accurately?

melbourne720 · 14 Jan 2008 at 12:05

I'm a software tester, don't test MS software though. Not quite sure what you mean by a proofing document - an record of actual results or something like that?

Feel free to mail me with any questions relating to software testing, I'll answer them if I can

Butters · 14 Jan 2008 at 12:34

yeah just a simple record of results. Do you bullet point things as you find them or write out paragraphs, etc?

[DOD]Asprilla · 14 Jan 2008 at 12:39

I do a little bit of Systest and UAT.

Generally i start with the user scripts that they will use for UAT and then follow the instructions, but use them incorrectly at each possible stage to see the system reaction. I do this for both single errors and combinations.

Recording is easy: document the steps you went though in detail including any data you entered into the system and then describe the outcome, using screenshots if neceesary.

Since I mainly work in agile environments, this information is loaded directly into the fault / bug logging system and assigned to the devs, rather than into any particular document.

Just seen your post above; I do the following:

Test Number:
Prerequisits:
Description:
Process:
Pass / Fail:
Detailed outcome:

I'd also, if it was appropriate, cross reference back to the original requirements / functional spec docs so show why it has failed it's test.

melbourne720 · 14 Jan 2008 at 13:45

I normall write a script in steps, and each step into a number of sub steps.

e.g.

Script 1: Test Invoice function.

Step 1: Create invoice PDF

Sub Step, Test Action, Expected Results, Pass/Fail, Questions - Issues

etc...

We mostly work by testing the conditions with the software. i.e. We know what the software should do, and write a script based around that. Run the script and then log any issues, with the script either getting a pass or a fail.