QA Humor: Testing

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

Don't think testing is important .. ask Obama

Managers, Hug your quality assurance analyst / tester / engineer the next time you see him / her

In the almost 3 years I have been in the role as a QA Analyst, I've come to understand that we are the first people that get blamed when things go wrong, and the last to get rewarded when they go right.

Quality Assurance Analysts / Testers / Engineers have to be as smart as Project Managers, as savy as Developers, and all the while imaginative and innovative in the testing process.

We have to deal with less-than-stellar documentation, often filling the blanks where they exist .. and they do exist. More often than not, we must be as attuned to the project as the Client, but often we are kept in the dark about specifics.

When bugs are found, its always the tester's fault. When they get missed, its always our fault. When the developers run late in coding, its test time that suffers and its our fault when testing is inadequate. But we do push back.

But if you don't think quality assurance is important, ask any one who has recently visited the healthcare.gov website and tried to sign up for affordable health care.

I can promise you, it wasn't tested. If it had been properly "QA'd", more people would have subscribed to their plans and Obama would be a national hero. 

And guess who's fault that would be ;)

Til next time my QA bretheren .. keep up the good work!

QA Humor: New to Quality Assurance

 

Found this while testing .. had to add my $.02

[src: NY Post - Original Article]

Quality is everyone's job

Stop me if you've heard this one, "why didn't QA catch it before!!

Dear Readers,

In my professional career, there are few things I have zero-tolerance for, and being admonished for doing the job I was hired to do ranks up there.
There are things within the field of IT that quality assurance analysts are responsible for, but there are more things that are beyond our control, and I wish to outline a few:

Faulty Requirements

The bane of any tester, no matter how good they are, is to have less-than-stellar requirements. When developers spend more time trying to figure out the outcome of a feature, they've wasted time programming. When QA is asked "figure it out" the end result are CRs that are rejected because the issue found is as expected. Really?! Where was that written? Oh! that's right, it wasn't!

Shortened / compressed timelines

All phases of the the SDLC are properly allotted a budgeted amount of time with which to execute the scope of work. When the project runs late, the time constraint most affected is that of testing. There will be a lot of push back from the QA manager, with the stern warning that the project-in-test will go live with a lot more issues than what's allowed. Shortened timelines will guarantee higher-than-tolerable failures.

Laziness

Note to Developers: I'm on your side 100%, but the burden of quality coding cannot be rested on the shoulders of the QA Analyst alone. There are a few that toss the project over the wall and hope it works, relying on QA to find the problems and improve the overall quality of the app / site. Unacceptable! it is not for QA to ensure the quality of the code, but rather the quality of the entire project. Developers MUST NOT rely on testers alone to ensure the features work.

Fix-A-Bug, Find-A-Bug

When time is of the essence, and the project is behind schedule, nothing is more frustrating to QA Analysts than to test, write a bug ticket, close said ticket then find a new bug introduced by the fix .. repeat! As a segue to my previous statement, carelessness is just not acceptable when the project needs to be handed off to the client at an expected time. Testing is tedious enough but the test-fix-break-test is tiresome especially when the build is handed back to QA without it being tested.

Its QA's fault .. even when it isn't

Nothing is more toxic or demoralizing to a tester / QA Analyst than to bear the brunt of an issue that made it all the way to the Client. QA can run a battery of test cases, crowd-source test the project, automate to no end, but there will always be bugs. To be blamed is just not fun.

Blame has not place in the workplace ... like on any team, its no one person's fault ... we own it, we share it!

Conclusion

The life of a QA Analyst is an inglorious one. We shoulder the responsibility of the project, writing up our test cases by rooting out use cases based on poorly written requirements. We bear the brunt of the problems, get the short-end of prestige, and never get the respect owed to us. However, it is for QA to speak out the solution to make it happen, not complain about the problem; nothing happens until it is spoken .. in a positive manner!

But enough about me .. how was your day?

QA Humor: Testing Requirement

 

I  take full credit for this

courtesy of memestagram .. get the app!

For iTunes