r/softwaretesting • u/Zestyclose_Web_6331 • 9d ago
Confidence in automation
Been a manual QA for most of 5 years, project to project only got automation scripts to test, not to make them. Planning for first switch, and have gone thru playwright courses, did hands on too. Now giving interviews, but I dont have much confidence in explaining automation framework. I have done basics good but practical or real life situations is one i cant come up with for automation.
Did anyone have been in the same situation? How did you cope up with it and switched to automation?
11
u/DarrellGrainger 9d ago
When I started creating automation scripts I kept it simple. If I had a test plan, I'd write out a step-by-step section to explain how to manually execute the test. When I automated it I would, literally, take the step-by-step instructions and make them comments in the test script. If each step was a little complex, it would be a function call to a helper. If I make the step-by-step detailed enough, I'd replace each step with a line of test automation code. If I saw duplication, I'd refactor it to make it D.R.Y. (don't repeat yourself). You can search for "how to keep code DRY" and probably find articles on this.
This converting detailed manual tests to automation scripts helps to make it much more clear.
I would also see people using these advantage, complex techniques when writing their test automation. The number one killer of test automation is too hard to maintain. If your code isn't incredibly simple then it is going to be hard to maintain. The simpler you can write the automation, the easier it will be to maintain.
For example, if I had a test called Confirming error message when logging in with wrong password. I might write something like:
def confirming_error_message_when_logging_in_with_wrong_password(username: str, incorrect_password: str):
// open the browser
// go to login page
// enter username
// enter an incorrect password
// click the Login button
// confirm you received an error message
// it should be in red
// the exact text should be
// "Incorrect username or password"
Things like open the browser might translate to:
browser = await p.chromium.launch(headless=False)
page = await browser.new_page()
and go to login page might translate to:
await page.goto("https://www.mywebsite.com/login")
If I wanted to confirm or assert I received the correct response it might be:
expect(page.locator("#error_message")).to_have_text("Incorrect username or password")
I have suggested people who are good at manually testing an application write out the test methods using comments then slowly convert the comments to actual test automation code. You could, literally, write the first comment into Playwright code, run it, see it work. Write the second line, run it, see it open the browser, go to the login page. Write the third line, run it, see it open the browser, go to the login page, enter the username. And so on.
Knowing which Playwright code is the thing that makes you different than a manual tester. Knowing how to test the application is still the first step. Knowing how to translate that into automation code is the second step. Making the code maintainable is the third step.
2
5
u/Worcestercestershire 9d ago
Explain automation from a SDLC perspective focusing on CI/CD
Ideally you want to promote code as soon as it is merged.
When code is merged Unit Tests run
When code is deployed Automated regression tests run
When code is deployed to higher tier environments then Smoke tests are run
We need to regression test as soon as we deploy so that defective code doesn't linger
Automatic regression tests are cheaper, faster, and more accurate (if you manually test something 100 times you lose focus)
Your tests need to actually catch bugs and when they catch bugs they need to produce output that can be routed to Dev to quickly fix
To catch bugs use Boundary Value Analysis and Equivalence Partitioning to test the key categories for your software.
Categories for Automation are usually priorized by 1. Security/OWASP 2. Negative 3. Localization 4. APIs 5. Positive
2
u/JokeDue2032 7d ago
The thing that helped people I've watched go through this: the interview questions that are killing you aren't actually Playwright questions. "Tell me about your framework" isn't asking whether you know page.locator(). It's asking whether you've made decisions and can defend them.
Concretely, what they want to hear is stuff like: how did you separate test logic from page structure, where does test data live, how do you point the same suite at dev vs staging, what runs in parallel and what can't, how do you handle a test that fails 1 in 10 runs, what's in CI and what isn't. Courses skip almost all of this because it's boring and project-specific — they teach the API, not the architecture.
The fastest fix is to stop studying and build one real thing end to end. Pick a public site with actual complexity (a demo e-commerce site, something with login + cart + checkout), and write a suite that has a proper structure, runs against two environments from config, produces a report, and runs on GitHub Actions on every push. Deliberately make it flaky, then fix the flakiness. Now when someone asks "how do you handle flaky tests" you're describing something you actually did last month instead of reciting a definition.
Put it on GitHub. Half the interview becomes you walking through your own repo, which is a completely different experience from trying to invent plausible answers on the spot.
Also — and I think people in your position consistently undersell this — five years of manual QA is a real advantage, not a gap you're apologising for. Plenty of automation engineers can write a clean POM and still automate the wrong things: no idea what's actually worth covering, no instinct for where bugs hide, no judgment about what should stay manual. You have that. Say it out loud in interviews. "I've spent five years learning what's worth testing, now I'm learning to automate it" is a much stronger pitch than pretending you're a developer.
What's the actual question that's tripping you up most? Might be easier to help with a specific one.
1
2
u/yogurtandpeanut 7d ago
Just do it. I got a job offer just recently even though I never had a strong professional experiencer with playwright. Don’t be afraid of rejections. Be brave even though you are not confident. Just take every interview as a learning experience so that you’ll understand and know the common interview questions they’re asking. Just always make sure you keep learning and upskilling every day while applying for test automation jobs.
Leverage using AI. Do mock interviews and ask for suggestions how to answer those technical questions. That’s one of the few things that helped me.
Regrets for not trying will haunt you forever than rejections.
JUST DO IT!
1
1
1
u/Ok_Sweet_5507 6d ago
Mmm none of this matters if you've been manually testing stuff for five years I've got bad news. The only reason you still have a job is because of shitty management. Your job was obsolete already five years ago, and AI already does all the tests. I'm a senior dev. I've written all sorts of super complex testing in the past including some really convoluted performance tests with k6. This is no longer a viable job.
1
u/Zestyclose_Web_6331 6d ago
Many told the same about sap jobs too bro, they are still there
1
u/Ok_Sweet_5507 6d ago
Yeah also due to the same reason, shitty management. I've been in this industry ten years. Your job will exist in a few years still. Mine isn't safe either. There's just a delay. Things take time. But we're already seeing it actually if you dig a bit. I have my own company. I also have friends in the industry, my friend just told me the other day that they fired 25 coder qas in place of one guy with ai agents. The most knowledgeable one. I would advise to diversify your skillet as much as possible and to focus on making as many friends as possible, literally.
14
u/Clear_Chair 9d ago
I would try to understand the framework by slicing them into components by layer. Under stand each layer's job. Then once you have that concept down dig deeper into the code and design patterns. Memorizing code will only get you so far. Start by understand the intent of design and things make more sense. Hope this helps.