Video summary

Cómo ser QA desde cero: el roadmap realista para empezar bien

Main summary

Key takeaways

Educational

Main ideas, concepts, and lessons

  • QA is not “finding bugs at the end.”

    • The video emphasizes that quality is about the perception of whether a system works, not merely the technology.
    • A QA (labeled “cua/qua”) is responsible for understanding the system and the user and for detecting risks before issues reach production—before the product reaches users.

  • QA solves the problem of “risk signals” being missed until damage is large.

    • Software failures have costs: users, business, or the team.
    • QA should identify problems early by asking the right questions:
      • Who will use it?
      • In what context?
      • What happens if something doesn’t go as planned?

  • QA must operate across two “worlds.”

    1. Functional/technical world: understand the full system—data, flows, integrations.
    2. User world: understand how users think—expectations, likely mistakes, pressures, misunderstandings. - QA’s job is to ensure these worlds don’t collide disastrously (i.e., to anticipate where misunderstandings and risks will emerge).

  • Learn QA in stages (not all at once).

    • Most people struggle because they lack the order of learning.
    • Skipping stages leads to frustration and learning things without knowing why they matter.

Methodology / roadmap (4 stages)

Stage 1 — Fundamentals / Bases (build the “way of thinking”)

Goal: Understand the product/system and what “quality” means for it.

  • Learn to understand systems, not code first

    • Be able to explain the product:
      • What does the app/system do?
      • Who uses it?
      • What data comes in and what data goes out?
      • What happens if something goes wrong?
    • Understand enough technical context to know where to look when something doesn’t add up
      • Concepts introduced: client/server, front/back, APIs, databases
      • Purpose: not to become a developer, but to ask the right questions and know who to ask.

  • Work within an Agile team context

    • Sprints, user stories, refinement
    • Know what is being built now and why.

  • Learn test concepts in terms of purpose and risk coverage

    • Examples: test levels, regressions, smoke tests
    • Focus: not “which tests to do,” but which specific risks each test type covers.

  • Include “soft skills” (framed as practical communication)

    • Communicate clearly
    • Ask tough questions constructively
    • Have timely conversations—often value comes from starting the right discussion, not only solving issues.

Beginner exercise (explicit instruction):

  • Use a simple app you use daily and answer:
    • What problem does it solve?
    • Who uses it?
    • What would happen if it stopped working tomorrow?
  • If this is hard, invest more time in building the foundation.

Stage 2 — Manual Testing (cornerstone of quality)

Goal: Develop real test design and reasoning.

  • Treat manual testing as an exercise in thinking, not mindless steps.

  • Design tests by asking:

    • What is the user’s intention?
    • What do you expect to happen? (expected results)
    • What happens if things don’t go as expected?

  • Use test cases as tools to organize and share thinking

    • A good test case must be clear about:
      • What is being validated
      • Why it matters

  • Balance quantity vs quality

    • The video contrasts:
      • Few test cases but high judgment vs.
      • Many test cases but poor quality

Exploratory testing (explicit concept):

  • Don’t follow a fixed script only.
  • Freely explore the product while staying intentional.
  • Record/evolve testing based on what you discover.
  • Put yourself in the user’s shoes:
    • Users make mistakes, go fast, don’t read, and may use products in unexpected ways.
  • QA’s focus:
    • Detect real risks that affect:
      • experience,
      • business,
      • data
    • Avoid “noise” (bugs/flaws unlikely to matter in practice).

Beginner exercise (explicit instruction):

  • Test a new feature using the same app as reference and answer:
    • What could possibly go wrong?
    • How would you detect it?
    • What impact would this have?
  • When this becomes natural, you’re on the right track.

Stage 3 — Automation (only after fundamentals and reasoning)

Goal: Use automation to increase impact by saving time—not to replace judgment.

  • Automation depends on whether you understand:

    • what to test,
    • why it matters,
    • and why tests fail.

  • The only real reason to automate: save time

    • Suitable targets:
      • repeated work each release (e.g., regressions, critical flows, variations)
    • Automation should enhance manual/testing strategy rather than erase it.

  • Automation rules/guardrails:

    • Not everything should be automated:
      • if it’s unstable,
      • if it adds little value,
      • if nobody understands it,
      • if it breaks quickly (it becomes noise).

  • Programming helps, but not as “start writing scripts day one”

    • Learn programming to understand:
      • what a test does,
      • why it fails,
      • how to keep tests alive over time.

  • Emphasize sustainability:

    • Automation is about building testing systems that last.

Team perspective (important instruction):

  • Automation is a shared responsibility
    • The development team should help define criteria for:
      • test coverage,
      • where the risk lies.

Practical guidance (instruction-like):

  • Identify which tests you will always repeat and why.
  • Once you know that, learning a tool becomes easier and more targeted.

Stage 4 — Specialization (deeper risk areas, not early fragility)

Goal: Focus on a problem type and risk impact.

  • Specialization is not mandatory as a “career ladder.”

    • People may remain strong in manual testing or go deep into automation.

  • Specializing means:

    • keeping global context while deepening in a specific area.

  • Popular specialization areas (examples listed):

    • Performance testing
      • Ensure systems handle loads, user peaks, response types
    • Mobile testing
      • Device/screen variety, versions, connection differences
    • Security testing
      • Extreme risk prevention (data, money, reputation)
      • Described as related to “ethical hacking”
    • Accessibility testing
      • Critical for not excluding real users due to early overlooked decisions
    • Also mentioned: data, compliance, user experience, etc.

Core warning / common mistake:

  • Don’t specialize too early before fundamentals are solid, or you risk creating fragile practice.

Self-check questions (explicit instruction-like list):

  • What problems am I most interested in preventing?
  • What faults am I especially good at detecting?
  • What tests (and impact) matter most to me?

QA in modern engineering context: Agile + CI/CD + DevOps

  • Software is deployed fast, sometimes too fast.

  • QA value shifts toward early risk detection:

    • timely questions,
    • pointing out dependencies,
    • notifying when something isn’t ready—even if it “works.”

  • DevOps is described as a way of working, not a specific tool/role:

    • development, operations, and quality collaborate from the beginning
    • build/test/deploy in a more sequential, controlled way to reduce surprises.

  • CI/CD meaning in the video:

    • Continuous Integration + Continuous Deployment/Delivery
    • Changes are constantly integrated and tested
    • Deployment to production isn’t postponed until the end
    • More frequent changes but smaller releases; still need fast, reliable feedback.

  • Focus on feedback speed:

    • QA doesn’t replace dev/product owner, but contributes criteria/context/questions others might miss.

  • Classic mistake:

    • “old-school QA” that tests everything only at the end.
    • This makes you arrive late to key decisions; in fast environments, arriving late may mean not arriving at all.

Practice guidance (instruction-like):

  • Think in terms of the end-to-end product flow, not a “testing phase.”
  • Engage with DevOps teams about:
    • environment configurations,
    • deployment behavior,
    • what happens if failures occur in production.

Portfolio (how to demonstrate QA ability)

  • Portfolio is not a collection of artifacts; it’s proof of how you think.

  • What teams want to see:

    • understanding of the product,
    • ability to prioritize,
    • clear reasoning for why one issue matters more than another.

  • What a portfolio can include:

    • test cases,
    • reports,
    • risk analyses,
    • explained artifacts (GitHub, Notion, website, screenshots).

  • You can build a portfolio without having “officially” worked as a QA:

    • analyze products you use daily,
    • try open source,
    • collaborate with others,
    • create small exercises.

  • Prioritize intention over volume.

  • Emphasize community and learning with others (team effort).

Growth direction:

  • Practice quality by:
    • making mistakes,
    • trying things,
    • prioritizing,
    • deciding with incomplete information.
  • Roadmaps don’t teach daily judgment—practice does.

Speakers / sources featured

  • Sam (speaker/host): mentioned explicitly (“By the way, I’m Sam…”) as the creator of the channel and presenter of the roadmap.
  • No other specific speakers or external sources are clearly cited in the subtitles (aside from references to other related videos, e.g., “signal-to-noise ratio,” and “six different paths to becoming a QA,” but without naming additional authors).

Original video