Regardless of your team’s size, a tester will communicate with all members, from developers to project managers. Additionally, some testers will perform demonstrations of new features to other members of their organization. These factors make a tester able to communicate crucial to completing the job well. However, good communication doesn’t just mean being willing to ask questions or being polite; it also means adjusting your communication to your specific audience. For example, if I’m presenting a feature to a stakeholder from a different team, I use general language to explain how the feature works. Explaining concepts with general language ensures all team members are on the same page and is just one way of communicating well as a tester.

Documentation, like communication, affects the developers, project managers, and stakeholders around you. Many don’t consider testing documentation an essential part of documenting your software, but it is. This documentation is a window into how services work and the thoughts process of your team at that time. I’ve often used my testing documentation to show how the software should and shouldn’t work when demoing a feature. Testing documentation should be clear enough that anyone should be able to read it. Being able to write good documentation is a crucial aspect of being a good tester.

Unit, Functional, Integration, End to End, Beta, and more testing techniques exist; knowing which ones to use where is essential. A carpenter doesn’t use a hammer to screw in a screw, so why should a tester use the wrong technique to test a test case. Testing shouldn’t be a massively time-consuming process, but it often is because multiple tests cover the same test case. This duplication of test cases occurs because teams don’t understand what technique they should use and why. A good understanding of testing techniques saves you time, headaches and makes you a good tester.

As more testing becomes automated, many new products now exist for testing. Tools like Rainforest QA, Percy, and Postman all work wonderfully for their specific purpose of no-code, visual, and API testing, respectively. However, like testing techniques, many of these tools are misused and become headaches. Therefore, articulating to stakeholders what tools work best can save your company money and time. Additionally, it’s essential to know when no tools, or manual testing, is best. Understanding what tools exist and how to use them best is the mark of a good tester.

Testing is a preventative measure in building software, meaning it can be hard to gauge how well a tester performs. Unlike development, it can be challenging for testers to gauge how well they are doing. Developers can measure their skill based on the quality of the software they’ve built; testers don’t have that same privilege. However, every good tester has solid communication and documentation skills and a thorough understanding of testing techniques and tools.

• What is quality assurance (QA)?
• Why is QA so important?
• How do I start testing my applications?

This issue will answer all those questions and more!

What is Quality Assurance (QA)

QA is a set of principles and methodologies to ensure your software is reliable and built as intended. Essentially QA ensures that your software does not break once into users’ hands and works the way you designed it. QA can encompass everything from automated tests covering the entire application to manual tests covering the flow of a specific feature on a web page. Regardless, QA is how you take a step back and look at your software to find anything that would cause the program to break or not meet your specifications.

QA is a set of principles and methodologies to ensure your software is reliable and built as intended.

Why is QA so important?

As I mentioned earlier, QA can be the difference between a happy paying customer and a customer who pays a competitor. An example of how even simple bugs have significant consequences is NASA’s Mars Climate Orbiter. The engineers who developed the orbiter failed to convert a metric to imperial measurement before the craft launched. So, after years of hard work and almost $200 million, the craft was unintentionally deorbited, and the mission failed. Unfortunately, without good testing, incidents like this will continue to happen. So, in essence, QA avoids the potentially severe and expensive consequences of bugs in your software.

Generally, QA is an afterthought for teams when building software. Usually, teams construct features first features and test plans last. Doing this makes you more likely only to test the way the feature should work or the happy path. Conversely, when teams develop test plans before or during development, potential errors are noticed more often and can be raised and fixed far before shipping to a customer. Developing without testing is akin to not going to the doctor regularly. You may be healthy, but you wouldn’t catch things before they become severe problems.

Developing without testing is akin to not going to the doctor regularly. You may be healthy, but you wouldn’t catch things before they become severe problems.

QA also can ensure that the way you designed a feature matches the implementation in your final product. By taking a step back and looking at your software from many different angles, you can discover how a feature doesn’t match your original design or is confusing to a user.

QA avoids the potentially severe and expensive consequences of bugs in your software.

How do I start testing my applications?

Testing is a crucial part of software development, but it’s not hard to get started. First, find a website to test, then create a document listing what you would like to test, and record your testing results.

For this example, I decided to test Meet Kevon’s website for his Making Twitter Friends course!

Before I start thinking about what to test, I create my test document. The test document helps us track and revisit our list of tests. At the top, I include a small summary of my tests like so.

Now that we have our document, we need to layout our list of tests, or test cases, before testing. When I start testing a website, I immediately look for

• Dead or incorrect links
• Input fields that accept invalid values
• Spelling errors (these can be bugs to you know!)

These bugs are easy to spot and fix but make a huge difference! As you can see, our test website has an email field; let’s add a test case to make sure that the email field only takes emails!

There was a minor bug when testing this where the email field accepts invalid emails; here is a potential bug! As a general rule of thumb, test every possible bug three times to ensure it’s repeatable, meaning it’s an actual bug!

After testing it three times, I documented that the test case was failing and let Kevon know!

Kevon fixed the bug, but I encourage you to test the fields yourself by signing up for his course anyway! ;)

Try this with your website or a website of a #buildinpublic community member today; you might be surprised by what you find!

If you do find anything, @ me on Twitter, @_heyglassy; I’d love to see what you all find!

If you enjoyed or received value from this newsletter, please make sure to like and share it. It helps this knowledge be seen by more people and generally makes my day!

Buy Me A Coffee!