Engineering Roles line, station 6 of 8
Software Testing and QA
Find the bugs that matter: test design, exploratory testing, API and accessibility checks, and bug reports developers love.
- 6lessons
- 4 hto read and do
- Beginnerlevel
- 6podcast episodes
- 12checked exercises
Tools you'll use in this course
The lessons open these with a template ready. They work for your own job too, no course needed.
About this course
Quality assurance is more than clicking through screens. Good testers think about risk, design tests that find many bugs with little effort, explore like a curious user, and write bug reports that get fixed. This course teaches those foundations, in line with the ideas behind the ISTQB Foundation Level syllabus, with practical work in every lesson.
You test Mangrove Market's customer checkout and the Store app's goods-received flow on handheld scanners. You plan testing around risk, design test cases with equivalence partitions, boundaries, decision tables and state models, run time-boxed exploratory sessions with charters, test an order API with a collection and check the data behind it with SQL, check accessibility and behaviour on cheap phones and slow networks, and run user acceptance testing with Ama, a store manager, before a go/no-go decision.
Every lesson has diagrams, quick checks, a hands-on Build it walkthrough, practice tasks with exercises checked in your browser, flashcards and a podcast episode. The course ends with a capstone project, testing the new receiving flow before rollout, and a final exam for a free certificate.
What you will be able to do
- Plan testing around risk and explain what you will and will not test
- Design test cases with partitions, boundaries, decision tables and state models
- Run focused exploratory testing sessions and report what you learned
- Test APIs, data and accessibility, not just screens
- Write clear bug reports and run user acceptance testing
Syllabus
6 stops, about 4 h in total. Each stop fills in when you complete the lesson.
What testing is for
Testing gives your team facts about risk, so people can decide whether to ship, fix or wait. In this lesson you learn to find the risks in a release, score them, and plan testing that puts the most effort where a failure would hurt most. You will do it for Mangrove Market's festival-rush checkout release.
Risk-based testingTest planningQuality characteristics
Designing tests that find bugs
You cannot test every possible cart, so you need a small set of tests that is very likely to find the bugs that are there. This lesson gives you four black-box techniques that do exactly that, and you will use them on Mangrove Market's checkout: partitions, boundaries, decision tables and state transitions.
Test designBoundary value analysisDecision tablesState transition testing
Exploratory testing
Written test cases check what you already expected. Exploratory testing finds what nobody expected: the photo that vanishes, the receipt sent twice, the count that drifts when the signal drops. This lesson shows you how to explore with a clear aim, a time box and notes that other people can use, on the Store app's new receiving flow.
Exploratory testingTest chartersSession-based testingTest oracles
Testing APIs and data
Almost everything the Mangrove app does on screen is a request to an API and a row in a database. When you test at that level, a check takes about a second instead of a couple of minutes, and you see exactly what the server said and saved. This lesson shows you how, with an API client, curl and a few lines of SQL.
API testingTest designRisk-based testing
Accessibility, devices and the real world
An app that works on the developer's new phone over office Wi-Fi can still fail for a blind customer, on a cheap phone, in a lift with no signal, or in a cold stock room with gloves on. This lesson gives you the checks that find those failures: the WCAG accessibility checks a tester runs by hand, the two numbers you can measure, a device matrix chosen from data, and a real-world checklist for networks, interruptions and places.
Accessibility testingTest designRisk-based testing
Bugs, reports and acceptance
A bug that nobody can reproduce does not get fixed, and a feature that real users cannot use should not ship. This lesson teaches you to write bug reports developers act on, sort them in triage, and run user acceptance testing that ends in a clear go/no-go decision backed by evidence.
Bug reportingBug triageUAT
Capstone: Test the new receiving flow before rollout
A realistic project with a rubric and a model answer.
Final exam and certificate
10 questions drawn at random, 70% to pass.
Capstone project
Test the new receiving flow before rollout
Mangrove is rolling out a new goods-received flow on the Store app's handheld scanners: receivers scan the supplier's delivery note, count cases, record short, over and damaged items with photos, and submit a goods received note (GRN) that updates stock, even when the stock room has no signal. Today receiving takes about 51 minutes per delivery and about 1 GRN in 12 is corrected later. Plan and run the testing for the release: a risk-based plan, designed test cases with the technique named, two exploratory sessions, API and data checks, accessibility and real-world checks, bug reports, and a go/no-go recommendation for the pilot. Use a test version of any app you can reach, or the flow as described in the lessons; say which in your write-up. Plan for 4 to 6 hours.
You will hand in
- A one-page test plan: scope, risks ranked by likelihood and impact, what you will and will not test, and the approach for each risk
- Designed test cases in a table, each naming its technique (partitions, boundaries, decision table or state transitions)
- Charters, session notes and debriefs for two exploratory sessions
- API and data check results, accessibility and real-world notes, and bug reports
- A go/no-go summary with the evidence and conditions for rollout
Check what you know
Already know some of this? Answer 6 quick questions, one from each lesson, and we will mark the lessons you can skim. It takes about 3 minutes and nothing is graded.
Questions
How long does the course take?
About four hours: six lessons of 30 to 40 minutes each, including the Build it walkthroughs and practice, plus an optional podcast episode of about 10 to 13 minutes per lesson. The capstone project takes 4 to 6 hours.
Do I need to code?
No programming experience is needed. A few practice exercises ask you to write test cases as a short list in JavaScript, and each task explains the syntax it needs and has a model answer. One lesson uses a little SQL to check data, with a template. Test Automation and Quality Engineering, the next course, adds real test code.
Does it prepare me for ISTQB?
It covers the main ideas of the ISTQB Foundation Level syllabus, such as the testing principles, test techniques, risk-based testing and the test process, with practical work. It is not official ISTQB material, so use the official syllabus and sample exams to prepare for the exam itself.
What do I need?
A browser, a spreadsheet or document tool, and an Android or iPhone for the accessibility and device checks. The API lesson uses curl or a free API client such as Bruno, Insomnia or Postman. The exercises run in your browser with nothing installed.
Is the certificate free, and how does the exam work?
Yes, the certificate is free, like everything else on Kolom. Each attempt mixes questions from the course's question bank with two practical tasks, such as designing boundary test cases or writing a bug report. You need 70% on both parts to pass, and you can try again after 24 hours.
Is it really free?
Yes. Every lesson, podcast episode, exercise, quiz, final exam and certificate is free. The labs and their templates for real work are free too. Plus and Premium add every lab challenge, weekly extras and a mentor on top, and they never lock the tools or the courses.