When performing tests on a form page with several fields and you run across an error after submitting the form, try to isolate exactly which field and submitted data caused the bug. If your test included many data entries in many fields, go back and start entering data in each field one by one, submitting each time, and seeing when the error appears again.

Once you’ve successfully reproduced your bug, then you want to make sure you fully understand the bounds of the offensive data. Enter different types of data – characters, numbers, special characters, particular formats (eg. if a date field try different date masks), mixed characters (eg. chars and numbers), blanks, etc. and submit to get the complete picture of what causes the error and what doesn’t.

If the error does not appear after attempting to isolate each field, then likely there’s some interaction between the fields that was occurring in your original test. Go back and enter the same data (or slightly different if there’s any unique value constraints) to attempt to duplicate the issue. When you can verifiably reproduce it again isolate fields one by one, keeping various combinations, until you find the minimum fields that are required to throw the error. Make sure you also continue trying different data combinations so you understand the bounds of the data in your isolated fields.

If the error cannot be reproduced, and you’ve tried as many different combinations of fields and data entries as you can consider, then mark it down as a spurious defect and keep your eyes open for it again, but move on to your next tests – there’s plenty more to do so don’t get too sidetracked on a wild goose chase!

Once you’ve nailed down the exact field(s) and data type(s) that are required to verifiably reproduce your bug, then you’re ready to write it up. Make sure you follow good procedures and include all this information including any specific steps to reproduce it. Well done!

Recent Posts

Leave a Comment