DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. Deployment
  4. Building a Test Automation Strategy

Building a Test Automation Strategy

During the Q&A portion of a recent webinar, the presenters realized that these aspects of introducing test automation are well known, but not well understood.

Chris Riley user avatar by
Chris Riley
·
Sep. 08, 16 · Interview
Like (1)
Save
Tweet
Share
3.44K Views

Join the DZone community and get the full member experience.

Join For Free

Ashley Hunsberger, Greg Sypolt and Chris Riley contributed to this post.

Bringing test automation into your organization is not as easy as writing and running a Selenium script. It involves first getting buy-in, building a team, establishing a strategy, and picking the right tools. During the Q&A portion of a recent webinar hosted by Chris Riley, Ashley Hunsberger, and Greg Sypolt, the presenters realized that these aspects of introducing test automation are well known, but not well understood. In our first post of the series we discussed getting buy-in. Below, in the second post, we discuss how to build a test automation strategy.

Getting started with test automation is easy. If you have a technically minded QA team, you can usually create your test script, sign up for a test cloud, and run the script in just a few hours. But keeping a test automation environment going for the long term is not as easy as any of us would like to believe. QA teams are generally better at building strategy than any other. And when it comes time to build a test automation environment, strategy is a key first element to both getting started and keeping it going.

When building a strategy, you have to address how the environment works, how the tests are run, how the test suite is maintained, the process of running tests, the design patterns of the test scripts, and more. Let’s look at questions from the webinar to address some ways to approach your test automation strategy.

Would you define what “traditional QA” is and what QA “was”?

Ashley: When I say traditional QA, I’m referring to waterfall. Teams got their requirements, engineers did their work, QA went off and did theirs, but couldn’t really do anything until dev was ‘complete’—and I use that term loosely. Devs wouldn’t know there was a bug in their code until sometimes weeks or months later because of testing cycles.

Greg: Traditional processes are designed for getting requirements, and developers and QA work in their silos. There is rarely any communication between developers and QA during the sprint. At the end of the sprint, developers will throw finished code over the wall at QA. This approach doesn’t allow for collaboration, and it leads to slow feedback, and no iterations during the sprint. Iterations are a key element to modern dev.

blog post

Can you define a list of essential skills every modern QA team member should have?(This blog post expands on this topic.)

Ashley: I still maintain that a QA mindset, whether via automation or not, is incredibly valuable in determining a holistic test strategy. You always need to be able to consider the end user, how the system works at a broader level than your team’s feature du jour, and what other types of testing to consider (not just automated tests, but accessibility, localization, performance, usability, security, exploratory). The key is how to incorporate that into your sprint and really push to the definition of done.

Greg: For us, it’s not a choice. We do not have dedicated DevOps resources as a Platform as a Solution (PaaS), so we are experimenting with the modern QA team member that can have both QA and DevOps responsibilities. QA is the gatekeeper of quality and it makes sense they maintain and champion the continuous integration tooling.

How do we write more tests faster?

Greg: Why do you need to write more tests? Everyone shares responsibility and follows DoD. Focus on building the right types of tests. It’s more about building a testing portfolio that identifies the areas of the application that would be a showstopper for end users, or that affect how your application makes money (at Gannett || USA Today, network ads testing is critical).

Ashley: I completely agree with Greg. Make sure you are writing the right tests instead of writing something just because you can. At Blackboard, we identify the most critical features and workflows and automate those, with as much unit and integration testing as possible, and some UI integration tests for our showstopper workflows.

Many times I feel like the DevOps Infrastructure problems have to be solved before I can do test automation. Is that true?

QA, Dev, and DevOps should share this task. It isn’t necessary for local development, but when it comes to scale and Continuous Integration (CI), it must be done up front (infrastructure first, not infrastructure last).

Greg: Read this post regarding the shared responsibilities. The team shares responsibilities for DevOps tasks. No one has been a champion for DevOps tasks. The modern QA position has become a technical role, the gatekeeper of quality, and may take on more DevOps responsibilities and tasks.

Ashley: Every company is different. At ours, QA does work closely with our DevOps team more and more as we transition to a modern delivery chain. We definitely still have our kinks, but we are still doing test automation. We are still working to be in the CI pipeline, but it doesn’t prohibit meaningful tests.

There is no question that QA is evolving. More tech, more strategy. But this is a fantastic opportunity for QA to become a first-class citizen. Given QA teams’ holistic view of the entire delivery chain (compared to IT Ops and developers consistently in the weeds), QA is best suited to build a strategy with DevOps to modernize development operations.

Testing Test automation Question answering Continuous Integration/Deployment

Published at DZone with permission of Chris Riley. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • A Simple Union Between .NET Core and Python
  • Connecting Your Devs' Work to the Business
  • Top 12 Technical Skills Every Software Tester Must Have
  • Too Many Tools? Streamline Your Stack With AIOps

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: