March 19, 2017

New Ministry of Testing Meetup! Care to Workshop Ten Minute Lightning Talks? Let's Group Up!

The only way to become a better public speaker? Practice, Practice, Practice!

Want to practice public speaking with me?

Here's my crazy idea: I need three volunteers who want to practice public speaking. We all meet together for a few hours once a week for four (or five) weeks in a row. We each pick a topic relating to Software Testing or Quality Assurance, and work it into a ten minute presentation, i.e. a "Lightning Talk". When we are ready, we present our talks to the Ministry of Testing - Boston.

Yes, it will be scary. For me, the idea terrifies me. Public speaking is a skill I need to learn. We can learn from each other. We can all "learn by doing".

I was thinking we could meet in April 2017: Mondays 4/3, 4/10, 4/17, 4/24. 

Sign up here, with the Ministry of Testing - Boston:

T.J. Maher is 5 foot 7, with short brown hair, blue eyes, and a red MEETUP sign attached to his black messenger bag. He should be there by 5:45 pm just to make sure there is a table he can steal.


Would this work? Let's discuss during the first meeting!

• 4/3/2017: Let's introduce each other and bounce around topic ideas that we each want to work on!
• 4/10/2017: Share the outlines we created for the talk, with each of us trying to come up with a good beginning for the talk. (We can decide on a new location, some restaurant or coffee shop).
• 4/17/2017: Each of us run through the first five minutes of our talks. Solicit Feedback. (We can decide on a new location, some restaurant or coffee shop).
• 4/24/2017: Each of us does a run through the full ten minutes. How are we? Do we need another session, or are we ready to present our talks to the Ministry of Testing - Boston? (We need to see if we can grab a place to stand up and present).

Question: How big should I make this event? I was thinking a small group would be better. But should we raise the attendee limit from a group of four people (three plus me) total to a group of five people total?

What is a Lightning Talk? (According to Wikipedia):

"The YAPC (Yet Another Perl Conference) 19100 Conference came up with the term “lightning talk” at Carnegie Mellon University in Pittsburgh. The term was first coined by Mark Jason Dominus in June 2000. The practice of lightning talks was first known to be used at the Python Conference in 1997, but was not named until the YAPC 19100 Conference".

Once again, you can sign up at the Meetup page for the Ministry of Testing - Boston:

Happy Testing!
-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!"

March 16, 2017

Upcoming free webinars from Joe Colantonio, creator of the "Test Talks" podcast

Here are a few upcoming free webinars from Joe Colantonio, creator of "Test Talks" podcast at

3/20/2017: Sponsored by Applitools, a free webinar "Key Test Automation Skills and Best Practices: Recap of Top Sessions from Automation Guild Conference 2017". You can register at

"In this webinar Joe Colantonio - the founder and host of Automation Guild, the first ever online conference dedicated 100% to test automation - will take a look back at the event, highlighting the sessions, speakers and top takeaways.

"Joe will cover the following topics:

"The difference between Applitools and Galen
  • "21 Free Visual Validation Tools
  • "How testing vendors are embracing open source
  • "How to grade your Selenium Tests
  • "PageObjects vs Screenplay pattern
  • "Is BDD just for Collaboration?
  • "TestOps – how automation fits into CI
"After the presentation, Joe will answer your questions in a live Q&A session".

4/26/2017: Sponsored by QASymphony, a free webinar, "Ask Me Anything: Live Q&A with Test Automation Experts Joe Colantonio and Paul Grizzaffi" will be held on April 26, from 2:00 pm to 3:00 pm EDT. You can register at

Joe Colantonio's Test Talks Podcast

Some of my favorite episodes of Joe's Test Talks Podcast:

Happy Testing!

-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!"

March 15, 2017

Check out Adventures in Automation, now on Medium.Com!

Adventures in Automation is now two years old! It's messy. It's busy, with text scribbled in every margin. And it's my online home.

It also can be difficult to read, with a layout not as clean as today's modern WordPress formats. I do like the cute little Matrix-In-Blue theme, but it can be kinda distracting.

Because it would take a lot of work for me to port all of the almost 190 posts I have written to somewhere else, this weekend I reviewed all posts of mine and am in the process of moving the better posts to at one at a time!

I've scheduled one revamped entry to be posted per day over the next two weeks. Feel free to follow and favorite what you like!

Happy Reading!

-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!"

March 11, 2017

Notes from Dan Cuellar's Webinar, Appium: Prime Cuts

On Wednesday, March 8th, the creator of Appium, Dan Cuellar, gave a Webinar, Appium: Prime Cuts.

Dan Cuellar
"Dan is the creator of the open source mobile automation framework Appium, and Head of Test Engineering at FOODit in London. Previously, he headed the test organisation at Shazam in London and Zoosk in San Francisco, and worked as a software engineer on Microsoft Outlook for Mac, and other products in the Microsoft Office suite. He is an advocate of open source technologies and technical software testing. He earned a Bachelor’s degree in Computer Science, with a minor in Music Technology, from the world-renowned School of Computer Science at Carnegie Mellon University in Pittsburgh". -TestCon Vilnius 2016 Bio

Description of the Webinar, Posted on YouTube:

For the Appium aficionados amongst us, Dan Cuellar, creator of Appium and Principal Development Manager at FOODIt, will cover some of the more esoteric pieces of Appium along with tips and tricks he’s assembled from around the world to help you broaden your knowledge of Appium.
Topics covered in this webinar will include:
-Windows and Mac desktop app automation support
-Preview of the new Appium GUI
-Tips & Tricks from around the World
-Deep dive into how some specific pieces of Appium work
-Q&A from the audience

March 10, 2017

What should be an automation developer's first language? Java? JavaScript? Python? Ruby? Notes from the March 7th Lean Coffee, Ministry of Testing-Boston

I have a question for all the automation developers in the audience:

Let's say you have a manual tester who wishes to become an automation developer. What is the first language you would advise that the manual tester learn?  Java? JavaScript? Python? Ruby? Or does it not really matter?

When someone asks me, I usually say: Java or JavaScript. It feel like those are the most in demand here in the Boston job market when it comes to automation.

Why do I say Java? Because, well, I am probably biased. It's my favorite language. It's the one I studied in grad school. It's the one in which I have two years of work experience. And it is the one I feel is in the most in demand. Studying it gives you good, solid Object Oriented Programming. It may have the hardest learning curve, but I think it is worth it. Work through Alan Richardson's Java for Testers. Purchase Alan's course, Selenium WebDriver with Java. Start reading classic software design books such as Robert C. Martin's Agile Development: Principles, Patterns, and Practices, and his Clean Code: A Handbook of Agile Craftmanship. Or Martin Fowler's Refactoring: Improving the Design of Existing Code. You will become well-versed not just in automation, but in software development.

Why do I say JavaScript? So many web-based front ends are being developed in JavaScript such as AngularJS and ViewJS, and web apps that are in Node.JS. Automation developers are pairing these web apps with frameworks that are also in JavaScript. See my blog post Learning JavaScript to see links I have collected.

I attempted to make the case on Tuesday to the other Ministry of Testing - Boston members that Java was good because it was more difficult than Python and Ruby... and it wasn't until I expressed it with the other members that I realized how daft I sounded.

They saw my point... but the problem was that I didn't realize was that if someone wants to start learning coding on their own, it might be best to pick languages such as Python or Ruby which might not have such a steep learning curve.

So, what do you think? :) Please vote, below!

Happy Testing!

-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!"

March 9, 2017

How to Signal that the Build is Broken? Look for UFOs!: Notes from the March 7th Lean Coffee, Ministry of Testing-Boston

When developing software, mistakes happen. When multiple developers are working on the same project, the mistakes of one developer affects all the others, so it is important that you make sure your code compiles, that it passes all the unit and integration tests other developers have set up.

If you check in code and merge it haphazardly into the main branch of whatever source control system you are using, errors may prevent the build process that sets the web app to run. Your changes? You "broke the build", temporarily preventing your colleagues from doing any work on that shared project. This is a minor problem... unless you merged in your code just before going home. If that happened, you just prevented anyone who wanted to work the late shift from getting any work done.

If only there was some type of sign, some type of visual cue that the build was broken!

Tuesday night, during the Ministry of Testing - Boston's Lean CoffeeAndreas Grabner, a Technology Strategist at Dynatrace, showed us that there was.

Imagine: You finally solved the problem you had been working on all day, merged your code, and packed up for the day. Heading for the exit, you see this:

"Look! It's a Sign! A Sign that We Are Hosed!"

Turn around. Go back to your desk. Your code broke the build. You need to go fix it.

This is the Dynatrace DevOps Pipeline State UFO.

Andreas demonstrates the UFO for Ministry of Testing - Boston

As Andreas explains it in his March 6, 2017 article, Using the Dynatrace DevOps Pipeline State UFO, "The Dynatrace DevOps Pipeline State UFO was built out of the necessity to visualize alerts, problems, health and CI/CD pipeline state within the Dynatrace R&D organization. It sparked a cultural transformation as it made code quality that we pushed more frequently through our Delivery Pipeline more visible".

Taken from

You can:

Thank you, Andreas!

-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!"

March 8, 2017

DevOps and Dynatrace: Notes from the March 7th Lean Coffee, Ministry of Testing-Boston

Last night, the new software testing group, the Ministry of Testing - Boston Meetup, hosted its second Lean Coffee Meetup at the Panera Bread in Porter Square, Cambridge, MA. We switched locations from February's Lean Coffee, going from a reserved section of a noisy brewpub to a coffee-and-sandwich shop where it was nerve-wracking for me to attempt holding enough tables for all of the attendees. For April's Lean Coffee, I'll make a reservation back at John Harvard's.

Going from beer to coffee seemed to be less of a draw, which seemed to work in the group's favor. After the first ten minutes of free-flowing conversation between us four, we voted to eschew the usual Lean Coffee ceremony of writing discussion topics on Post-It notes, then voting on the priority and how many minutes we as a group should discuss a topic. We were all having too much fun just talking!

One of the attendees, Andreas Grabner, a Technology Strategist at Dynatrace, stopped in after meeting with some clients. Poor guy! What was meant to be a Lean Coffee turned into our own personal Dynatrace Q & A session, with us peppering him with questions for two full hours, interrogating him about their software development process, their automation process, and everything in between.

For those who missed last night, you can see Andreas speak tonight! Andreas will be giving a talk at the Boston Jenkins Area Meetup  on "Metric Driven DevOps with Jenkins".

Of all the things Andreas said, the most shocking thing was this: Dynatrace did away with a separate tester role at their company.

As I said to him, "That statement just sent chills up my spine! ... So you have just developers do the testing?"

Yes. Everything is automated. It did take a big culture shift. They spent years re-organizing the company. When you shift testers into more of a developer role, it can help them both. Coders taught testers how to code and testers taught coders how to write better tests.

I had to interrupt: "But who catches things such as typos? Bad graphics? Wrong copy uploaded? Not everything can be automated". Andreas mentioned that it is the customer that catches them.

Andreas went on to explain that Dynatrace spent incredible amounts of brainpower how to automate everything: Not just the code deployments, but the delivery mechanism itself. Developers could deploy whenever they wanted. But since changes went straight into production, it forced them to take ownership of production. They had to make sure not just that they didn't break the build, but also that they weren't pushing errors into Production, because the customers would see it. Dynatrace forced developers to interact directly with their customers, which forced them to become more responsive to the customer.

A funny thing happened. Without any filter between developers and the customer, it made the developer more in tune to the customer's needs. Yes, they heard negative feedback, as they always had, but it also allowed them to hear positive feedback from the customers using the product. When they fixed issues promptly due to the fast feedback, or put in a new piece of functionality that customers liked, they heard about it, unfiltered.

I'll share more of Andreas' insights in the next blog post. In the meantime, check out the talk Andreas gave last August at DevOpsDays Boston 2016! ( Official site ).

Andreas Grabner gives his talk to DevOpsDays Boston 2016
"How can we detect a bad deployment before it hits production? By automatically looking at the right architectural metrics in your CI/CD and stop a build before its too late. Lets hook up your test automation with app metrics and use them as quality gates to stop bad builds early!"

Happy Testing!

-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!"

March 7, 2017

The Differences Between BDD and TDD? Is this correct?

Have you ever had someone ask you a question, and in the process of answering the question, you weren't really sure if you were giving the correct answer?

This happened yesterday where I am working as a contract Sr. QA Engineer.

Question: "What is the Difference Between BDD and TDD? Is it the same thing?"

The answer I gave: No.


BDD: Behavior Driven Development
TDD: Test Driven Development

BDD is a way a business analyst and a QA Engineer can fashion the requirements and the tests.
TDD is a way of software development. Fashion the unit test first, then the code that supports the test.

BDD is using the Given / Then / When format Dan North came up with when working with TDD (Article, Better Software, Introducing BDD, March 2006), that Martin Fowler then echoed (Blog, GivenTHenWhen, Aug. 2013), that the Cucumber people with their Gherkin-style language ran away with.

That was the answer I gave... How could I have made my answer simpler?

- - -

Here is more information that I found while I was doing research:

Why is the famous BDD tool called Cucumber? Aslak Helles√ły didn't want to pick a geeky name. Read what he said on Quora about why he picked that name. 

BDD style had a direct link from Dan North to Aslak Hellsoy, when Dan donated his rbehave for Ruby to the RSpec project and the RSpec Story Runner that Aslak Hellsoy came across. Aslak liked it, wanted to improve it.

TDD, using Java, for example, you would first write a bit of code in the src/test/java branch, then the src/main/java branch, then back to the src/test/java branch as code was being developed. Write the first unit test, run it, and of course it will fail. RED. Write the code to support the test. Everything passes? GREEN. Need to combine like elements, similar elements in the code? REFACTOR.

TDD had been around for a while before BDD. See Kent Beck's Test Driven Development: By Example (2002) or this Wikipedia article on

So how did BDD come from TDD? Dan North < > in his article Introducing BDD writes:
"While using and teaching agile practices like test-driven development (TDD) on projects in different environments, I kept coming across the same confusion and misunderstandings. Programmers wanted to know where to start, what to test and what not to test, how much to test in one go, what to call their tests, and how to understand why a test fails.
"The deeper I got into TDD, the more I felt that my own journey had been less of a wax-on, wax-off process of gradual mastery than a series of blind alleys. I remember thinking “If only someone had told me that!” far more often than I thought “Wow, a door has opened.” I decided it must be possible to present TDD in a way that gets straight to the good stuff and avoids all the pitfalls.
"My response is behaviour-driven development (BDD). It has evolved out of established agile practices and is designed to make them more accessible and effective for teams new to agile software delivery. Over time, BDD has grown to encompass the wider picture of agile analysis and automated acceptance testing".

Happy Testing!

-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!"

March 3, 2017

Serenity BDD: An Automation Framework That Uses Specification by Example (SBE)

When someone is demoing a new automation toolset for the very first time, so many questions in my mind start bubbling to to the surface:
  • This is an open-source tool? What grad student created it? What was the student attempting to achieve with this tool? What problems were they trying to solve?
  • Is the tool on GitHub? Unit tests and code samples provided for us novices learning the tool? 
  • What company supports it and sponsors it? Is the tool popular enough for a community to have built itself around the tool? 
  • Is the tool still being maintained? When was the last time code was checked into the GitHub repository? How many are watching and have starred the GitHub repository?
Although the contract position I start on Monday, begins as a manual testing position -- the best way to learn the system under test -- it'll move to an automation position using the tool Serenity BDD

