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

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

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

Warning: DO NOT ATTEMPT TO DEAL w. Mills Search International Incorporated

Social Engineering / SCAM Alert !!

Dear QA Analysts and People Abroad, I'm normally not a big fan of calling fraudulent actions out on public forums, but this one is heinous on multiple levels ... and worse, because I too was taken.

I preface this by stating that it is despicable beyond words that there are some who would take advantage of others, and go to great lengths to exploit a basic need like getting job to support a family or pay for needed expenses (medical, or otherwise).

We don't need foreign terrorists when we have these people lurking. They ought to get the worst of punishments.

It starts with an e-mail ...

The initial phase of the scam takes place in the form of an e-mail sent to you from a "Mr. R. Giles" ... a person I cannot guarantee as legitimate (or real) for that matter. This person send you an e-mail stating that he's writing in response to an ad you responded to on some job board. If you're like me, you've lost track. So you reply.

Then comes the urgent call-to-action ...

A follow-up e-mail is sent to you stating if you're still interested to respond with additional steps. Keep in mind, other than the request to purchase a book (which didn't seem like a terrible thing - for $20), there was no real financial commitment.

There was a pre-qualifying test to take - about 100 questions - that were relevant to the position of interest. Again, I'm a fairly intelligent person and the questions asked were very on-point with what one would expect for a position of interest.

References required ...

Here's where things may start to take a turn. This fictitious person requires a listing of references. Typical of any agency, they ask for a resume, references, etc. There's nothing on my resume that I should be afraid of being tampered with, but there are former employers and other tid bits of information that could be used for good or ill.

The references is again, a typical ask. But in hindsight, this is means by which this $%^& spreads the maliciousness.

Finally, the site fails ...

So after a couple of days when I hear nothing back regarding my test results, references, or where I'm even at in the process I send an e-mail. The e-mail bounces. I give it the benefit of the doubt as it could be a host of different issues. I try again, same effect! Now I'm pissed for getting taken.

I check the website, and suddenly its down. Guessing distinct IPs get blocked once the scam is completed. Well played, #$%^& ! Well played!

 Lesson Learned

In the quest to better my station and move upward, I was faced with a very insidious and clever ruse. I send this out to all who may read this, beware of this. But don't take my word for it ... click these links and do your diligence, as I should have done.

• Victims of MSII
• Domain Information

7 Reasons Why QA Is Difficult

7 Reasons Why QA is Difficult

Posted on 08/13/2012 in Testing Trends by Jamie Saine

 Click here to read the article

Blogger's Note: I cannot and will not claim credit for this article ... I am merely passing it along as it is a brilliantly written piece on what QA goes through.

Enjoy!

QA Tool: Push Notification Debugger for iOS Apps

iOS App Developers and QA

I recently came across this by way of my linked feed and I wanted to share it with you all.

To be honest, I've not completely reviewed this myself as I'm not a developer and push notifications that we do test are done client-side (via the app), so I cannot attest to its viability .. but here goes!

https://github.com/blommegard/APNS-Pusher

QA Humor: Agile Process from a QA's perspective

I can't take credit .. I can only pay it forward. Enjoy

 

Original Post

Using new technology to watch porn .. seriously?!

"Nothin' like porn in the morn"

We are doomed as a society when we reduce the most advanced technology to a new means of watching porn. I'm not one to judge .. by any means. But honestly, is this necessary?

Read the article, voice your opinion

QA Humor: The wrong way to ensure quality

 

Original story, click here

Lessons Learned: What Agile QA has taught me

What Agile Means to Quality

For Agile, there really is no 1 set of ways to go about it. If you're used to Waterfall, Agile is just a more "compressed" version. 

While you may get different opinions, these few things hold true:

"Garbage In, Garbage Out"

Good testing starts with a good process. That means you have an Entrance Criteria, Process Document, and Exit Criteria, as well as a Sign-Off Document prior to delivery of your project.

"The Right Tools"

As QA, you need to ensure the documents and tools you are using are concise and relevant. Check that they are up-to-date, finalized, and located in a centralized spot that everyone can access.

"Agile Doesn't Mean Sloppy" 

That means all players are responsible for their contribution; when designers or developers are careless, testing will drag.

"Quality isn't everything, its the only thing"

Don't be afraid to call out anything, or anyone, that interferes with your efforts (unless its a management decision).

"Be Thorough, Be Patient"

Do not let ridiculous deadlines, or shifted priorities, circumvent your testing efforts.

"Can't Catch 'Em All!"

There will always be a bug or two that gets away from you when you go live. From my experience, its your job to catch the biggest ones and report even the tiniest ones. More often than not, these teeny ones will be baked in towards an update.

"Don't Hate, Congratulate!"

Testing can be trying at times, but I can't stress it enough how important it is to pat your designer or developer on the back when the job gets done, or when they're doing well. Always lend a hand if you can to ensure they're doing their job to the best of their abilities.

