The first month of a good QA course has no test automation in it. You spend four weeks learning what to test, how to report a bug so it gets fixed, and how to check an API and a database.
Automation comes after that, because a script only repeats the checks you chose. If you choose weak checks, the script runs weak checks faster.
What does a QA engineer actually do?
QA (quality assurance) means checking that software works before users get it. A QA engineer reads what a feature should do, decides how to test it, finds where it breaks, and writes that down clearly enough for a developer to fix it.
Most of that is thinking and writing, not coding. Code helps later, when the same checks must run on every change. So the first month builds the thinking, in this order.
Week 1: Where does testing fit in building software?
Start with how software gets made. Learn the steps a feature goes through, from the idea to the release, and where testing sits in each step. Learn the main kinds of testing too: checking one small part, checking parts together, and checking the whole app as a user would.
Add Git basics this week. Later, your test code lives in Git, and employers will look at your GitHub.
Then practise on something built for testers. Practice Software Testing is a free demo shop. Its makers keep one version with bugs added on purpose, so you know there is something to find. Pick one page, like login, and write down everything it must do.
Week 2: How do you choose which inputs to test?
You cannot test every possible input, so you learn to pick the few that matter. This is called test design, and it is what separates testing from clicking around.
Two techniques do most of the work. Equivalence partitioning splits inputs into groups that should behave the same, and tests one value from each group. Boundary value analysis then tests the edges of each group, because that is where code often breaks.
Here is a simple case. A month field accepts 1 to 12. You test 0, 1, 12 and 13, which are the values on both sides of each edge. For a Nepali mobile number field, you would test 9, 10 and 11 digits, not fifty random numbers.
This is also a good week to start JavaScript on the side, a little each day. You will need it in week five, and it is easier to learn slowly than in a rush.
Week 3: What makes a bug report good enough to fix?
A bug that nobody can reproduce does not get fixed. Mozilla's bug writing guide calls the steps to reproduce "the most important part of any bug report".
A good report has four parts:
- a short summary that names the problem,
- numbered steps to reproduce it,
- what you expected and what actually happened,
- the browser, device and version you used.
Mozilla gives two more rules worth keeping. Separate what you saw from what you guess. Write one bug per report.
If English is your second language, this is good news. Short numbered steps work better than long paragraphs. A developer reading "3. Click Pay. 4. Page shows Rs 0" understands it at once.
Learn two words this week too. Severity is how bad the bug is. Priority is how soon it should be fixed. A typo on the home page has low severity but can still have high priority.
Week 4: Why do testers need Postman and SQL?
Many bugs hide behind the screen. The page says "Saved", but nothing reached the database. The form shows an error, but the server crashed underneath it.
Postman lets you send a request straight to an API (the part of an app that sends and receives data) and read the answer. Every answer has a status code. Codes from 200 to 299 mean success, 400 to 499 mean the request was wrong, and 500 to 599 mean the server failed, as MDN explains.
That gives you an easy first test. Send an empty or wrong value. A good API answers with a 400 and a clear message. A 500 means the server did not know how to handle it, and that is a bug to report.
SQL does the same job for data. You place an order in the app, then run one SELECT query to check that the row exists with the right amount. Testers who can do this find bugs that clicking alone never shows.
Is an old laptop enough for the first month?
Yes. These four weeks need a browser, the Postman desktop app, a text editor and Git. None of them are heavy, and the practice shop runs online, so there is nothing big to install.
Heavier tools come later, with automation. By then you will know if QA suits you.
What can you try tonight?
Open the buggy version of the practice shop and give yourself 30 minutes. Find one bug. Write it up with the four parts above, as if a developer you have never met will read it.
Then install Postman and follow its guide to send your first request. Look at the status code, then change the address so it breaks, and look again.
Saarathi Academy in Old Baneshwor, Kathmandu teaches QA in this order in its Software Quality Assurance course: manual testing in weeks 1 to 3, Postman and SQL in week 4, then Playwright automation. The week-by-week syllabus is public before you pay.
Top comments (0)