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?

What it means to be a leader in testing

Background:

During CAST I sat for an interview with Pradeep Soundararajan of Moolya Testing. We talked about a few things mostly on what it meant to be a leader in the testing space. They made a short video on the interview so check it out or read the transcript.

Transcript:

When I think of test leadership, I think of two angles: one is the thought leadership within the industry itself, and in the other is the experience I’m able to impart on my coworkers. So sort of two diverging ideas. One of them is because I’m often the sole tester. It usually means I’m sort of the de facto person that knows testing a bit more than everyone else. It’s like how do you coach and extend and just sort of bring up the level of testing and quality within an organization? Then the other part is like, what are other people doing? What are the things I’m missing? What are, you know, just constantly looking at what the industry and sort of beyond are doing?

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

Join my Webinar on Participating in Code Reviews as Tester

Last year I wrote an article for Stickyminds about Participating in Code Reviews as a Tester where I made the case for Code Reviews being more than just a chance to catch bugs. They also serve as a chance to see how something is built and have a conversation about it.

We, as Testers, question software differently from developers so it’s important that we participate in this knowledge-sharing practice and now I’m going to try to show everyone how!

I’ve partnered with TestCraft for a webinar on May 21, 2019 at 9am PST.

I will demonstrate a live Code Review (or two) and show everyone it’s not about knowing how to code, it’s about asking questions and learning about the changes.

Expect to Learn:

  • The basic git workflow, where the creation of a Pull Request leads to Code Reviews
  • What to look for when you are Code Reviewing from a tester’s perspective
  • A practical way to get started doing your Code Reviews on your own
    The webinar will end with a Q&A.

[button url=”https://www.testcraft.io/webinar-participating-code-reviews/?utm_campaign=Participating%20in%20code%20reviews%20as%20a%20tester%20webinar%20-%20chris%20link&utm_source=linkedin&utm_medium=social” color=”blue” size=”medium” type=”square” target=”_blank”] Sign Up Here! [/button]

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!

Contributing to GitHub is for Everyone at the Online Testing Conference

On June 13th Matt Heusser and I will be giving a talk at the Online Testing Conference on the value for testers in contributing and using GitHub. Actually it will be more than just a talk, we’ll do a full demo on how to get started on GitHub by creating and contributing to a repository of your own. Then we’ll give you some ideas on how to use it going forward. (Hint: there are lots of uses besides code.)

Update 06/14/17:

Matt posted the slides on SlideShare and the video is now live:

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!