The information for this blog post was taken from the content of a Git Basics training at EG’s 2020 QA Retreat. The purpose of this training was to provide a baseline for Automated Test Developers. Often times, automated testers find ourselves performing only a few Git commands. On some projects, we may clone the main project repository but make few commits. On other projects, we may have separate repositories for automated testing code and may be the only user, versus working on a… [continue]
Containerization Fundamentals
Imagine: You are joining a team developing an application as a [test automation engineer|business analyst|developer]. There is a Dev, Stage and Production environment for the application (and the several other applications it integrates with). Dev is very unstable, constantly down and bloated with testing data. Something breaks and an investigation is required to determine if it was bad data, a new code change, or some external dependency. Or worse, nothing happens at all, and Dev just stays broken until the… [continue]
Training and Professional Development: Caring for and Feeding our People
Over the last 20+ years, I have attended several training sessions and conferences. Some have been good, and some have been fairly poor. In conversations with a few other EG folks, we were trying to boil it all down to determine what makes for a good training or conference. Why do we put forth the effort? What are we trying to accomplish? When a company commits to the level of investment in its people that continuing education requires, it should… [continue]
Simplify Selenium Selectors
Failing to prepare is preparing to fail. – John Wooden Writing strong automated tests comes down to preparation. (I never thought I would be drawing connections between sports and automated tests, yet here I am.) Putting in the hard work up front pays off immensely on the back end. With a solid Page Model architecture in place, writing the actual testing scripts becomes much easier. Getting to that point can be difficult but Gregg Reed’s current sequence of posts for… [continue]
Selenium Java: An Intelligent Example Part 3
In our previous post, Selenium Java: An Intelligent Example Part 2, we dug into the code. We demonstrated how everything is tied together. We outlined the BasePage, WebDriverResource, and BrowserFactory classes. In this post we will be digging into the concrete page objects themselves as well as writing a sample test that uses multiple page objects. Concrete Page Class Each concrete page class extends BasePage. Doing so provides them with everything they need to be a page object. Each web… [continue]
Selenium Java: An Intelligent Example Part 2
In our previous post, Selenium Java: An Intelligent Example Part 1, we described how to manage Technical Debt and the importance of using a Page Model. We also gave an overview of the classes used in this example project. In this post, we will be getting into the code. We will demonstrate how everything ties together and how you could build a similar project to test your application. BasePage The BasePage class is at the center of it all. It… [continue]
Selenium Java: An Intelligent Example Part 1
In our introductory post, A Survey of the Automated Testing Landscape, we defined the problems we often find in automated testing. In this series, we will walk through an intelligent example of a Selenium test project that uses common design patterns and object oriented principles to help solve the problem of Technical Debt. This is not to say that this example is the perfect solution that will solve all of your problems. Remember from the introductory post that unicorns do… [continue]
A Survey of the Automated Testing Landscape
The tools available in test automation these days are pretty amazing. The options are getting a little overwhelming. You could choose to pay for an expensive product that would make a lot of decisions for you, or you could go old-school and write everything yourself. Many companies choose to buy expensive products, because they think that will give them an advantage. They may feel that designing their automated testing environment from scratch is not feasible. Their developers are busy with… [continue]