Happy Thanksgiving!

Happy Thanksgiving, Dear Reader! 

• May your Thanksgiving feast have included all of your requirements.
• May your dinner have passed User Acceptance Testing.
• After the day long Agile Sprint, may you and the people gathered 'round have a happy retrospective!

One of the things I am thankful for is the Ministry of Testing - Boston, the people I have met, and the great conversations I have had while running events! This may sound odd, but before I discovered this group Summer 2016 when it crashed Fitbit, I didn't know that such a thing as local networking group of software testers existed!


I'm thankful that I volunteered to help out this group last year.

I'm thankful that Conrad Holloman, the creator of the MoT Boston Meetup, trusted me to cover for him when he went on active duty.

I'm thankful that I have had the opportunity to lead this group when Conrad needed to devote more time to Operation Code.


Most of all, I am thankful for my wife, Melissa, for allowing me to excitedly bounce event ideas off her, working with me on logistics, all her help, and all of her love and support. The last Meetup I ran was Nerd Fun - Boston five years ago. How much I missed it!


Oh! And if you are a veteran and need help breaking into the software development field, you must sign up for Conrad Holloman's group, Operation Code at https://operationcode.org/


From me and mine, to you and yours, I hope you have a Happy Thanksgiving!




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

Webinar Notes: Justin Ison, "Automated Exploratory Testing": Crawlers and Data Gatherers

Imagine if you could write an app that would handle the monotony of gathering all the screenshots when performing user interface testing on web, mobile and desktop apps. It could randomly crawl though the app under test and collect screenshots that compared and contrasted differences between:

• Browsers and platforms, such as IE9, IE10 & IE11 on the PC, Safari on the Mac, Chrome, Firefox, Safari on the iPhone, and Chrome on an Android device. 
• Mobile devices such as a variety of Samsung Android devices, iPhones, and tablets.
• Various screen resolutions and breakpoints for web & mobile apps that have a responsive web design. 
• Various orientations, such as portrait and landscape. 
• Localization Testing: How the site keeps (or doesn't keep) its layout when the text is changed to Spanish, German (with its much longer words), Russian (with its Cyrillic alphabet), Arabic, or Hindi. 
• How mobile apps behave if you do taps, presses, long presses, or swipes. 

Justin Ison < @isonic1 >, Senior Success Engineer at Applitools, did just that! 

If his name sounds familiar, it is because I wrote in Mid-November about attending an Applitools Eyes training session that he gave me.

Exploring Applitools, a visual testing tool for web, mobile and Mac / Windows desktop applications.

The life of a software tester can be difficult.

Performing browser testing, comparing and contrasting all screens you need to test on for just a single web page, the look-and-feel for all the different combinations and permutations of browsers and platforms can be even more difficult.

Performing regression testing on an entire web site, confirming that what once passed still passes, checking that each visual element, image, font size, font style, font color, copyright date in the footer, privacy policy link, and graphic, no matter how small, has the same look-and-feel across all browsers, is its own special type of hell... Especially if it the regression tests have to be rerun, say, every two weeks. This is why it is better to offload the repetitive tasks to a system which performs visual testing.

Why can regression testing the UI be difficult for a team of software testers?

TestBash Philly - Day 2!

Day 2 of the TestBash Philly software testing conference, put on by the Ministry of Testing!

Next year: San Francisco!

TestBash Philly - Day 1!

Seven speakers. Ten types of games people can play that represent what testers face daily. Free breakfast, lunch, dinner, and an open bar. A full day of activities from 8:00 am, starting with a Lean Coffee, and ending at 11:00 pm, with attendees breaking out their board games.

Day 1 of TestBash Philly, here in the FringeArts Theater, at Penn's Landing in Philadelphia, PA was amazing! Paying all expenses out of pocket to get here was completely worth it. As the sole active organizer of the Ministry of Testing - Boston, it was nice to connect with other organizers!

... I wonder if we could bring a TestBash to Boston in 2019? ... I wonder if Microsoft's N.E.R.D (New England Research and Development) Center would be a good venue? It does allow people to book events, but it has been closed for a bit while they do some reconstruction. Hrm...

TestBash Philly 2017: The Pre-Test Bash Meetup

It took me seven hours, heading into Boston to catch the train to Philadelphia, then another train to get across the city to Penn's Landing to where TestBash Philly 2017 is being held, but I finally made it!

Today, I volunteered to help out the speakers putting on the two day software testing conference for the Ministry of Testing. Tonight I went to the Pre-TestBash Meetup. But before that, I was on a quest to find an authentic Philly Cheesesteak sandwich. Luckily for me, I found Campo's Deli right off the train station and devoured one whole.

Campo's Deli

Tinkering with Twitter: Post a Tweet Using Twitter4J to interact the Twitter REST API endpoint

This is Part Four of a multi-part blog series on putting together a basic API test framework for the Twitter Search API. Care to go back to the beginning? 

Now that we have been introduced to Twitter4J, a Java library built to interacts with Twitter's API, set up credentials that authorized Twitter4J to use our test Twitter account, and installed the Twitter4J library in a Java project, we can start writing code that can do three things:

• Connects to the REST endpoint of the Twitter API.
• Posts a Tweet to the Twitter account we set up. 
• Examine how Twitter4J interacts with the Twitter API

To figure out how everything works, we can view:

• Code examples on the Twitter4J official site which tells you how to post a tweet (updateStatus) and search for tweets (search).
• The Twitter4J javadocs, more detailed documentation of how you can interact with the various classed set up. 
• The source code in the Twitter4J GitHub repository.
• Compare the Java code you see with explanations in the official Java Tutorials.
• Lastly, review the docs for the Post and Engage Twitter using the API.

Tinkering with Twitter: Setting up an API Testing environment with Twitter4J

This is Part Three of a multi-part blog series on putting together a basic API test framework for the Twitter Search API. Care to go back to the beginning? 

The last few posts we covered a lot of ground:

• An overview of the Twitter API, and Twitter4J, which we will be using to access the Twitter API
• How to do Advanced Searches using Twitter
• HTTP Status Codes and Possible Error Codes
• How to generate credentials such as the Consumer Key and Access Token.

For this entry, we will be walking a user through setting up an API development environment with IntelliJ, Java, and Twitter4J.

Thank you, Angie Jones, for your support!

I can't remember how Angie Jones ( @techgirl1908 ) and I first connected two years ago. Did she stumble on my blog first? Or did I drop her a line on Twitter first? No matter.

For the past couple of years, I've been an Angie Jones superfan.


I've been loving how she has put herself out there for the software testing community, giving many unique automation talks that I'd watch on YouTube, and then chat with about them with her on Twitter.

And Angie's been reading this blog, reviewing demo projects I have been doing as I tried to re-learn coding after a ten year absence, always encouraging me to keep up the good work.

Tinkering with Twitter: Getting credentials, consumerKey, accessToken

This is Part Two of a multi-part blog series on putting together a basic API test framework for the Twitter Search API. Care to go back to the beginning? 

In order to be able to programmatically interact with Twitter through their APIs, you need an:

•  OAUTH Consumer Key
• Consumer Secret
• Access Token
• Access Token Secret 

Then, you need to place them in a Twitter4J Properties file.

The file will look something like this: