{"id":4352,"date":"2021-10-25T07:00:13","date_gmt":"2021-10-25T06:00:13","guid":{"rendered":"https:\/\/www.diogonunes.com\/blog\/?p=4352"},"modified":"2021-11-05T22:29:27","modified_gmt":"2021-11-05T22:29:27","slug":"testing-concepts-3","status":"publish","type":"post","link":"https:\/\/www.diogonunes.com\/blog\/testing-concepts-3\/","title":{"rendered":"Testing is not just\u2026 (Concepts #3)"},"content":{"rendered":"
\"\"
Photo by Lenny Kuhne<\/a> on Unsplash<\/a>
<\/figcaption><\/figure>\n
\n

\ud83c\udfc6 This post was featured<\/strong> in Software Testing Weekly #95<\/a> and Coding JAG #60<\/a><\/p>\n<\/blockquote>\n

<\/p>\n

This is part of my free testing course<\/a>, focused on teaching you the fundamentals of testing<\/em> \ud83d\ude09<\/p>\n

\ud83e\udd16 Automation<\/h2>\n
\n

Much of what we find as testers comes off-script and high-value unknowns are found by letting humans do what humans do best – thinking creatively!<\/p>\n

\u2014 Connor Roberts<\/a><\/p>\n<\/blockquote>\n

Tools can be used to support many testing activities \u2014 automating checks is just one.<\/p>\n

Testing is about using and creating tools to support your work, not trying to get them to replace you. Testing as an exploratory, intellectual activity, cannot be replaced by automated checks.<\/p>\n

No automation will ever replace the tester reaction of “hmm, that’s odd”.<\/p>\n

Automation is a tool that frees us from repetitive monotonous tasks; a means to save time and invest it in using our brains towards our testing goal. And since words matter, we prefer to say “Automation in Testing”<\/a> than “Test Automation”.<\/p>\n

Remember: your product will be used by humans, like you. If only bots “test” your product, what kind of product will you deliver?<\/p>\n

\u2705 Checking<\/h2>\n
\n

When you check, you confirm what you already know. When you test, you search for new information.<\/p>\n

\u2014 Connor Roberts<\/a><\/p>\n<\/blockquote>\n

As you should know by now, testing encompasses many activities \u2014 checking is just one of those.<\/p>\n

According to Rapid Software Testing<\/a>, checking is “the process of making evaluations by applying algorithmic decisions to observations of a product”. Algorithmic meaning objective and repeatable. That’s why checking is an activity that can be performed by a tool instead of a human.<\/p>\n

However, testing is a cognitive work that can only be performed by a human, optionally supported by tools.<\/p>\n

\ud83d\udca5 Breaking software<\/h2>\n
\n

Somehow, code that worked just fine for the developer doesn’t work for the tester. The reason is that the tester did something the developer didn’t expect.<\/p>\n

\u2014 Kate Paulk<\/a><\/p>\n<\/blockquote>\n

Testing is about exploring and discovering new information. Sometimes, testing attacks the software to check how it stands its ground (e.g. Penetration Testing). But most of the times, testers just search places that are broken and report them. They might not look broken, they might look unexpected or unpleasant to the user.<\/p>\n

It’s like holding an object in your hand and, gently, look for cracks. In dysfunctional teams, testing can be blamed for not finding bugs or finding too many issues. Testing is just “the messenger”, so focus on bringing reliable and relevant “news” to your team.<\/p>\n

\ud83d\udc35 Straightforward<\/h2>\n
\n

Testing is often thought of as something anyone can do (\u2026) It takes real skill to do these things well and in a systematic way.<\/p>\n

\u2014 Claire Reckless<\/a><\/p>\n<\/blockquote>\n

Anyone can “play around” with a product. But testers explore it in a structured way. They use their intuition to look for problematic areas and their empathy to think\/feel like a user. They report their findings objectively, together with recommendations.<\/p>\n

Anyone, even bots, can perform an action and compare the actual result with an expectation. But testers design scenarios to maximise coverage while minimising execution time. Some will be automated, and for those they will use\/create tools and frameworks.<\/p>\n

\n

If you have skilled testers with the freedom and knowledge to investigate beyond test scripts, you will find your testers doing (\u2026) a number of things to add value to your software, that an untrained person wouldn’t know are even possible.<\/p>\n

\u2014 Kate Paulk<\/a><\/p>\n<\/blockquote>\n

\ud83d\udcaf Quality Assurance (QA)<\/h2>\n
\n

Assuring quality requires control and when there are so many variables in play, control comes down to everyone doing their best work to make the software as good as they can get it.<\/p>\n

\u2014 Kate Paulk<\/a><\/p>\n<\/blockquote>\n

Quality is a team effort. If something fails in production it’s because the whole team failed: maybe the PO had unclear requirements, the developer forgot to consider an extra scenario, the DevOps deployed at the wrong time and the tester did not explore enough to spot the issue.<\/p>\n

The people who test are as human as the people who code, and all humans make mistakes. Testing is neither invincible nor a gatekeeper. Even with medical software, where lives are at stake, mistakes happen.<\/p>\n

\n

There is a powerful alternative to the orthodox, expensive, and boring methodologies that aim at the best possible quality: (\u2026) the discipline of good enough software development.<\/p>\n

\u2014 James Bach<\/a><\/p>\n<\/blockquote>\n

Testing can inform if a product has enough quality<\/em> for release, or if the user will perceive<\/em> the product as stable and useful. Otherwise, you risk never finishing your testing.<\/p>\n

\u23f3 Finite<\/h2>\n
\n

Does my (current) testing concentrate on making the product better or perfect? Be smart with your priorities: work on making the product better, not perfect.<\/p>\n

\u2014 Lina Zubyte<\/a><\/p>\n<\/blockquote>\n

Nothing can be tested completely. With an unlimited budget and an unlimited deadline (e.g. billions of years) it would be possible to check every combination of inputs that would lead to every bug of a particular software. But that’s impossible.<\/p>\n

Part of the skill of being a tester is deciding what to test. You will have to compromise and prioritise. That will be your test strategy<\/a> to achieve ~~perfect~~ good enough software. And when do you stop testing?<\/p>\n

\n

Ultimately, testing is finished<\/em> when management has enough information to enable them to make the decision whether or not to release the product.<\/p>\n

\u2014 Claire Reckless<\/a><\/p>\n<\/blockquote>\n

Sources<\/h2>\n