Every day, new features and products are shipped into the world to eagerly awaiting users. Sometimes, they are adequately tested and won’t break, meaning happy customers and more profit! But, other times, they are shipped without proper testing, putting your product at risk. Without testing, quality assurance (QA), you could lose customer trust and revenue through broken products.
From No-coders or senior developers alike, everyone can adequately test their products to ensure they are built as intended, are free of bugs, and stand up to their users. This newsletter, Testing for Everyone, shows you how to do just that!
By now, I imagine you have more questions, like
- 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!
