The Problem
There were times during testing when dev accounts were needed. Creating and tracking these accounts was mostly a manual process. The different platforms varied in account creation, but they shared relatively the same flow:
- Create an account tracking item.
- Navigate to an email provider.
- Create a unique email.
- Create a unique password.
- Create or use a backup recovery email.
- Link the email to the gaming account.
- Fill out the account tracking item with the relevant data.
- Connect the dev account to the created email.
The problem was that this could be a time-consuming process, especially when a tester needed to create several accounts at once. Tracking also became difficult because a tester needed to balance the administrative task of tracking an account with creating it.
Account creation couldn’t be fully automated, especially because email providers had protections against spam accounts. But some steps could be automated. I focused on email and gamer tag generation, task generation, and uploading the account to a spreadsheet for additional tracking.
The Tool
I noticed a bottleneck for testers when creating emails and gamer tags, so I wanted to create a workflow to help. The tool generated a unique email and gamer tag. The user could choose from preset options based on spreadsheet data.
I gathered the headers that populated the spreadsheet and created data classes from the headers and values so that I could easily serialize them back into dictionaries when I need to implement sending more detailed payloads to communicate with other applications. I exposed the values to dropdowns in the user interface so that the tester could choose from preset options.
The tool then created a task and added an account to the spreadsheet with the relevant account data. This all happened with a couple of button presses.
Architecture
I was creating this tool for a specific project, but I wanted the tool to be shared across different projects. So I had to think about the architecture of the project early so that I could extend the code to fit other projects’ needs.
I separated the layers handling external services, the business logic, and the user interface. The business logic should not care where the data was coming from because different projects might not use the same applications. I also wanted to keep the UI easily extendable in case new fields were required in the future.
Impact
Creating a new account to validate a release required several minutes of manual effort. When several accounts were needed, the setup time could add up before testing began. The tool could also improve tracking because it was difficult to see which tester was using a dev account. Having a database that specifically tracked account checkouts could minimize administrative tasks.
What I Learned
Since I had to go through the process of creating dev accounts myself, I learned that it was important to understand the process before starting the task and to know which parts could be automated versus which parts couldn’t.
This also helped me focus my development time on features that actually mattered. I also learned about the process of setting up requests in Python and working with APIs and spreadsheet data.
