Hey, I got an offer from AQA for an iGaming project, and I need your help.
The job’s all about creating automation from the ground up. There was already a project, but it was written in Python. The job uses my favorite TS/PW combo.
The thing is, I’ve never really started a project from scratch before. I’ve always just joined existing ones.
The company wants to assign two more manual testers to me who want to switch to AQA (I don’t have any mentoring experience either), but I’m not particularly afraid of that. I’ve never worked with tests on AWS or anything like that. All tests were run through CI/CD in GitLab. I made separate projects for different domains (.env or in the PW config itself), but I didn’t do anything on a large scale or for large projects.
How did you deal with such challenges?
What should I focus on first, what should I pay attention to, and how can I avoid making things worse with my automation?
Are there any best practices that are better to follow when creating a new project?
Fixtures, POJ, decorators (as @smoke)
Maybe there are FAQs for it
2 Likes
Automation QA, yep, that’s where things like Python skills are handy.
Does “iGaming”, mean gambling, or just microtransactions on a specific platform? Regardless, if you have been chosen for the skills you have , and start the job, all you need to do now is be calm.
I jumped into a brand new (to me) industry 2 months ago and am having a great time inventing my own wheel using Python. I am still on Python 3.7, but at some point I’ll update to 3.12 - but right now I’m trying to keep things compatible. But yeah, my general starter steps have been to create a wiki page where I just throw all my ideas and even minor bugs into one big page. Any notes that are interesting go into a small personal jira project which is really a big backlog that I can use to pick up. But mostly I take stock every morning to see if I am heading towards the correct target to get stuff integrated into the TeamCity CI/CD. Right now I’m working on installers, and soon I will get the TeamCity artefact download code hacked together. But you get the idea, stop often , look for any landmarks or “virtual milestones”. And then check with a manager, and with your own internal compass to see if you are headed in the right direction. If someone hired you, you are probably the best person for the job.
2 Likes
If I understood correctly, you’re only focusing on e2e test automation.
I don’t know if that really answers your question, but I would prioritize:
- baby steps
- going from A to Z before adding many tests
- applying new learnings to the whole thing each time
What I mean by that is, to be a bit caricatural: Start by writing one simple e2e test and make it so that:
- it runs it locally
- it runs on someone else computer
- it runs from someone’s computer into a real environment
- it runs from a “server” (you might simply ask for SREss or DevOps help)
- it is launched automatically (you choose the trigger though, maybe daily, maybe existing CI/CD)
- its status is reported automatically (via slack or azure or whatever)
- bonus point if you can link your test to existing product documentation
Once you have this “stream”, then you can always go further on each step. For example:
- more tests
- more environments
- parallelizing tests
- some subsets are launched more often than others (ex. critical = every hour)
- create a dashboard for everybody to see current health of the system
- tracking the coverage rate via the documentation mapping
- e2e tests template provided to dev’ for them to create future tests
- …
If it is more than e2e tests (also units and integration), then you can keep the same ideas (baby steps , create the length before the depth, and improve all each time). Simply it’ll be other steps.
If it is more than automation, then sorry, I’ll need more context 
1 Like