I just started a new job as a
Software Engineer in Test three weeks ago. The main task right now is to try to get to know the product as a whole where our SET team will be writing an automated test framework.
What I Have Been Doing For Work
I've been spending the past few weeks executing huge stack of manual test scripts, asking the QA Engineers for help executing the test steps, getting to know both the system, how the system is being manually tested, and the system's documentation at the same time. I've also been creating onboarding documentation for any other new SET hires that come after me. If being an Software Engineer in Test doesn't work out (
heaven forbid!) and every single manual QA job is phased out, I can start my third career in the software industry as a tech writer.
What I haven't been doing yet is coding. The team narrowed down the automation stack to be Geb + Groovy + Spock, so I have been trying to learn that during my nights and weekends with little side projects.
My Ongoing Side Projects: Learn Geb + Groovy + Spock
Side Project #1: Investigating Yeoman
... This might take me another week to finish up.
Side Project #2: Contributing Geb + Groovy Tests to Open Source project
- Contributing to someone else's open-source automation project. I noticed there are automation examples in Java, Ruby, and sometimes C#... but there aren't any in Geb + Groovy + Spock. I wonder if I could learn that tech stack by helping out?
... Why this side project? ...
Why Contributing to an Open Source Project is a Great Learning Tool -- Code Reviews!
As an automation developer, the real learning begins...
... Not when I am researching how to code the first draft of an assignment...
... Not when I am actually writing the code to get the darned thing to compile...
... It happens during the code review...
Imagine writing a research paper. You spend a few days gathering research materials. You sketch out an outline. You spend four or five hours writing a good rough draft, and submit it to the teacher for review... and it is returned to you, covered with annotations and corrections written in red ink. After the first, second and third draft, you find out all about incorrect grammar, poor sentence structure, etc. But through the process you become a better writer.
The same exact process happens when coding. The first time someone reviews your code, you might be getting more lines of comments than there are lines of code! It may be painful to go through, having to re-write everything again and again, but it is helping you up your game.
I've spent the past two years being paid to contribute to a closed-source automated test framework for an eCommerce platform accessible worldwide. I've made hundreds of contributions to that project and, let me tell you, going through a code review is never is easy. Over time it becomes easier. It is all about trying to meet the team's wants and expectations. Over time, you learn.
This will be my first time contributing to an open-source project. If you want to learn how to do the same, I have written up instruction on,...
Setting Up an Open Source Project On Your Local Machine
Let's say you found on
GitHub an open-source project looking for contributors, and you want to contribute:
- Sign up for an account on GitHub. Me? My account is @tjmaher.
- Are you familiar with the command line interface? If not, install GitHub for Desktop.
- Not familiar with GitHub, repositories, branches, committing changes or pull requests? Follow this Hello World walkthrough that GitHub has created.
- Not familiar with forking other people's repositories into your own GitHub repository? GitHub has a forking tutorial, too.
- Go to the GitHub project and create a fork of their project, copying it to your own account on GitHub.
- Go to your local computer. Pick a folder or directory to download the open source project. I created a subfolder called "code" in my Home directory, so on my Windows 10 PC, I download everything into C:\Users\tmaher\code
- Clone or Download the project. Set it up to download it using GitHub for Desktop.
- Think about what micro-additions or subtractions you want to make the project. Make a new branch for that project. Are you done with that small task? Commit your code for that branch. Want to do another task? Commit that code, too.
- Done with the contribution? Create a pull request for your branch. It will start the code review process.
- You will start hearing corrections, both major and minor, from other contributors. Listen to what they are saying, and learn from them.
So, I Tried Opening The Project In IntelliJ...
I love using
IntelliJ as an IDE! It has a free Community Edition, suitable for any Groovy, Gradle, or plain ole Java project. If you want you can download it
here. I have the latest version, IntelliJ IDEA version
2016.3.
The project I wanted to contribute to was a few years old, still written using Apache Maven to handle all the dependencies (
Read More). When I opened the project in IntelliJ, and tried to set the project up to recognize the pom.xml file that was handling all the dependencies... I found out that I couldn't! Maven just didn't exist in IntelliJ! I couldn't figure it out! And I couldn't download it as a plugin...
What the heck? Did IntelliJ switch over completely to
Gradle?
Oh... wait a minute... I found the answer...
Here is a little Public Service Announcement:
Happy Coding!
-T.J. Maher
Twitter |
LinkedIn |
GitHub
// Sr. QA Engineer, Software Engineer in Test, Software Tester since 1996.
// Contributing Writer for TechBeacon.
// "Looking to move away from manual QA? Follow Adventures in Automation on Facebook!"