FAQs to How I Became An Automation Engineer (talk)

I’ve given the talk on How I Became an Automation Engineer a few times. Each time I’ve gotten good feedback and a lot of questions from engaged participants. With each repeated question, I try to update my talk to address those points for future audiences. However often I do this some repeated questions still arise. I’ve taken this challenge as both an excuse to write out my answers and try out a FAQ schema block!

Frequently Asked Questions

Here are the FAQs for my talk How I Became an Automation Engineer.

How do you decide the scripting or programming language to use in your testing? Do you typically use the same language the app is built in?

My recommendation is to use a programming language that your company supports. By this I mean a language that someone within your company uses and can provide feedback on your code through code reviews. This may or may not be the language the application is built in. Most companies use several languages. You might build your tools in JavaScript while the application is built in Java.

Ultimately your goal is to tackle the task at hand. Use the tools and languages that make sense.

Is (insert name of your current tool) sufficient enough to perform all types of automation testing?

No, probably not. Hopefully you work for an organization that wants to use the right tool for the right job.

Part of the process for learning about tools is we figure out what they are and aren’t good for. No one tool is good for all jobs. The same goes for the person using the tool. If you only know one tool you’ll try to use it for every problem. The more tools we learn, the more likely we will use the right tool for the right job. This also makes us more valuable in the market for new jobs.

What are your thoughts on using frameworks with record features to start learning automation?

It depends on your needs and your skills.

In the past, Record and Playback features were sold as Snake Oil. They’d fix all your problems. But they usually were much good beyond proof of concepts.

Today, more and more services are cropping up with codeless / record and playback capabilities. If these meet the needs of your project and/or company, then use them. One challenge for the individuals learning and using these these tools is they might not benefit your (market) value in the long term.

Sometimes the team or project doesn’t support automation either for budget or time concerns. How do you tackle that?

Test Automation is there to provide feedback, but it costs money and takes time to build and maintain. So if you are on a short term project then it might not be worth the time an effort to do certain kinds of test automation.

What kinds make sense? Well it depends on the project. It might be worth it to do unit tests but not much else. Or it might be worth it to build some one-off probabilistic automated tests to help you discover problems because it doesn’t have to be maintained. Remember the point of automation is to reduce our time or extend our capabilities but all that must be done within the context of your project.

Do you recommend learning to test and automate at the API level? Is Postman adequate for this?

Yes! In general I recommend automating tests at the unit level first, then at the service or API level and lastly at the UI level. Learning to explore APIs is a big part of this and eventually once you explore them, you can create automated tests.

Postman is a good tool for exploring APIs (there are probably others). It might also make sense for you to write some automated tests in Postman but that really depends on your goals and/or if there are better places to do it. This depends on your overall strategy.

According to your last slide, the future of the Automation Engineer role is uncertain. Do you think it’s better to move to the developer role or there is still hope that automation roles will be still exist?

We know that in high performing teams developers own the automated tests and testers are allowed to explore for risks. So there’s a high probability in companies looking to build high performing teams that Automation Engineering roles will disappear or not exist. There’s also a high probability of developer roles being needed in the future. We just don’t know when any of this will occur. If you are going to move, it makes sense to survey the landscape and see what the options are, see what your skill levels are and be practical.

What is the name of the book about you recommend / quote about high performing teams handling test automation?

Want to watch the latest recording of this talk?

You don’t have to be an expert to teach

You don’t have to be an expert to teach someone else, you just need to know a little more than they do.

Years ago when I became an assistant scuba instructor, I was able to provide huge value to new students despite my having far less diving experience than all of the other instructors. Simply being able to help them out when I could and knowing the process meant a great deal. On the plus side I learned a lot from the questions they would ask, such that it made me a much better assistant (and eventually full) instructor.

For the same reason I started teaching AST-BBST, I wanted to learn more about the material. I probably wasn’t the best student (frankly I don’t know how well I did in the classes other than passing it) but I loved the information so much I wanted to get more exposure to it. Over time as I interacted with hundreds of students and dozens of instructors I feel like I’ve become exposed to more ideas and absorbed more information than I would have without it. I’m no expert but I’m probably better than most.

All of this is to say the Association for Software Testing is always looking for instructors to help teach classes. The class itself is free (once you’ve successfully completed one AST-BBST class you qualify) but the lessons you learn are incredibly valuable.

How I Became An Automation Engineer

Have you ever wondered what an Automation Engineer is or what they do? I’ve never found a great definition so I shared my experiences on How I Became an Automation Engineer and what that first year has looked like: the good, bad and the ok. I also talked a bit about the future of this role and the many challenges I see it facing (which might be a bit controversial).

