Justify for QA/QC

JUnit Testing

Duration

This class is a three-hour instructor-led synchronous online training session for Quality Assurance/Quality Control analysts.

Executive Summary

This class provides answers to fundamental questions that should be asked by every QA/QC professional:

  • When in the project life-cycle should a QA/QC professional engage with a team?
  • Has a shared understanding of project status  reporting criteria been established long before QA/QC testing begins?
  • Isn’t JUnit testing a Developer’s responsibility?
  • Why should a QA/QC Agile team member understand the mechanics of JUnit test execution?
  • If I learn about JUnit metrics reporting, how does that knowledge prepare me to enhance team effectiveness?

Prerequisites

  • Prior familiarity with Java and Eclipse is helpful, but not required
  • Installation and configuration of the required components, using the QuickStart guide
  • Verification of configuration by having all JUnit tests run successfully (“green”)

Topics

  • The QA/QC role on an Agile Team
    • Goals and challenges
    • Team “balance”
  • Eclipse IDE basics
    • Perspectives and views
    • Errors and warnings
  • JUnit 4 Test Lifecycle
    • The JUnit view in Eclipse
    • Errors vs. failures
  • Using EclEmma to generate code coverage metrics
    • Reading and analysing code coverage metrics
    • What is an “element?”
    • What is an “instruction?”
    • What are “total instructions?”
    • What are “covered instructions?”
    • What are “missed instructions?”
    • What is “coverage?” 
  • Why code coverage matters
    • What is “low” code coverage?
    • The case against code coverage as a quality indicator
    • The case for code coverage as a responsibility indicator
  • Red-Green-Refactor
    • What is “duplicate code?”
    • What is “coverage efficiency?”
  • JUnit Strategy for Testing (JUST)
    • From TDD to JUST
    • What is the difference between a Mock and a Functionally Equivalent Service?
    • Justify features
  • Team role cohesion 
    • Developer expectations
    • Blended responsibilities
    • Observations of high-performance teams