Creating Our Test Scripts and Planning for Quality

Testing is an integral part of software development.  It is critical for producing quality and an essential habit to develop early in your career.  We will look at building test considerations into our product development process from the very beginning.  This is an excellent way to keep the cost of fixing bugs down as we will catch them early in the process when they are easier to correct. Validating Data

Garbage in, garbage out is something that rises to the level of a golden rule in software.  Not only can bad data be useless on its own, but it can also corrupt and crash an entire system.  Therefore, the payoff for doing proper validation of your data and testing those validations is huge.  When you are checking validations, there are several things to consider.

• empty/null values
• exact minimum size or value
• exact maximum size or value
• one above and one below the exact minimum
• one above and one below the exact maximum
• For strings, check special characters and tags

Make sure you run through these as part of checking your validations and also make sure your specification notes how to handle these situations.

Inputs, Outputs and Happy Path

The most natural path through the solution to test should be the happy path.  This is the experience a user gets when they enter all valid data, and everything works correctly.  There may be some feedback and output to verify as part of testing the application.  Thus, it makes sense to start here.  Let's make sure our solution works in at least one instance. After the happy path has been tested, then start walking down it and figure out where things can go wrong.  This will help you determine how to check input, output, and user messages or notifications.  The beautiful thing is that this provides a somewhat logical approach to testing and helps reduce the guesswork involved.

Exceptions and Notifications

The most challenging part of building your test scripts often is determining exceptions and how to notify the user when they occur.  By their very nature, exceptions are situations that are not normal or maybe even expected.  That does not mean they are always a complete surprise nor do they preclude the ability to handle them in some way.  You do not expect to cut your finger, but you still have bandages in case you need them. The trick is not only identifying exceptions.  There is also the decision to be made whether you recover from it, choose another approach, or notify the user.  When you create thorough test scripts, then these decisions should all show up in your results after a run of them.

Your Homework

Walk through your specification and create test scripts.  The linked document will hopefully help you with this step and provide some good experience in creating test scripts. The updated Document with Example Test Scripts/Notes: ProductCreationWorksheet-Episode4