Note: BDD stands for Behavior Driven Development. Read more about it in Introducing BDD ( Mar. 2006) by Dan North, the creator of JBehave, or on Martin Fowler's blog entry, GivenWhenThen (Aug. 2013).

Also, note: I haven't actually downloaded or installed the tool yet, or even tinkered with it. This is just me, an automation developer, attempting to do online researching, and compiling what I have found. I cannot make any recommendations about this tool and how easy or difficult to use. This is just gathering the initial research.

March 2, 2017

Tips for Working With Recruiters: An Interview with Mitch Kurker

Although I have been working with recruiters ever since the boom, starting my software testing career as a QA Consultant at Oracle's Waltham, MA office back in August of 1996, I never really knew what a recruiter's life was like on the other end of the telephone.
  • What was their day-to-day life like at work? 
  • What did they like about their job? What did they dislike about it? What did they wish would improve?
  • Did they have any advice for candidates on making the interview process smoother, from the phone screenings to the in-person interviews?
  • It's tough out there for manual testers who follow traditional non-coding QA roles. Did they have any tips?
  • And, not to press my luck, but did they have any tips on negotiating salary? 

... As a new co-organizer of the Ministry of Testing - Boston Meetup, I felt it was my duty to found out.

Over the weekend, I drafted and sent out a Google Forms survey, How Boston Recruiters See The Software Testing Industry 2017 to every recruiter I have spoken to in the past two years. Below is the response I received from half of the two-man team that placed me in a position last Fall: Mitch Kurker and Rob Wall, at Modis IT - Boston.

Name: Mitchell Kurker
Title: Executive Recruiter, Technology
Company: Modis - Boston, almost two years
Studied at: University of Massachusetts at Amherst - Isenberg School of Management

How Does Your Company Stand Out From The Crowd?: "Personally, I think it is more about the individual you are working with rather than the company that recruiter works at. With so many agencies out there, so many are alike, but so few recruiters are."

About The Recruiter

How Long Have You Been a Recruiter? How Many Years in the Business?

"I'm coming up on 2 years as an Executive Recruiter. This is my first job after graduating college".

What is a typical day for you?

"My typical day is split between working with clients and hiring managers to understand their hiring needs or potential projects coming down the road. The other 50% is spent identifying, sourcing, and meeting with potential candidates for said roles".

What do you love about your job?

"I love working with people. Almost 100% of my business is done in person. I meet with every client and company I'm working with to understand their culture, and at the same time, I do my best to meet with every candidate in person who may be a fit. This is to ensure a long-term match for culture and personality. I also love the satisfaction of finding potential candidates their next great career move! My favorite part about my job is receiving referrals from clients or candidates because this means I'm doing my job the right way and providing great customer service". 

What do you hate about your job, and would you mind if I quote you on that?

"I hate when a client or candidate thinks I've failed them. Everyone makes mistakes and I'm not perfect, but I do my best to handle each client and candidate on an individual basis and give them my best effort and attention. As busy as this job can be, that does not always happen, however that is no excuse!"

About The Interview Process: Got Any Advice?

Job placement can be tricky, from cold calling potential resources, screening applicants, setting them up with interviews, and negotiating the final offers. Do you have any advice you would give to software testers?

For the Initial Phone Screen with the Recruiter

"Be yourself and keep things casual. We are not the enemy :) we're here to help you and learn about you as a technologist and as a person. Whenever a candidate has their guard up when speaking with me, it's not so much a 'red flag' for me not to work with them, but instead, I know there must have been a bad experience at some point that I would like to hear about so I don't give that candidate the same bad experience".

For the Initial Phone Screen with the Client Company

"Use your recruiter for preparation! I do my best to learn the ins and outs of each position, the hiring manager, his/her team, and the overall company culture. This is why we do things in person. Recruiters can not make you a great technologists or give you the answers to the test, but we can do our best to give you as much artillery as possible to 'win the interview' assuming we know our clients very well".

For Interviewing with the Client Company On-Site

"Dress to impress. I always suggest business professional, unless specifically instructed otherwise. First impressions are everything, and appearance is that first impression. Also, do your research on the company. If you're getting an on-site interview, chances are you're somewhat technically qualified. At this point, it's important to impress the hiring manager with your knowledge of their overall business & industry". 

For Negotiating Salary

"Trust your recruiter. Our clients pay us a percentage of your base salary, so it is in our best interest to get you the highest offer possible. At the same time, we understand the market, and this is where our expertise comes in handy. We do our best to get a candidate their ideal target salary, while not pricing them out of the market demand. Be open with your recruiter about what you're currently making, what your high-end target salary is, and the low-end salary that you'd potentially consider after going through the entire process. Communication is key to be sure you and your recruiter are on the same page!"

About Manual Testing

How difficult is it for manual testers to find work?

"2017 is a candidate driven market. I suggest manual testers expand into automation, to be as marketable as possible, but with how low unemployment is in the tech industry, jobs are aplenty for good talent in general!"

Do you have any advice for manual testers?

"Some industries where I see the demand for manual testers currently are in the biotech and pharmaceutical industries. But that is always changing, and so should candidate skill sets. Candidates should always be exposing themselves to new technologies and challenges".

Parting Thoughts

Any Last Comments You May Want To Add?

