Brian Jordan, Automated Testing for the Non (and FUTURE!) Coder: Notes from his talk with the Ministry of Testing - Boston

Do you have a cool software testing technique that you would like to share with an appreciative audience? Have you been working with a new automation tool, and want to share your thoughts about it? Come give a talk to the Ministry of Testing - Boston! We meet twice a month all around Cambridge and Boston, Massachusetts.

How can you become a speaker for our group? Just ask!

On Tuesday, May 2nd, Brian Jordan, formerly from Code.Org talked about techniques used to test the lesson plans he was generating to allow kids from Kindergarten to Sixth Grade to learn how to code.

Thank you, Moshe Milman, the COO of Applitools for sponsoring that night's food and beverage! I still need to confirm the location for your talk to us in two weeks.

And thank you so much, Tomer from iZotope for letting our group crash at your place once again! If it wasn't for you, we wouldn't have a Meetup!

About Code.Org

"Code.org® is a non-profit dedicated to expanding access to computer science, and increasing participation by women and underrepresented minorities. Our vision is that every student in every school should have the opportunity to learn computer science, just like biology, chemistry or algebra. Code.org organizes the annual Hour of Code campaign which has engaged 10% of all students in the world, and provides the leading curriculum for K-12 computer science in the largest school districts in the United States". - About Code.Org

About the Event

6:00 pm to 6:30: Meet and Greet

The first half-hour of every Ministry of Testing - Boston Meetup is a meet-and-greet, where members can meet fellow software testers where we can talk about our favorite testing techniques, and network with others to see if there are job openings.

iZotope provides a quite spacious lunchroom + presentation space!

Normally when meeting at iZotope, members pick something up from Landmark Plaza in Kendall Square. This time, Brian, our speaker, asked around to see if anyone wanted to sponsor our event. Thank you, Applitools!

6:00 pm to 7:00 pm: The Main Event

Brian Jordan, in his talk Automation Testing for the Non (and future) coder, expanded upon an earlier article he had written, Robo-Testing your Website Without Writing Code:

"In this post you will learn why it’s often worth automating your otherwise manual dev/production build verification tests, how to choose between 'little to no code' and 'code-heavy' options, and—for 'codeless' tests—what services are worth taking a look at & why". 

Like in his article, Brian went over software testing tools such as Testium, Ghost Inspector -- and of course Applitools Eyes! -- giving demos of each.

By the way, Brian is no longer with Code.org. He is now a game developer. See, Clone Drone at the Danger Zone!

Automated Testing for the Non (and FUTURE!) Coder - Brian Jordan from Brian Jordan

Brian's Testing Journey

Brian shared with us his testing journey. He wasn't a QA Engineer... he was Software engineer, learning as he went. When he started on this quest to create games to teach kids how to code, he started with no tests and had to build them as he went.

When Code.org started Brian was working on putting together a K-12 curriculum. A Non-profit. The classes can be Open source. Why? "Every student should have the opportunity to learn".

Back in 2013 - 2014 when he started the project, "testing" involved a Bug bash: Everyone banging on the site at once. Testing, he knew, was important:

• Dealing with kids, things will break in interesting ways.
• If there is a bug in the lesson, you just blocked a whole lesson plan.
• It also needed to work with IE9. Odd windows firewall settings.

A Most Curious Bug

Someone had built a lesson plan, a course based on Minecraft. It seemed to work fine in testing, but when it was shipped to a school. it would operate fine for a few minutes, and then shut down. They would start up the program. The browser would shut down. Any browser. Every browser! The browser would shut down.

Brian had an idea: “Could you go do Minecraft.net?” The teacher opened up a browser, and a few minutes after the game loaded up, the browser shut down. Software operating in the background mistook the course for Minecraft.

How Did They Set Up Tests?

Brian talked about how he uses a behavior driven design style (bdd) for the tests.

List tests as Scenarios. How should the software behave?

We've covered a lot about BDD in this blog.

How He Originally Wrote Tests: Cucumber using Ruby, mapping out every scenario and how it should behave.
Continuous integration solution: Circle CI


During their journey they moved:

• From no automation
• To test automation 
• To interactive service test automation.

Non-code based automation

Who does it work best for?

• Startup founders, projects that are getting big.
• Infrequently changed pages, such as test maintenance.

Testing Tools Covered

• Testium
• Ghost Inspector 
• Applitools Eyes

Testim: You can point and click to set up your tests, write simple loops, and it will automate your app.

The good thing is that it can also run locally on your machine. If you are a developer, you want to make sure that you can test out your code on your local machine.

Applitools

With Applitools:

• If a button disappears or moves, you get a record of it.
• Wider margins suddenly appear? Got it. 
• Duplicate buttons. Mysterious scroll bars appearing? Screens are captured.

Thank you so much, Brian, for coming to talk to our group!

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