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.
It doesn’t have to be this way, though. Tools below the GUI have come a long way in recent years. There are endless javascript libraries available for automated checking of javascript. With more teams adopting APIs, there has been an increase in tools available for doing automated API checking. There has also been huge advancements in visual checking tools, which teams can also take advantage of.
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 ObjectivesAttendees 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.
Cross-functional teams with a tester embedded into a small agile team is a popular and on-trend approach to distributing the testing effort across software development. Ebay, Google, Microsoft are some of the more well-known names to have adopted this approach.
How does test management fit into this? Does it even have a place in organisations wanting flatter hierarchical models? Should all testers report to delivery leads?
At Tyro Payments, we’ve built a team from 5 to 23 testers in one year. The emphasis has been on training and coaching so each tester is the expert within their team able to continuously improve the testing process. However, as we grew, the approach had to be constantly revised. We experimented with many ideas, pivoted a few times and constantly evolved our ideas about what it meant to lead testing in a high growth organisation.
This keynote will describe that journey ending with some thoughts on test management and how it might fit (or not) into a future where the only certainty we have is that testing will look very different to what we do today.
Join us for a cocktail, hors d’ oeuvre, and socializing.
If I wake you up in the middle of the night, are you able to tell me, as a good tester, what risks are still applicable in your system under test? And what impact these risks can have when this software goes to production? Although I never had to wake my testers up, in many cases they couln't answer the question! In my opinion: covering risks is underestimated because we don't like the subject: it is too abstract, sometimes too philosophical or negative. While on the other hand if we have to deal with problems in production because we underestimated risks, fingers are pointed at those who were able to cover the risks (such as testers). Dealing with riks determines the success of a product and therefore the success of a organization. I will look how organizations should be organized to get the maximum commitment of their empoyees and if this is the case: motivated testers who feel free to communicate about risks. Nowadays I am working in an organization using the agile/scrum approach and my role changed from test manager to test facilitator. This doesn't mean that the focus on risks disappeared. On the contrary: I see a lot of risks at the integration level of systems that are not recognized and not covered because no scrum team feeds responsible. Therefor I like to discuss the following question: 'how to communicate with the focus on risks?". This should be a focus point in the communication between testers, developers, analysts and stakeholders. I will look at 2 kind of risks I see: product risks and project/process risks. After this elaboration I like to discuss how to communicate effectively as testers in a scrum team and as a test facilitator on risks without being sees as the guy who is constantly looking at the dark sight. So how can we improve communcation within and amount scrum teams and with an implementation manager responsible for a release with risks as important subject? I will use my current assignment as the experience report for the discussion.
Take aways:
Do you know the meaning of your organization, system, product?
Can you deliver the important risks right away?
How can you communicate about the (process and product) risks your dealing with?
Have something to say? Want to stand on your soapbox? Do a lightning talk! A lightning talk is five minutes or less, no slides, just you and the audience. Sign up information will be available at the registration desk.
Some days it appears as if the entire software world is deciding to “go agile”, usually without tester input. To those uninvolved in the decision agile becomes simply a moniker for change and as a result of this testers often view the approaching transition with trepidation, if not abject horror.
In this session, Mike Hrycyk will explore 17 reasons why agile makes a tester’s project, success factors, even life, better. From the pragmatic to the humorous, Mike will familiarize and humanize agile, relating it to what we already know and are comfortable with to help demonstrate that the change agile brings is really just a refocusing on what we already know works.
Some of the reasons include: Test involvement in early requirements discussions isn’t by chance anymore it’s a necessity; with two week sprints, Test can’t receive builds more than 10 days late; and of course – agile meeting toys.
