Testing is not an isolated activity. It interacts with and influences other disciplines in software development such as design, coding, release management, and deployment. As testers, our skills and experiences add value far beyond the immediate context of verifying functionality. Threats to value other than software errors exist.
Yet our discussions are often constrained to the testing space, omitting the connections to, and dependencies on, other roles and activities. Testing is an integral discipline of software development, and often plays an active and important role in bridging gaps between technical and business-focused roles, between leaders and engineers, and between makers and users.
How does the testing piece fit into the software development puzzle? How does – and how should – testing interact with other disciplines in software development? How can we most effectively add value to the software development projects we participate in?
Please join us for our 11th annual conference at the Simon Fraser University Harbour Centre campus in downtown Vancouver, Canada, August 8-10 2016.
IMPORTANT NOTE: Creating a profile on this site does not constitute registering to attend the conference. If you would like to attend and have not yet registered, please Learn More »
The testing community is fixated on Automated GUI Checking.
The majority of automators are opting for Selenium WebDriver. Selenium is a fantastic project, and WebDriver has a superb API. If I was wanting to automate user journeys in the browser, I would turn to WebDriver. Unfortunately, WebDriver seems to be the default tool for a lot of (if not all) the automated checking teams do, regardless of context, and what it is they are actually trying to check.
This can be problematic for multiple reasons. Primarily, these checks tend to be slow and brittle (this of course depends on the skill level of the person creating them). Another is that by nature of them being at the browser level, you almost always end up checking a lot more than what you intend to. They’re not focused and targeted on a specific piece of functionality or behaviour.
In this technical hands-on tutorial, Richard and Mark will introduce attendees to these new tools/frameworks. We will work as one big automation team to move existing GUI WebDriver checks further down or up the stack. After examining what the original intention of the check was, and now having more exposure to new tools, could we rewrite them at a different level in the stack? Then, reflecting on the impact this has had to our automated checking, including whether the checks are more targeted or faster than before.
The experiential aspect of this tutorial is that it’s up to you (the attendees) where we decide checks move to, if they move at all. We will be working as one big team, so there will be lots of lots of discussion and learning from peers. If you’re interested in advancing your automated checking, come along.Learning Objectives
Attendees in this workshop will get exposure to many new frameworks, tools and libraries. They will learn that these new tools aren’t any more difficult than WebDriver. The will also see that working with WebDriver all this time has armed them with a lot more programming skill then they may have realised. Which in turn can really help them improve their automated checking tools, which in turn could improve the team approach to testing, improve quality and really help the business.
Attendees will be tasked with reviewing an existing suite of automated checks, attempting to understand what they original purpose was, a useful skill when moving to a new team or trying to improve existing checks. They will be given hint and tips on how to do this. They will partake in multiple discussions with attendees and experts from the field.