🚀 Testing QA Desde CERO!!! Clase 1

Main ideas / lessons conveyed

• Course purpose: Teach “testing from scratch” with a strong emphasis on practical work and workplace relevance, not just theory.
• Focus on objective, reproducible test design: Good test cases must be clear, precise, concise, and impersonal so they can be executed by anyone (or by the original author later).
• Testing process definition: Testing is framed as the process of verifying and validating that a program/software aspect works as intended, training test analysis (not only executing tests).
• Avoiding theory overload: Concepts (like standards such as ISO/STV) are introduced progressively, but learning is always anchored in hands-on exercises.
• Realistic workload: Testers may need to execute many test cases per day; students practice consistency and speed.

---

Methodology / structure for writing a test case (from the spreadsheet exercise)

The instructor walks through a test case template (spreadsheet columns) and explains what each part means and how to fill it in.

1) Test case identity & organization

• ID
  • Identification/name of the test case, aligned with the project’s naming conventions.
  • Sometimes includes a link/copy of a Gira ticket (Gira is described as a test case manager).
• Project grouping / examples
  • Examples like “Mate” / “Mate 001” / “Cookie” demonstrate different projects and naming.

2) Status and dates

• Test status (examples mentioned)
  • waiting: created but not executed yet
  • executed: already performed
  • rejected: created but later not accepted/needed (or postponed/discarded)
  • A “creation status”/stage is also referenced (example phrasing implies a design/creation stage).
• Design date / creation date
  • The date the case is created (optionally including the year).

3) What the test case is about (title/description)

• Test description (or title/summary)
  • Must communicate what and/or where (order doesn’t matter, but be consistent).
  • A “mate” metaphor is used to teach action + context description (e.g., kitchen, login, entering a password, pressing the login button).

4) Preconditions / context (what must be true before steps can run)

• Preconditions
  • Everything required before execution can proceed (e.g., hot water, mate set, yerba mate, sugar for sweet mate).
  • If preconditions aren’t met, the case cannot proceed to test steps.
  • Wording should be specific (e.g., “bombilla inside mate gourd”, “hot water” vs “boiling”, etc.).
  • Some environments may be implicitly understood, so preconditions don’t always need repetition (e.g., already being inside the page/application).

5) Test steps (how to perform the test)

• Test steps
  • Each step is an action (click, enter data, place an item, pour water, etc.).
  • Steps must be:
    • numbered/ordered
    • very explicit
    • written in impersonal, concise language
• Level of detail guidance
  • Include “how/where” details to prevent misunderstandings.
  • Example: specify where the bombilla goes, how it’s positioned, and how water is added (e.g., until it covers the herb).
• Step count guidance
  • Ideally 5–6 steps, acknowledging that sometimes it can be more.
  • Avoid splitting into too many test cases arbitrarily, but don’t make cases unnecessarily long.

6) Expected result (what should happen after steps)

• Expected result
  • Written in an impersonal/objective way.
  • Emphasizes objective outcomes (e.g., the mate is prepared/ready to drink).
  • Defines what “correct” means for that case—objectively and test-owned.

7) Result obtained (actual execution outcome)

• Result obtained
  • What actually happened after running the steps.
  • Can be:
    • matching expected (pass scenario)
    • missing/incorrect (fail scenario), e.g. “mate prepared but lacked sugar” or “too sweet”
• Evidence linkage
  • Strong emphasis on recording evidence for outcomes.

---

Evidence, retesting, and bug creation (supporting sheets/columns)

Evidence (what must be recorded)

• Evidence types
  • Screenshots (examples: Greenshot; also mention using F12 inspector to check CSS pixel values)
  • Photos/images linked via URL
  • Video recordings uploaded to Drive/online storage and pasted as links
• How evidence is used
  • Evidence is referenced in the test case output (linked in an evidence column).
  • For alignment/measurement-like issues, use tools to check pixel offsets and include the results.

Bug / issue workflow (Bugs sheet concept)

• If results don’t match expected:
  • Create/record an entry in a Bugs sheet, including:
    • what happened
    • evidence link
    • author/name (instructor corrects students not to put “I” in sheets)
    • severity and other metadata
• Severity concept
  • Severity reflects how much the issue blocks or prevents the flow:
    • minor visual issue vs bigger functional block

Retesting

• Retesting happens after developers claim a fix is done:
  • tester runs the test again
  • results are updated in retests (or an equivalent column/section)

Observations / clarifications

• Optional notes may include:
  • circumstances
  • comments/clarifications about what happened

---

Practice instructions given to students (homework/exercise)

A) Homework / continuous practice

• Students receive homework:
  • practice one or two test cases during days they might not practice.
• Reminder:
  • later in real projects they may execute 20–30+ cases per day, so building practice habits matters.

B) In-class exercise: fill the spreadsheet with a real routine

Students must:

• Open the provided test case spreadsheet
• Pick a small part of their routine (example: “getting up”, “breakfast”, “going to work”)
• For that routine action, create test cases by filling:
  • ID/project grouping
  • status
  • creation/design date
  • test title/description
  • preconditions
  • ordered test steps
  • expected result
  • result obtained (later after execution)
  • evidence
  • observations/comments
• They are encouraged to write using a phone or computer; instructor offers alternatives and reminders.

Spreadsheet tips provided:

• Excel date autopopulating by dragging
• using Ctrl+C / Ctrl+B for copying into multiple cells

C) Additional practice page (web-based exercise)

• Later, the instructor introduces a practice webpage (link shared via WhatsApp/Zoom).
• Students practice creating test cases for UI elements, e.g. selecting “Samsung Galaxy S6” and interacting with buttons/filters.
• Expected behavior:
  • write steps and expected results that match the page actions.
• Instructor example guidance:
  • preconditions: “having internet connection” or “being in the environment/page”
  • steps: “go to main page”, “go to monitors button”, “click monitors button”
  • evidence: screenshot/URL evidence link

---

Concepts about test organization: test cases vs user stories vs categories

• User story
  • A broader umbrella describing many aspects/parts (e.g., “school routine”).
  • Often organized outside the structured spreadsheet style (or used as a grouping concept).
• Test cases
  • Cover small, specific functionality—ideally one “thing” at a time.
  • Multiple test cases roll up under a story/category (e.g., “school routine” includes waking up, dressing, breakfast).
• Categories/folders
  • Used to group related test cases (e.g., items under a main page such as phones, laptops, monitors).

---

Key cautions / quality rules emphasized

• Avoid subjectivity in testing
  • “Correctly” is discouraged as vague; expected outcomes should be precise and observable (e.g., “too much sugar”, “lacked sugar”, “button list displayed”).
• Do not leave unclear steps
  • Over-explaining beats ambiguous under-specification.
• Evidence is part of correctness
  • For UI alignment/pixel differences, measure with tools and provide screenshots/evidence links.
• Don’t indiscriminately create or share
  • Share/ask colleagues selectively for review—don’t distribute broadly across the whole office.
• Impersonality and consistency
  • Use consistent naming and formatting across the dataset.

---

Speakers / sources featured

• Speaker (main instructor): Elías Caballero
• Other students mentioned (names referenced):
  • Marquito
  • Ale (also “Alicia” appears as a chat participant)
  • Alejandro/Georgio (first name unclear in the original context)
  • Ignacio
  • José
• Referenced tools / systems (not speakers):
  • Gira (test case manager)
  • Greenshot (screenshot tool)
  • F12 / Inspector (browser dev tools)
  • OpenShot (mentioned in the evidence/screenshot context)
  • Drive (file hosting/storage for evidence)
  • GIGA / Excel (mentioned as environments where execution/results may have been recorded)