Search for a command to run...
No comments yet. Be the first to comment.
Whether you are a No-Coder or Senior Developer, this newsletter teaches everyone to create reliable software through testing!
Testing For Everyone, Issue #1
On Testing For Everyone, we talk a lot about why people should test their applications, but we haven’t talked about the testers themselves. Testing, like the wider programming world, has a semi-steep learning curve. Like most jobs in software development, It’s overwhelming to learn about the various testing frameworks, techniques, and tools you’ll use. However, testers have the unique challenge of gauging how well they’re doing as a tester. While developers measure their effectiveness by the quality of what they’ve built, testers don’t have that same luxury. Testing is preventative, so the absence of bugs is typically the closest thing to “quality” testers can measure. Instead of gauging by a lack of bugs, which is unsatisfactory, testers should measure themselves by their quality of communication and documentation and their understanding of testing techniques and tools.
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.
