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.
Read the project requirements so you know what to look for
Before you begin actually testing, it’s a good idea to read whatever requirements documentation your company has for the project. Even if your developer talked to you about the requirements and even if you read the requirements earlier on, read them again. I like to create a checklist of isolated, high-level business requirements that I need to test for: creating a new user, using the search filter to find data, editing forms, and the like. This gives me direction for my testing, and it also encompasses the low-level requirements that are very important but that I tend to get stuck on – buttons working, images rendering. This helps keep me from focusing too much on “breaking” things on purpose and helps me stay focused on checking the system for real usability.
TWO: Develop your style, but keep it flexible
Though it may take some time, you will naturally develop your own testing “style.” For instance, my style includes leaving a trail of “breadcrumbs” that marks every click I made, every link I followed, to test a feature. This helps me become more familiar with the system, and it also shows the developer exactly what I did to break their code. This was doubly helpful on one project, when there were several ways to access an asset upload screen. One of the “trails” to that screen allowed me to upload a file without problem, but taking the other path gave me errors when I tried to use the upload feature. Having documented the trail of clicks I made each time, I was able to help the developer narrow down the problem quickly.
Each new system will present new challenges
One of the beauties of consulting work is that each project is unique. Not only is the software created for different types of businesses, but the software will have different use cases for each of those differing businesses. This keeps the work engaging, but it also means that there is no standard “cookie-cutter” QA requirement. The bodybuilder’s client portal requires his clients to upload progress pictures regularly, so his system requires file upload testing with file type validation. That requires a different method of testing than a mobile app that uses location services for reporting crime to a task force. Developing a consistent style is an important part of your growth as a QA, but try not to keep it too rigid, or your standardized practice may miss something.
Make sure your documentation makes sense to your developer
Your style must be flexible also because you will work with several developers over your QA career, and different developers have different ideas about how QA should work. Some developers like to push changes in large batches, while others will push changes after only 2 or 3 bugs. Many that I’ve worked with prefer to see documentation in an Excel spreadsheet, but some prefer a Word document. One developer I work with leaves the system’s error messages “ugly” in the testing phase so that they state exactly what part of the code is the problem, and he has me copy and paste that message into my documentation.
THREE: Acknowledge that a system is more than the sum of its parts
Perhaps the most important part of the QA process is viewing the system from the perspective of the client. QA is not only for ensuring links are not broken and checking filters for filtering, it is also the final inspection to ensure that the client will get a product that suits their needs. A QA analyst must learn about the client in order to understand the purpose of the software. What do they do? What is their goal? What workflows do they follow, and how did the developers include the workflow in the system?
A software solution is an ecosystem and its workflows are the king fish
Remember, a workflow is more than just the single action of using the “forgot password” feature or editing a record in the Users table. A workflow is the accountant’s daily routine of logging in, searching for work orders that were completed yesterday, and then creating a new invoice for each work order. That whole process is a workflow. By testing for the functionality of the whole workflow, I am checking that not only are the high-level business requirements, such as “User can log in to the system using their email and password,” and “User can create a new invoice record,” are met, but also whether the system is intuitive for each user role and for each type of work that the software needs to accomplish. This will take you beyond the basic checklist discussed in step 1. This will bring you to a holistic testing method that reaches almost everything and leaves you with a much happier client.
Most custom software solutions have more than one user, and generally there is more than one user role. The accountant may not have the same permissions as the field worker, and they certainly will have different workflows. When doing QA, it is important to think of all of the different user roles and how each one fits into the software ecosystem. This will help you better understand the client as a complex entity, which will in turn cause you to be more thorough.
TL;DR
At first glance QA work may seem to be rote and shallow, but in reality, it requires critical thought, attention to detail, and application of “big picture” thinking to accomplish the final step in development before the client sees the product. A good round of testing before client release can make or break your product, and your relationship with the client.