Week 5 AGILE SKINNY

0.0(0)
Studied by 0 people
call kaiCall Kai
Locked
learnLearn
examPractice Test
spaced repetitionSpaced Repetition
heart puzzleMatch
flashcardsFlashcards
GameKnowt Play
Card Sorting

1/99

flashcard set

Earn XP

Description and Tags

Refined version

Last updated 1:13 AM on 7/16/26
Name
Mastery
Learn
Test
Matching
Spaced
Call with Kai
Chat

No analytics yet

Send a link to your students to track their progress

100 Terms

1
New cards
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 over following a plan. The right side still has value — Agile just prioritizes the left side more.
2
New cards
What does "Individuals and interactions over processes and tools" mean in practice?
People solving problems together matters more than following a rigid process or relying on tooling. A 10-minute conversation beats a 3-day ticketing cycle.
3
New cards
What does "Responding to change over following a plan" mean in practice?
When new information arrives — user feedback, market shift, a better solution — Agile teams adapt the plan. Waterfall treats change as a failure; Agile treats it as expected.
4
New cards

What are the 3 pillars of Scrum?

  • Transparency (everyone can see the state of work and impediments),

  • Inspection (the team regularly examines progress and process),

  • Adaptation (based on inspection, the team changes what needs to change).

5
New cards

What are the 3 Scrum roles?

  • Product Owner (maximizes product value, owns the backlog),

  • Scrum Master (improves team effectiveness, helps the team use Scrum well),

  • Developers (create the Sprint plan, adhere to the Definition of Done).

6
New cards

What are the 3 Scrum artifacts?

  • Product Backlog (ordered list of everything needed for the product),

  • Sprint Backlog (the plan for the current Sprint — owned by developers),

  • Increment (the sum of all Done work — usable, valuable output of the Sprint).

7
New cards

What are the 5 Scrum events?

  • The Sprint (container for all other events) —> 1-4 weeks

  • Sprint Planning (select items and create the Sprint Goal) is done once at the start of each sprint → Up to 8 hours for a 4-week sprint

  • Daily Scrum (15-min daily sync to inspect progress),

  • Sprint Review (demonstrate the Increment to stakeholders) done once at the end of each sprint → Up to 4 hours

  • Sprint Retrospective (reflect on process and identify improvements) is done once at the end of each sprint. → Up to 3 hours

8
New cards
What is verification?
"Are we building the product right?" — checks whether the software conforms to its specification. Example: all acceptance criteria for the login feature pass.
9
New cards
What is validation?
"Are we building the right product?" — checks whether the software actually serves real user needs. Example: UAT reveals field workers can't tap the login button while wearing gloves, even though all AC passed.
10
New cards
Can you verify perfectly and still fail validation?
Yes. If the specification didn't capture what users actually needed, passing all tests means nothing to the user. Example: the login screen passes all AC but the error message appears below the fold on small phones — users never see it.
11
New cards
What is Quality Assurance (QA)?
Process-focused and preventive — it improves how the team works to stop defects from being introduced. Example: a Three Amigos session that catches a missing edge case before development starts.
12
New cards
What is Quality Control (QC)?
Product-focused and detective — it inspects what was built to find existing defects. Example: running a regression suite that catches a broken feature.
13
New cards
What is the key difference between QA and QC?
QA prevents defects by improving the process. QC detects defects by inspecting the product. You need both — QC without QA means finding the same types of defects sprint after sprint.
14
New cards
What is positive testing?
Verifies the system works correctly with valid inputs and authorized users. Example: valid email and password authenticate and redirect to the dashboard.
15
New cards
What is negative testing?
Verifies the system handles invalid inputs and error conditions gracefully. Example: wrong password shows "Invalid email or password" and no session is created.
16
New cards
What is edge case testing?
Verifies behavior at boundaries and unusual combinations. Example: a password containing only spaces, an email at maximum 254-character length, or simultaneous login from two devices.
17
New cards
Why are negative tests not optional?
Error handling behavior is a specified requirement, not an extra. Production failures are dominated by the error path, not the happy path. A positive-only test suite leaves the entire error-handling and security layer unverified.
18
New cards
What is severity in a defect?
The technical impact on the system — assessed by the tester. Example: a NULL input crashes the admin server = Critical severity.
19
New cards

