Jobyssey

So, as development on Jobyssey rolls along we’ve stared seeing more pieces of functionality completed and ready for testing.  As a start up, our developer hands over the code and it’s up to us to check that everything is functioning properly.  We found a real dearth of ideas about how to implement an extremely simple, basic QA procedure.  Plenty of ideas as to why QA was important, why you should hire QA people, how you should track bugs and so on, but not much that spoke to the “QA on a shoestring” contingent (Yo).

Here’s the procedure we followed:

Functionality testing:

1.  Set up a Google spreadsheet to hold your testing plan and to record results.  It should have 5 columns: test condition, expected result, actual result, status, and owner (see a sample spreadsheet here).
2. In the “test condition” column, write out each thing you should be able to do with the software.  Once you’ve described all of the primary functionality you should also add any likely problems or misuses you want to check for (for example “user applies for job they were already declined for”).
3. In the “expected result” column, put each thing that should happen as a result of the test condition on its’ own line.  For example, row 1 might have a test condition like “user applies for a job” and the first expected result “ticket created with status set to applied”, and several following rows might hold other things that should also happen as a result of the same action (such as sending the employer an email).
4. Now the fun starts :-).  For each test condition, try the feature/ action specified, and check for each expected result.  If it works, put a “yes” in the “actual result” column and rejoice.  If it doesn’t perform as expected, put a “no” in the “actual result” column and add a note in parentheses explaining exactly what doesn’t work properly.  Save a copy of the page or error message if needed and reference it here, or refer to the relevant design document if needed.
5. Decide what to do about your “no’s”.  Color the line red for severe problems that keep you from completing testing, or that are major functionality problems.  Less critical problems get colored yellow.  Every problem should be assigned an owner that is responsible for fixing it.  If it is an ongoing issue notes on the fix should be kept in the status box.

We haven’t done any load testing, etc. as yet, but when we get there I’ll post that too.  Hopefully this will be a help to other startups without the resources yet to hire QA staff.  Comments and suggestions from anyone with a QA background or experience doing basic QA would be most welcome!