Diapers and User Stories

Once upon a time disposable diapers just were invented for people as a substitute to washable
diapers. They added convenience for unplanned outings and emergencies. But when they were understood as the norm and taken for granted, the result was more landfills occupied with junk that takes more than 500 years to decompose.
Advantage – anyone could take care of the child and people were not tied to the child.
Disadvantage – babies who used to be potty-trained by 18 months take 36 + months now.

Once upon a time user stories were suggested in agile methodology for unplanned needs about which much was unclear but there was a need, an unplanned need, but a valid need. This enabled anyone to be able to write requirements and put them through the backlog. But when they were understood by the upper management as norm and taken for granted, the result is lots of user stories (most of them poorly written) that look the same and take longer to understand and implement and result in half-baked products that constantly break other logic.
Advantage - the business teams can pile up on wants with user stories in bits and pieces.
Disadvantages – Art of writing fully vetted technical requirements is forgotten leaving a lot to be improvised by the developer on the fly.

Diapers and User stories were meant for good purposes, but misuse and overuse made kids and IT inefficient. They both deal with a lot of Shit!!

Are you a Tester or a Checker

Checking is about PASS and FAIL
Testing is about HOW it Works
A Checker checks the surface within the boundaries of the requirement
A Tester explores the product and understands what it does and how it does it
A Checker tries to find where the product is broken
A Tester tries to find how the product can be improved
A Checker will ensure the requirement is met
A Tester will want to ensure the product is viable regardless of what the requirement says.
Testing is not part of checking
Checking is part of testing, but not the total gist of it.
Ex - Super Man / Clark Kent
A Checker will only see the obvious difference in the dressing
A Tester will want to find out WHY the differences exist
Ex – Menus or Drop Down lists
A Checker will make sure the list of items show up as listed in the requirements
A Tester will explore where this data is stored (hard-coded or from the Database or some other logic)
Ex - Authentication
A Checker will check to see the registered user is authenticated with valid credentials
A Tester will find out where the registered user information is saved and make sure the passwords are encrypted / salted too.
A Checker will check to see the user can log out
A Tester will explore the user session and its termination process. And will try to authenticate in other ways.

Checkers all over the place in the name of software and other testers. Testers are hidden within this bunch. They put their jobs on the line to do the right thing. They are relentless. They want to learn how it works. They want to make things better with the process and the product. They are the hidden heros.

Badass, Bad, Ass

Badass people do not need introduction. They are awesome by default. They are passionate in their
jobs. They know themselves. They respect others. They see potential. They see possibilities. They do not stick to sameness unless the sameness is also as badass as they are. They don't have impossible in their vocabulary. They won't be heros today, but they are Gods.

With badass people, I don't have to dumb myself down. I can be myself. I can even be a better me. I feel human.

Bad people are not characteristically bad. They are just morons. They are not even good at what they do. They fear even the slightest change. They are insecure. They hang on to legacy practices and technologies. They are slow as f....

It is sad to work these people. It is depressing. You can try and teach them new things or better things but they won't get it. In this case what does not kill you does not make you stronger. It just makes you crazy.

Ass people are characteristically like the bad people, but they have learnt to make noise. They are
oxymorons who impede progress. They make a lot of noise over things that matter most to them. They squash real issues impacting the quality of work just because it does not serve their purpose. They are back stabbers.

They put fear into others. They create self doubt. They do take credit for other's work shamelessly. They withhold information to look like heros. They will excel and fool people into thinking they are more than they really are.

A Testers Life

There is a plethora of examples explaining about a Developer's life. It is time to show the QA in the same "light". I am a QA and only some of these are my experiences. Which ones can you relate to?

This is what they think QA are like

This is what we wish QA could be like

My first day on the job - I am introduced.

Product training for QA

I am trying to find my way through SharePoint

It has always been like this. It's not a bug, don't log a ticket for it, the existing QA tell me. (Or maybe they do not want to admit that they missed a big fucking bug.)

This is how Devs are trained about the project.

This is how QAs are trained about the project

I finally get my build to test. It is 5:00 pm Friday

I am not given access to anything, but I am expected to test

Setting up Test Data

Smoke Testing (it usually never detects the fire or smoke till we get to production and a customer reports it. But it sounds good.)

Trying to catch a sporadic bug. Arrrrrgh!! 

I test on multiple environments. (One size does not fit all)

(All paths do not lead to the destination)

I test with all possible scenarios

I also test on IE. (!!Why are the Mac users sitting next to me!?!.)

With every test, I see bugs crawling towards me.

My bugs got closed without justification.

Dev Team meets me for the first time

One of the thingies is spinning. Dev tells me it met the specification!! (They close my bug)

They tell me it is a great space saving design "users" will be happy using it. (Again it is not a bug)

Dev asks me to redo every step that lead me to find the bug. I do it even though I know it is not relevant.

I reproduce the bug for the developers, the PM, the BA, other Stakeholders. (my keyboard is chaffing)

Testing the same thing over and over really feels like this. Dizzy!! (sorry regression testers.)

I really don't want the tests to Fail. But I have to do the right thing.

PM's reaction when I stop the release and Dev supported my decision

Revamped product looks modern. Team agrees it is modern and we are out of time and budget. What the heck, lets release it hope people won't notice it. 

Expected vs. Actual. 

They ask for MY opinion during retrospective. (My contract is often ended for being honest.)

They hate me for logging bugs and doing my job.

Product is released. I got Fired

They told me it's an edge case, none of our users can do that in Production. (deal with the upcoming law suite bitches!!)

Its my baby, I don't want to break it

The old school philosophy of testing is "Break the software". I used to think this way and be driven this way. Then I realized something, when my focus is on breaking something, my approach is attack mode.....

If I want to break a glass vase, I throw it down and it breaks.

If I want to break my software, I find vulnerable spots and take a jab at it.
Then what?
I report, "hey, its broken" and probably feel proud that "Hey, I broke it!!"
Then what?
I don't know. 
I am not sure if this approach every worked for me.

I usually fall in love with most products I work on. They are my babies. I want the best for them. I want them to evolve and improve. I want them to co-exist with their sibling applications. I want them to have a unique name in the software industries. I want to give them the best opportunities I can provide with my team.

It takes a village
It take a village to raise a kid.
It takes a team to create a product.

Know the history
Know where the kids come from. Their background, family history, family health history and such.
Know where the idea for the application come from. The requirements and the needs that lead to creating the application.

Understand what they want
We want to give the best of the best to our kids. But that wont make them happy. Understanding what they want and trying to give them as much of what they want will make us happy.
We want to create the best possible application. But the application may not need the extra bells and whistles. It just needs that extra umph. Try to give what it needs with what we got.

Protect them from threats
Kids should be educated about pedaphiles and manipulators so that they can protect themselves when we are not around. Because, the bastards always make sure the kids are alone to take advantage of them. Provide them with whistle or phone or a process to attract attention when in trouble.
Software should be prepared to deal with hackers and hijackers so that they it can protect itself anywhere in the world. Provide them with Captchas or trace of analytics to understand what happened when.

Extra care when sick

We have to give extra attention to the kids when they are sick. Not hate them for being sick.
We have to give extra attention to the application when they are vulnerable. Not walk away and abandon them.

Rules have to be followed
Kids may not want to follow rules sometimes. But they should not be given an opportunity certain times. They have to follow the rules as part of the society
Application functionality may become dull or not enough adventurous some times. That is okay. It is for the application's own good. It is to follow some rules a it is part of the society.

They will leave the nest
Don't try to hold on to the application out of fear of being jobless. When it is time, it is time for the application to go through new process and into new departments and have a life of their own.

Enjoy them

Enjoy being with the kids. Explore the world with them. Talk about anything with them and see what they think. If they need to understand certain things more than the other, explain it to them.
Enjoy working on the application. Explore the software world with it. Input anything and observe what comes out. If the software needs to be tested in other ways using other tools, definitely do it.

Watch them grow and evolve
Watch your kids grow and evolve into something wonderful
Watch the application grow and evolved into what it is meant to be.

Quality Assistant

I am often asked about how I deal with my programmers on a day to day basis. The question means well, I am giving them bad news about their work. It is only natural for anyone to doubt - how this paid relationship works!?

There is this joke / story I heard a while ago that could explain the tension between a developer and the QA. Here the Wife is the Developer and the Husband is the QA.

Wife: (puts on a new pair of jeans) Does this make my butt look big?
Husband: (just stares, if he tells her the truth, she might get mad. If she does not her friends will tell her the truth and she will still get mad)
Wife: Honey, you can tell me. I won’t get mad.
Husband: You say that now….
Wife: I promise I won’t get mad. You can tell me anything. We should be able to tell each other anything.
Husband: OK, here it goes. I slept with your sister.

That is how I typically roll. I gain their trust and then give them a bunch of bugs I found. It is not my job to make sure every bug I logged is fixed and is accepted. It is  team decision to fix a bug now or to backlog it or reject it. It is not my decision or the developer's decision. (Although this is old school thinking from 1997).

Thanks to this notion, many organizations maintain their teams working against each other while working for the same goal (like “frenemies”). But there are teams where developers and their testers work together to build not just a product, but something great. In the later the A in QA means Assistance. Not assurance!

I mean what are we assuring? What can we assure? We are assistants. We are quality assistants to the developers. We assist them in doing a better job. We are not finding faults. Together we build a better product.

I have not met a developer who did not care about the quality of their work or their
product. So, they care. They don’t just code and sit back for the QA to find issues and work on putting them down. They do their part of testing to make sure their code works. It is my job to make sure the product as a whole makes sense and it sensible (Yeah , yeah, bug free, what ever that means).

I prefer to make my application better by continuously exploring it, learning about it and respecting it. I dont believe in breaking it or trying to break it. (Again 1997??)