BT

Your opinion matters! Please fill in the InfoQ Survey!

GitHub for Testers

| by Ben Linders Follow 12 Followers on Jul 27, 2017. Estimated reading time: 7 minutes |

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

Talk to a developer about version control, and you’ll likely hear about Git as a workflow tool and GitHub as both a place to store code and a personal resume. Yet to a less technical person, like a tester or business analyst, Git is a sort of magical voodoo that spawns builds and bugs. It can be beneficial for testers to join and use Github for personal and professional projects and to contribute to existing projects.

Matt Heusser is the managing director of Excelon Development; Chris Kenst a test engineer for Laurel & Wolf. The two spoke about contributing to GitHub at the Spring Online Testing Conference 2017.

Heuser and Kenst started by showing the audience how to create a GitHub account and begin contributing. Because the video of their talk is replayable, the audience can watch the video once to "get the gist", then follow along a second time through, pausing to run the command as they go.

InfoQ interviewed Heusser and Kenst after their talk about using GitHub outside of code, the benefits that testers can get from using GitHub, and what can be done to stimulate the use of GitHub and other open source tools by testers.

InfoQ: You mentioned that GitHub can be useful for lots of things outside of code. Can you give some examples?

Matt Heusser: Sure. Any test artifacts - plans, session notes, how-tos, can be put into version control. Specifications (if you put them in, say HTML or MS Word format) can go into GitHub.

Chris Kenst: Exploratory Charters, lists of pretty much anything, cheat sheets, data or even a reddit style Ask Me Anything (AMA). Also through GitHub pages you can create and host websites (testers should have some online presence) and write and publish books. The only limit is your creativity!

Since creativity is stimulated by examples, let me provide a few. Below are a few public test artifacts I have created or have found to be useful. The first is a description plus examples on how to writing exploratory charters using the format popularized by Elisabeth Hendrickson. The third is a great big list of strings that you can use in string-based input fields that might help you find failures. Lots of fun!

Example Test Artifacts:

There are a lot more examples of creating and hosting websites through GitHub pages (testers, this is a good option). The first is a personal website and blog for Ben Balter a product manager at GitHub. The second is a very simple personal website that resembles more of a landing page with links to various social media sites. The cool thing with GitHub websites is that if you like something, you can fork it, make some updates and turn the site into your own! The third is an open source, community driven website containing software testing conferences and workshops. If you want to get started contributing to GtiHub this is a good option: Contribute to testing conferences.

Example Websites:

InfoQ: How does it work when you’re using GitHub for non-code objects? Can you use all features of GitHub?

Kenst: All projects are treated roughly the same. Each time you create a repo you get access to all of GitHub’s major features including version control, Issues, Wiki, etc. Even with non-code objects you can submit pull requests and make incremental changes.

Heusser: Yup. Everything is seamless except for merges and diffs of binary files. The pick-the-latest-version-of-a-line-between-two-branches magic of git isn’t going to work on MS Word docs.

InfoQ: What’s the benefit that testers can get from using GitHub?

Heusser: First and foremost, you can understand the workflow of the developers and communicate in their own language. This leads to less friction between the two. Second, you get one step closer to the build artifacts and the code itself. If you can start to read a little code, you can pinpoint errors in the program down to the source-code level. This gets you better at reading code, maybe contributing to code review. As I’m sure Chris will point out, you can also use github itself for workflow - approving individual push sets, filing bugs, and so on. Plus, of course, having a gitHub and making contributions to it is a public portfolio, making it easier to get hired and creating less risk for the customer.

Kenst: That’s right. Both profit and nonprofit organizations (think the Selenium Project) are increasingly using GitHub to host their code.

First, this means software professionals are increasingly likely to use the GitHub workflow in their professional lives. In this workflow code changes are submitted through pull requests where testers and developers can visually see the code differences and test those code differences separately before merging them into production. Automated tests run at various levels of the system on these pull requests making giving teams possibly huge process and testing advantages. As Matt said, this also means testers can contribute to code reviews and submit bugs through GitHub Issues.

Second, this means organizations and recruiters increasingly look to Github accounts as a way to evaluate candidates for jobs. Why read a resume when you have a public portfolio of work easily available? Even if this portfolio contains side projects and non day-job related material, it can still be a more valuable demonstration of skills than a resume alone.

InfoQ: At the Online Testing Conference you took the approach of first showing how people can signup for GitHub and start a project, and then explaining how this works. Why did you do it this way?

Kenst: The main goal of our presentation was to make sure those watching would be able to setup a GitHub repo and contribute to it. This plus the time constraint meant going with the demo first and then following up with good but optional background information and examples.

Heusser: When we started, the demo was long and our extra material was longer. We were worried about going over. I’d say we did a good job tightening it up, which was mostly Chris! (Laughs)

InfoQ: What suggestions do you have if people want to stimulate the use of open source tools like GitHub by testers?

Heusser: It’s a good question. Honestly, I see a lot of leads and coaches saying things like "just do it!" or asking questions like "why can’t the testers use new_tool?" My suggestion is to pair with the testers to help them accomplish the work with the new_tool, be it github or selenium or whatever. I suspect you’ll find either it’s a little harder than you expected, and the ramp-up time and support is a reasonable request, or else you’ll find it’s easy and pairing helps overcome the resistance. Either way, you win!

Now, for some advice for practitioners: Start a project! Learn to code with katas. There’s a huge difference between sort of being able to follow along by google-searching advice on how to loop, and having deep expertise in a programming language. A couple of katas run through a couple of times can create that expertise. Start by forking my katas repo - then use katagenerator.rb to create your own katas. Here’s an easy one - roman numeral to decimal converter. Go ahead and commit that and put in a pull request to add it. Now you actually know how to commit to project!

Then, next time you need software and start the long, painful process to get budget, look for an open source alternative - for example, Selenium is an alternative to UFT. Look for the project and see if there is a way to contribute to it, even it is just bug reports. Especially if it is just bug reports; you will learn another part of git workflow, it is easy to learn, and it will probably be appreciated!

Kenst: With regard to software testing tools, the biggest advancements in the past decade have come from the open source community. Selenium is the standard for testing web applications (and is in the process of becoming a W3C standard). Appium is likely to end up in the same place for automating mobile applications. The great browsers and browser tools we have are thanks to the advancements from the open source community (e.g. Chrome). Git is one of, if not these most popular version control systems and it also is open source.

In order to keep relevant, testers need to keep an eye on these projects (and the others that come along). Guess where you can find most of these projects? On GitHub!

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT