Study notes from Julia

Welcome back. In Part 1 you learned the map, the SDLC and the role of QA, and in Part 2 you learned the craft, how to turn a requirement into well-chosen test cases. Part 3 is the part nobody teaches you and every job assumes you already know: how to actually fit yourself into a real team. You will hear words like Scrum, Kanban, sprint, backlog, and stand-up thrown around as if everyone was born knowing them. You were not, and that is fine. By the end of this you will be able to walk onto any team, read how the work flows, and know exactly where you insert quality, whether they run two-week sprints, a continuous board, a regulated waterfall, or an AI-native pipeline that ships ten times a day. The framework on the wall changes. Your job, protecting quality wherever the work flows, does not.

Study notes from Julia

This is not a tour of Agile ceremonies you will forget by Friday. Every section answers one practical question about your Monday morning. First: how do I read the delivery system I just joined, instead of guessing? Second: how do requirements actually arrive here, and how do I make them testable before code exists? Third: how do I generate the right tests from whatever the system hands me? Fourth: how do I slot into the team’s rhythm without becoming the bottleneck at the end? Fifth: how do I become the person whose evidence the team trusts when it is time to ship? Keep asking, the whole way through, "what would I actually do with this on a real team?" That question is the difference between memorising Agile and being useful on it.

Study notes from Julia

The first mistake new testers make is treating "Agile" as one fixed thing they have to obey. It is not. Agile is a set of values, and every real team interprets them differently. One runs strict Scrum, another runs a loose Kanban board, a third calls itself Agile but ships like a waterfall. Before you can fit in, you have to read the actual system in front of you: how does an idea become a ticket, who decides it is ready, how does it reach you, and how does it get to users. Do that and you stop waiting to be told your job. You start seeing where quality is missing and step into the gap. That is what this section trains.

Study notes from Julia

When I join a new team, I do not start by memorising their ceremonies. I start by drawing the flow: where does an idea come from, who turns it into work, how is it decided to be ready, how does it reach a developer, how does it reach me, and how does it reach a user. Once I can see that line, the framework label stops mattering. Scrum just tells me the rhythm is two-week batches. Kanban tells me work flows continuously and I should watch the columns. A regulated waterfall tells me feedback comes late so I push my energy upstream. None of that is intimidating once you realise frameworks are just different answers to the same question. Read the flow, find the gaps, fill them.

Study notes from Julia

Scrum and Kanban are the two you will meet most, and they feel different to test in. Scrum batches work into fixed sprints, usually two weeks, with a planned set of meetings: planning, daily stand-up, review, and retrospective. The rhythm is predictable, which helps you plan your testing, but the danger is everything piling onto your desk in the last two days. Kanban drops the fixed batches and just flows work across a board, column by column, with limits on how much can be in progress at once. There is no sprint boundary to hide behind, so testing has to happen continuously as cards arrive. Same skills, different timing. The trick is to notice which one you are standing in and adjust when you do your heaviest work.

Study notes from Julia

Do not believe anyone who tells you Agile killed every other model. Waterfall and the V-model are alive in regulated, safety-critical work, banking core systems, medical devices, automotive, aerospace, where every requirement has to trace to a test that proves it. At the other end, newer rhythms are appearing. Basecamp’s Shape Up replaces sprints with six-week cycles and an "appetite" instead of estimates. AI-native teams lean on the agentic loop so heavily that code arrives fast and the real bottleneck moves to validating and shipping it, which is your job. You do not need to master all of these today. You need to recognise them so that when a team says "we do not really do Scrum, we run cycles," you can nod, read the new flow, and find your place in it.

Study notes from Julia

I want this one to stick, because it is the spine of the whole course. In a decade I have watched teams swing from waterfall to Scrum to Kanban to "we do our own thing now," and every few years a new methodology gets sold as the answer to everything. If you tie your identity to one framework, every change feels like a threat and you spend your energy defending a process. If you tie it to the real job, finding risk and turning it into evidence the team can act on, every framework is just a different room to do that job in. The teams change the furniture. You still know why you are there. That is what makes you employable across your whole career, not just this job.

