I never thought I would work for a company that builds websites. I have lots of academic training and job experience, but none of it centered around technology. I first worked with Cantilever as a client while they developed a project that I am still a part of. I got really involved during the build process of a website and I guess I must have been pretty nice about it because they offered me a job after the site launched. They liked my attention to detail, communicativeness, and attitude when finding and reporting bugs to them. At the time, I did not even know that what I was doing was called QA. So, I had no formal training on how to QA something but lots of apparent proclivity. Over time, at Cantilever I have developed this raw talent into professional-grade skills. As the QA engineer on a project, the team relies on me as the last line of defense against problems being shipped in our websites. I now feel confident that I can perform this job capably and want to share how I got to that place.

Maybe your story is like mine or maybe you’ve gone a more direct route to working in the website-building-industry. If you’re in the former group, this article is for you as I share what I’ve learned while overcoming imposter syndrome. If you’re in the latter group, this is still for you because we are all learning and improving together, right?

So, here they are, dear readers: my top tips for building a structured and successful QA strategy! Before we get to those four tips, though, here’s the main takeaway:

Organization and clear communication are key.

If nothing else, this is what I want you to remember. The next four tips are practical breakdowns of this concept. You can stop reading here. (Although, I hope you won’t.) That being said, I invite you to read on. Short on time? That’s okay. Each tip is the title of its own section — its very own “TLDR.” You’re welcome.

‍

1.Know what your tools are and keep access to them in a central location.

‍

The name “Quality Assurance” implies comparison to a standard and thus necessitates multiplicity because at the very least you have to compare to something. Keeping the collection of tools that you use on a project in a single location makes them easier to find. What URL(s) are you testing? Where is your issue repository located? Are you comparing a build with design comps? Where are the project’s passwords stored for team use? These are just a sampling of the things you may need to know.

Rather than spending time looking them up, keep all necessary links in a single document that serves as a hub that you can easily start from and return to as you work on the project. Maybe your Dev team will build this (mine does), but even if so, you should know where it is and help update it with things like the milestone that you created within the repository that you’re using so that the rest of the team can find those excellent bugs that you found. (Yay, you!)

‍

2.Work with your Dev team to build and maintain a QA Checklist so you have documentation of acceptable behavior.

QA Checklists at Cantilever detail the components, pages, and expected functionalities within a project. They can include screenshots, written descriptions, and bullet points of what things should be explicitly tested. Our Dev team builds the initial document so that the QA team knows what to look for.

While a QA Checklist provides an excellent overview of what to expect at the beginning of the testing process, it is not uncommon for design or functionality to shift during development. Design creep is just a thing that happens. But, it becomes problematic when these changes are not noted or updated in the QA Checklist. Update the QA Checklist to reflect current expectations, aspects of the project that are in the process of being built, or weird behaviors that are known and accepted. (It is common knowledge that not all browsers function the same way or have the same amount of user traffic so certain obscure “bugs” might not be worth fixing.)

When these changes are made, be sure to notify the rest of the team that you are working with to ensure that you are all working towards the same goal and standard, especially if you delete anything out of the document. Nobody enjoys the feeling of: “I just had this here! Where did it go?”

‍

3.Take notes on what you have tested.

What browsers or devices have you tested for the project? Are there multiple components of pages that need checking? During your testing process, think like Hansel and Gretel: leave yourself a trail that you can follow once you’ve gone deep into the weeds. Remember how our teachers always told us to “show your work” when we were learning how to do math? The same principle applies.

Sure, in the moment, it might be super-easy to mentally hold all that you’re doing, but life is full of distractions that pose opportunities for your brain to change focus and forget what you had held in your mind. If you need to pause your QA work, save yourself from a future headache: make clear (and concise) notes of what you have (or have not) done.

Yes, whatever is fighting for your attention will have to wait while you jot down what parts of the project you have tested so far, but these notes along with the QA Checklist function like a map in that they show you both where you will go and where you have come from. Future you will thank you (along with any team members you may work with if you have to pass the project along).

‍

4.Use a template for reporting issues to clearly and efficiently communicate your finds with your Dev team.

You’ve found a bug — hooray! Now, how do you best communicate to your team about it? This is where a QA report template comes in handy. This is a pre-established format for reporting a bug which you can copy and paste into a new issue. Cantilever uses our own issue template and it vastly improved my ability to communicate my finds with the rest of the team in addition to helping them more quickly find and address the bugs that I found. Our rule of thumb when working with a template is to just fill out the parts that are pertinent. You do not have to use all of a template, but using one helps you:

• Provide the necessary information and details about a bug
  There may be steps or details to finding a bug that are not immediately noticeable to you but are important for your Dev team to know when finding or fixing the issue.
• Avoid over-communicating non-essential information
  Think “communication traffic jam.” Providing too much information can flood communication lines and negatively impact your team’s ability to work efficiently. A template can help you decide what does and what doesn’t need to be communicated. Can’t tell if it needs to be communicated or not? At least it provides some structure so that the rest of your team can easily look through what you’ve provided and determine for themselves what they need to know.
• Speak “developer” language without having to know it
  Maybe, like me, you have little to no training in how to build websites but you’re good at finding stuff that’s broken or otherwise not functioning as it should. Using a template can provide guidance on what or how to communicate your finds with the rest of your development team so that they can find and squash those bugs.

As a bonus, using a template provides training on what and how to communicate. After roughly a year of using a template, there are times when I do not use one when bringing a find to the attention of the rest of my team because I now have a better understanding on what information needs to be provided and how I can most efficiently communicate it. Don’t have a template of your own? You can use ours (provided below in markdown) as a starting point:

### Summary‍

(Summarize the issue encountered concisely)

### Steps to reproduce

(How one can reproduce the issue — this is very important)

### What is the current issue behavior?

(What actually happens)

### What is the expected correct behavior?

(What you should see instead)

### Relevant logs and/or screenshots

(Paste any relevant logs — please use code blocks (```) to format console output, logs, and code as it’s very hard to read otherwise.)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

/label ~bug ~reproduced ~needs-investigation

‍

Wrapping it up

Thank you for reading this article. I usually edit Cantilever’s articles, not write them, and this has been a blast. If you find these tips helpful, please let us know! Have a modification you’d suggest or other ideas? We’d like to know those, too!

Maybe after reading this article, you’re thinking: “She’s rad. I’d love to have this team build a site for me.” (Oh my gosh! We’d love that, too!)

So, leave us a comment or drop us a line. We’re all about getting better together and would love to chat.