Engineering Quality – Asking the Right Questions at the Right Time 
Chris Hetzler
Senior Solution Architect
Appolis

Introduction:

In the modern area of software engineering, QA resources must view themselves as software engineers. And as engineers, they need to ask the right questions at the right times in order to maintain the quality of their delivered products. Many organizations currently have QA resources that are “domain experts” but are not necessarily technical experts and would like to steer these “domain experts” into more of a technical testing type of role.

Learning Objectives:

This presentation outlines several questions that must be asked by QA resources during the various phases of the SDLC. The reasons for asking these questions are also given along with some suggested follow up responses. By using these questions as a starting point for the transition to a more technical role a QA resource can ease a transition that can be difficult or impossible at times.

Outline:

  • Introduction
    • We are in an Engineering age for software
    • Quality can be engineered
    • QA personnel are engineers and need to think like them
    • Question everything
    • How to target your questions
  • The Early Phases (Requirements and Design)
    • Requirements
      • Who is the customer ...
      • What happens if ...
      • What happens when ...
      • What should happen if ...
      • What should happen when ...
      • What are the consequences to QA of this ...
    • Design
      • Does A affect B ...
      • Can A affect B ...
      • Should A effect B ...
      • Could A effect B ...
      • And what about C ...
      • Are requirements questions answered ...
      • What are the consequences to QA of this ...
  • The Working Phases (Implementation and Testing)
    • Implementation
      • Where are A and B ...
      • How are A and B built ...
      • How do A and B communicate ...
      • Does the implementation environment work for QA ...
      • Are design questions answered by the implementation ...
      • What are the consequences to QA of this ...
    • Testing
      • What happens when ...
      • What happens if ...
      • Why do these things happen ...
      • Are these things supposed to happen ...
      • Are the testing and development environments the same ...
      • Are all of the implementation questions answered ...
  • The Ending Phases (Release and Maintenance)
    • Release
      • What are the only things that happen ...
      • Are these things documented correctly ...
      • What are the acceptable risks with this ...
      • Are we satisfied ...
      • What is missing ...
      • Are all of the testing questions answered ...
    • Maintenance
      • Why can't this happen when ...
      • Why can't this happen if ...
      • Are customers satisfied ...
      • What do customers want next ...
      • What do customers need next ...
      • What do we want next ...
      • Were all of the release questions answered ...
  • Conclusion
    • Engineers tend to learn by doing and observing
    • Take these with you and use them with other QA resources
    • You can level the playing field with development quickly
    • The most non-technical people can achieve a level of technicality using these techniques that will allow them to communicate with other engineers on an engineering level

Biography:

Chris Heltzer's experience include the following:

  • Lead tester for the Microsoft Dynamics GP 9.0 web services release and was tasked with creating the entire test strategy for the project.
  • Lead developer for the Microsoft Dynamics GP 10.0 web service release.
  • Tester at Microsoft in the Dynamics division for 3 years and developer in the same division for 1 year.
  • Currently working at Intuit as senior Quality Engineer leading the effort to architect a new quality strategy for the processing of payroll
  • Master of Science, Software Engineering, NDSU
  • Bachelor of Science, Computer Science, NDSU
  • MCSD
  • MCAD