A Brief History of the Selenium Testing Framework

August 11th, 2016 by Chris Tozzi

Ever wonder where Selenium (the testing framework, not the mineral you get from eating clams) came from? Here’s a short history of the technology, from its origins more than a decade ago as a proprietary tool through the present era of Webdriver.

ThoughtWorks and The Origins of Selenium

Selenium originated in elder days – by which I mean 2004 – as a tool for testing web applications. It was developed by Jason Huggins, a programmer at ThoughtWorks.

That Selenium originated at ThoughtWorks is interesting. While no one in 2004 was talking about Agile infrastructure, ThoughtWorks was the place where Martin Fowler made his career. Fowler went on to become one of the major thought leaders behind the migration to microservices. While Fowler can’t take credit for Selenium, it seems fitting that the tool, which is an important part of automated testing for DevOps-inspired workflows today, originated in the same place from which the Agile infrastructure revolution later emerged.

Open Source Selenium

At first, Selenium was used only internally by ThoughtWorks employees. But that changed by the end of 2004, when the tool was open-sourced.

(more…)

Environment-Agnostic Testing and Test Data Management for End-to-End Test Stability

July 28th, 2016 by Sahas Subramanian

In the Design Patterns for Scalable Test Automation webinar we discussed the importance of adapting proper patterns for the scaling and maintaining of E-E tests. A couple of additional important aspects for End-to-End (E-E) test stability are:

  • Environment-agnostic tests – Tests should be independent, self-contained units, and should run against any environment without code change, and with no dependency on anything else (apart from the runner)
  • Test data – How to prevent tests failing because expected data wasn’t available in the system

In the context of a web app (not legacy, thick-client applications), let’s take a look at how to deal with these challenges.

Environment-agnostic Tests

E-E tests need environment-specific configuration information such as the URL, role, user name, password, etc. Needless to say, hardcoding these parts of the test is not a good practice. It makes updates and maintenance difficult. A better solution would be to tokenize, keep the key/value pair separate and use them as part of the test flow. Different technologies offer different tactics to handle the need. (more…)

Quality Assurance and Software Testing: A Brief History

July 12th, 2016 by Chris Tozzi

Developers have been testing software since they first started building software following World War II. And quality assurance as a whole has a history that stretches back much further than that, of course.

But have you ever wondered how we got from the early days of programming – when developers relied on ad hoc methods for finding bugs in their code – to the modern world of Selenium and cloud-based testing?

Keep reading for a (brief and totally non-exhaustive) history of quality assurance and software testing.

The Origins of Quality Assurance

I could start by describing quality assurance processes in preindustrial societies, long before anyone had ever heard of software. But that would actually require writing a book.

So I’ll just quickly note some things that are probably obvious if you think about them, but that you might take for granted. Before the Industrial Revolution and the advent of modern capitalism, the calculus of quality assurance was a bit different than it is today. Markets were usually monopolized by guilds. Without free market competition, assuring quality wasn’t necessarily important for keeping customers happy. And in the absence of strong governments, attempts by the state to prevent defects in products tended to be rare or ineffectual. (more…)

Headless Browser Testing with CasperJS

June 30th, 2016 by Greg Sypolt

I must admit, the first time I heard about headless browser testing, I had zero knowledge of the technology. As I started to learn more about headless browser testing and compared it with Selenium, it quickly came to my attention that both are different, and both have different objectives. There is no rivalry or battle; both testing frameworks serve a purpose in your delivery chain.

A headless browser is a web browser without a graphical user interface. Headless browsers provide automated control of a web page in an environment similar to popular web browsers, but are executed via a command line interface or using network communication.1)Headless browser – Wikipedia, the free encyclopedia.” 2015. 1 Jun. 2016

Selenium is a portable software testing framework for web applications. Selenium also provides a record/playback tool for authoring tests without learning a test scripting language.2)Selenium (software) – Wikipedia, the free encyclopedia.” 2011. 1 Jun. 2016

Let’s take a closer look at CasperJS (headless browser testing framework) and how we can add another testing layer to our delivery chain. (more…)

References   [ + ]

Catching Bugs Too Late

June 23rd, 2016 by Ashley Hunsberger

Putting quality first is critical. Teams must take ownership of quality, but to do so they have to create an environment that allows them to build quality in, instead of testing it out much further down the road to delivery. Finding bugs late is too costly if you aren’t yet to the point of being able to prevent them (implementing BDD). Ensure you can find them early.

Staying green is hard work!

I’ve seen many things change this year. My daughter began kindergarten. (How did THAT happen so fast?!) I also began blogging, and our department is trying to shift from Waterfall to Agile and Continuous Delivery, with teams shifting to own quality instead of tossing code over to QA… all great changes. But one thing has remained the same. We were still finding bugs late.