"Do What You Love, Love What You Do!"

Last but not least, smile and make your job fun. Testing is tedious, but that doesn't mean you can't get creative and make the task more enjoyable.

Notes from a Meet Up | Building & Scaling A Test Driven Culture

Quality is owned and shared by everyone ...

It has been some 2 weeks since my last blog post - nature of the beast in the life of a QA Analyst - and I've since attended 3 Meet-Ups. If you've not heard of them, I highly recommend joining meet-up (meetup.com) and seek out QA Analyst / Testing groups.

This Meet-Up - establishing a test driven culture - was particularly informative. Here is a brief synopsis, lectured by the lead developer, going by the nickname "db":

Scope

The scope of a test-driven culture is to establish a mentality where there is a 2:1 ratio of test cases-to-code, such that each unit in the feature has been thoroughly tested before integration. Testing is in short, a continuous process from inception to deployment.

Ownership

In a test-driven culture, ownership is shared, and the environment encourages collaboration.

Technology

The technology employed in testing ought to be relevant to the project being tested. Artsy Developers favor open-source technologies. These technologies allow for efficient composition of test cases, continuous testing, and scalability as new features are added. In a test-driven culture, testing starts in tandem with development, not after.

Methodology

RSpec (rspec.info) is the choice method for establishing the testing library. In addition to the Input -> Response paradigm, additional dissection of test data (API) in a production environment is employed to yield real-time results (ex.: API calls are made, confirm response, verify side effect).

Scalability

Testing is run during the development of each unit / component. Continual testing is performed until each unit is bug-free. Then testing efforts are ramped up during integration. Further testing is done once entire project is fully integrated and ready for deployment. Test efforts must be scalable in response to change orders, scope creep, and any other unforseen circumstance.

Results

Signs of a test-driven culture include continuous improvement to test efforts, consistent remediation of issues found, efficient testing effort using the most current technologies, and the overall buy-in from upper-management.

Cost

The cost of failure is catastrophic once a product is live. The impact thereof include loss of revenue, loss of consumer confidence, client dissatisfaction, damage to reputation, and so on.

Conclusion

• For a true test culture to exist, testing needs to come as second-nature.
• While in production, user-reported issues can become fixes for the next iteration.
• Features in development start out as test cases and evolve to features.
• The truest measure of success for the project is that it works.
• Test-driven cultures do not rely on QA - the safety net is removed forcing Devs to own the quality of the code they write
• QA Analysts are encouraged to integrate with Developers and vice-versa

QA Humor: Vintage Social Networking ... and more

Vintage Social Networking

HDD Evolved

Panda Express

Thank you REDDIT - reddit.com - for reducing my productivity somewhat

Lesson Learned: Politics is N.S.F.QA

Warning! Politicians .. please avert your eyes to this post  as it may offend your sensibilities ... as most things tend to do

I wish to preface this post by wishing all of you - whatever denomination you may or may not be - a blessed holiday.

Having written this on the later days of Easter, I felt it appropriate to begin a new season by reflecting on the past.

It was some time ago that experienced first-hand the effects (positive and negative) of politics in the workplace.

Positive

If there can be some positive take-aways from the effects politics is that  forming the right alliances with the right people can be advantageous for both career growth and professional development. Its always best to surround yourself with people that are going to bring you up, not motivated to take you down. These people will nurture your professional growth and act as "mentors" that you may one day pay it forward.

Negative

Then there is the uglier side of politics. The "dark side" as it were that does more to impact personal and professional growth. These agents serve in the interest of themselves at the expense of others and mask their ineptitude in politics. I've seen first-hand how an entire department can suffer in performance when games are played. 

I've also seen how a lack of accountability, either from a fellow co-worker, or superior can cause strife, aggravation, and unnecessary duress. I'm not saying I'm perfect, and I've taken stock of the things I could have done better, but never once did I engage in any sort of political shenanigans to better my station.

Conclusion

In closing, I write this as a way to finally rid myself of the things in my past that have had a significant impact in my current endeavors. I can summarize this post by simply saying politics is not safe for QA. Politics get in the way of us effectively doing our job as primary defense against the hostile environs of production and mass consumption. Politics has no place in Quality Assurance, but sadly, it rears its ugly head when the quality of a product tested or service provided is impacted by external influences. And who gets the blame when it goes bad? ..... Exactly!

Thoughts?

QA Industry Survey

Where do you think QA is going?

This survey is now closed. To those who participated, Thank You!

App Submission Humor

Because I have awesome friends that share stuff with me all the time, enjoy:

• http://cs319420.vk.me/v319420472/5331/H1yQ_mLLEZM.jpg

QA Tool: Mind Map for iOS Testing

As promised, here's what a co-worker shared with me for iOS and I thought it was brilliant and I happily share with you - iOS Testing Mindmap - enjoy!

Lesson Learned: QA is NOT a verb !!

Dear Non-QA Managers, Analysts, and readers alike:

I wish to discuss the following pet peeve with the following scenario:

• Mgr: "Hi Team, I have a project that needs to be QA'd by end-of-day today. Whom can I assign for this?"

QA testers look to each other in wonderment, asking what is this "QA'd " word they speak of?


1. QA - the initials for Quality Assurance
2. Quality Assurance (v) - the act of ensuring the product / service is in compliance with the proposed scope of work, performs as expected, is approved by the Client, and fulfills the intent for users.

A project is not expected to be "QA'd" any more than planning it is to be "PM'd". I cringe a little when I hear it, but its become a buzz word synonymous with "tested".

I do apologize if this comes off petty, but I wanted to share my pet peeve as an Analyst serving at the behest of others. That, and the industry buzz words, like " Going Forward ".

What is your pet peeve? I'd love to read about it.

QA Tool: Mind Map for Android Testing

A co-worker shared this link with me for Android and I thought it was brilliant. Can't keep good things like this to myself so I pass this on to you -  Android Testing Mindmap - enjoy!

QA Tool: Process Mapping

From time to time, I plan to tidy up my tool box and share some helpful tools that I've collected along the way. This one in particular is from BONITA SOFT - http://www.bonitasoft.com/ - and it is a free process mapping tool that can help graphically interpret your internal QA process (and any other business process).

I've researched this a bit and it was intuitive. If you're experienced with UML documentation like I am, this is a snap! If not, you'll pick it up quick

Lesson Learned: Avoid seeing the Forest from the Trees!

How many times in the course of testing has this happened to you:  you've lost objectivity. You lose perspective of what the app or site is about.

Naturally, you test and re-test, running through all possible positive, negative, and edge cases. You've become so ingrained with the inner-workings of the project that somewhere along the way, you miss the obvious - the essence of what its about.

Full disclosure, this has happened to me a couple times. You're so bent on looking for the "show-stoppers" bugs, but you'll overlook the obvious.

What I call seeing the forest from the trees.

All the more reason why it helps to have a fresh set of eyes. Someone unfamiliar with the app / site, who doesn't have a test plan, or test scripts to follow, but will use it as it was intended.

The greatest lesson I learned was to step back from the project and look at the entirety of it. Ask yourself, "what is this supposed to do?" (and I don't mean asking from a functional perspective). A lot of times, the most obvious issues will be missed when objectivity is lost. 

If this has happened to you, I'd love to hear about it.

What makes a great QA Analyst

Good testers learn from success, great testers learn from failure

So there you are, intrepid QA Analyst, tasked with a project of high profile. You've written up the plan, attended the meeting, and ran through all positive, negative, and edge cases. You've filed tons of issues, and close just as many; test-report-retest-repeat.

The app goes live and you've stamped your name on it to assert 100% functionality and that the project fulfills the desires of the Client. Then the inevitable happens .. a missed bug that causes the app to fail. The app is live and getting bad reviews due to the performance issues encountered during an install or update. Client is angry. Your Quality Assurance Manager is doubting your skills as a tester. And all you want to do is just crawl in a hole. What do you do?

In my short time as a QA Analyst, I have seen my share of co-workers crash-and-burn when an app fails in production. I have experienced a fail or two myself. How one handles failure is a measure of the kind of person (and tester) they are. Good testers learn from success, but its the great testers that learn from failure.

A great tester applies what he / she knows in their testing and can get to the root-cause of why the failure occurred. Fails fall into two categories: omission and commission:

• omission: you overlooked the most obvious (or not so obvious) issue
• commission: you tested inadequately

A great tester perseveres when things look bleak and is not afraid to ask for help. A team is as strong as the weakest link, and with good leadership, preventative measures can be made to ensure the mistake is not repeated. I have had the privilege of helping my co-workers and likewise being coached on ways to get better. In the end, its only made me better at my job.

And the learning continues ....

Tell me about your worst day and how you handled it

"Who are you?" asked the Caterpillar to Alice.

I start this blog with a simple introduction. You are a Quality Assurance Analyst, but what does that mean?

You spend hours of your day planning, testing, re-testing, reporting defects, closing defects. Why?

"Who are you?"

Are you merely a tester, serving the purpose of a mindless automaton? Or are you the last line of defense .. the champion of product quality and the vessel for the company's reputation?

Are you better than the bottom of the totem pole? More than a minion serving at the pleasure of the project manager?

alice in wonderland caterpillar | Tumblr

I will tell you who you are. YOU are the person, the team, that determines the fitness of a product or service. YOU hold the integrity of the organization in your hands. Through you goes the product in its last phase. Through you go the many hours of planning, designing, and developing a product that addresses the Client's needs, but by proxy represents a company's image.

You tester, you analyst, you keeper of quality. To you, I say cheers! Job Well Done!!

I plan to share my experiences and acquired methods and tools here in this blog, as I hope you do to, if for no other reason than to show that there's more to QA than just testing.

+ end of line