Tuesday, September 17, 2013

Saturday, August 24, 2013

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?

Friday, August 9, 2013

Sunday, July 21, 2013

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

Friday, July 5, 2013

Thursday, July 4, 2013

Coder Dojo: Mentorship Program

teaching youth to code

Hey all, I wanted to drop this quick little posting to share the good news! Sometime ago, my family and I went to an awesome science and technology street fair in the West Village by NYU ... had an amazing time.

Out of a few things I took away from the experience, I made a connection with some awesome people at Coder Dojo.

What is Coder Dojo?

CoderDojo NYC is a free open non-profit movement to teach youth ages 7-17 to code. Learn more about us, become a volunteer or join us for our upcoming sessions!

In the month's to come, I will be taking a day out of my time (not much to ask) and volunteering - the objective is to teach children basic coding. Of course, my son will be in tow as I get to teach him a little of what "papi" does and hopefully he'll have some fun.

I'll keep you posted on the progress of our journey!

Next Post: Mentor Meet Up on July 10