I’ve written many times about the importance of quality first. But how did our team take action on that? First, we HAD to have automation. Purely manual testing was just not going to cut it anymore. Don’t get me wrong, I still very much value human-based testing. But frankly, it can catch things too late. So, enter our automated tests. We began with what we called our pre-commit tests. These must be run — you guessed it — before you commit code! Yes, they are slower than unit or integration tests. But they take around 7-8 minutes (allowing time to go grab some coffee, stretch, whatever). They are our most critical features and workflows. Aside from running locally before committing, they are also scheduled and running many times over during the day with all the commits going on. Once we established that set of tests, we began our work on more user acceptance tests – still hero workflows, but trying to keep in mind the fine line between useful UI tests and too many tests (think of the testing pyramid). (more…)

Patterns and Coding Practices for Stable End-to-End GUI Tests

June 16th, 2016 by Sahas Subramanian

We all know the importance of the Test Automation Pyramid and why it makes sense to align various automations in this way. Given that guiding principle, end-to-end GUI tests sit at the top, with a considerably small number of tests compared to other types (Unit, Integration, Service tests), and they are useful to verify business workflows. In the book Agile Testing: A Practical Guide for Testers and Agile Teams, the authors explain the testing quadrants, the GUI tests’ fit in the grand scheme of things, how to rationalize intention, and be smart about overall Quality strategy.

sahas_fig1

http://www.exampler.com/old-blog/2003/08/21/#agile-testing-project-1

The intention of the E-E GUI tests is to verify “whether we build the right thing from the business perspective.”

(more…)

Accelerate Multi-browser Testing Using Sauce Labs and Webdriver.io

June 7th, 2016 by Sahas Subramanian

There are a lot of webdriver-based testing frameworks out there. Webdriver.io is a relatively new cool kid on the block. It has enough to differentiate itself and helps us to focus on creating reliable GUI tests. A few highlights on what this framework comes with:

  1. Out-of-the-box ES 2015 support – leverage all the goodness that ES6/ES2015 offers.
  2. Out-of-the-box promises support – This framework uses Q.js internally, and every single command represents a promise. The second command will be executed only after the first command promise is resolved.
  3. Out-of-the-box Sauce Labs runner service – to run tests on Sauce Labs
  4. Out-of-the-box parallel test runner (wdio) – to run tests across multiple OS/Browser mixes in parallel
  5. A rich set of APIs makes the test code short and concise

 

These advantages help organizations focus on their core responsibility — to automate their verification process quickly instead of developing and maintaining custom libraries to support automation efforts (more productivity — we all love it).

(more…)

The Sauce Journey – Courage, Transparency, Trust

May 25th, 2016 by Joe Alfaro

In my last blog post, I described the first step on our journey from Engineering to DevOps, which was the formation of project-focused SCRUM teams. SCRUM brings many opportunities for improving the development process, but it’s wise to keep in mind the old saying “SCRUM doesn’t fix problems, it points them out.” This means that the very first thing to emerge from SCRUM is transparency, because it requires us to examine how our teams and processes actually function on a day-to-day basis, and through ceremonies like stand ups and retrospectives, we are asked to clarify our goals and purposes to our colleagues, our customers, and ourselves.

The essence of SCRUM ceremonies is communication, and communication leads to transparency. In standups, making a statement about what you plan to do that day, and what is blocking you, provides a simple way to bring transparency about your work to your team. But it also forces you to be introspective, to be clear to yourself about what you are doing, what the blockers and issues are, and what it is that you can accomplish. More than anything else, stand ups are opportunities for reflective communication that surfaces problems at the same that it seeks to resolve them and move the entire team closer to their goal. The same can be said of retrospectives, but here the emphasis shifts from internal to external communication. From the internal perspective, retrospectives are useful for documenting issues and how they were met, and then using that information for iterative improvement. But they are much more important for communicating to customers that we understand where our challenges are, and that we have ways to deal with them. (more…)

Two Approaches to Test Automation Architectures

May 23rd, 2016 by Chris Riley

I’ve yet to see two development environments that are alike. But even if there is no cookie cutter approach to software delivery, there are standard approaches, and methodologies that are consistent throughout modern software development and that frame nearly all environments.

Because there is a big move in software testing to go from purely manual testing (a non-technical process) to a fully automated deeply technical one, how QA processes are set up, and how it fits into the overall delivery chain is very important. Let’s take a look at the two most common architectures for test automation, and why they may or may not be the best approach. (more…)

Why is Manual QA Still So Prevalent?

April 28th, 2016 by Joe Nolan

This past week I casually heard comments alluding to the imminent death of the QA Analyst or Manual Tester. (To be clear, I am not referring to the QA Automation Engineer, who builds test automation.)

Not only does the function not seem to be going away, recruiters are still out their hunting testers down. Out of curiosity I did my own review of randomly selected job posts from Monster and Indeed for average QA positions, and discovered that there are still a lot of jobs available for manual testers.

With the importance of catching bugs early, and the ability to automate all testing, why do companies and projects resist the investment in CI and test automation? I will explore the reasons why now, and whether the resistance is good or bad. (more…)