What is priority in a defect?

The business urgency of the fix — driven by the Product Owner. It’s release-blocking, so for example: The checkout button does nothing when clicked — nobody can complete a purchase. This is high priority.

20
New cards
Give an example of high severity but low priority.
A NULL input crashes the internal admin server (Critical severity) but only staff can trigger it and it's not release-blocking (P3 priority).
21
New cards
Give an example of low severity but high priority.
A broken company logo on the login page (Low severity — nothing is technically broken) but the CEO is demoing live tomorrow (P1 priority — must be fixed tonight).
22
New cards
What is an error in the defect chain?
A human mistake — the root cause. Example: a developer misreads the spec and codes tax-exclusive when it should be tax-inclusive.
23
New cards
What is a defect in the defect chain?
A flaw embedded in the artifact as a result of the error. Example: the wrong calculation logic is now in the code.
24
New cards
What is a failure in the defect chain?
The observable deviation a tester or user sees. Example: checkout total shows $110 instead of $100 when a specific product is in the cart.
25
New cards
What is the defect chain in order?
Error → Defect → Failure. There can be a long latent period between a defect being embedded and a failure being observed — a defect can exist for months before it's triggered.
26
New cards
What is two-value BVA?
Select the boundary value and the adjacent value just outside the valid partition. Example: for valid range [1,10], test 0, 1, 10, 11.
27
New cards
What is three-value BVA?
Select below, at, and above each boundary. Example: for [1,10], test 0, 1, 2 at the lower bound and 9, 10, 11 at the upper bound.
28
New cards
When should you use two-value vs three-value BVA?
Two-value when time is constrained. Three-value for high-risk inputs, financial calculations, and regulated functions — it confirms both the boundary and its neighbors behave correctly.
29
New cards
Why does BVA find more defects than middle-ground values?
Boundaries are where off-by-one errors and inclusive/exclusive mistakes hide. Testing quantity = 5 never detects whether the developer wrote >= 1 or > 1 at the lower bound. Testing 0 and 1 does.
30
New cards
What is an equivalence class?
A set of input values the system is expected to process identically. Example: all ages under 18 are rejected the same way — testing 5 gives the same result as testing 10 or 17.
31
New cards
Why does testing one representative per equivalence class provide sufficient coverage?
If the system truly treats all values in a class identically, any one value reveals the same behavior as all of them. Testing 5, 10, and 17 for the "too young" class is redundant.
32
New cards
Why does each distinct type of invalid input form a separate equivalence class?
Because different violations produce different error messages or behavior. A password that's too short, too long, missing uppercase, and non-string are all invalid but each produces a different error — each needs its own test.
33
New cards
What is the test automation pyramid?
Many unit tests at the bottom (fast, stable, cheap), some API/service tests in the middle, few E2E UI tests at the top.
34
New cards
Why does the pyramid recommend few E2E tests?
E2E tests are slow (minutes each), expensive to maintain, brittle when UI changes, and hard to debug. The inverse — many E2E tests, few unit tests — is the "ice cream cone" anti-pattern: slow pipelines, brittle suites, low developer trust.
35
New cards
What is the "ice cream cone" anti-pattern?
The inverse of the pyramid — many slow E2E tests and few or no unit tests. Produces slow CI pipelines, brittle suites that break on every UI change, and developers who don't trust the test results.
36
New cards

What does PDCA stand for and how does it map to an Agile sprint?

Plan, Do, Check, Act.

  • Plan = Sprint Planning and Refinement.

  • Do = sprint execution.

  • Check = Sprint Review and daily standups.

  • Act = Retrospective.

37
New cards
Why is running PDCA every sprint more powerful than annually?
The cycle runs every two weeks instead of every 6–12 months, making quality management continuously adaptive. Problems are identified and fixed before they compound across many sprints.
38
New cards

What happens in the Act phase of PDCA?