Watch Now

Slides

References

Update:

Since the OnlineTestConf I’ve given this talk a few more times, the latest video you can find on my list of Publications. I’ve also written up some FAQs in case that helps!

Participating in Code Reviews as a Tester

Have you ever wondered what a code review is and/or what it’s like to participate in one? Are you a tester, product or business person who regularly interacts with the output of the code but wonders if they could catch bugs earlier by “shifting left”?

Turns out you don’t have to know how to code in order to learn about the changes, question the assumptions, clarify ambiguities, and generally participate in the knowledge-sharing around Code Reviews. Here’s a presentation on how to get started and what to look for.

Simply register to gain access, and the video will start right away.

Slides

References

It’s easier to write about tooling

It’s easier to write about tooling than it is to write about the decisions we took and models we made prior to choosing it. (The same is true for talking about tooling). I can write about a specific test I designed with WebDriverIO far easier than I can write about the strategy taken, oracles used or even the trade offs.

Aside from being a popular approach, there’s a lot of value in this directness. I’m able to succinctly communicate a specific problem and solution that might help someone else solve a similar problem.

The downside is when someone doesn’t understand this subtle communicative strategy and makes the wrong assumption(s) about the decision path. This seems to be a common pattern when talking with someone new to automation in testing: they just want the tool and none of the other fluff.

My solution for this problem is a bit of fishing: I will recommend a tool and then ask a lot of background questions even if that means I retract my initial recommendation.

Lessons Learned from the Contributing to GitHub is For You Workshop

On April 11, 2018 I gave a workshop called Contributing to GitHub is For You is For You (abbreviated as C2GI4U) in Des Moines, IA to the Des Monies Area Quality Assurance Association (abbrevitated as DAQAA). Roughly 36 people signed up for the DAQAA event meetup and of those about 22 showed up. Scheduled for 3 hours (including a break in the middle for food) I set out to cover a number of topics around using Git + GitHub including:

  • Creating repositories
  • Branching
  • Submitting changes in Pull Requests
  • Merging, reverting, cloning, forking, and other common commands, etc.
  • Using git locally from the command line and GitHub remotely through the web

In a little less than 3 hours we were able to run through three quarters of the exercises, covered all of the basic git commands and many of the intricacies of using the Git + GitHub workflow. Everyone walked away knowing how to grab and contribute to a project in Github using Git in the command line. A few people were overwhelmed having to pick up terminal commands in addition to Git commands, but most were able to get through the exercises and commit jointly to the C2GI4U repository. By the end a few felt so empowered they were going to apply what they learned the next day at work. (This point made me feel quite well.)

Workshops (generally) are fun because we get to do hands-on technical things. They also bring up interesting challenges, some of which are expected and others not so much. For example I expected some people might have to learn to navigate the command line (or re-familiarize themselves). Although we split time between GitHub’s nice UI you can’t get away from the command line but with practice during the workshop many people became more comfortable. However there were a few things that I didn’t expect and hope to improve upon the next time:

  • Provide a list of git commands we will use alongside the exercises. I had a list of all the git commands we were using as well as a list of exercises BUT they were in separate places.
    • I included a few cheat sheets with a bunch of different git commands but these were too broad to teach from, especially for people brand new to git.
  • Include information about storing GitHub up credentials. Although this wasn’t a big issue (you get a prompt to login) I always forget this step since my credentials are saved in my terminal. Everyone ran into this problem.
  • Make sure people are aware of the location of their code. I was good about this up front, but I need to make it a part of the pre-requisities and slides. This is as simple as making sure you are in your Documents folder before cloning a repo.
  • Branching can get quite complex. I’m also not sure how much of a challenge this was for people to understand and perhaps because of this how exactly to address this complexity except by going through exercises (I even drew a few diagrams on a whiteboard). Ideally I’d have more information / follow up references and maybe another diagram or two. I don’t think I explained Remote vs local branches as well as I could have.
  • Not really an improvement but a general note of thanks: A few of the organizers from DAQAA had experience with git + GitHub and so I was happy to have had a few helpers roaming around. An unexpected but happy side effect was participants helping one another out which made my job that much easier.

The goal here was getting closer to the development workflow (like git + GitHub does) to help reduce the knowledge gap for testers, business analyst, other developers, etc. and help make them more comfortable with the technical aspects of software development. (There were a couple of attendees who were learning to program in Java and the course they were taking assumed they knew how to use Git + Github which they did not. This class helped them become more proficient.) Overall I think we achieved that goal.

More:

A GitHub Workshop & why Version Control is a Technical Skill