"I suggest keeping an open mind with every recruiter you have a meaningful connection with. I understand how often candidates are contacted about the next great role - we recruiters get those messages quite a bit as well. For direct-hire positions, you never know when that next great role will come, or when you're suddenly without a job. Having a large and trusted network of recruiters who truly understand what motivates you and what you're looking for is going to be the best way for you to land your next amazing position, or get back into the work force as quickly as possible without having to 'settle' for any old job".

Thank you, Mitch, for the detailed responses! Mitch can be reached at:

Are you a recruiter that places QA resources in the Boston area? 

Take the survey, How Boston Recruiters See The Software Testing Industry 2017, in order to be indexed on the Boston Recruiters page on the Ministry of Testing - Boston Meetup site. 

Contact T.J. Maher if you wish to host an event at your Cambridge or Boston office location!

And thank you, Conrad Hollomon for tapping me to be a co-organizer of the Ministry of Testing - Boston! I haven't had this much fun since I was an Assistant Event Coordinator of Nerd Fun - Boston!

And as always, Happy Testing!

-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!"

March 1, 2017

Working with Recruiters to Find Manual Testing QA Positions? Make Sure to Always Be Kind

Nobody likes job searching. Nobody.

It is a stressful time for candidates for QA positions. You might be on edge because time and money are running out. You might feel like you are being placed through the wringer, being under constant examination. You might feel cynical about the process, thinking that you are being treated like nothing more than a big fat commission by the endless swarms of recruiters cold calling you, and you might be easily aggravated with them, and you might want to verbally lash out at them, or give them a hard time.

In a word: Don't. Please don't. Job searching is stressful all around, not just for you, but for the recruiter who is attempting to place you at their client company. Be kind to them. Always, always try to be kind.

On Monday, I started sending out a new survey -- the first one I've ever created -- How Boston Recruiters See The Software Testing Industry 2017. I've wanted to create a series of blog posts, articles, and presentations on the perspective of a Boston area recruiter -- a viewpoint that would be quite helpful to members of the new Ministry of Testing - Boston I just started to help organize -- for a while. I received a response back immediately that really opened up my eyes to the harshness of their reality.

February 28, 2017

From Mel the Tester to Ministry of Testing - Boston members: "Be a bigger part of the testing community"

From: Mel The Tester
To: Ministry of Testing - Boston members:
Subject: Be a bigger part of the testing community
Date: February 28, 2017

- - - - -

"Hello Ministry of Testing - Boston!

"You all are well on your way to being a part of the large Ministry of Testing community. One of the ways you can do that is to contribute to the community at-large.

"There are opportunities to contribute by creating content for the Ministry of Testing organization and The Dojo.

"Writing articles for Ministry of Testing is one of the ways to get your thoughts and ideas out into the community, teach others new techniques or offer tricks and point out traps for old ones. The testing community needs a big voice, a big presence to help define the future of testing. You can be part of it.

"Contact Melissa Eaden for your opportunity to contribute.

"Slack: @melthetester
"Twitter: @m_eaden

"PS - if you would like to create tutorials via video contact Richard Bradshaw via Whiteboard Testing or contact him on twitter @FriendlyTester

"Thank you!"

- - - -

Mel the Tester's Blog is­
Happy Testing!

-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!"

February 27, 2017

Boston area recruiters: What is your day-to-day life like? How do you see the Boston area software testing industry?

Hello, Boston area recruiters!

I'm going to be writing a series of article about the day-to-day life of a recruiter. I was wondering if I could get your input?

The other focus will be how Boston area recruiters see the Boston area software testing industry. I was thinking of gathering information and sharing it with the new Ministry of Testing - Boston meetup with a series of blogs, articles, and presentations. 

Would you mind taking a quick survey?

Please like and share this with your co-workers! Thank you very much!
Happy Testing!

-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!"

February 25, 2017

New Ministry of Testing - Boston Event: 3/13/2017: Automated UI Testing using Apple’s XCTest/Swift @ Slalom Consulting

From the Ministry of Testing - Boston website:

"Description: With the increasing popularity of both mobile applications and Apple hardware, Quality Assurance (QA) professionals are being asked more and more to test native iOS applications. Automated User Interface (UI) testing continues to grow in popularity and can help save time, money, and eliminate human error in the testing process.

"Apple’s XCTest provides a robust UI testing framework that allows a QA professional to automate most actions a user would perform on a mobile device. With convenient features such as UI recording and the option to write tests in the feature-rich Swift programming language, this framework is a popular and solid choice. Using the case example of an ongoing iPad app build, we will explore how QA professionals can use this framework to build a comprehensive testing suite and touch upon some of the plumbing/DevOps associated with getting up and running and automating aspects of the Software Development Life Cycle (SDLC)".

Sign up here!

Happy Testing!

-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!"

February 24, 2017

New Meetup Event: Wed. March 29th, 2017: Come share your QA Knowledge with the "99 Second Testing Talks" with the Ministry of Testing - Boston @ iZotope, Cambridge, MA!

Is your manager at work forcing you to step up and lead technical discussions about testing, QA, or automation? Are you scared of public speaking? Need the practice? Come and volunteer to give a “99 Second Software Testing Talk”!

