Week 5 - Agile

What is Scrum? and its 3 pillars?

A lightweight framework for developing complex products through empirical process control, which means you learn by doing instead of theorizing. All scrum teams are agile, but not all agile teams are Scrum.

• Transparency: Everyone can see the state of work, the backlog, and impediments.

• Inspection: The team regularly examines progress, the product, and the process.

• Adaptation: Based on inspection, the team changes what needs to change.

What are the three Scrum accountabilities?

• Product Owner: Maximizing the value of the product resulting from the Scrum Team’s work.

• Scrum Master: The Scrum Team’s effectiveness - helping the team and organization use Scrum well.

• Developers: Creating a plan for the Sprint, adhering to the Definition of Done, etc.

Name the 3 scrum artifacts:

• Product Backlog: Ordered list of everything needed for the product

• Spring Backlog: Plan for the current Sprint: selected items + how to deliver them. (Owned by the developers)

• Increment: The sum of all “Done” work - usable, valuable output of the Sprint

Define the Definition of Done.

It’s a quality contract for the increment. If any item doesn’t meet the requirements, then it stays in the backlog. Testers help define and enforce this.

What does Iterative vs Incremental mean in Agile?

• Iterative: Repeat and refine. Each cycle revisits the same area of the product and improves it based on the feedback.

• Incremental: Add new usable pieces

What is Agile Test Philosophy? What are its 3 pillars?

A set of principles and practices that align quality activities with Agile’s core values. It’s a mindset that shapes how testing is planned, executed, and communicated.

• Shift-left testing: Move testing activities earlier in the process, like where requirements and code are formed.

• Whole-team quality: The entire team is accountable for quality, not just testers

• Continuous testing: Automated and exploratory feedback flows throughout the pipeline

Give an example of Agile vs Waterfall:

Waterfall feedback is like submitting an exam and waiting 6 months for your results, while Agile feedback is like a teacher reviewing your draft every 2 weeks before final submission. So Waterfall is the type A friend, while Agile is a type B friend.

When would we use Agile? When would we use Waterfall?

Use Agile when there is high uncertainty, fast feedback loops, and frequent releases expected. Use Waterfall when requirements are stable, heavy documentation is required, and the scope is fixed.

What’s your favorite approach?

Maybe Regulated Agile, where we do Agile sprints but produce phase-equivalent documentation at release milestones, because I enjoy documenting as we go.

What is the SDLC?

It’s a set of phases, activities, and outputs used to conceive, design, build, test, deploy, maintain, and eventually retire a software system. It is not one single fixed method — it is a lens for organizing work.

What are the phases of the SDLC?

1. Planning and Requirements: Scope, feasibility, budget, “Why are we building this? What is done?”

2. Analysis and Design: “What will the system do? How will it be structured?

3. Implementation: Coding, unit testing by developers, integration of components

4. Verification and Validation: “Does it work as specified and does it serve users?” System testing, integration testing, UAT, reviews

5. Deployment / Release: Ship it. Promotion through environments, rollout strategies, rollback plans, and release notes

6. Operations and Maintenance: Maintain it. Monitoring support, patching, feature enhancements, and eventually planned retirement.

The lifecycle model determines when or how often you do these activites

What is velocity and why should it not be used as a pressure metric?

Velocity is the total story points a team actually completes in a sprint, measured historically over 3-5 sprints to forecast future capacity. It should not be used as a pressure metric because it's a forecasting tool — not a measure of productivity. Pushing a team to increase velocity leads to overcommitment, which is one of the most common causes of testing being squeezed at the end of a sprint.

What is a Sprint Burndown chart?

A chart that tracks remaining work over the course of the Sprint.

What does a flat line on a burndown chart mean, and what does the "cliff pattern" indicate from a QA perspective?

A flat line means work isn't completing — usually caused by a blocked story, an environment issue, or a story that was larger than estimated. The cliff pattern (where most points drop in the last 1-2 days of the sprint) is a quality risk — it means testing was compressed into the final days, the Definition of Done was likely rushed, and half the sprint's work was verified under time pressure.

What is the standard format for writing a user story and what do the three parts mean?