Study notes from Julia

You can practise this without a QA job. Take any group that produces something, your current team, a side project, a community group, and draw how an idea becomes a finished thing. Who has the idea, who decides it is worth doing, who makes it, who checks it, who ships it. Then mark the weakest handoff, the point where something could quietly go wrong and nobody would notice until late. That weak handoff is exactly where a tester adds the most value. When you join a real team, this is the first thing I want you to do in your first week: not learn their tools, map their flow and find the gap. Then you have something useful to offer instead of waiting for instructions.

Study notes from Julia

Every delivery system has a moment where a fuzzy idea becomes the work the team commits to. In Scrum it is a user story with acceptance criteria. In Kanban it is a card pulled onto the board. In waterfall it is a requirements document. In Shape Up it is a shaped pitch. The wrapper changes, but the risk is identical: if the definition is vague, quality dies quietly, long before anyone writes a test. This section is about owning that moment. You will learn how requirements show up, how to make them testable, and how the team agrees on what "ready" and "done" actually mean, so that work does not reach you full of holes you have to discover the hard way.

Study notes from Julia

Do not let the format intimidate you. A user story that reads "as a Tallawah Billing customer, I want to pause my subscription, so that I am not charged while I travel" is carrying exactly the same information as a paragraph in a 40-page requirements document: who, what, and why. Agile teams write it small and refine it just before building. Structured teams write it all up front and sign it off. Either way, your reading is the same. Who is this for, what do they actually need, why does it matter, and what is missing. The skill you are building is reading any of these wrappers like a tester and spotting the gap. Once you can do that, switching between a story and a spec is just switching the page layout, not the thinking.

Study notes from Julia

Acceptance criteria are where a requirement becomes testable, and writing them is one of the highest-value things you can do early. The Given-When-Then shape keeps them honest: given some context, when the user does something, then a specific, observable thing should happen. "Given a Cedar & Calabash customer with an active plan, when they request a pause, then billing stops at the end of the current cycle and resumes automatically after 30 days." Read that and you can already see your tests: what about a customer with no active plan, what about a pause requested on the last day of the cycle, what about pausing twice. If you cannot picture how you would check a criterion, it is not finished being defined, and saying so out loud, before code exists, is real testing. This is the Part 2 craft, applied the moment work is being shaped.

Study notes from Julia

Refinement, sometimes called backlog grooming, is the meeting where the team looks at upcoming work and makes it clear enough to build. New testers sit quietly in this meeting because they think they have nothing to add until there is something to click. That is exactly backwards. This is where you add the most value, because the questions you ask here are free, and the same questions asked after release are expensive. When a story lands, ask the things nobody else asks: what happens when the payment fails halfway, what if the user is on their phone with no signal, what does "fast" mean in numbers. You are not slowing the team down. You are catching the disagreement while it is still a sentence. Walk into refinement with three questions ready and you will change how the team sees you within a sprint.

Study notes from Julia

Two simple agreements protect quality more than any tool: the Definition of Ready and the Definition of Done. Ready means a piece of work is clear enough to start, the acceptance criteria are testable, the dependencies are known, and nobody is guessing. Done means it is genuinely finished, and that includes the testing, not just "the code compiles." The reason these matter to you is that they are how you stop the oldest bad habit in software: shipping a story as done while the testing is shoved into a vague "next sprint" that never comes. When the whole team has agreed that done includes tested, you are not the nag at the end. You are holding the team to a promise it made to itself. Help write these agreements early and you will spend far less of your career fighting to be allowed to test.

Study notes from Julia

Take a deliberately vague story: "users can manage their Nyam Box subscription." That single word "manage" is hiding five features. Can they pause, cancel, upgrade, downgrade, change the card on file? Each one is a different flow with different rules. Pick just one, say cancel, and write it as Given-When-Then: given an active subscriber, when they cancel, then access continues until the paid period ends and no further charge is made. Now list three things that could go wrong: cancelling on the final day, cancelling with a payment already in flight, cancelling and immediately resubscribing. In five minutes you have turned a wish into something the team can build and you can test. Do this with a real story in your next refinement and watch how fast people start bringing you the fuzzy ones on purpose.

Study notes from Julia

Once work is defined, you have to generate tests for it, and "generate" is the right word because it is an active, continuous thing, not a one-time document. The system is constantly handing you signals: a refined story, a design mock-up, a pull request, a failing build, a spike in production errors. Each is a prompt to ask "what does this change put at risk, and what would prove it is safe?" This section is about converting those signals into the right tests at the right level, deciding what to automate and what to explore by hand, and yes, using AI honestly to draft the obvious cases fast so your judgment goes where it actually counts. Part 2 taught you how to design a case. This is about generating them in the rhythm of a live team.

Study notes from Julia

When you generate tests, the first decision is not "what do I check" but "at what level." A fast unit test, a service or API test, and a full end-to-end test through the screen all cost different amounts to write and run, and they catch different things. The instinct of a new tester is to test everything by driving the UI, because that is the part you can see. It is also the slowest and most fragile place to test. Wherever you can, push a check down to the cheapest level that still proves the risk: validate a billing rule at the API, not by clicking through five screens to reach it. The aim is not a tidy pyramid for its own sake, it is fast, honest feedback. Part 1 covered the levels; here the point is to actively choose the level every time you generate a test.

Study notes from Julia

As you generate tests, split them by job. Automated checks are for the things that must stay true on every single release: the login works, the total adds up, the order saves. You write those once and let the pipeline run them forever, so you never have to manually re-check them. Exploration is for the new, the risky, and the genuinely human, where you sit with the feature and deliberately try to break it in ways no acceptance criterion described. Beginners think the goal is to automate everything. It is not, and "100 percent automation" is a phrase I want you to distrust. Automation guards what you already understand; exploration discovers what nobody wrote down. A strong tester is generating both, all the time, and knows which job each test is doing.

Study notes from Julia

Let me be honest about AI, because the hype is loud and the truth is more useful. AI is genuinely good at the parts of test generation that are pattern-heavy: drafting cases from acceptance criteria, expanding a boundary set, combing through large amounts of data, and checking whether one service returns what another expects. Hand it the story, the real code, and the actual context, and it will give you a fast first draft. What it is still bad at is exactly the human part: seeing that a screen is visually broken or misaligned, judging whether a full user flow actually makes sense, and finding the risk nobody specified. So the division of labour is clear. AI drafts the obvious cases at speed; you bring the judgment about what matters, the eye for what looks wrong, and the call on what is safe to ship. You review, you correct, you own the result. That is leverage, not replacement.

Study notes from Julia

The best testers do not only generate tests when a story is handed to them. They treat every change in the system as a prompt. A pull request lands: what exactly changed, and what sits close enough to have broken? A production error spikes: what test, written now, would have caught this before users did, and how do we make sure it never escapes again? A design changes: what new path did that open? This is how testing keeps up with a team that ships continuously. You are not waiting for a testing phase, you are generating evidence in response to the system’s signals as they happen. When a field failure becomes a new automated test, you have closed a loop the whole team can feel. That habit, turning every surprise into a permanent check, is what separates a tester who keeps up from one who is always behind.

Study notes from Julia

Practise generating, not just designing. Picture one small change: Irie Eats now accepts a coupon code at checkout. Do not jump to clicking. First, spread the tests across levels: a unit check that the discount maths is right, an API check that an invalid or expired coupon is rejected, and one exploratory charter, "explore coupon codes combined with failed payments and re-orders." Then ask the question that catches the sneaky bugs: what sits next to this change that could break without anyone touching it, the order total, the loyalty points, the receipt email? In a few minutes you have generated a small, sharp set of tests aimed at real risk, at the right levels, from a single change. That is the daily motion of testing on a live team, and it is a muscle you can build right now with imaginary features.

Study notes from Julia

Now we get into your actual week. Working inside the flow means moving with the team’s rhythm instead of waiting at the end of it. It means reading the board, knowing what is in progress, testing as work arrives rather than letting it pile up, and understanding how the pipeline carries your tests to the build. It also means knowing two timing strategies by name, shift-left and shift-right, so you can talk about quality before code is written and after it reaches users. The single biggest trap for new testers is becoming the bottleneck: the person everything waits on right before release. This section is how you avoid that and become part of the flow instead of the dam at the end of it.

Study notes from Julia

The ceremonies sound mysterious until you see what each is really for, and then they are obvious. Planning is where the team decides how much to take on, and your job is to make sure testing effort and risk are part of that decision, not an afterthought. The daily stand-up is a quick fifteen minutes where everyone says what moved, what is stuck, and what they need; you use it to surface blockers and what you are about to test, not to give a status report nobody asked for. The review, or demo, is where the work is shown to stakeholders, and you are the voice of what is actually proven versus what just looks finished. The retrospective is where the team improves how it works, and it is the right place to raise a recurring quality problem instead of suffering it quietly. None of these are tests for you to pass. They are rooms where you keep quality visible.

Study notes from Julia

The fastest way to become unpopular and overworked is to let testing bunch up at the end. When every story lands on your desk in the last two days of the sprint, you cannot do good work and the team blames the timeline on you. The fix is to move with the flow. Pull a story the moment it is ready instead of waiting for the whole batch. Pair with the developer while they are building so problems surface in minutes, not days. Watch the "to test" column and push to keep it short, because a long one means work is rotting. And automate the boring, repeatable checks so your scarce human attention goes to the risky, interesting, human parts. This is the difference between a tester who is a bottleneck and one who is part of the current. On a Kanban board especially, your job is to keep work flowing, not to be the place it stops.

Study notes from Julia

Two phrases will follow you through this career, so learn them properly. Shift-left means moving quality work earlier, into the requirements and design conversations you saw in the last two sections, so you prevent defects instead of catching them. Shift-right means learning from production: watching real user behaviour, error rates, and performance after release, and feeding what you find back into your tests. Modern teams in 2026 do both at once, because shipping continuously means you can never test every combination before release, so you also watch carefully after it. Feature flags, gradual rollouts, and real monitoring are how teams ship safely at speed, and a tester who can read production signals is far more valuable than one who only checks a staging environment. The best defect is the one you prevented; the second best is the one you caught in production before most users hit it.

Study notes from Julia

Continuous integration, usually shortened to CI, is the pipeline that runs your automated tests automatically every time someone pushes code. It is the team’s heartbeat, and you need to understand it even if you are not the one who set it up. When the build goes red, it means something is broken right now, and on a healthy team fixing it jumps to the front of the queue, because everything built on top of a broken build is suspect. The quiet killer here is flaky tests, the ones that pass and fail at random. A green build is comforting, but a flaky suite makes it the most convincing lie in your pipeline, because people start ignoring failures, and then they ignore the real one. Treat a flaky test as an emergency to fix or quarantine, not as background noise to scroll past. A pipeline only protects you if the team still trusts it.

Study notes from Julia

You can feel how flow works with a pen and paper. Draw three columns, "to test," "testing," and "done," and drop in five imaginary stories. Now add one rule: you may only have two cards in "testing" at once. That single limit, called a work-in-progress limit, changes everything. Instead of starting all five and finishing none, you are forced to finish what you began before pulling the next card. This is the core idea behind Kanban and it is the antidote to the bottleneck problem: less work started at once means work actually flows to done instead of stalling half-finished. Try it for a real week, even on your own tasks, and you will understand why teams put limits on their boards. Finishing beats starting, every time.

Study notes from Julia

The last section is about who you become. In a weak setup, the tester is a gate at the very end, the person who says no when it is already too late. In a strong one, the tester is the quality function the whole team leans on, woven through the flow you have just learned to read. You become that person by giving the team decision-quality information at the moment it has to choose, by measuring what genuinely matters and ignoring the numbers that mislead, and by carrying your judgment into whatever the next framework or technology turns out to be. AI will keep changing the tools. The job, the human call on what is good enough to ship, stays yours. This is how you turn everything in this course into a career, not just a checklist.