Never gave a talk before? This will be a wonderful way for you to learn by doing!
  • Jot down a topic you want to share in the comments section of the event page on the Meetup site. 
  • Rehearse your talk a few times between now and the time of the talk. 
  • Feel free to show up with 3 x 5 cue cards if needed! The purpose of this event for members who may be uneasy speaking in public to get practice. 

Sounds Great! Where do I sign up?

New Group: Ministry of Testing - Boston 

Where to Meet:

The event will be held at iZotope’s office , in their spacious lunch room. It is an eleven minute walk from the Kendall / MBTA Red Line stop. For Directions, see … signs inside will direct you from the front door to the lunch room.

T.J. Maher is 5 foot 7 with short brown hair, blue eyes, a “Hello My Name is T.J.” nametag and a red MEETUP sign attached to his black messenger bag.


6:00 pm to 6:30 pm: Meet and Greet: 
  • iZotope can provide the location but unfortunately not the catering. 
  • Feel free to grab something beforehand at The Friendly Toast, Mamelah’s Deli, Bon Me, The Smoke Shoppe, or any of the many places at One Kendall Square and bring it along. iZotope’s public area has many tables where we can gather. 
  • Directions for local takeout places are listed on the event.
6:30 pm onward: The 99 Second Testing Talks Begin!
  • The first five people giving a talk can line up at the front of the room. 
  • T.J. Maher will have a clipboard, where he can collect the name of speakers, the name of the talk, and any information participants want to exchange with the group (their website, Twitter handle, LinkedIn profile name, etc). 
  • One by one, going through the first set of speakers, after being introduced, let’s cheer the them on as they launch into their talk. 
  • When the stopwatch app on my iPhone reaches 80 seconds, I’ll signal the speaker that time is almost up. 
  • After 99 seconds, the person’s talk ends. We applaud wildly! 
  • We go to the next person in line, and that person gets introduced. 
  • Has everyone spoken? The next five speakers who want to can come up, and the process continues. 
  • Anyone else want to give another 99 second talk? Come on up! 
  • Inspired by another talk you hear? Improvise a talk on the spot! 

Need examples of 99 Second Talks?

Origin of 99 Second Talks:

From Scott Berkin’s Blog post, “99 Second Presentations”, Nov 18, 2012:
“A running joke in the world of presentations is: how short can they be? They used to be an hour. Then TED went to 20 minutes, Pecha Kucha to 6, and Ignite to 5. The trend of short presentations has been on the rise for years and one wonders where it will stop.

"But then consider TV advertisements: they’re 30 seconds long. The good ones communicate many ideas well in a very short amount of time.

“Years ago I ran an event at Microsoft called Design Day. Each year we’d experiment with different formats and one year we tried 99 second presentations. It went well and we did it the next year too. Unlike most speaking events it gives the audience a real chance to participate.

“ [...] It’s a small commitment to get someone to speak for less than 2 minutes. They can practice their material 10 times in half an hour. The surprise of short format speaking is it forces speakers to get to the good stuff”. 

About iZotope: 

From their site:

“iZotope makes innovative products that inspire and enable people to be creative. Based in Cambridge, Massachusetts, iZotope has spent over a decade developing award-winning products and audio technologies for professionals and hobbyists alike. Used by millions of people in over 50 countries, iZotope products are a core component of GRAMMY-winning music studios, Oscar and Emmy-winning film and TV post production studios, and prominent radio studios, as well as basement and bedroom studios across the globe. iZotope also powers products made by industry partners such as Adobe, Avid, Microsoft, and Sony. iZotope was recently honored with an Emmy® Award for Outstanding Achievement in Engineering Development for its flagship audio repair suite, RX®”.

Happy Testing!-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!"

February 20, 2017

The Ministry of Testing - Boston Meetup certainly keeps me busy!

From my LinkedIn profile, posted today:

Starting March 6th, I will be on a new six month contract-to-perm assignment as a Sr. QA Engineer at Ahold, Inc, the holding company for Stop and Shop, Giant Food, Hannaford's, and Food Lion. A new team will be developing new web and mobile apps at their New England Headquarters, and needed someone to test it as it is being built, then work with developers to automated those tests. Where is the HQ? Well... it's right here in Quincy Center, where I live... Literally a five minute walk from my apartment complex. Shortest. Commute. Ever!

... I am so looking forward to this! Most importantly, I will be glad not having to job search. The next two weeks can be like an extended staycation.

Good thing, too! There is so much I want to do:

  • Ahold uses as an automation solution Selenium WebDriver with Java, Serenity BDD as a testing framework, and the Zephyr plugin for JIRA. Although I am starting out manual testing -- the best way to learn how a product works and how it ticks --  it'll eventually move to automation. I want to make sure I am ready! I'll be researching all about those testing tools. Expect a few blog articles on BDD, Serenity, and Zephyr in a few months! 
  • I am now a new co-coordinator of the Ministry of Testing - Boston Meetup group. Are you a QA Engineer in the Cambridge, MA or Boston, MA area? Come join us! Are you a QA Manager who wants to share your knowledge and wisdom? I know a group who would love to be your audience! Contact me so we can set something up on our event calendar
  •  In two weeks, the Ministry of Testing - Boston group will have its next QA dinner-and-discussion meeting at Panera Bread in Porter Square, Cambridge, MA. We held our last Meetup on February 7th, 2017 at John Harvard's Brew House. It was a very good group of people, with some thought-provoking questions on the nature of quality and how one can assure it. I am working that into a new proposal for my next TechBeacon article. 
  • Oh, and I still need to finish off my blog series on the Java library, REST Assured, a way to test RESTful APIs. The first article was written on February 4th. I had the sample code all ready to go, when my five year old PC ran into a blue-screen problem, and I haven't been able to bring it back to life. Luckily, I have backups, and backups of backups that hopefully will be able to set me up when I finally purchase a new machine. In the meantime, this Asus Chromebook I bought when that happened has really been suiting my needs! 

