The Good Bug

Developers ... There is such a thing, let me explain!

Dear Devs,

When a Quality Assurance Analyst / Engineer / Tester is tasked with testing your app / site, our objective is two-fold: we look to ensure it does what its supposed to do (functionality, performance, esthetics, etc.) and what its not (ie, crash, UI fail, etc.) to do.

Once in a while, by chance, skill, luck, or imagination, a defect will be reported that is equal parts exciting and educational.

The a-ha bug!

The excitement of the "a-ha bug" comes from the idea that it makes the project (app / site) better. It is the kind of issue one tester was insightful to find when everyone else overlooked it. It moves up the chain to the Project Manager and invites a conversation with the Client as to the best course of action.

I was recently on a project where a Tester found a really great issue for an iOS app. It was the kind of issue that was creative in its method educational in its resolution. We were to go back to the Client to ask as to best way to solve this.

 

The money bug!

Not so much a bug as it is an opportunity found by a weakness uncovered. This is the kind of defect that presents a chance for expansion, scaling, or otherwise improvement; the "low-hanging fruit" find that are Sale People's best friends.

The good bug!

The good bug is the bug that causes an epic fail by happen-stance and creative testing. Any Analyst / Tester / Engineer that finds these kinds of bugs ought to get a raise. These are the sneaky issues that somehow make their way to production.

Conclusion

Devs, know we QA people take great pride in making (and breaking) your app / site, but know that in the end, its for the best. The issues we write up are not to overwhelm you but when a good bug comes along that provides a lesson learned, take it as a sign of better things to come ... sort of.

QA Tool: QA Test Plan WBS

Applying Project Management fundamentals to Quality Assurance

Hey all,

I was responding to a comment posted on LinkedIn when I found myself writing up a neat little work breakdown structure for writing up a test plan .. thought I'd share:

1.0 - Objective

   1.1 - Define testing agenda and purpose of document
           1.1.1 - Get Project Charter
           1.1.2 - Get S.O.W

2.0 - Testing Scope

   2.1 - Establish what is to be tested
          2.1.1 - Get Testing Requirements from PM / Devs
          2.1.2 - Get Testing Bounds (what won't be tested / out of scope)

   2.2 - Determine level of effort for test tasks
           2.2.1 - Test Types and Duration
           2.2.2 - Test Task Dependencies & Schedule (when to start a new cycle)

3.0 - Personnel

   3.1 - Who are the Client and Stakeholders involved
           3.1.1 - Get names from PM

   3.2 - Who are the other members on the team (PM / Devs / BA / QA / etc.)
           3.2.1 - Have Kick-off Meeting
           3.2.2 - Get Names, Roles & Responsibilities

4.0 - Hardware / Software

    4.1 - What Hardware will be used
            4.1.1 - Meet w. PM / Devs
            4.1.2 - Get hardware assessment from PM / Devs

    4.2 - What Software will be used from BRD
            4.2.1 - Meet with PM / BA / Devs
            4.2.2 - Get software requirements in use from BRD

    4.3 - What additional resources will be employed
            4.3.1 - What is normally in use

5.0 - Risk

    5.1 - Establish risk matrix from features-in-test
            5.1.1 - Meet with PM / BA / Devs
            5.1.2 - Get Risk Analysis from BRD

6.0 - Entrance / Exit Criteria

     6.1 - Determine when testing is to begin
            6.1.1 - Meet with PM / Devs / QA Team
            6.1.2 - Get Release schedules / Test Cycle schedules

     6.2 - Establish when testing is finished
            6.2.1 - Establish sweep-completion ETA

7.0 - Glossary

      7.1 - Write up all terms, acronyms, and defined language in use
             7.1.1 - Meet w. QA Team
             7.1.2 - Draft list of terms and definitions (including CTAs, navigation end-points)

8.0 - Appendix

       8.1 - Copy of BRD
       8.2 - Copy of Functional Specs
       8.3 - Copy of Wireframes (if any)
       8.4 - Test Cases**

9.0 - Approval

      9.1 - Sign-off by all parties involved

** I usually bake my Test Cases into the test plan as punchlist