A testing technique in which a tester or developer spends an extended period using the software from the perspective of a specific user role, completing realistic tasks and observing how the system behaves under real-world conditions. The approach surfaces issues that scripted tests tend to miss, particularly around usability, unexpected user behaviour, and the gap between how a system was intended to work and how it is actually used. It is especially valuable for understanding complex permission and role-based systems, and for exposing friction that only becomes visible when someone is navigating the software as a genuine user rather than as a tester looking for defects.

An issue reported by a customer to the support team that requires involvement from the engineering team. This may be because the issue is a defect or require deeper diagnosis & analysis by engineers (developers or tester) to understand the behaviour that the customer is experiencing and advise them on steps to resolve their problem. Companies often have policies or Service Level Agreements (SLAs) that define how quickly engineering teams must respond to and resolve escalations from customers.

Behaviour Driven Development is an agile approach to delivering software with the goal of the developers, testers and product owners or business analysts collaborate to have a shared understanding of intended behaviour through examples. These examples can then be formulated into test scenarios and automated to provide evidence that the desired behaviours are implemented and working successfully. These automated test scenarios are typically written in a human readable format known as Gherkin. The three phases of BDD are Discovery, Formulation and Automation. Note that tests written in Gherkin are not inherently BDD test cases as this requires completion the Discovery and Formulation phases.

Specification by Example is an agile approach to delivering software where the requirements are defined as executable specifications. Teams identify the scope of the work and illustrate the intended behaviour through examples. The key examples are refined into executable specifications which are then turned into automated tests. These test can then act as living documentation for the software. In order to provide human readable tests for the living documentation, tests may be written in Gherkin based frameworks or other frameworks such as Concordion or FitNesse. The methodology has significant overlap with BDD and ATDD.

An attacker who uses an exploit to perform a malicious action and make an attack.

A tool, code, or method used to take advantage of a vulnerability.

A mistake is made within code or the environment, creating a vulnerability.

Authorization is having permission to perform actions or see the data I want.

Authentication is "Proving that I am who I say I am"

IDOR is when you can access or modify data just by tweaking the URL or API request, and the system doesn’t check whether you should be allowed to. Let’s say you’re logged in as a test user, and you spot a URL that end in : orders/view/123That number at the end might be your order ID. But what happens if you change it to: orders/view/124 ...and suddenly you're viewing someone else’s order? Maybe you can even delete or modify it. That’s an IDOR, a lack of proper access control. It’s not just websites either. You can try the same thing in APIs using tools like Postman. Change the ID in the request and see if you can grab or update someone else’s data. If you can, it means there’s no access check, and that’s a critical security flaw.

Cross-site scripting, also known as XSS, is one of the most prevalent issues you get in web applications. It’s an issue we all need to be very wary of, as it's fairly easily discovered by attackers, but it’s also quite easy to test for. It’s a type of vulnerability that doesn’t go after the website itself, but instead goes after the user of the application. It works by injecting JavaScript into an input, and that script then runs for whoever is using the page. When testing, one common technique is to try and make an alert box pop; just a teeny tiny bit of JavaScript, usually something like <script>alert(1)</script>. If you can get that to run, that means your script has executed, and you've found a cross-site scripting issue. That might seem harmless, but it shows the door is open. A more skilled attacker could go on to do much worse things, like stealing cookies, hijacking sessions, redirecting users to fake websites, or stealing passwords. So even just getting the alert to show is a big red flag. Types of Cross-Site Scripting: Reflected XSS: If you can get the attack into a URL and send it to someone, like over Slack or social media, and it runs when they open it, that’s a reflected attack.  Persistent XSS: If the script gets saved to the database and runs for anyone who visits the page, that’s a persistent attack. And that’s a really bad one, a critical issue that needs fixing immediately. Top tips for testers getting started: Start simple by trying to make an alert box pop up; it’s a safe and easy way to show that JavaScript can run. Try placing your JavaScript test input in different places, like form fields or in the URLs. Try saving your test input and check if it runs when other users load the page. If it does, the application might have a persistent XSS vulnerability. Test reflected XSS by copying the full URL and sharing it with a friend (make sure they know you’re testing). If you want to explore further, try using JavaScript to redirect the user or show a fake login screen, this helps you understand how serious the impact can be.