Happy Testing!

-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!"

February 10, 2017

When asked by TechBeacon what the state of the QA Industry is like, I must have been in a real foul mood

When I was asked a few months ago by Mitch Pronschinske, Managing Editor of TechBeacon, I must have been in a real foul mood. In Mitch's article, 7 DevOps trends to watch in 2017, dated January 12, 2017:

"Testers will learn to code or perish

"TJ Maher, an automation developer and TechBeacon contributor, spent the last two years updating his skills to move from manual tester to automation developer to software engineer in test. In those same two years, he’s seen many of his former QA testing colleagues lose their jobs due to the major changes going on in the testing industry right now.
“Continuous integration and continuous delivery turned the big splash of Selenium WebDriver into a tsunami that washed away almost all of the software testing industry, drowning many of the manual testers and eroding their base of employability.” —TJ Maher
"For many testing engineers, 2016's motto was 'learn to code or perish.' Testing is now focused at the web services level, with tremendous demand for RESTful APIs, and Selenium wrappers, he says".

... Surely it can't be as bleak as I thought! 

Do you have a cheery story about manual testers getting the recognition they deserve, and being appreciated? Leave a story in the comments section below. 

Come help cheer me up! :) 

Happy Testing!

-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!"

February 9, 2017

DEV vs QA: A Conversation about Quality

Yesterday the Ministry of Testing - Boston held its first dinner-and-discussion event, a "Lean Coffee" at John Harvard's Brewhouse in Harvard Square. The discussion was centered on automation. How can we tell if automation is improving quality? What is your favorite automation tool? How can we get training? Most of us were new to automation -- until the past few years, coding knowledge wasn't really a requirement, so it was good to be able to network with one another and talk about the problems we were currently facing as we navigated this brave new world.

One question kept coming up that we couldn't quite answer ... how do coders measure quality?

A working definition of quality I have had since grad school:  To meet or exceed the expectation of the stakeholders, from the project manager (on time, on budget), to the customers using the product (intuitive design, good user experience).

Are you a software engineer? What metrics do you use to measure the quality of your code, your project, and your team?

... In spite of holding a BSCS / Theater Minor and Masters of Software Engineering, I have only been coding on-the-job for the past two years. From what I have seen, when a software developer thinks about of "quality", they may first think of the quality of the code:

  • Is the code as readable as it can be? (See Uncle Bob Martin's Clean Code)
  • Is the code as refactored as it can be? (see Martin Fowler's Refactoring)
  • Is the code written as simply and efficiently as it can be?
  • Are there unit tests and integration tests set up? Are they run before checking in code into the master branch? Do the tests all still pass? 
  • If creating a web app, how does it look in the bare minimum of browsers and platforms: Chrome, Firefox, and Safari for the Mac? 
When a QA Engineer thinks about quality, they first think about the quality of the end-user experience, and the quality built into the software development process:
  • Who are the people using this product? What are the different levels of the customer base?
  • How are they using this product? Test all major browsers, platforms, or mobile devices they will use!
  • Are the requirements testable? Are there acceptance criteria listed that indicate the "definition of done"?
  • Are there any assumptions that need to be spelled out in the requirement? Is DEV and QA on the same page on what the product should be?
  • How are the quality of the tests? Do they match the requirements? All of them? Have they been peer reviewed? Have you looped in the rest of the team: Product owner, DEV, user experience and checked to see if there is anything missing? 
To me, the relationship of DEV and QA shouldn't be the relationship between an artist and an art critic. Instead, it should be like that of a writer and a copyeditor, both working together to create a quality product. 

Software development is a partnership of DEV and QA. With DEV focused on the bottom up, from the code to the UI, and QA focused from the User Interface on down, the team can increase its chances to create a quality product.

Now that QA Engineers are expected to code, they now have to do double duty, incorporating both the DEV and QA definition of quality into their work. 

Are you a QA Engineer? Are you a Software Engineer? What does quality mean to you? Write your comments below! 

Happy Testing!

-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!"

February 7, 2017

Feb 7, 2017: Software Testing Lean Coffee @ John Harvard's in Harvard Square, Cambridge, MA

Tonight, I organized my very first Ministry of Testing - Boston event, a "Lean Coffee".

Picture a dinner-and-discussion event run like an Agile end-of-sprint retrospective, where members write down on Post-It Notes things they want to discuss, and people vote on the topics.

I haven't run an event in at least five years, since I was part of the Nerd Fun - Boston Meetup running five events a week, back in 2008 - 2011. Back then, my favorite place to meet was at John Harvard's Brew House, holding discussions at a large round table that seats fifteen. It is situated under a stairwell, and with the lower ceiling, the acoustics are much better than you would think in the crowded pub atmosphere.

I met up people before the event around the corner in the food court of the Harvard Square Garage mall, with my "Hello My Name is T.J." nametag, and a big red MEETUP sign attached to my black messenger bag, just like the old days.

We filed in at 6:30 pm, and had a lively discussion! Some of the discussion topics:
  • Scrum as a QA Process
  • How Can We Tell If Automation is Improving Quality
  • Favorite Automation Tool for Agile
  • Cucumber vs TestNG vs JUnit
  • Should QA be in DEV teams?
  • Picking Stable Jobs/ Compaines
  • Suggestions for Agile Training
  • "Testing" or "QA"
  • Lean Coffee at Work
It was a good break for me. I have been doing nothing but try to set up interviews for the past few days, trying to find my next automation development gig.

If you want to keep track of the discussion, I have posted a conversation thread on the Ministry of Testing - Boston Message Board at

Happy Testing!

-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!"

February 4, 2017

Software testing blogger looking for Automation Development Position

Well, that didn't last long!

Anyone looking for an full-time permanent automation developer? I'm looking for the Cambridge/ Boston area.

Ideal job: To do the same exact thing as I am doing with this blog, investigating and applying new tools, techniques and technologies in the automated software testing field.

-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!"

Are you sure the bus line is still listed?: Don't gather data from the UI. Use a RESTful API endpoint instead!

You are an automation developer on a team developing in Java a new public transportation web application. The customer base for the app is located in Southeastern Massachusetts.

The MBTA (Massachusetts Bay Transportation Authority) oversees the subway lines and buses of the Greater Boston area and the surrounding suburbs. The #230 bus line stretches across four cities, connecting a Commuter Rail Station in Brockton, MA (my hometown), a bus terminal for the Brockton Area Transit's BAT bus, and a major subway stop in Braintree, MA.

You will need in this project to get data from the MBTA for this particular bus line: bus schedules, bus stops, maybe even bus locations. But this begs the question:
  • How do you make sure that the #230 bus line is still listed?

Attempt #1: Manual Testing: Use the MBTA's Web Site

The easiest way to test to see if the #230 bus is still listed by the MBTA is a visual check through the MBTA's website.

1) Go to
2) Select the "Bus" icon

