The first thing I would do, after being embedded in your development team, pore through all your Confluence documentation, and study the official documentation of the automation toolsets we use: I would start building a parallel side project using the same toolsets, to deepen my knowledge on what I am learning on-the-job.
- Who made this testing tool we are using?
- Who initially created it?
- How has it evolved?
- What was the initial problem it tried to solve?
- What inspired it?
With the help of the software testing community I find the experts who are writing the blog posts, the articles, the technical talks describing how the tool can -really- be used.
Who knows? Maybe in my seven-year tenure as a former organizer of a Boston-area software testing community, I already know them!
I then start compiling my research notes. I start blogging about the toolsets, comparing notes with others in the software testing community, relaying the information I have collected back to your company.
- Your documentation about the toolset becomes better.
- Brown-bag sessions start appearing.
- Articles get written on your corporate blog, raising your team's external profile.
- Stand-up training sessions get scheduled so manual testers can get up to speed writing their own tests.
I am currently #OpenToWork for a full-time permanent remote role as a Software Development Engineer in Test. Coding samples and framework walkthroughs are on the Programming Projects section.
No comments:
Post a Comment