The team uses retrospective findings to update processes, adjust practices, or change the Definition of Done — turning learning into concrete improvements for the next sprint.

39
New cards

What does the I in INVEST stand for in Agile/Scrum?

Independent — the story can be developed and delivered without waiting for another unfinished story.
40
New cards
What does the N in INVEST stand for?
Negotiable — the story is not a fixed contract, it's an invitation to a conversation about the best solution.
41
New cards
What does the V in INVEST stand for?
Valuable — the story delivers something useful to the end user or business. Ask: does the "so that" actually make sense?
42
New cards
What does the E in INVEST stand for?
Estimable — the team has enough understanding to size the story. If they can't estimate it, it needs more clarification.
43
New cards
What does the S in INVEST stand for?
Small — the story fits within a single sprint. If it doesn't, split it.
44
New cards
What does the T in INVEST stand for?
Testable — clear, unambiguous acceptance criteria exist. If testers would be guessing what "done" looks like, the story isn't ready.
45
New cards
Which INVEST letters matter most to a QA engineer and why?
V (does the "so that" deliver real value?), S (small enough to fully test within one sprint?), and T (are there clear AC, or will testers be guessing?).
46
New cards
What does "Given" mean in Given/When/Then?
The precondition — the system state that must exist before the action. Example: "Given I am logged in as a registered user."
47
New cards
What does "When" mean in Given/When/Then?
The action being performed. Example: "When I submit the login form with valid credentials."
48
New cards
What does "Then" mean in Given/When/Then?
The expected observable outcome. Example: "Then I am redirected to /dashboard and the nav bar shows my name."
49
New cards
What should well-written acceptance criteria cover?
The happy path (normal success), boundary and edge cases, and error states — not just the obvious scenario.
50
New cards
Why is Given/When/Then useful for testers specifically?
It makes AC directly testable — the Given becomes the precondition, the When becomes the test step, and the Then becomes the expected result. There's no ambiguity about what "done" looks like.
51
New cards
What is statement coverage?
Measures what percentage of executable lines were executed during a test run. 100% does NOT mean bug-free — wrong logic can still execute all lines.
52
New cards
What is branch coverage?
Requires every decision (if/else, while, switch) to evaluate both True and False at least once. Stronger than statement coverage.
53
New cards

Why is branch coverage stronger than statement coverage?

Statement coverage can hit 100% while never testing the False branch of an if statement. Example: if is_member: fee *= 0.5 hits 100% statement coverage with only is_member=True — the no-discount path is never tested. Branch coverage requires the False path too.

54
New cards
What does 100% statement coverage actually guarantee?
Only that every line was executed at least once. It says nothing about whether the logic is correct or the assertions verify the right behavior.
55
New cards
What is exploratory testing?
Simultaneous learning, test design, and execution — guided by a charter, bounded by a time box, documented in session notes, and followed by a debrief.
56
New cards
What is ad hoc testing?
Unstructured testing with no plan, no notes, no time limit, and no follow-up. It can't be audited or reproduced.
57
New cards
What is the key difference between exploratory testing and ad hoc testing?
Discipline. Exploratory testing is structured investigation guided by a mission. Ad hoc testing is random clicking. Both are unscripted, but only exploratory testing is auditable and repeatable.
58
New cards
When should you choose exploratory testing over scripted regression?
When learning is high — new features, unclear risks, complex workflows, or after automation finds nothing new (pesticide paradox). Keep scripted regression for stable critical paths that need repeatable signals.
59
New cards

What are the five components of a SBTM exploratory session?

  • Charter (the mission — what are we investigating and why),

  • Time box (60-90 minutes),

  • Oracles (heuristics for judging whether behavior is correct),

  • Notes (audit trail — coverage map, bugs, follow-up ideas), Debrief (share findings with the team).

60
New cards

What is Testing Principle 1? (What does passing tests mean?)

Testing shows the presence of defects, not their absence. Passing tests don't prove bug-free software — they prove no defects were found in those specific scenarios.

61
New cards

What is Testing Principle 2?(why cant we test everything?)

Exhaustive testing is impossible. Use equivalence partitioning, BVA, and risk-based prioritization to test the highest-value combinations.

