DZone
Performance Zone
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
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Performance Zone > Testing Even Before a Line of Code Is Written: Is It Possible?

Testing Even Before a Line of Code Is Written: Is It Possible?

In this article, follow an interview explaining why testing should apply across the entire software development lifecycle.

David Brown user avatar by
David Brown
CORE ·
Aug. 04, 22 · Performance Zone · Interview
Like (1)
Save
Tweet
2.66K Views

Join the DZone community and get the full member experience.

Join For Free

Testing is often viewed as a necessary evil in software development, in order to ensure the quality of applications. Most commonly, however, testing occurs after the coding process has been completed.

However, according to the Ministry of Testing’s OpsBoss and author of Testing of Web APIs Mark Winteringham, testing should apply across the entire software development lifecycle. In his book, he even wrote that testing should be done “even before a line of code is written.”

How Is That Possible?

Mark says this comes from a process of questioning the purpose of a piece of code that is “sitting down with your team as you are designing your content...working out what sort of solutions you're going to come up with… and questioning the problem as well.”

He shares: “Understanding what the problem is, trying to make sure everyone's on the same page, that there's no misconceptions makes the approach a lot more fluid,” adding that testing before a line of code is written is about questioning ideas and problems to get everyone on the same page from the start.

He says that this is also inspired by Janet Gregory and Lisa Crispin’s “Whole Team” approach.

Winteringham further shared a good strategy model to bring IT teams and stakeholders together during API development, the idea of exploratory testing and automation during an episode of Coding over Cocktails, a podcast by Toro Cloud. You can view the full interview on YouTube below.

Quality and Risk

During the episode, Winteringham explained how quality and risk are two sides of the same coin when it comes to testing.

“Traditionally, like when we talk about testing, it tends to sort of get stuck in this older thinking of it's just confirming requirements, it's confirming expectations. So, it's taking what has been explicitly stated, whether that's a big requirement, document or a user story, and turning that into some test cases, test scripts and just running those,” he describes.

However, he says that we need to make sure that “the actual testing that we’re doing is targeted,” especially since teams are now being asked to deliver faster.

“That's where the quality and risk aspects come in within strategy. My focus is thinking about what quality matters and getting everyone else to think about what quality matters to our end users. Like, what do they care about? How do they define quality to themselves? And then use that as the sort of launching point for where I'm gonna focus my testing because I can't test everything. So, I want to be effective and I want to be laser-focused on the things that matter the most,” says Winteringham.

Thus, we can set the concept of “quality and risk” as the north star of our testing strategy, and plan around them.

But how do we capture or map risks in order to improve the quality of our software?

Capturing Risk With Exploratory Testing

This is where exploratory testing comes to mind, and Winteringham explains how the exploratory testing space is basically the use of “charters.”

“Charters are ways of capturing risk, but writing it in a way that's an invitation to explore…how I track risk is in the testing activities I do and the plans that I set around that. Historically we have risk registers, but they tend to sit separate from strategies. It'd be lovely to see something in the future where we can actually see quite clearly what risks we're concerned about and what things they are tied to,” he expounds.

You can learn more about testing, and listen to more of the world’s leading experts on architecture, design, and the technologies that facilitate digital transformation on the Coding over Cocktails podcast below.

Coding Over Cocktails · Testing Web APIs with Mark Winteringham
Exploratory testing IT

Published at DZone with permission of David Brown. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Replace your Scripts with Gradle Tasks
  • How Do You Know If a Graph Database Solves the Problem?
  • The Ultimate Software Engineering Job Search Guide
  • Build a Java Microservice With AuraDB Free

Comments

Performance Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • 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:

DZone.com is powered by 

AnswerHub logo