Automation Bootcamp

01 Introduction

Module 1 — Introduction

Welcome to your very first step in the world of test automation!

If you’ve been living in the kingdom of manual testing, get ready. Because now, you’re about to become the caster of invisible hands that do all those actions for you, flawlessly, tirelessly, and predictably.

This is not about replacing yourself with a robot. It’s about amplifying your impact. Automation lets you multiply your testing superpowers—faster releases, fewer regressions, more confidence.

In this first module, we’ll build a solid foundation: you’ll understand what automation really means, what it isn’t, and how to start your journey with the right mindset, tools, and habits.

Learning Outcomes

By the end of this module, you will:

1. What Automation Is — and Isn’t

Let’s clear the fog.

Automation is not magic—it’s methodical engineering. Automation is not the same as testing faster—it’s testing smarter. Automation isn’t about writing scripts—it’s about designing systems that check reality.

Imagine you’re a chef in a busy restaurant. Manual testing is like personally tasting every dish that leaves the kitchen. Automation is installing a smart kitchen sensor that checks every plate’s temperature, presentation, and ingredients before it hits the table. You still design the recipes, you still care about quality—but the checking becomes systematic.

Now, why is this distinction so important?

Because automation that merely “clicks stuff” is fragile. True automation:

When you automate, you’re building a miniature observer universe that watches your application’s behavior from every angle.

2. The Reliability Mindset

Automation isn’t just about coding tests. It’s about building trust between humans and machines.

Let’s unpack the three pillars that hold this trust: determinism, idempotence, and observability.

Determinism: “Same Seed, Same Flower”

Imagine you plant a seed and water it the same way every day—but one morning it grows into a rose, another into a cactus, and another into a banana tree. Weird, right?

That’s what non-deterministic tests feel like.

A deterministic test is one that behaves predictably: same input, same result, every single time. In automation, determinism means:

When a test sometimes passes and sometimes fails without code changes, it’s not your app that’s broken—it’s your test logic.

👉 Determinism builds trust. When a test fails, you know something truly changed.

Idempotence: “Pressing the Button Twice Shouldn’t Blow Things Up”

Suppose you click a “Pay Now” button twice by accident. You wouldn’t want to get charged twice, right?

In automation, idempotence means your tests should have the same effect whether they run once or a hundred times.

A non-idempotent test might:

The remedy? Reset your environment. Use setup/teardown methods. Design your tests so they clean up after themselves—like polite guests after a dinner party.

Observability: “If You Can’t See It, You Can’t Fix It”

Ever tried debugging a problem described only as “it didn’t work”? Frustrating, isn’t it?

Automation without observability is like driving blindfolded.

Observability means every test tells its own story. When a test fails, you can instantly know:

That’s why we integrate tools like Allure—they transform dry test outputs into rich narratives: timelines, screenshots, and metadata that make debugging almost beautiful.

3. Your First Practical Setup

Enough theory—let’s get our hands moving!

In this part, we’ll walk through setting up your automation environment in a GitHub Codespace, running your very first test, and verifying that everything works.

Step 0 — Fork the repository

In order of making this course the most unique and personal experience please fork the repository to your github account (this is like buying your read to build sandbox at the market and have it delivered to your front door.)

In our repository, click “Code → Codespaces → New Codespace”. GitHub will spin up a Linux-based environment in the cloud—with VS Code, terminal, and Python ready.

Step 1 — Launch Your Codespace

Think of a Codespace as a ready-to-cook meal kit: all the ingredients pre-measured, tools laid out, and instructions clear.

In our repository, click on “Quickstart → → Fork me”. Alternatively you can click this link as well.

If you don’t have a github account you can check this link here

Step 2 — Install Dependencies

Once inside your forked repository (you’ll know its yours because in the repo name will appear like this: /automation-bootcamp), open the vs code terminal and run:

pip install -r requirements.txt

This tells Python to fetch every library listed in the requirements.txt file—like shopping for all the right ingredients before cooking.

These libraries will include:

If you see a few warnings—don’t panic. As long as there are no red “ERROR” messages, you’re good.

Step 3 — Run Your First Test

Now type:

pytest -q

That -q flag means “quiet”—so Pytest will only show clean, minimal output.

If all is well, you’ll see something like:

.                                                                    [100%]
1 passed in 1.05s

Congratulations! You just executed your first smoke test in the automation world. 🎉

Step 4 — Peek into the Code

Let’s look under the hood.

Your smoke test might look like this:

from selenium import webdriver

def test_open_google():
    driver = webdriver.Chrome()
    driver.get("https://www.google.com")
    assert "Google" in driver.title
    driver.quit()

Pretty simple, right?

You opened a browser, navigated to Google, and confirmed the title.

Behind that simplicity, though, is an entire chain of automation magic:

This is the automation equivalent of a heartbeat—your first verification that the circulatory system works.

4. Anatomy of an Automation Project

Before you move on, let’s understand how a project like this is organized.

When you open your repository, you’ll see a structure like this:

qa-automation-bootcamp/
│
├── README.md
├── requirements.txt
├── tests/
│   ├── test_smoke.py
│   ├── test_login.py
│   └── conftest.py
├── reports/
│   └── allure-results/
└── .github/
    └── workflows/
        └── ci.yml

Let’s decode what each part does.

requirements.txt

Like a grocery list—it tells Python what dependencies your recipe needs.

tests/

Your main kitchen. Every file starting with test_ is a test module, and every function inside beginning with test_ is a test case.

conftest.py

This is where Pytest fixtures live—shared setup and teardown logic. Think of it as your “mise en place”: everything prepared before cooking.

reports/

Where Allure stores raw execution data. You’ll later run allure serve reports/allure-results to view them as beautiful dashboards.

.github/workflows/

Contains YAML configuration files for GitHub Actions. These define how your CI pipeline runs: install dependencies, run tests, generate artifacts.

README.md

Your guidebook. Always keep it updated! It’s the first impression any collaborator (or recruiter!) will see.

5. Mindset Over Mechanics

Here’s a truth most tutorials skip: The hardest part of learning automation isn’t syntax—it’s thinking like an engineer.

Automation demands curiosity and patience. You’ll often face “invisible errors”:

When that happens, don’t panic. Investigate like Sherlock Holmes.

Ask:

  1. What changed since it last worked?
  2. What evidence do I have? (logs, screenshots, timing)
  3. Can I reproduce it manually?
  4. Is it my app or my test?

Each failed test is a tiny lesson in cause and effect. Each debug session strengthens your intuition.

6. Reliability and Ethics

As you gain automation power, remember the responsibility that comes with it.

A flaky test can block entire releases. A misconfigured locator can delete production data.

Automation engineers hold the keys to massive pipelines—treat them with care.

Follow these golden rules:

In short: build like a craftsman, test like a scientist, think like a guardian.

7. Common Beginner Pitfalls

Let’s save you from the most common traps.

1: Copy-Pasting Without Understanding

Automation is not a recipe to memorize. It’s a discipline to internalize. Each command you write tells the browser a story—make sure you understand the plot.

2: Ignoring Waits

Web pages are alive—they load asynchronously. If you click too soon, your script fails. Learn to use WebDriverWait wisely.

3: Hardcoding Paths or Data

If your test only works on your machine, it’s not automation—it’s a demo. Always write code that runs anywhere.

4: Testing Too Much Too Soon

Don’t automate everything from day one. Start with smoke tests—the ones that validate core flows. Once those are stable, build up gradually.

Automation is like weightlifting—progressive overload, not brute force.

8. What’s Next?

At this stage, you’ve learned:

In the next module, we’ll explore Python for QA engineers—not just as a programming language, but as a reasoning tool. We’ll cover:

You’ll write scripts that don’t just run—they explain themselves.

9. End-of-Module Checklist

Before moving forward, make sure you can:

When all boxes are ticked—congratulations. You’ve crossed the threshold.

← Back to Modules