62
New cards

What is Testing Principle 3? (Early testing)

Early testing saves time and money. A defect caught in refinement costs a 5-minute conversation. The same defect in UAT costs 2 days of fix and retest.

63
New cards

What is Testing Principle 5?(Why should you evolve your testing?)

The pesticide paradox — running the same tests repeatedly eventually stops finding new defects. Evolve your test suite by adding new scenarios when features are built and running exploratory sessions on changed areas.

64
New cards

What is Testing Principle 6?(Is there a single universal strategy?)

Testing is context dependent. The right approach, depth, tooling, and formality depend on the product type, risk profile, industry, and team. There is no single universal strategy.

65
New cards

What is Testing Principle 7?(verification vs validation)

Absence-of-errors fallacy — finding and fixing all defects doesn't mean the product is useful. A system can be verified (zero defects against spec) and still fail validation (doesn't serve user needs).

66
New cards
What are the typical states in a defect lifecycle?
New/Open → Assigned/In Progress → Fixed/Ready for Retest → Retesting → Closed. If the retest fails: Reopened → back to Assigned.
67
New cards
What does "New/Open" mean in the defect lifecycle?
The defect has been discovered and logged, and is awaiting triage — severity, priority, and assignee haven't been set yet.
68
New cards
What does "Assigned/In Progress" mean in the defect lifecycle?
A developer owns the investigation and fix.
69
New cards
What does "Fixed/Ready for Retest" mean in the defect lifecycle?
The developer has deployed a fix to the test environment. The tester hasn't verified it yet.
70
New cards
What does "Reopened" mean in the defect lifecycle?
The fix didn't work or introduced a regression. The defect goes back through the Assigned → Fixed → Retest cycle.
71
New cards
What does "Closed" mean in the defect lifecycle?
The fix is confirmed working — or the risk was formally accepted and documented. Always set a resolution code: Fixed, Won't Fix, Duplicate, Cannot Reproduce, or Deferred.
72
New cards
What is the difference between "Won't Fix" and "Deferred" as resolution codes?
Won't Fix means the team has decided this defect will never be fixed — the business accepted the risk. Deferred means it's a valid defect but the fix is postponed to a future release.
73
New cards
What does "Cannot Reproduce" mean as a resolution?
The defect couldn't be confirmed — no one can reproduce it with the steps provided. Verify the environment, build version, and test data before closing. Reopen if evidence arrives later.
74
New cards

What is the difference between TDD (Test Driven Development) and BDD (Behavior Driven Development)?

TDD means writing a failing test first, then writing code to make it pass, then refactoring. BDD extends TDD by writing tests in plain language (Given/When/Then) that describe behavior from the user's perspective — that both developers and non-technical stakeholders can read (collaboration focused).

75
New cards
What does TDD stand for and what is the process?
Test-Driven Development. Write a failing test → write the minimum code to pass it → refactor. The test defines the expected behavior before any implementation exists.
76
New cards

What is a Test Plan, and what should it include?