From the MBTA webstite,

Test #1: Assert that the "230" entry is in the dropdown for "bus".

3) Choose "230" in the dropdown provided.

4) Wait until you are redirected to the schedule for the 230 bus line at

Test #2: Assert that the schedule appears.

Schedules and maps from MBTA
We can visually check confirm that:

  • Yes, the 230 bus line is listed on the front page
  • Yes, the bus schedule appears... after a bit.

... But what if we want this to be part of an automated test and just want a yes or no answer to the question "Is the Bus Line Listed Correctly?"

Problems with Gathering Data from the UI

Let's say that we use Selenium WebDriver for our test. We write an automated script to:

1) Go to
2) Select the "Bus" icon
3) Choose "230" in the dropdown provided
4) Wait until you are redirected to the schedule for the 230 bus line

And we wait... and wait ... and wait...

... and wait ...

... and you may be automatically redirected to the bus schedule, or you may not.

Automate this with Selenium WebDriver and Java, and, mark my words, you are going to spend the next month or so trying to get the synchronization correct so the test doesn't time out.

This test will be deemed a "flaky test". Woe to anyone attempting to use this test in their test library.

A better test would be to not go through the web site at all to get this data, and communicate with a webservice that has this information instead.

A Better Way to Gather Data: RESTful API Endpoints

Luckily for us, like many sites nowadays, the MBTA offers an MBTA Developer Portal. Developers of third-party applications can read production data in real time, to see not just schedules of the buses and trains that the MBTA operates, but also the positions of the buses and trains in real time.

The MBTA wants to share it's data with the public. It provides: 
  • A public key you can use to test out the system (but make sure to subscribe for your own key if you are doing more than monkeying around)
  • Documentation on how to set up information queries (See the PDF for the MBTA-Realtime API Quickstart Guide dated 5/2016)

What is the Public API Key?

"Below is the current open development API key. It may change at any time. This key is open for all developers to use in development and testing. DO NOT go into production using this key! Register for an account and request a key of your own on There is no cost. 

"As of 5/11/13 the open development API key is:  wX9NwuHnZU2ToO7GmGR9uw"

What Information Can You Lookup?

According to the QuickStart documentation, part of the items you can look up are:

  • Stopsbylocation: GPS coordinates, listing latitude and longitude of the bus or train
  • Routesbystop: All the stops on the Red, Green, Orange line or bus line
  • Predictionsbystop: When will the next train or bus be arriving?
  • Alertheaders: Are there any service alerts?

You can see even more information in the MBTA-Realtime API Documentation (V 2.1.3) dated January 4, 2017. Listed is that you can query routes, such as bus routes.

If we wanted to manually interact with the API to check if the bus line #230 is still active, we can:

1) Go to to view all routes.

2) Search on the page for the numbers "230", and we can see:

"route_id" : "230 ",

... And, yes, we can see that the 230 bus line exists!

Coming Up Next Article...

We have covered a bit about REST APIs before. Last year we covered:

For this section, we will be covering how to use Java, TestNG and REST Assured to interact with MBTAs API. 

Until then, Happy Testing!

-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!"