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.