On April 11th, 2018 I’m giving a workshop in Des Moines, IA to the Des Moines Area Quality Assurance Association (DAQAA) called Contributing to GitHub Is for You (join us!) on learning to use git with GitHub. The workshop is based on a presentation I did with Matt Heusser called Contributing to GitHub is for Everyone from the OnlineTestConf last year.

One important technical skill of increasing importance is using version control (also referred to as source control) systems. For those un-familiar version control systems give the user the ability to track changes to code, text, html, images and pretty much any other file you want. This in turn gives the user the ability to accept, reject or restore changes to individual files on a granular level. Whether you want to look at code, documentation, file bugs, backup important files, or create a website you are increasingly likely to do this in version control.

At Laurel & Wolf people outside of our engineering team like Product, UX, legal have GitHub accounts just so they can have insight into what’s going on, what might be shipped, see what legal disclaimers we are using, etc. This is in addition to JIRA which is more broadly used across groups in the org.

1*iHPPa72N11sBI_JSDEGxEA

According to the latest Stack Overflow developer survey git is the most popular source control system in use today. It’s probably due in no small part to GitHub’s increasing popularity. (Or is that a chicken and egg problem?) Github is increasingly the place to host your public and private files and has given rise to the GitHub workflow aka create a branch, add commits, open a pull request, review code, and deploy. It’s a workflow that many companies and projects now use daily.

This means if you can use git to push changes to GitHub you can become technically fluent in basic software delivery. If it sounds interesting come join us or watch the shorter presentation mentioned above!

Practice using Selenium Now!

Have you ever wanted to learn a little bit about Selenium WebDriver but didn’t know where to start?

Turns out there are some good tips / tutorials online for practicing writing Selenium in Ruby. One of those is a newsletter called Elemental Selenium that has something like 70 tips. You can sign up for the newsletter if you want but what I found valuable was to look at several of these tips, write them out (don’t copy + paste) and make sure you understand what they do. Turns out when you do this and you commit them to a repo, you can reference back to them when you come across similar problems in the future.

Simply stated [highlight]the goal is to:[/highlight]

  1. Read through the Elemental Selenium tips and then write (don’t copy + paste) the code yourself.
  2. Try running the tests locally and see how things work.
  3. Once you’ve written a few tests, refactor those example tests so they become more DRY (don’t repeat yourself). Create page objects.
  4. Commit these to your own repo on GitHub.

Putting your code on GitHub will have the benefit of showing you can write (at least) basic selenium automation. Although this code may not be your “best foot forward” given how new you’ll be, it is a starting point. As you learn more and make improvements, your code will reflect this.

These tips are (hopefully) grouped correctly but within each group there may be some variance. See if you can do one or two per day (some will be easier than others). If you see something interesting and want to jump to it immediately, go for it.

Beginning to Intermediate:

Intermediate to Advanced:

I’ve recommend a few people try this exercise because I found it valuable. Am I missing anything else? Has anyone else done something similar but in a different language or tool?

Catching up on a few Conferences

One of the great things about modern testing conferences is most either live stream or record their conference talks so the information can be disseminated to a wider audience. While you don’t get the interaction and conferring that an in-person visit would get you, it does make it easier for those who can’t travel to or are priced out of many conferences and allows them to get potentially useful insights.

After I went to CAST in August I wrote in-depth about my experiences. CAST was my one and only conference for the year, so when the Selenium Conference came up I couldn’t swing it. STARWEST is going on now, but again can’t swing it. The good news is it’s easy to catch up on many (maybe not all) of the important conferences.

First, I’d highly recommend catching up on CAST 2015, if you haven’t already:

I’ve gone through all of the CAST videos because despite being in attendance, there were so many were sessions that I just didn’t get to go to. Even the ones I attended, watching them again gave me some additional tidbits.

Second, I’d recommend catching up on is the Selenium Conference 2015 (or SeConf 2015). I’m working on this one as I write:

Have I missed any other testing or testing-related conferences? I know STARWEST has it’s virtual conference but it doesn’t put anything online. Enjoy!

Shaping Your Identity as a Tester

On Thursday, June 25, 2015 I presented my first webinar called Shaping Your Identity as a Tester that was based on an earlier article I wrote called Blogging for your Career.

uTest recorded it and made it part of their uTest University series, you can check it out here. I’ve also embedded the video below for easy viewing. The slides are pretty simple. My part lasts less than 30 minutes, the rest of the time is spent answering questions fielded from the 75 or so participants who joined. Check it out:

If you joined the webinar and your question wasn’t answered or if you have any questions after watching it here, feel free to leave me a comment (or contact information) or connect with me (on the right) and I’d be happy to respond!