Subscribe: FrazzledDad
Added By: Feedage Forager Feedage Grade B rated
Language: English
custom  execution  record playback  starting  test execution  test  things  time  tool  tools  toolset  webdriver  you’ll  you’re   
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: FrazzledDad


Bleary-eyed ruminations of a work at home Father.

Updated: 2017-01-17T08:41:54.964-05:00


Speaking on Leadership at KalamazooX Conference


I’ve been asked this question enough times over the years I thought I’d (finally!) write up a quick post to point folks in the right directions for getting started. What are the best practices for getting started with WebDriver (or some other User Interface functional automation tool)? So first off, forget “best practices.” There ain’t no such a thing. There are guidelines and lessons learned you need to adapt to your own situation. With that in mind, here are some of my thoughts and references you should consider as starting points for your own journey. Whatever you do, do not jump straight into throwing code or tooling around in order to try and solve some poorly understood problem! Invest some time thinking, planning, and experimenting. You’ll be much happier with the end result. (Ask me how I know…) Clearly Define The Problem You’re Trying to Solve Why do you want to move to WebDriver or some other nifty UI functional test tool? Get together with your entire team (which includes support, product owners, stakeholders, etc.) and talk about the “why?” behind your thinking. Look above the “simple” technical issues to larger process and business problems. Some of those responses might include: We’re seeing a huge spike in support tickets due to unclear functionality or outright defects after every major release We’re missing ship dates due to the time needed for regression testing Work items slip in to following iterations due to time for testing… and the corollary: Testers get work items only a day or two before the iteration finishes Regression defects get found a week or two after the root cause We’re not building what I (the stakeholder/PO) wanted There aren’t necessarily wrong answers or items for this list. Just make sure you understand the problem you’re trying to solve—and you may find different ones to solve after these discussions! Choose a Tool That Works for Your Team and Situation WebDriver is a wonderful tool that I love and use all the time. However, it’s one of many tools that might solve the job for you. Consider the things you identified above, then have a look at all potential solution toolsets. Do you want a plain English/Domain Specific Language toolset that helps you clarify specifications and behaviors? Do you want a record and playback tool that will help you get a starting point built quickly? (Dismissive of record and playback? They used to suck. They’ve grown up. A lot. Have a look and be open-minded.) Do you want to just write thin wrappers around WebDriver and roll forward? All these are considerations you need to take in mind. Go read Elisabeth Hendrickson’s wonderful blogpost from 2011 “Selecting test automation tools.” Her post is still one of the best I’ve ever read on going through the selection process. You’ll need to update the list of actual frameworks, drivers, and tools, but still… Plan Your Approach Once you’ve selected your toolset, spend some time laying out your initial approach for your UI tests. Spend time working with your toolset to understand how it handles things like representing pages/views/etc. Figure out where you can tie in calls to your own custom code for doing things like test setup, invoking heuristics/oracles, environment configuration, etc. Get clear on how the toolset works and what a test execution lifecycle looks like. For example, let’s say you’re using Cucumber and WebDriver on the Java stack. You’ll also need some form of test execution framework like TestNG, JUnit, etc. In these cases JUnit (or TestNG) is generally the starting point for any test execution. Details vary, but JUnit likely starts a single test that calls out to the Cucumber runner. Your Cucumber step definitions make WebDriver statements that manipulate a browser while referencing your own custom page objects for details on each page/view/etc. Those step definitions may also invoke your own custom framework to create data, validate database conditions, and tear down test structures. Understanding this l[...]