• Skip to main content
  • Skip to header right navigation
  • Skip to site footer
  • Docs
  • Support
  • Account
Pongos Interactive

Pongos Interactive

Websites and Mobile Apps That Work

  • About Us
  • What We Do
    • Small Business Website Packages
    • WordPress Website Maintenance
    • WordPress Website Audit
    • Custom Software & Plugins
    • GYBO Academy
    • Pongos Learning Lab
  • Our Work
  • Testimonials
  • Blog
  • Contact Us

Testing with Your Users in Mind

Home / Software Testing / Testing with Your Users in Mind
December 1, 2013 by Chrissy Rey

Editor’s note: Randy Sandberg is Pongos Interactive’s Chief User Advocate, and heads up our testing department.
>>>>>>
“Fundamentally you can’t do your own QA, it’s a question of seeing you own blind spots.” ~ Ron Avitzur

If you look carefully at the quote above you’ll find a typo. The point being that programmers are not best suited to find their own bugs. Just like writers rely on editors to catch their “bugs”, programmers use testers for the same purpose. That is, it takes a combination of highly skilled programmers and testers to create a quality software product.

Within the development community, it’s a well known fact—given today’s complex software—one cannot test every aspect of a project. Typical budgetary and timeline constraints only enhance this fact. Thus testers, with the help of other stakeholders, decide where to focus their efforts. This is called managing risks. That is, a decision not to test something saves time and money but increases the risk of bugs getting released into the wild.

How does one decide what to test and more importantly what not to test? The exact formula is beyond the scope of this article, but with your users in mind, three questions should be answered. First, what devices/operating systems/browsers do the majority of your visitors use? Second, what current features are popular and what upcoming features have your users most requested? And finally, if a particular feature were to break, what would the impact be on your users and your organization?

These questions help form a “Do Not Break” list of devices, operating systems, browsers, and features to focus limited testing efforts on. Once a plan of action has been made, and testers know what to do via test cases, then the process goes something like this:

1. Tester finds a bug and writes a problem report. The report includes a descriptive title, what the tester expected to happen, what actually happened, detailed steps to recreate the bug, and any other noteworthy information including screenshots and videos.
2. Programmer reproduces the bug, attempts to fix the bug, and then sends the problem report back to the tester for regression testing. Regression testing helps show the bug was fixed without introducing any new bugs.
3. Tester repeats the original steps and, if the bug can no longer be reproduced, closes the bug. Otherwise the tester sends the report back to the programmer for further investigation.

Testing with your users in mind not only saves time and money during the project, but ultimately pays off over the long term as well given less support issues and increased user appreciation as well as engagement. Oh, and as for the typo mentioned earlier, here’s how the quote should look: “Fundamentally you can’t do your own QA, it’s a question of seeing your own blind spots.”

Category: Software Testing
Busy on the computer

Want to work with us?

We would love to hear from you.

Get Started

Quick Links

  • Home
  • Documentation
  • Support
  • Contact Us
  • My Account

Services

  • Small Biz Websites
  • Custom Software
  • GYBO Academy
  • Learning Lab

Connect

  • Facebook
  • Twitter
  • LinkedIn
  • YouTube

Pongos Interactive · 2141 Priest Bridge Drive, Suite 8, Crofton, MD 21114 · (410) 774-9003
Copyright © 2023 · Pongos Interactive · All Rights Reserved