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

QA Humor: For those who were outsourced, laid off, or otherwise downsized .. enjoy!

 

(thank you, Reddit)

src: http://www.textoverit.com/card/2504/its-not-called-a-layoffwe-are-realigni

Mentor Meet Up on July 10th

Programming from with scratch

Dear Readers,

I should start this post by apologizing for the lateness of my entry. A lot of time, circumstances, and testing has happened since my last post, and I meant to submit this in a timely manner.

On with it then .. !

Scope of the class

All the mentors were tasked with teaching kids the basics programming. The process started with coming up with an idea (PLANNING), mapping out the story (DESIGN), basic coding (DEVELOPMENT) and presenting the idea (DEPLOYMENT).

Let the coding begin ...

The platform in use was called Scratch - a flash-like program with a simple user interface where simple functions, methods, and other actions were pulled onto a screen by drag-and-dropping items onto a "story board". Our novice "developers" got to design the background, add a character, and create a small animated scene.

Showing off...

While the majority of time was spent on creative, many of the kids got to deploy their ideas and show off their "programs" to others. The objective was to simply introduce children to the world of development all while making it fun

Lesson learned ...

For the most part, it was about fun. I can't pretend there was much in the take-away experience. The nuances of programming structural procedures were lost in the mix. But there was a lot to be said for having fun mapping out a plan, drawing up a storyboard, and executing an idea. Scratch provided a quick and simple way to create simple movies that didn't involve scripting. My son was amongst the many of other kids and he now wants to make another.

MISSION ACCOMPLISHED

QA Humor: Requirements Gathering

A picture is worth 1,000 words ... this said it all!

<< click to enlarge>>

Image source: projectcartoon.com
Found on: Usability Geek / Requirements Gathering, Pt.1