vodQA nite without any hangover

Its been long time since there was any activity in this blog. Finally time has come to break the silence

Yesterday me and ravi had attended vodQA nite, A conference intended to bring all QA from different companies to share ideas. This is the first time I have heard in my career about any conference conducted only for QA. This gives me positive vibes towards QA profession which was listed most times in 'others' category.

I come back to the main topic vodQA nite. Frankly speaking My Intention of attending this conference was to move away from the routine QA we do. Most of the topics were about automation, from different people from different companies. Who doesnt want to know how these skills are practiced in different companies, because there are always different perspectives.

Venue of the conference was Thoughtworks, Yerwada, Pune. True to its name it was kind of IT park with tall well designed buildings and a pleasant environment, people mostly dressed in formals carrying tags roaming around :)

we were searching for the venue inside IT park, Finally we found it. we were stopped at the entrance to show the gatepass. we didnt have one. we went to get the gate pass and then entered thoughtworks building.

As we entered we saw lot of people who had come to attend conference. I just glanced through 360deg and got the first look of the venue. It got me thinking, because It was one of its kind

No cubicles
Seating arrangement as if you are sitting in a conference hall
Studio kind of setup
colorful sticky notes
dashbords

Overall what I felt was it was something different from the routine work environment setup, my expectations about the presentations were high now. This is the list of

Speakers & Topics:

•Swapnil Kadu from Synechron Technologies - Transitioning from Waterfall to Agile - Challenges
•Srinivas Chillara from etakey - Trials & Tribulations
•Sumit Agrawal - Automation Execution results Dashboard
•Sagar Surana from Amdocs Dev. Ltd - Intelligent test design
•Manish Kumar from ThoughtWorks - Be Agile, Get Rapid Feedback
•Anand Bagmar from ThoughtWorks - Future of Test Automation Tools & Infrastructure
•Sudeep Somani from ThoughtWorks - Decoupled Automation Frameworks
•Chirag Doshi from ThoughtWorks - Write tests in the end-user's lingo

It was very refreshing and good learning from few of the presentations especially the last 4 topics. It gave a glimpse of where QA is heading towards. All the presentations has something new to offer, it was an interactive conference. we met one of an old acquaintance Ketan, he was a consultant from SNS who had come to help us with poker testing, he briefed us about the company, people, work culture and type of work. It was Impressive, he said its tought to get in thoughtworks becoz it has 7 rounds and I understand now, if you have to clear 7 rounds then what stuff you need to have :)

Overall event was well organized and I felt satisfied after attenting that I did not waste my time. I suggest you to attend if it happens any other time. I will be there too :)

Note: I forgot to mention, we also had a chance to meet Ayyappa whose Office is in same building. we spent some time over tea discussing all topics in one go as usual ;)

To STOP the Train - Pull the CHAIN

If you don't do right things at the right time you are inviting failure, as the title goes "To stop the train pull the chain"...you must know when to pull the chain

If you do it in a wrong time, you may end up paying a fine of 500rs maybe(I have never pulled, so I dont know exact amt :))

BUT it doesn't mean you should never pull the chain. Infact you should have the commom sense or presence of mind to pull when it is absolutely necessary

How many times have we said this "we should have done that", "we should have done this" yet we dont do it always...either sometime or rarely

How many times have you pulled the chain in your job? A general myth is the only the Manager or leads are eligible to do this or responsible to do this. I am very sorry for you if you hold this thinking...right from a tester to a qa manager each one of us has responsibility to raise an alarm when something is wrong. It is this inability that causes most harm in projects, people feigning off in guise of their designation or not wanting to be a person who is a whistle blower. we need to make teams aware of the Importance because It matters a lot.

one more analogy comes to my mind

Think of a referee not blowing a whistle when a player make a foul, what if he blows whistle after 5 mins--->he loses credibility, he is embarassed, looses his confidence, his mistake is repeated in all TV channels, "if this mistake is costly"

It is same in our IT projects, if you don't blow the horn at righ time, you are inviting trouble, It may be very costly

what I want to highlight is the Importance of raising alarm at righ time in a project, If its agile then you are bound to be caught for you negligence, BUT if you are not into agile you may escape or it may become a way of life (which may be good for you at that moment but not so good if you happen to join a agile team)

AGILE itself says, search me in a dictonary, you will find "I am deft and active"

Ooops I did it again!!

The embarrassing mistakes (that I recall of now) I've made while reporting Defects/Bugs from my Rookie days till now:

Obvious ones:
1>Asked to refer a attachement in report, never attached one to the report.
2>Incorrect Spelling/Grammer.
3>Expecting a developer to understand the context in which I have filed the defect. i.e. not specifying the steps to reproduce.
4>Reporting a defect on incorrect version.
5>Re-opening a defect on a version which is not yet released. (I know, What was I thinking).
6>Refering to wrong table for values which I would not find in them.

Tricky ones:
1>While testing for values in a recently added column in a table forgot to sort query results in desc. order.
That way the entries for older records was ZERO/NULL and I think it's a defect.
2>Mentioned in defect report that I clicked on a buuton,when I actually hit a button using keyboard.


Ofcourse the Idea here is not to show how naive I was in my early years as a tester, but to get to know common mistakes we all make.
Well ofcourse also to gain something out of it!!!

Tell me about yours?

Clients report more bugs than QA team.

Guys,
I have a practical situation to handle.
The build release cycle for the client in my company is on daily basis.
So QA receives build at around 4 or 5 pm and would have to deliver the build by 7 or 8 pm. In such a short timeline, the QA is not able test the whole application in the same day. He only tests the defects that have been fixed and changes that have been made with a few tests on impact of the fixes too. We do a complete round of testing the next day morning, but until then the client who's located in US does a full round of test and gives us defects in the morning.

Now, if we think we could insist on Dev giving the build earlier than 4-5 pm, thats not quite possible becoz we have a daily call at around 12-2 pm with the client who prioritizes the issues to be fixed for the day. For the plight of Dev guys having 3-4 hours of development time, we can't even reduce their timelines. And as the client is so demanding for the defects fixes and CRs for the day we can't even reduce the no. of defects handled per day.

To add up to our complexities, the tester and developers working on this project are both inexperienced.

I'm just wondering what would be win-win solution for all (Dev, QA and Client)? I'm in a deadlock situation, pl. bail me out! ;)

How long before you close a defect

I was testing a pretty tricky defect today. I realised that I had encountered a similar defects 3-4 versions/builds back.
At first I was suprised as too why did it re-earth. Did I not test it enough before closing it?
As I pondered on it, I wondered when is the right time to close a defect.The answer will be very simple -->The moment you think it will not occur again:)
However life is not that simple now is it?

There are many things you wil have to look out for:

1.Severity of the defect.
2.Probability of it's occurance.
3.Confidence in the developer.

However I still not able to figure out when is the best time to close a defect.

1.After couple of regression rounds?
2.Just retesting it over a couple of builds/version?
3.If the unit testing results are very positive?

Any suggestions?

If I work in a Gaming domain - Am I an Expert?

There is generally a myth in software Industry, that If you work in a certain domain for a long time you become an expert and are Invincible. In my opinion this is not completely true why?

1. My urge to get the gaming domain knowledge arises from my passion for giving my best at the skill I have been hired for, not for becoming an expert at that particular domain(If you beocme an expert thats a plus), But there is a fine balance between these 2 things.

2. Other teams blindly assume that QA teams are the Domain experts, which is not the case. Other teams like BA, Dev also have knowledge but because they work on certain part of a project, they limit themselves to knowing what can serve their purpose.

3. It is essential for us(QA) not to get into this fixed mode of domain knowledge, Tomorrow If I switch job to another company that deals in other domains,I will again have urge to gain knowledge to do efficient testing. Overtime I will definitely loose or forget prev domain knowledge.

The funny thing about gaming domain is you get easily addicted to it-especially Gambling games, eventhough we might not want to admit it. I will realize it If I look deep within.

My trigger for writing this post is the poker tournament held today in our company, QA team were favourites but This MYTH was broken, other team guys went away with all the first three slots :)I was happy because I got to learn something from this event.

I paste a small story here:

"My Grandfather owned a cigar shop/card house in California. He would say he made his money on people trying to get their money back. The real money in gambling is taking advantage of people who already lost so much, they're desperate to get it back...addicts. The casinos know something about compulsive gambling addiction that we addicts need to learn...the Addiction Cycle. We have an emptiness or negative self-image. All the signals around us suggest, if we had more money, then we could be fulfilled, buying whatever we desire. Since we're not getting enough income for this from our jobs, we feel the lottery, or the bingo parlor, or the card room or the casino can provide us what we want. After all, didn't uncle Joe just win another $ 15,000 jackpot? He never loses! (He never tells you when he loses.) So you take some money to go and cash in. You lose...a lot. You're so embarrassed and humiliated that your self-image is damaged even further. The guilt compels you to try even harder next time with more money, so you can regain your pride...but you lose again, taking you even lower. Until you do something to break the cycle, you'll grind yourself ever lower and more addicted."

After reading this story I felt that we still have not reached this stage and will never reach one :)

Note : This post is purely my opinion, you are free to comment, I would love to see your thoughts on this

8 ways to be a good software tester

Again not my own post, but makes a nice read.

http://www.testandtry.com/2009/04/14/8-ways-to-be-a-good-software-tester/