Author: Libby Reiner

ONE:  Don't just "break the system" I remember my very first QA task when I started here three years ago.  I was testing a client’s internal employee management system.  I had never tested anything before, so I asked my project manager, “How should I QA the software?  What does that mean?”  He answered simply: “Do your best to break the system.”  Okay, I thought, should be easy enough.   So, when I sat down at my computer, I opened the user management screen and did my best to mess with it – invalid email addresses (example: cersei@lannister.net, ned@winterfell, harryunderthestairs.com), phone numbers with too many or too few digits.  And I made sure to document in Notepad every “error” I found this way. After about an hour of this, I proudly sent my list to the developer.  Look at all the bugs I found!  A few minutes later, the programmer walked over to my desk and explained gently that these were not the only types of bugs I should be looking for.  While it is worth knowing which fields catch invalid data types and which do not, this is only the beginning of the testing process.