An Individual Contributor (IC) is a role where your impact mainly comes from doing the work yourself, not from managing other people. A simple way to think about it:An IC is like a senior person on the team who still builds things. They may review work, help others, or influence decisions, but they are not responsible for running the team.In Quality Engineering, an IC might: Test or investigate issues Improve tooling or checks Review work and point out risks They create impact mostly through their own work and judgment, not through people management.

Impact statements describe the outcome of your work rather than the task you performed. Instead of listing what you did, they show what changed because you did it. They make your contribution clear, measurable, and easy for others to understand.Example: Task: Created API test suite Impact statement: Improved release confidence by reducing post-deployment API failures

The STAR model is a simple structure for explaining real experiences. It helps you tell a clear, focused story by breaking it into four parts:  Situation – The context or problem you were facing Task – What you were responsible for Action – What you actually did  Result – What changed because of it  Example:  Situation: A regression cycle kept slipping because no one trusted the test results.  Task: Improve the reliability of the suite.  Action: Identified the top flaky tests, stabilised them, and moved the suite into CI.  Result: The team cut regression time by half and stopped rechecking everything manually.

A command-line search tool that finds patterns in text — short for Global Regular Expression Print. In simple terms: it hunts through files and tells you where the thing you’re looking for is hiding.

A debugging technique where you explain your code (and your confusion) out loud — often to an object, like a rubber duck. The magic: saying the problem forces your brain to slow down and reprocess the logic, and half the time you’ll spot the issue before the duck even blinks. How it works:  Pick your “listener” — a duck, a plant, a coffee mug, or a colleague who can tolerate monologues. I have a lot of friends on my table to listen to me, my fav - sleeping Pikachu.  Walk through your code line by line, explaining what it’s supposed to do.  Wait for the moment you realize what it’s actually doing.  Why it works: Turning thought into speech forces clarity. You can’t gloss over details when you have to articulate them — even to plastic.

A distributed version control system that helps you track changes, collaborate without overwriting each other’s work, and recover from “oops” moments and make them "aha" moments. Think of it as a timeline of every decision your codebase has ever made - the good, the bad, and the experimental.Common commands:  git clone <repo-url> – Makes a local copy of a remote repository. Basically, downloads the project (and all its history) onto your machine.  git status – Tells you what’s changed since your last commit. Great for confirming if you’re in control or if chaos has already begun.  git add . – Stages all modified files for commit. You’re telling Git, “These changes matter — track them.”  git commit -m "message" – Saves a snapshot of your changes. The message is your future debugging diary — write something meaningful.  git push – Sends your commits to a remote repository (like GitHub). The part where you finally share your brilliance — or your broken code.  git pull – Fetches and merges the latest changes from the remote. Always do this before pushing, unless you enjoy merge conflicts.  git log – Shows commit history. Great for tracing when that one bug was born.  What's the git command that you learnt the hard way?

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.