Scope (what's in/out), testing approach (functional, exploratory, automated), environments and test data, entry and exit criteria, risks and mitigations, and a defect management process. In Agile, it's lightweight — a page per sprint. In regulated contexts, it's a formal versioned document with sign-off.

77
New cards
What are test scripts?
Step-by-step instructions that tell a tester exactly what to do and what to expect. They can be manual (written steps a human follows) or automated (code that executes the steps programmatically).
78
New cards
What is the difference between a manual test script and an automated test script?
A manual script is a written list of steps a human executes. An automated script is code (e.g. Python + Selenium) that executes those same steps programmatically — faster, repeatable, no human fatigue.
79
New cards
What is the difference between system testing and integration testing?
Integration testing verifies that two or more components work correctly together — it tests the interfaces between them. System testing verifies the complete, fully integrated application against its requirements end-to-end.
80
New cards
What does integration testing focus on?
The interfaces and data flow between components. Example: testing that the payment service correctly receives an order from the cart service and returns a confirmation.
81
New cards
What does system testing focus on?
The complete, integrated system against its functional and non-functional requirements. Example: testing the full checkout flow from login through payment confirmation on staging.
82
New cards
What is the Software Development Lifecycle (SDLC)?
A set of phases used to conceive, design, build, test, deploy, maintain, and retire a software system. It's a lens for organizing work, not a single fixed method.
83
New cards

What are the different types of SDLC’s?

  • Agile

  • Waterfall

  • Scrum

  • Kanban

  • Other combinations of Agile and Waterfall

84
New cards
What is functional testing?
Testing what the system does — verifying features, behaviors, and business rules against requirements. Example: verifying that valid credentials authenticate a user and redirect them to the dashboard.
85
New cards
What is non-functional testing?
Testing how well the system performs — quality attributes like performance, security, accessibility, and reliability. Example: verifying the checkout API responds within 300ms at p95 under 200 concurrent users.
86
New cards
What is the difference between functional and non-functional testing?
Functional testing verifies what the system does (features and behaviors). Non-functional testing verifies how well it does it (speed, security, scalability). Both are required — a feature can work correctly but fail under load.
87
New cards
What are the essential fields when writing a test case?
Test Case ID, title/summary, linked requirement, preconditions, test data, atomic test steps, expected result, and priority.
88
New cards
Why are preconditions the most critical field in a test case?
Most flaky test failures are actually precondition failures — the system wasn't in the right state before the test ran. Example: a test for "add to cart" fails because the user isn't logged in, not because the feature is broken.
89
New cards
What is API testing?
Testing application programming interfaces directly — sending requests and validating responses without going through the UI. Checks status codes, response bodies, headers, error handling, and performance.
90
New cards
Why is API testing valuable compared to UI testing?
APIs are faster to test, more stable, and closer to the business logic. Most defects in a system exist at the API layer. API tests sit in the middle of the test automation pyramid — the sweet spot between unit tests and slow E2E UI tests.
91
New cards
What is regression testing?
Testing that ensures new changes haven't broken existing functionality. Needed after bug fixes, new feature development, code refactoring, environment changes, and before releases.
92
New cards
When should regression testing be run?
After any code change — bug fix, new feature, refactor, or dependency update. In CI/CD, automated regression runs on every commit or PR merge. Manual regression is run before major releases.
93
New cards

How do you test an entire backend?

  • Through unit tests (individual functions),

  • integration tests (component interactions and API contracts),

  • API tests (endpoint behavior),

  • performance tests (load and stress), and security tests (authentication, authorization, injection).

You don't test it through the UI — that tests the frontend, not the backend.

94
New cards
Why would you use automation testing?
To run repeatable checks faster than any human can, on every code change, 24/7. Automation catches regressions immediately and frees testers to focus on exploratory and judgment-based work.
95
New cards
What are the limitations of automation testing?
Automation can only find what it was programmed to check — it can't notice a confusing UX, an unexpected behavior, or a feature that technically works but serves no user need. It also has high upfront cost and requires maintenance when the product changes.
96
New cards
What is an API?
An Application Programming Interface — a defined contract that allows two systems to communicate. One system sends a request (usually HTTP with a method, URL, and body), and the other returns a response (usually JSON with a status code).
97
New cards
What is the difference between a hard assert and a soft assert?
A hard assert stops test execution immediately when it fails — the rest of the test doesn't run. A soft assert logs the failure but lets the test continue — all assertions are evaluated and failures are reported together at the end.
98
New cards
When would you use a soft assert instead of a hard assert?
When you want to check multiple independent conditions in one test and see all failures at once. Example: validating a user profile page where you want to know if the name, email, AND avatar are all wrong — not just that the name failed.
99
New cards
Give an example of a defect with high severity but low priority.
A NULL input in the internal admin tool crashes the server — Critical severity. But it's P3 priority because only internal staff can access the tool, the input is validated in the UI, and regular customers can never trigger it. Serious but not release-blocking.
100
New cards
What is an example of a defect with low severity but high priority?
A broken company logo on the login page (Low severity — nothing is technically broken) but the CEO is demoing live tomorrow (P1 priority — must be fixed tonight).