Study notes from Julia

You will hear "quality is everyone’s responsibility" said like a magic spell, so let me make it concrete, because left vague it is meaningless. It does not mean you stop testing. It means you stop being the only person who thinks about quality, and you stop being the gate that blocks things at the end. You advocate instead of police: you bring evidence and options to a decision rather than a flat veto, you help developers get better at testing their own work instead of guarding the skill, and you raise risks early and loudly enough that nobody is shocked at the end. When a release genuinely should not ship, your "not yet" lands as trusted judgment because you have been visible and fair the whole way, not because you are the obstacle nobody warned them about. That reputation, fair, early, evidence-led, is what makes a tester someone teams fight to keep.

Study notes from Julia

When you become the quality function, people start asking you for numbers, so know which numbers are honest. The four DORA delivery measures are a good backbone: how often you release, how long an idea takes to reach users, how often a change causes a failure, and how fast you recover when one does. Pair those with escaped defects, the bugs that actually reached users, and you have a real picture of quality and speed together. Now the traps: the number of test cases written, the percentage of tests automated, and bug counts used as a scoreboard all feel productive and measure almost nothing useful. Worse, the moment any metric becomes a target, people game it, and you get a thousand trivial test cases and a beautiful automation percentage protecting nothing. Measure to learn where the risk is, never to rank the people. That distinction will keep you honest in every status meeting you ever sit in.

Study notes from Julia

You are entering this field at the moment AI is reshaping it, and that is an advantage if you are honest about the division of labour. Predictions that most developers will soon orchestrate AI more than they hand-write code are already half true, and it means code arrives faster than ever, which pushes more pressure onto validating and shipping it, your job. So lean into the parts AI does well: give an agent the real context and let it draft tests and data, comb through logs, check that services agree with each other, and take a first pass at the obvious cases. Then keep firmly in human hands the things it cannot do, seeing that a screen is visually broken, judging whether an entire user flow makes sense, finding the risk nobody wrote down, and making the call on what is good enough to ship. The human in the loop is not a weakness to be automated away. It is the point. Be the person who directs the tools and owns the judgment, and you will be valuable no matter how the tools change.

Study notes from Julia

If you forget everything else, keep these three moves. Read the system: whatever team you join, map how work flows from idea to release before you worry about their tools. Find the gap: spot the handoff where quality is most likely to slip, the vague requirement, the missing test, the rushed release. Become the quality: step into that gap with questions, evidence, and judgment the team can trust. Those three moves work in Scrum, in Kanban, in a regulated waterfall, in Shape Up, and in whatever the industry invents next, because they are about people and risk, not about a methodology. You now have the map from Part 1, the craft from Part 2, and the way to fit into any team from Part 3. The rest is reps. Go get them.

Study notes from Julia

Here is where to put your energy next. Revisit Part 1 if any of the SDLC or role-of-QA language felt shaky, and Part 2 to sharpen the test-design craft you applied throughout this part. The QA Career Roadmap maps the whole journey ahead, stage by stage. If you want the formal grounding, the ISTQB Foundation syllabus now folds agile testing into the core certification, so that is the one to study rather than the standalone agile module, which is being retired in 2027. And if you are curious about life beyond Scrum, read Shape Up and skim the DORA guides so the next methodology shift feels like a new room, not a new planet. You are ready for a real team. Go find the gap and fill it.

Study notes from Julia

That is Part 3, and it is the part that turns knowledge into a career. You came in maybe a little intimidated by all the Agile words, and you should now be able to walk onto any team, read how they work, and know exactly where you belong in it. Keep practising the small drills: map a flow, make a story testable, generate tests from a change, run a board with a limit. They are tiny, and they compound. Most of all, hold on to the through-line: frameworks come and go, but a tester who can read any system, find the gap, and become the quality the team trusts will always have a place. I am proud of you for getting this far. Now go do the reps on something real.