"As a [type of user], I want [to do something], so that [I achieve some benefit]." The role defines who the story is for, the goal defines what they need, and the "so that" defines why — which is the most important and most frequently omitted part. Without the "so that" you don't know what the feature is actually trying to achieve, which limits your ability to test beyond the happy path.

What is the Given/When/Then format and what should acceptance criteria cover?

Given/When/Then (also called Gherkin) is the standard format for writing acceptance criteria. Given sets the precondition, When describes the action, and Then describes the expected outcome. Well-written acceptance criteria should cover the happy path (normal successful scenario), boundary and edge cases, and error states — not just the obvious scenario.

What is the INVEST criteria and which letters matter most to a QA engineer?

INVEST stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable — a checklist for whether a story is sprint-ready. For a QA engineer the most important letters are V (does the "so that" deliver real value?), S (is it small enough to fully test within one sprint?), and T (are there clear unambiguous acceptance criteria, or will testers be guessing what done looks like?).

What is the difference between an Epic, a User Story, and a Task?

An Epic is a large business capability too big for one sprint — it gets decomposed into User Stories. A User Story is a feature told from the user's perspective that fits within a single sprint. A Task is the technical work created by developers during sprint planning to explain how they'll deliver a story. Only Stories live on the Product Backlog — Tasks are created inside a story during planning.

What are the phases of the Waterfall model in order?

Requirements → Design → Implementation → Testing → Deployment & Maintenance. Each phase largely completes before the next begins — you don't go back up once you move forward.

What is the biggest weakness of Waterfall from a QA perspective?

Testing happens at the end, after requirements, design, and implementation are all complete. Any problems found — wrong requirements, bad design decisions, integration failures — were introduced months earlier and are now expensive to fix. When earlier phases run over schedule, the testing window gets compressed first, meaning testers are pressured to sign off on software they haven't fully validated.

What are the four values of the Agile Manifesto?

Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change by following a plan. Importantly, the right side still has value — Agile just prioritizes the left side more.

What are the five Scrum events and what is the purpose of each?

The Sprint itself (the container for all other events, fixed-length up to one month). Sprint Planning (team selects backlog items and creates the Sprint Backlog and Sprint Goal). Daily Scrum (15-minute daily sync for developers to inspect progress toward the Sprint Goal and adapt the plan). Sprint Review (team demonstrates the Increment to stakeholders and collects feedback). Sprint Retrospective (team reflects on their process and identifies improvements for the next Sprint).

What is the difference between verification and validation? 

Verification asks “are we building the product right?” - it checks whether the software conforms to its specification (acceptance criteria, API contracts, design docs). Validation asks “are we building the right product?” - it checks whether the software actually serves real user and business needs in the real world. You can verify perfectly and still fail validation if the specification didn’t capture what users actually needed.

Give an example of a feature that passes verification but fails validation.

A mobile login screen that passes all acceptance criteria (valid credentials authentication, invalid credentials show an error message) but fails UAT because field workers wearing gloves can’t accurately tap the small password field, and the error message appears below the fold on small phones, so users never see it. The spec was satisfied - but the real-world user need was not.

What is the pesticide paradox and what should a QA engineer do about it?

Running the same tests repeatedly means they eventually stop finding new defects — the software becomes immune. Fix it by evolving your test suite regularly: add new scenarios as features are built, add a regression test whenever a defect is found, and run exploratory tests on recently changed areas. Example: a 200-test regression suite catches nothing for 6 sprints, then a customer finds a bug in the new multi-currency module that nobody had tested.

What should a professional test report include beyond just pass/fail counts?

Scope tested, what was found (severity-classified defects), what was NOT tested and why, residual risk, and a clear go/no-go recommendation with rationale. Example: instead of "40 passed, 2 failed — release recommended," you'd state which features and environments were tested, describe the two open defects with severity, call out that load testing wasn't done yet, and give the PO a documented risk acceptance decision.

What are the four traits of the tester's mindset?

• Critical thinking: Questioning assumptions and evaluating evidence

• Curiosity: Exploring beyond the happy path

• Constructive Skepticism: Verifying claims rather than accepting them

• Attention to detail: Recording exactly what happened, not approximately