http://dilbert.com/strips/comic/2012-04-30/
Funny ... but on the other hand, at times this is true. Just because something has been written about, does not necessarily mean it is always true. Things change, evolve, and we need to change and move accordingly. At times, we need to flow against the tide for what we think and believe is the right thing to do.


This definitely applies to what I have seen in my career so far ... so keep thinking in innovative and creative ways - even if at times you have to swim against the tide!

Many a times I end up trying to do too many things at almost the same time. I have got mixed results out of this approach.


I think off late, more often than not, I have not been too successful at juggling many things together ... this could be because of mental fatigue and burnout. 


As a result I have consciously tried to take a step away from items of relatively lower priority. This has helped me tremendously.  Also, I came across this post (http://blogs.hbr.org/schwartz/2012/03/the-magic-of-doing-one-thing-a.html)- which talks about techniques how to be more effective in your work. See if this helps you too!

Dear Testing enthusiasts,

Our recently concluded vodQA organized by ThoughtWorks Pune, on 17th March 2012 (http://testing.thoughtworks.com/events/testing-and-beyond), was a huge success. Your participation, energy, questions, thoughts, comments and feedback raised the level of this event to great heights! We thank you for that.

You can join the following groups to keep up-to-date with what’s happening in vodQA, to know when the next vodQA is happening, to connect with fellow testing enthusiasts, share thoughts related with testing, etc.

LinkedIn group: vodQA (http://linkd.in/IaHcFG)
Facebook group: vodQA (http://on.fb.me/HUPAX9)
Twitter: @vodqa

Here is what happened in this 7th edition of vodQA (4th in Pune):

Statistics:
375+ attendee registrations
35+ speaker registrations
130+ attendees

All videos from this edition of vodQA are available here: http://bit.ly/JRRTtH, and pictures are available here: http://on.fb.me/Jq4Qyh

Based on feedback received, here are the topics that attendees found most useful:
- Open Space
- Mobile Testing
- BDT  [ Behavior Driven Testing ]

Summary of feedbacks received:- video feedbacks (http://bit.ly/Jm88Qd)
- Impressive, please continue conducting such events
- I have attended vodQA for first time, it is an amazing experience
- Nice initiative taken by ThoughtWorks
- Have this event once in Quarter
- Parallel tracks (Participants found it difficult to choose one session over the other)
- Each speaker should have a Slide with email and contact details
- Should have more experienced speakers
- More time for Open Space
- Make arrangements for Parking
- Food can be improved

Want to hear more of:
- Cloud Computing, Security Testing, Malware, Ethical Hacking, Agile methodologies, mobile tech
- Current industry trends and topics

Suggestions given by attendees for next vodQA: http://bit.ly/HXGZ9I


External blogs by:
Anand Bagmar: http://bit.ly/HU78r5
Savita Munde: http://bit.ly/FOS6ll
Srinivas Chillara: http://bit.ly/IaVRAB
Sessions/Topics details:
- vodQA opening
YouTube: http://bit.ly/Jb3MPl

- Opening note by Chaitanya Nadkarny
YouTube: http://bit.ly/JckWcR

- Quiz
YouTube: http://bit.ly/I8o5sv

- Testing is Dead. Long Live Testing - Shrinivas Kulkarni
Synopsis: Last year, three leading software doctors pronounced testing dead. As we mourn the alleged demise of our craft - questions raise as what to do next? This talk analyses the meaning and impact of death of testing. The talk then deliberates on potential next steps and challenges ahead of us.
YouTube: http://bit.ly/JpXI4O
Slides: http://slidesha.re/IrBL4o

- Testing a Massively Multi-player Online Game Server - Nirmalya Sengupta, Srinivas Chilllara
Synopsis: An online game server's functional and non-functional features lead to non-standard challenges for both architecting as well as testing. This talk starts with an overview and then discusses one testing scenario in depth. We stress particularly on testing the asynchronous nature of the application's method calls. A few general approaches of testing such applications terms are alluded to at the end.
YouTube: http://bit.ly/HWO1NP
Slides: http://slidesha.re/JRZKHQ

- Virtualization Impact on Software Testing - Parthasarthi T
Synopsis: Virtualization Impact on Software Testing
YouTube: http://bit.ly/HWjFrj
Slides: http://slidesha.re/Jq4bNe

- Mobile Testing: Challenges and Solutions - Ashwini Phalle
Synopsis: Different testing requirements that mobile applications have, challenges and solutions.
Challenges:
1. Complex mobile testing matrix, Expensive test environment
2. Repetitive testing
3. Mobile testing for devices located at various locations
Solutions:
1. Risk Based Testing approach
2. Using Mobile device emulators
3. Use of Automation tools
4. Leveraging external services
YouTube: http://bit.ly/Jb4hZw
Slides: http://slidesha.re/Jb9Rer

- Open Space discussions
YouTube: http://bit.ly/Jb4k7O

- The Marshmallow Challenge - Sneha Kadam
Synposis: This is a fun and instructive design exercise that encourages teams to experience simple but profound lessons in collaboration, innovation & creativity. It challenges you to find hidden assumptions in business requirements & learn to Fail-Fast-Fail-Often! In 18 minutes, teams must build the tallest free-standing structure out of spaghetti, tape, string and one marshmallow which must be on top.
YouTube: Part 1: http://bit.ly/HR4XiX
YouTube: Part 2: http://bit.ly/J7t8zJ

- Mobile Testing: In and Out - Sudeep Somani
YouTube: http://bit.ly/JifEQH

- BDT (Behaviour Driven Testing) - Anand Bagmar
Synopsis: What is Behavior Driven Testing (BDT)? How does it differ from Behavior Driven Development? What tools support this kind of testing? The value proposition BDT offers.
YouTube: http://bit.ly/HUSuuY
Slides: http://slidesha.re/I69BNK

- Code Coverage of Function Testing Automation Scripts - Aakash Tyagi
Synopsis: Challenge As the product is a vast product that provides so regression suite of this was very big. It was taking about 14 days to execute and with every release it was increasing. The main challenge was to keep regression suite comprehensive as well small so that it can be executed many time. Solution Emma was used to find code coverage of product code then redesign the regression suite.
Slides: http://slidesha.re/HWQJCQ

- Negative Testing, in a positive vein - Srinivas Chillara
Synopsis: How to think about "negative testing", and why it may not be truly negative.
YouTube: http://bit.ly/IaKOr4

- Virtual Communication and Testers - Archana Dhingra
Synopsis: What is Virtual communication and its importance in IT industry. - The common mistakes we all commit while communicating in a Virtual environment - How to effectively manage and communicate with virtual teams. - Conflict resolution in a Virtual setup.
YouTube: http://bit.ly/Jq3uUc

- Automation Reusable Framework based on QC - Vysali Alaparthi
Synopsis: About ART:A hybrid framework named as ART (Automation Reusable Test) is used for end-to-end automation as ART framework supports automation of web, windows, and AS/400 applications. ART framework uses automation tool owned by HP i.e. Quick Test Professional (QTP) for execution of automated keyword-driven test scripts.Key Achievements: Efforts involved in test cases/scripts integration has reduced.
YouTube: http://bit.ly/Jlb8MH
Slides: http://slidesha.re/IrBtua

Closing note: Shalabh Varma
YouTube: http://bit.ly/Jb9fFO

Looking forward for your continued comments, feedback, thoughts and support to make vodQA more successful, and the QA community more vibrant and connected!

See you in the next vodQA.

Thank you.

vodQA Team.
vodqa-pune@thoughtworks.com

Don’t you ever take an advertisement for granted…

Story Summary [Make the blender blend unusual objects]
Date [between 1997 and 1998 - I was 13 to 14 years old]
That day I decided to test whether the blender would really ‘blend everything’, as said in the advertisement.
My goal was to validate that the poweful Pic-Lic blender liquefies all you want it to.
Test Approach: Stress testing, blender motor and blades should be strong enough – Equivalence.
The result: FAIL- blender does not blend everything, plus no recoverability at all.
The lessons I’ve learnt: it is a very dangerous experiment. Pieces could have been thrown against me or I could even have set the place on fire.

Description of the experiments:

So, by the end of nineties a famous brazilian brand of home appliances released a new version of what they would call multiprocessor. It was a blender with stronger blades and a stronger motor that should be able to mix the thickier of the mixtures.

Guess what?! Have you ever wondered I would loose the opportunity to try and make that thing blend something really stupid? No, I mean incredibly stupid, like a glass for example?

You’re right. I did not leave this opportunity go by.

I was used to see people blending tomatoes to make sauce. I was also used to see them mixing onions, and also milk-shakes.

What I never saw people doing was mixing things like a whole egg. Or perhaps ice rocks. Maybe a k n i f e. Uhmm, a glass?! (come on, why the hack would somebody want to ‘blend’ a knife? Well, don’t ask me to explain, I just had some random thoughts. How different it is from when you try to inject a sql query into a Name field? Have you ever seen seomeone called “SELECT COUNT(*) FROM tabname”? Nope. So text fields should be injection-resistant as well as blenders should be non-liquefiable objects resistant. Just that simple

Let me go on with the story…

So I opened the counter, mounted the blender and plugged it in the power. It looked so shiny new. And it sounded so smooth, just like a V8 engine idling.

Next, just to see it working, I grabbed a small glass of water to put some in the blender. Then pressed the power button. Nothing exciting.

Ok, now the hardcore part begins. ICE ROCKS…YEAHHH!!!!
I opened the fridge and picked up three ice rocks. But I had to put them back because I wouldn’t have them melting in my hand. By this time I realized my plan had a mistake. Would I throw the rocks inside the blender while it was running, or should I put them and then start??

hmm…let’s make it work the heavy way. I got the rocks back and put them in a way they would lock the blades. I wanted to see how powerful was that motor.

Press power and

GZZZZ. PRRRRRRT.

Mixed. Blender passed this test.

Next – an egg. So I threw that water and crushed ice away and took an egg.

Again, better to put the egg to mix while the blender is running or stopped? Well, better start it with the egg already there, because while running I should open the lid, and by doing that I would mess up with the kitchen.

Nothing special. Just crushed the egg. Inedible omelete.

Now that was what I was looking forward to see…the glass!!!!
But then I started to think like a grown up child. I would break the glass, and while cleaning the blender up the pieces would most likely hurt me. So the glass was out of scope.

Knife. Yes, my friend. A Knife. L e o    w a s    a b o u t    t o    p u t    a    k n i f e    i n s i d e    t h e    b l e n d e r   c u p, and I do not have a good explanation for that. Maybe that’s because it was a kind of a Ginsu knife and I wanted to see a real battle between blender blades and Ginsu.

For some reason I put the knife upside down inside the blender. I was considering the fact that the knife would most likely end up being useless, and so would the blender blades. So I went to the soft: the plastic handle. It would suffer a bit, but then I would take the knife to the garden and leave it there. People always need a knife when gardening.

Good. The knife was already inside the blender. It took me only 10 seconds from the moment I pressed power button to the moment I released it. The noise was so high that it really got me shocked.

The knife got a shockingly ugly handle whet I took it outside the mixer cup. It looked jagged like a pencil that someone usually bites.

The blender…yeah, you know. The blades were looking somewhat different. They were Bent.
Also the blending cup was all cut.

And so cut were my privileges at home: internet, weekend at granma’s, video-game.

Last thing I remember is that I was grounded for the weekend.

And I’m glad the sound of that knife inside the blender scared me. Next step would be to mix some gravels. That would have been the end of a blender.

That’s all.

Cromulent Testing returns. Did you survive? Find out!

You need your score from this survey.

25 - 35

You appear impressively mellow, with almost no job stress and seem practically burnout proof

36 - 50

You express a low amount of job-related stress and are not likely to burn out. Look over those questions on which you scored a 3 or above and think about ways you can reduce the stresses involved.

51 - 70

You seem to be under a moderate amount of stress on the job and have a fair chance of burning out. For each question on which you scored a 4 or above, consider ways you can reduce the stresses involved. If possible, take action to improve your attitude or the situation surrounding those things that trouble you most.

71 - 90

You express a high amount of job-related stress and may have begun to burn out. Consider studying stress reduction, assertiveness, and burnout prevention. Mark each question on which you scored a 4 or above and rank them in order of their effect on you - beginning with the ones that bother you most. For at least your top three, make a list of ways you can reduce the stresses involved and take action to improve your attitude and/or situation. lf your body is reflecting this stress, get a medical checkup.

91 & up

You seem to be under a dangerous amount of stress and are probably nearing an advanced stage of burnout. Without some changes in your behaviours, attitude, and job situation your potential for succumbing to stress-related illness is high. Consider taking classes in stress reduction and burnout prevention and/or seeking professional help.

What the cromulent testers think:

While the above advice is sound, its focus is on changing attitudes. This is important, but sometimes the place you work needs to change or you need to change the place you work.

Or in extreme cases, exercise.

Peace out.

‘Burnout Questionnaire’, Public Welfare, Vol. 39, No. 1, 1981, American Public Welfare Association

Questions for stress testing… yourself.

This questionnaire is taken from “Public Welfare, Vol. 39, No. 1, 1981, American Public Welfare Association”.

Rate the 25 questions according to the following scale:
1 = Never
2 = Rarely
3 = Sometimes
4 = Often
5 = Always

Do you:

• worry at night and have trouble sleeping?
• feel less competent or effective then you used to feel?
• consider yourself under appreciated or ‘used’ on the job?
• always feel tired, even when you get enough sleep?
• dread going to work?
• get angry and irritated easily?
• have recurring headaches, stomach aches, or lower back pain?
• feel overwhelmed?

Are you:

• always watching the clock?
• avoiding conversation with co-workers?
• rigidly applying rules without considering more creative solutions?
• increasing your use of alcohol or drugs?
• automatically expressing negative attitudes?
• excessively absent?

Does your job:

• overload you with work?
• deny you breaks, lunch time, sick leave or vacation?
• demand long shifts and frequent overtime?
• pay too little?
• lack access to a social-professional support group?
• depend on capricious funding sources?
• not have enough funds to accomplish agency goals?
• lack clear guidelines?
• entail so many different tasks that you feel fragmented?
• require you to deal with rapid program changes?
• Demand coping with an angry public?

Tally your score.

Cliffhanger! Find out if you’ll survive next post!

‘Burnout Questionnaire’, Public Welfare, Vol. 39, No. 1, 1981, American Public Welfare Association

Thoughtworks Pune organized another successful vodQA on 17th March 2012
Statistics:375+ attendee registrations35+ speaker registrations100+ external attendees20+ Thoughtworkers
Sessions/Topics covered:- Code Coverage of Function Testing Automation Scripts - Aakash Tyagi
- Mobile Testing: Challenges and Solutions - Ashwini Phalle
- Business Analysis - Beyond Technical & Communication Skills - Anil Dagia
- Testing is Dead. Long Live Testing - Shrinivas Kulkarni
- Testing a Massively Multi-player Online Game Server - Nirmalya Sengupta, Srinivas Chilllara
- Behaviour Driven Testing - Anand Bagmar
- Virtualisation Impact on Software Testing - Parthasarthi T- Negative Testing, in a positive vein - Srinivas Chillara
- Virtual Communication and Testers - Archana Dhingra
- Automation Reusable Framework based on QC - Vysali Alaparthi
Workshops:- Mobile Testing: In and Out - Sudeep Somani
- The Marshmallow Challenge - Sneha Kadam
Some feedbacks received:

• Impressive, please continue conducting such events
• I have attended vodQa for first time, its Amazing experince
• Some forum about Innovation & "Testing process"
• Nice initiative taken by Thoughtworks
• Have this event once in Quarter

External blog: http://savitamunde.wordpress.com/2012/03/18/thought-provoking-vodqa-pune-a-testing-conference/
Please join our LinkedIn Group - vodQA and our FaceBook group - vodQA..
We will be uploading the pictures, videos and slides to a common place soon for everyone to see.
Thank you all who attended for making this a successful event.

Some time ago I was playing around with Krypton - a web testing driver written by Hakan Raberg while he was working in Thoughtworks Studios and the coolness of SWT Browser component. While doing so, I realized that writing a web recorder using the SWT Browser component is quite straight forward.

I have done a simple spike that you can checkout here. I think this is a good idea because:

• SWT Browser uses a real rendering engine (like XUL Runner for Mozilla) under the hoods. So, even though you do launch a real browser, the functionality is that of a real browser.
• A recorder on this can use IE for recording as well, which is not possible with, say, Selenium IDE.
• It is very fast and it integrates with superior recording capabilities of tools like Twist

While this might seem like a waste of effort - I am not going to spend the next 3 months building this! - I think if Krypton picks up, there is a good chance that this is the default Recorder implementation.
Even otherwise, I think this is a good way to show the coolness of SWT Browser component and that itself is worth the simple spike!

Its the year 2012 and I still see functional test code bases using Thread.sleep() at arbitrary places. Its very surprising that the person who has written this can't think of why this could be a problem (Flaky Tests) or how it can be fixed.

As mentioned in an earlier post, I have created a very simple library for Java - WaitUtils. You can checkout the code and download it from Github. Its a BSD 2 Clause licensed open source software.

The library is really simple - you always make sure you wait for some thing i.e. an event or a predicate. You never sleep without answering some basic questions. This way whenever there is a need to wait, you will do so thinking about things like:

• What am I waiting for?
• How long should I wait for?
• What should I do if what I am waiting for does not happen?

Now, these look trivial, in fact, obvious. However, you would be surprised at how many functional tests do not follow this. By answering these simple questions, you can make sure that your tests are reasoned out better. 
The library intends to solve this once and for all by introducing a WaitUtils. You can download the jar, attach source and checkout the Java docs. The API is trivial and is self-explanatory.

Story Summary [Start the car with the gearbox in the 1st gear without stepping the clutch pedal]
Date [between 1992 and 1993 - I was 8 to 10 years old]
That day I decided to test whether the parking brake or the engine would win the fight.
My goal was to validate that the car would never run if the parking brake was on.
Test Approach: Acceptance test for the parking brake feature.
The result: PASS – brake wins.
The lessons I’ve learnt: never do this far from home or you will get in trouble.

Description of the experiments:
I was a pretty hyperactive kid who loved to spend his time inside a car, pretending to be driving. I was also very close to my grandfather Ewaldo, who would let me do almost everything I wanted.

One day I went with him to a club where he usually would play cards with this friends. I told him I wanted to stay inside the car to listen to some music. So he left me inside the car WITH the car keys and stayed there inside the club playing cards.

(By the way, the car was a 1988 Ford Del Rey Ghia, which used to be my granpa’s favorite model. He was very fond of Fords, specially this model.)

Half an hour passed since my granpa left the car. I was there “driving” the car for quite a while, so I got tired of just pretending to be driving that car without any engine sound.

And there comes Evil Leo’s ideas…

What if I turn on the car
and step the gas pedal
and turn the steering wheel
and turn on the air conditioning
and play with the power window buttons…..

Well, I started doing all that and it took about some 15 minutes to turn out to be boring.

(Oh, I forgot to mention a few important details…since then I was really up to learn cool things, and driving was something very cool to me. By that time I already new a car should not be started without putting the gear box in the N position OR stepping on the clutch pedal, cause if I did so the car would run. There was no Poka Yoke device to avoid the car from moving, or at least trying to move)

Ok. I knew the car would run if I didn’t disengage the clutch or put the gear box in Neutral. But what I didn’t know was the effect of not doing at least of these things, PLUS leaving the parking brake activated. And that was the perfect time to give it out a try.

NHÓWÓUP.

That was the sound I heard first time the key was turned. The engine already started loosing the war. Parking brake wins round one. And, man that sounded so funny that I started to laugh and got so glad to have new findings to report to my granpa.

So I tried again and again and again…and after about 6 tries I heard the following sound when attempting to start the engine…

TÉC TÉC TÉC TÉC TÉC

Woops…that was not expected. The engine does not sound like this, I thought. I had no idea what that sound would mean.

So I tried a recovery scenario – tried to start the engine using the right way to do so, but heard the same sound.

And there comes granpa with his happy face. And he sits, says hello, and tries to start the car.

TÉC TÉC TÉC TÉC TÉC

He asked me what I did and I said I was just playing with the car.

Then he tried twice, got out of the car and started talking to the guy that was in the club entrance. I SAW the guy telling him that he saw that little boy starting the car with the gear on.

So there comes granpa back shouting some german words I will never forget…

“Kleine sch–sse junge was has du getan” – Something like “you little sh-tty boy, look what you did”

And he went back inside the club and a few minutes later he got back with 3 other fat men. He sat on the driver’s seat and the other 3 guys pulled the car to make it start…

That day we went home and I learnt so much German!!!

But besides the new German words that I added to my vocabulary, I also learnt that the engine is started by a little electronic motor, and this motor uses a lot of power from the battery. So when the car runs out of battery it won’t start, and that was pretty common in the south of Brazil back in the 80’s, when they came up with those Ethanol engines without cold start mechanism – you would make your car run out of battery just by trying to start it. I’d call it a suicidal car.

And that TÉC TÉC sound is this engine starter device not being able to turn the engine due to a low battery situation.

Last thing I remember is that I was gounded for two days.

That’s all.

About the title: Foster the People – Pumped Up Kicks

Story Summary [Insert stones into granpa’s car exhaustion tailpipe]
Date [between 1992 and 1993 - I was 8 to 10 years old]
That day I decided to test whether the car would really not work properly if I put something into the exhaustion pipe.
My goal was to validate that the car would stop just like it did in the Beverly Hills Cop movie
Test Approach: Acceptance test for the exhaustion capacity of the engine – Equivalence.
The result: PASS – stones win.
The lessons I’ve learnt: never do this far from home or you will put someone in trouble.

Beverly Hills Cop. Did you watch this movie? I did. And not even did I watch it, but I also wanted to see what would happen if the same thing Eddie Murphy did in the car on the movie (movie, a isolated test environment) would be reproduced in the real world (world, production environment).

It was a sunny summer afternoon and there was Granpa Antônio’s (Rest in peace, ganpa – he passed away last month) Ford Corcel parked in the garage. And there were also me, one of my cousins – Ricardo, and one of my little brothers, Henrique, playing in the frontyard, planning what could we do next.

We walked inside the garage and started pulling the car back and forth, just for fun. We did that for a few minutes and then it turned out to be boring and we had to find something else to do instead.

Then the idea: “What IF….”

The scene of Eddie Murphy inserting a couple of bananas into the exhaustion tailpipe of a car just came into my mind. But there was no banana around.

What IF… we go inside the house and grab some?
-No, cause if we happen to put bananas there and the car really stops, then my grandmother Odila would know who was responsible for the act.

What IF… I get some rocks and put there?
-Humm, great idea. Pretty original, cause the effect could be the same that the bananas did in the movie, although I would only discover the truth by making it happen. Besides, the parking area was full of gravels. So I did it…

I ran outside the garage and grabbed a handful of small stones, then ran back into the garage. So I lay down under the car and started putting the rocks inside. I put about twenty pieces of stone and got tired of doing so.

Next step: start the engine. But how could I ever do that? I was too young to drive, and I had no excuse that would make granpa start the car.

Then my parents decided to go home….
-Damn, how the hell will I ever know the result of my experiment – thought I.

In the next day my family went to have lunch in my aunt’s house. Granpa and granma were supposed to be there too, but they didn’t make it.

The phone rings and I hear my aunt Ivone repeating something like “the car is not starting”.

I can clearly recall my feelings…I was freak’n scared ‘cause I knew they would somehow find out who was the responsible, but in the other hand there was that mission accomplished feeling: the test passed, Eddie Murphy was not faking it.

Next thing I remember is that I was grounded for a week.

That’s, all.

About the song, which my friend @nettofarah played today in the office right after our buddy Joshua White started singing it:

-Harry Belafonte: Banana Boat Song

Even without testers on the team, you still need to test, or your customers will.

Here are some ways the team can help fill the gap:

Right at the start:

• Follow work flows until it’s understood what needs to be done. Swim lanes help.
• Think edge cases. Do they reveal new scope or change the design?
• Find out why you’re doing what you’re doing
• Remember where similar projects have gone wrong. Appear smart by telling others as if you just thought of it.

Before people start coding:

• What’s the least you can do to responsibly meet the requirements?
• Draw the possible paths, what happens at the end of each one?
• What assumptions are you making? How can you challenge them?
• How will you know when you’re done?

Testing stuff works during and afterwards:

• Moar automation. Developers rock at this.
• Run a tight ship; check your own work as you go
• Collaborate with your colleagues. Let them see your tests. Do handovers.
• Rotate, it’s best if someone else tests your work

You probably also want to read up on user interaction/performance/security/infrastructure testing.

Go for coffee and discuss how to test tricky problems. Work as a team. Share ideas. Get in there and have a good time. We still test because it’s fun.

When a damn curious child and a warning sign are put together, no one can imagine what is going to happen….

Story Summary [Burning a cellphone battery]
Date [between 1994 and 1996 - I was 10 to 12 years old]
That day I decided to test how a cell phone battery would react to fire
My goal was to validate that the battery would explode, and how strong would that explosion be
Test Approach: Smoke test – for real…
The result: FAIL
The lessons I’ve learnt: never ever try to burn a battery, cause you can really get injured – if not physically by the explosion, psychologically by your parents.

Description of the experiments:
When I was a child one of my greatest amusements was to read user’s manuals and electronic devices’ information. At that time [mid 90s] cell phones were in the beginning of their popularization, and I would have so much fun pretending to be using my father’s Motorola PT 550.
Straight to the point – so, my father bought a new battery since the one that came with the phone got bad and would not last longer than half and hour.
What did Leo do then?
I took the old battery in order to disassemble it, aiming to see how a battery pack would look like inside. But while reading the label on it’s back I saw a few warnings like:
- Do not reuse or disassemble this battery pack.
- Do not overcharge it.
- Do not SET IT ON FIRE. IT MAY EXPLODE AND OR CAUSE EXTREME INJURIES.

Place your bets on what caught my attention….
EXPLODE?? WOOAA, amazing!
Cause injuries? Béép. Dangerous. I should remain far from the test environment to keep the integrity of my own body.

So I built a plan – I picked up some old newspapers, the battery pack, alcohol, a bucked of tap water and a matchbox.
I also had to find a safe place to do my test – I decided to go to the front yard of my family’s house, so that I could set the battery on fire, close the door and inspect everything through the peephole.

FINE.

There went little Leonardo with a Motorola battery pack wrapped up on paper completely wet with alcohol.
I left the “device under test” in a “safe” distance from me, lit a bunch of matches and threw over the “device under test”. The matches just did not make to the battery, so I tried again, next time together with some paper, and this time I succeeded. There was the pack on fire.

I ran towards the door, closed it and looked through the peephole. The device stayed lying there on fire for a couple of minutes until the fire stopped, and when it did I got very VERY upsat (Damn, it didn’t explode).
I took the water bucket, opened the door threw the water over the “device under test” and started inspecting the wreckage…it became a brick of hard melt plastic, and nothing else.

Later that night my parents got home and smelt that plastic aroma, then they found  a burnt battery into the trash bin at the kitchen and they got SO mad. Who else could have done that? My three brothers – Eduardo, Henrique e Guilherme – would never do that king of thing, thought them…

So they came to me and said so many things, like I could have died, become blind, loose my hands, my arms, burn my face…well, all those things we usually hear from our parents, you know. And it always reminds me of that 2004 movie, Butterfly Effect. It makes me scared of the price I paid to become a real tester.

Next thing I remember is that I was grounded for two days. No Super Mario World that week.

The registrations for attendee and speakers for vodQA Pune on 17th March 2012 is now open. Looking forward to see you there :)

Why is my life Test Driven?

Long before I could ever dream about being a professional tester, and even before knowing about the existence of such an amazing and rewarding career, my favourite activity already used to be spending time doing [little|dangerous] experiments.

When did my life turn out to be Test Driven?

Such joy started in my childhood, by the time I was that little “why? why? why?“ bastard, and this behavior pattern remains still as my main motivator. It is what makes me wake up every morning and know that I got something cool to do and will learn something new, and if I won’t, at least I’ll go break something old.

What is my intention with this “My Test Driven Life” thing?

Since I am still a kid (born 1984, but my ideas are not more advanced  than those a kindergarten kid would have), in this blog you will probably read some stories that are pretty recent.
The idea behind My Test Driven Life is to share fun experiences I go through in the course of my life as well as the valuable lessons I learn each and every time something new happens.

How am I showing you the tests my life is driven by?
For the sake of your own pleasure (not to say patience) the following format is applied in all the stories I reveal here:

-Story Summary [Doing something stupid]
-Date [a close date and my age by the time the action happens]
-That day I decided to test [what]
-My goal was to validate that [what]
-Test Approach: [Smoke|Acceptance|Unit|Performance].
-The result: [PASS|FAIL]
-The lessons I’ve learnt: [what did I learn doing this test?]

-Description of the experiments:

<<here goes the long story>>

Hope you enjoy. Feedbacks are welcome, either the goods and the bads.

If you ever have a story to share, PLEASE send me an e-mail and I promise I’ll format your story and blog it here.

Dear Devs,

Have you ever had code bounce immediately out of test because it just didn’t work? It’s messy and wastes a lot time. You’re expecting the tester to do all your testing, a common mistake. We’re not asking you to do two jobs, with a little effort you can tidy as you go, catching these basic problems yourself.

The following are helpful, let our conscience be your guide.

Before you start work, check what you’re doing makes sense. Talk it over, ask who, what, where, when and why. Verify that what you’re going to do is what they want.

While coding, ensure the code actually does what you believe it does. Stray from the happy path; what could a user do by mistake? How could a user cheat the system? Ask questions like “What happens if I…” and get answers. Not all who wander are lost.

Your development skills will help you. Use your knowledge of code to bend it a little. Does any part of the code make you feel queasy? Start there.

Check white space, min and max lengths, validations, mandatory and optional fields, nulls. It’s literally (not figuratively) painful for testers to report these kinds of problems. Just make sure it works. Please.

To conclude, your forays into testing won’t replace a competent tester but it will save them time and heart ache; let them focus on more devious aspects their craft.

I recently discovered an interested fact. Studies show that we perceive ourselves to be 20% more attractive than we actually are.

This was one of a handful of fascinating studies described by Robert Trivers during an RSA talk about his latest book Deceit and Self-Deception: Fooling Yourself the Better to Fool Others

Trivers has spent the last few years studying the peculiar phenomena of self-deception. The basic premise of his book (which I plan to read asap) is the hypothesis that deceit and self-deception are linked. From an evolutionary perspective, it is logical that we can better convince others of our superior status, strength, attractiveness etc. if we believe them to be true. I won’t attempt to outline the arguments, you would be better off reading the book or listening to the audio of the RSA event.

Let’s assume that the hypothesis, “We deceive ourselves to better deceive others” is true. What does that mean for Product Managers?

Most Product Managers are the biggest champion of their product. I don’t know of a Product Manager who would work on a product they didn’t believe in. That belief needs to be infectious for your product to grow. Colleagues, customers, friends, strangers should all be left with a great impression of your product after speaking to you.

But what if, we are fooling ourselves? What if we view our products as 20% more appealing than our customers do? All that confidence is great when pitching a product or when writing convincing copy, but does it help us build products that people want to use? Are we biologically predisposed to seek out vanity metrics relating our products? How do we deal with this potential misperception?

My gut reaction is to be even more driven to back up my vision with facts.  To always strive for a good balance of quantitative and qualitative data about my product. Make sure I make a habit of getting out of the building.

From now on I will try to always challenge myself whenever I big up my product to myself, especially when it seems automatic.

I could of course be wrong. Maybe truly believing your own hype makes the difference between success and mediocrity?

 

"No sympathy for the devil; keep that in mind. Buy the ticket, take the ride...and if it occasionally gets a little heavier than what you had in mind, well...maybe chalk it off to forced conscious expansion"

 Hunter S. Thompson (Fear and Loathing in Las Vegas)

On our mailing list where we discuss all sorts of important development issues and organise pub trips, a mate of mine came up with an interesting problem to do with testing - It went a bit like this ..

“I've just been talking to someone who I has attempted agile without any QA or automated tests at all. Unsurprisingly they've seen an increase in regression issues and are now looking to retrofit done automated testing.”

As the resident tester it got me thinking. What is the cost of regression testing in an agile project ? - well the cost in my opinion is actually 0, zip, nadda, snake eyes !!

Right about now everyone who has faced the cost of regression testing is thinking I am smoking crack? or maybe hill billy drunk on the 4th of july? - I’m not and here is why.

Lets say you have a project you estimated at 30 points - whatever - you figure as you are going along you can do roughly 5 points a week including getting it manually QA’d in a test environment and showed with great fan fare to your product owner  - Happy days!! - you will be out of there cashing the check in 6 weeks... 

or will you.. 

What was your ACTUAL velocity??

Easy I hear you all say - 5 points!! 

The problem is, it wasn’t really - The 5 points a week was stuffed with tech debit, Now I’m not talking the stupid tech debit i’ve cited before where you just sweep all the hard stuff into the tech debit backlog to temporarily inflate your velocity (and we all know how thats going to end) I’m talking about serious tech debit that wont bite you for a month or so. The question is actually what did you DO for that 5 points? 

Write code that solved the problem?

Or write code that solved the problem with unit tests, integration tests, platform tests, automated UI tests that prove every build and deployment you haven’t broken anything??

In most cases its the former  - And here is where logically (though not financially I’m sorry to say) it doesn’t cost. What is actually happening is your velocity gets corrected. You weren’t doing 5 points, you were actually doing maybe 3 but incurring the tech debit of poorly tested code allowed the team to inflate their velocity to an unrealistic 5. The over all correction theoretically will be 4 weeks in this case - but anyone who has tried to go back and retrofit tests to poorly tested code will know its harder than writing them at the time. so in this case it will take longer. 

I guess if you can guarantee some other poor stooge will have to deal with it later you *could* give them crappily tested code to work with but once the smell has pervaded the building you wont be working back there any time soon and your rep wont be the greatest.