Strengthen your functional testing with technical tools that uncover hidden issues and speed up debugging

Eighteen months, 19 modules, and 59 amazing contributors later, the MoT Software Testing Essentials Certification is complete! Looking back, my favourite part has been seeing so many community m...

During filming for Module 18 of the MoT Software Testing Essentials Certificate, Marie Cruz put a demo e-commerce site through its paces with a k6 Studio load test and managed to reveal a hidden we...

Analogies: You bought a balcony ticket, but the stairs to the backstage were just… open. No one stopped you. No one checked. You walked in, sat at the controls, and nobody noticed. Or...You bought a regular ticket. But no one’s watching, so you just walk past the velvet rope into VIP, then backstage, then the cash counter. No one stops you. No one even asks, “Hey, should you be here?” What’s happening: It’s not about who you are, it’s about what you’re allowed to do. Broken access control means those checks are either missing, misconfigured, or just trusting too much. Test Like This: Change IDs in URLs. Hit admin routes with a normal account. Submit actions you shouldn’t have access to. If the system doesn’t push back, that’s your red flag. Simple rule: Getting in is one thing (authentication). But being let loose to do anything once you’re in? That’s the real problem.

Analogy: You bought a fancy smart lock… and left the default password as admin123. It’s like building a bank vault and taping the key to the front door. What’s happening: This is when your app or system is set up in an insecure way — usually by accident. Default settings, unnecessary services, verbose error messages—config is messy, and attackers love that. It’s not a flaw in the app; it’s a flaw in how the app was set up. Test Like This: Check for open ports, directory listings, or debug messages. Pro tip: Now every application uses frameworks. Go to the default sensitive pages of that framework. Most developers miss that.

Analogy: It’s like asking a guest to write their name on a building entry form, and they write, “Also give me the keys to your house,” and your building's security guard just… does it.What’s happening: You trusted user input to become part of a command or query without double-checking what they wrote. They didn’t just fill the form—they rewired the backend through it.Test Like This: Inputs aren’t harmless. Test it using inputs from the link below.It's my swiss knife for giving an input box a "green" flag.

Analogy: Imagine a bouncer who checks your ID once and then lets you come and go forever, even if you hand that ID to your drunk friend.What’s happening: Tokens don’t expire, passwords are weak, and sessions stay open. It’s like giving out permanent backstage passes to anyone who tries hard enough.Test Like This: Steal your own cookies. Reuse a password reset link. Log in on one tab, change the password on another, and see if the first still works. And then log out in the third tab.It blows off most of the time.

Analogy: You write down your ATM PIN on a sticky note… and paste it on the machine. Then tell yourself, “It’s fine, it’s in small font.”What’s happening: Sensitive info—passwords, credit cards, tokens—are getting exposed in logs, error messages, or raw API responses. Often by accident. Always dangerous.Test Like This: Dig into API payloads, browser dev tools, or error pages. I had once found very sensitive data using Inspect Element because a developer had hardcoded some checks.

A testing persona is a fictional character that represents a typical user group of your product. They are built, where possible, using real data about your users’ demographics, behaviour, goals, and pain points. Think of them as a quick way to step into your users’ shoes when testing. For example:  Non-tech-savvy users: They want simple, intuitive interactions.  Experienced users: They expect advanced functionality and shortcuts.  Users with disabilities: They may need accessibility features like screen readers or keyboard navigation.  Testing with these personas helps you cover a wider range of potential user experiences. Why use testing personas? Testing personas help you go beyond just checking if features work. They let you see things from the user’s point of view. They make it easier to understand what real users, especially those with disabilities, might struggle with. This helps testers make sure everyone can use the software and have a similar experience. By bringing these user stories into testing, you can focus on what matters for each user group.  Focus on User Behavior, Not Just Features: Personas push you to look beyond just testing if a feature works. Instead, you’re testing if it works for the user. Different users have different needs and expectations, and personas help you account for that.  Optimise for Business Value: Testing personas ensure that you’re not just testing in isolation but also aligning your testing efforts with the business goals of the product. If a feature doesn’t provide value to the persona, it likely won’t provide value to the business.  Improved User Experience: Testing with diverse personas helps testers have empathy for different users and contributes to creating a product that’s easier for everyone to use.  Enhanced Reputation: A product that meets various user needs can build trust and loyalty among users. This also keeps a product reliable enough for its team to focus on innovation.  Less Frustration: Addressing different user challenges helps in reducing confusion and frustration during use. This can help in building the best possible experiences.  Higher ROI: By meeting user needs, a team moves ahead in innovation. Hence, your work can increase sales and profits. 

Start testing before any code exists by using the RRM to uncover risks, clarify ambiguity, and prevent costly rework.

Bugs come in many forms and have many names. Defects, errors, failures, faults, issues, exceptions, glitches, inconsistencies, or system failures, but most teams simply call them ‘bugs’ for simplicity. While testers play a critical role in identifying bugs, their resolution requires collaboration with different roles including developers, product managers, and stakeholders.