Explaining Testing to 5 year old kids

On a popular forum a question was asked about how to explain Testing to 5 year olds. Here is how I responded.

I would divide the tiny tots into two groups. Call one ‘Creators’ and the other as ‘Correctors’. Next I would give the creator group a box of coloured clay and a large picture of a complex but easy to make animal (straight from Spore like this one).

I would tell the “Creators” to start making different parts ensuring as much perfection as possible in respect of colour, shape, texture & so on not to forget say the emotion in certain parts like say eyes. Within the same group a bunch of kids would collect the parts and create the animal. ***The units thus  have been developed and integrated… if only it was so easy***.

I would meantime ask the “Corrector” group to watch the other group by being close but not talk or give comments. (***If they have to then we are talking agile not old fashioned waterfall which what this exercise is***).

Once the animal (***sadly referred to the application also by many distinguished professionals in the middle of the night or on the m+nth day when the release ought to have been made*** ) is delivered the Corrector group go to work by pointing the mistakes in the sculpted model vis-a-vis the picture. The Corrector group would inform about these blemishes to the Creator group and ask them to make the corrections.  The fun that results from the arguments that ensue would bring tears to our eyes for sure.  Ha!  The ‘not-closed’ arguments could be escalated for resolution to you – ‘the customer’. It should be easy enough bug-triage.

Now after this exercise you are in a good enough position to relate what has been described here with what happens in real with you/us.

Hope this helps. One request though – If at all you like this or any of the responses from our distinguished community & carry it out on Fathers Day – it would be fun to hear  what transpired and your experience with the young geniuses. It would be a good read rather than some of  the ego-pokes about this & that I get to read on this forum though I learn also from that.

Maybe through hearing about your experience, we could relive some of our innocence left behind even if for a moment.

P.S. On STC I think a question was raised about how to explain Testing to ones Mother, now this with Children. What next – our spouse? Let it come.

 

Advertisements

My Blog Effigy

I used the Wordle toy and fed it my blog’s URL and see what popped out.

a "Picture" speaks more than a thousand words!

Does it convey something in a snap? It sure does and so the toy for its sheer creativity is a great tool, indeed. Go play!

Test Management Tool Features

Someone posed a question on Linkedin about features to have and wish for in a Test Management Tool. I wrote a response as below.

A) Requirements whether definable within the tool. If not and a Requirements Management Tool is envisaged or known then the Test Mgt.Tool to link up effectively with the requirement ids.

B) The link between the two will help you derive the test cases written vis-a-vis the requirements and later on how the defects stack up against the requirements suggesting which areas are buggy.

C) The flexibility of test reporting whether you just started the phase, in the middle of it or finished it a while back. Check the reporting from a technical and management perspective from an analysis and ease of understanding point of views. Does it handle consolidation of numbers across test cycles for a project and across projects across a period of time thus facilitating comparison. Check also whether Plan v Actual information is available.

D) The customisability features available in tuning the test report as per you need. Say you need to put in free-format text to explain the numbers or graphs as part of analysis.

E) Export/Import feature to/from various formats like Excel, PDF etc.

F) The roles available within the tool and the associated workflow. (check how effectively it maps to the existent one in your organisation and for the gaps how you will handle it).

G) How effective are the collaboration features in case the teams are geographically separated. (Look at teams working across time zones and whether the tool can facilitate communication in terms of baton passing from one to the other.

I) The contingency features – what if the tool crashes in the midst of system test. What are the fallback features. Can we quickly pick the pieces and keep with the schedule without any panic.

J) The capability to write once and batch different tests for different needs say to test comprehensively (across different cycles); regression test; smoke test, compatibility tests and so on.. check how it ties in with the reporting.

K) Audit Trail / Security features incl. access privileges.

L) Does the tool capture information/parameters like reviews, derived metrics (calculated fields), environment information, number of test cycles, personnel details & so on.

 

 

 

If I was a test case I would…

My creative juice flowed months after I saw the responses to the idea on Software Testing Club  & late enough to miss the ebook. While I miss the thrill of seeing my name in print (Ha!) my testing ego is certainly not bruised at the cost of my creativity cajoling me with this –

If I was a test case I would aspire to be like the lighthouse to help navigation in choppy waters; a police dog to sniff out the bad ones and a torchlight to illuminate the road less traveled…

Let the light shine in our world!

“Process? Ohh $#*t!!”

The p-word brings to mind how people associate it (process that is) with either documentation, collection of metrics or numbers that is never ending taking different forms, boredom, smirks around the table or succumb and don’t complain thoughts (an escape mechanism to end the discussion quickly).


What is not realised is that process is not something that is cast in stone or something that has to be accepted like a guillotine. It is something that one has to believe in. But because it has worked for someone before it does not have to be accepted in all situations. So one has to question, think and debate in one’s mind and along side the views of those who are impacted before it is something that becomes process for the time being…

A discussion on Linkedin prompted me to post a response to  the question on institutionalizing a QA Process.

1) For any process change believe in them first and in them being able to achieve what they have to not just from the organisation/top management end but also from those from the practitioner’s as applicable by understanding what is in it for them.

2) Make the process changes by focusing & prioritising on those that make an impact on deliver/quality/cost aspects impacting the end-user or the customer. It would be easier to convince the practitioners that bettering the process would benefit them indirectly by introducing elements that bring about customer delight. Thus try highlight the value of the process rather than the mundane aspect of say some numbers collection & crunching.

3) Understand the process independently of the organisation and the practitioner and play the devil’s advocate which may help balance the process out. Be sure “not to play the tune” as the powers-that-be want you and be ready to persuade and convince of the ills that might be in the proposed process changes.

4) Introduce process changes in an agile manner by doing it bit-by-bit and through collaboration, communication and taking the team along with you.

5) As has been mentioned here by others – the process is never independent of the people and both have to co-exist for some meaningful output to occur.

6) Remember you are a facilitator and should believe in the greater good trying & playing the wise-one to perfection & listen listen listen…

Believe in the value that emanates and not the process per se.

For the complete discussion see the link here.

When institutionalizing a QA Process, would you save the resource or would you strive to achieve the goal?

Hello! Is anyone out there!

After eons I am back to what I do best (amongst other things, ahem ahem) and that is writing and it feels good and as my hands shiver with excitement I think it feels exhilarating more than  just ‘good’. So there…you know I am here for life!

What I have been upto is perhaps a shade less exhilarating I would admit.

But the real fun is around the corner I guess….

I have been doing all of this lately –

  • Reading up on behavioural aspects of Psychology (check my Linkedin Reading list) and being fascinated by the works of people like Liebermahn, Ekman etc. I have been reading these and others on my NookColour which is a gift to myself in celebration of myself getting wiser by the day.
  • I continue to be impressed by contents of  most of  the testing blogs written by testing gurus as well as new kids on the block though I wish I could read more…
  • An acquaintance gifted me a download of ‘Criminal Minds’ (All Episodes – Seasons 1 to 5) on my birthday and I have been following the exploits of Hotch & his team. Have been joyously and studiously lapping how they dig the minds of serial killers, perverts, sadists & so on. On display amongst the  professionalism that the team displays in solving the crimes through behaviour analysis is the sad & grim reality of the fate of their personal lives.  (Next up I hope someone does me a good turn for ‘Lie to me’. Aah hope!)
  • Using my slightly better than basic knowledge of Photoshop I turned in a composite to participate in the STP driven contest (started to drum excitement & entry into their upcoming conference). Here is my picture submission and the link below. Go ahead & vote for those you consider worthy.

http://www.stpcon.com/PicPit.aspx

But I have been doing all this besides discussing an opportunity which I am excited about but sshhhh… more of that later once it is clothed in ‘official’ reality.

Setting up Testing

I came across a blog post on the web about setting up a testing department and took inspiration to write my own piece based on my past experiences and what I would do if I get the opportunity again. (I must add that I blogged about this earlier though in bits and pieces).

"You can dream, create, design and build the most wonderful place in the world, but it requires people to make the dream a reality" - Walt Disney

This is comprehensive in my view and this is how will I go in a step-by-step manner to set up a revenue-generating testing unit from the ground-up.

  • Understand the ethos of the organisation to gauge the level of willingness to accept testing as a new contributing function.
  • Have a series of meetings with impacted (non-testing) managers and influencers:
    • to inform about the testing function and how it will mesh in (eg. speak about the Agile way) to shape up application behaviour;
    • Assuage any feelings about testing trying to ‘steal the thunder’ or testing being a roadblock;
    • Make a best effort to nip the power-tug-of-war in the bud by demonstrating and speaking words that echo team spirit, maturity and pragmatism. Display a chest-out, no-nonsense attitude.
    • market the capabilities sought to be added to the table and how it will benefit all in the ultimate analysis.
  • As per the budget and need, start hiring people keeping capability, diversity and team structure in mind.
  • Hire uncompromisingly those who will assimilate into the testing culture sought to be ingrained and keep deterrents out, however brilliant they maybe. Keep the tester attribute checklist handy.
  • Create and mentor an interviewing team upfront into interviewing/shortlisting/hiring aspects and related. Refer Cem Kaner’s article on ‘Hiring Software Testers’ and other good practices.
  • Build a team that throbs passionately and build brick by brick from day 1.
  • Form a core team upfront comprising of test managers, self, leads and bright upstarts to deliberate on functioning, issues, infrastructure, tools and resourcing needs of the test team. Meet regularly upfront and periodic later as per need. Prepare status report comprising discussion points and actions. Distribute to Management and key stakeholders.
  • Form a team to deliberate, decide about testing servers, tool for logging bugs, etc. This team would self-destruct after procurement and implementation.
  • Begin assigning testers to projects understanding need & fitment. Monitor & mentor.
  • For new projects begin work in earnest from estimation to delivery and related expectations setting as the project progresses. It is expected that there will be feet that will feel being treaded on and territory trespassing feelings. Listen, understand and straighten out matters unemotionally and professionally. Ensure that results speak louder than words at the end of day for that will linger more than the ‘pee-squirts on the trees’. Monitor and Mentor continually drilling into your team about test team being hard-working investigators and fearless journalists rather than  gatekeepers.
  • Begin the task of reusing, renovating or creating generic artifacts for test planning, estimation, test cases, reports, tools, etc keeping the standards and delivery timeline in mind. Deviate where necessary with ready justifications with highest priority accorded to testing, progress and results (information sharing).
  • Profile the team and identify gaps in knowledge and skills (technical & soft).
  • Enlist testing thought trainers who are practitioners first and last to mend & remedy the gaps and elevate capability levels.
  • Start building a library of books, videos, 5-starred web articles of testing masters (stored within EverNote) and so on to lend credence to the importance of coninued learning.
  • Encourage people to share and present snippets from real life testing experiences which brought cheer, new learning and won credibility of the customer. This would not only help knowledge percolation but also inflame team bonding and development to new levels.
  • Set meaningful and mutually accepted performance measurement criteria for testers. As per this ensure the feedback is given not as a ritual but driven by circumstances and need to help the individual and team growth. At the same time accept suggestions for improvement and feedback from the reverse direction showing willingness to listen and remedy if justified.
  • Meet the team regularly keeping an open door and motivate, compliment and reward achievements in monetary and non-monetary manner. Create events to meet the team in an informal manner to let the hair down so to speak.
  • From the testing success stories identify 2 things – stories that will sell and actors within it who starred – who would be superstars come the prospect/customer (in plain speak make case studies of them to help your sales).
  • Once levels of testing capabilities assumes both depth and breadth then start building a team of mavens across testing fields (say Automation, Non-functional testing areas, Manual testing etc.). Preparing collaterals like fact sheets, case-studies, presentations etc. is a logical next step.
  • Whilst the team grows and in the light of new customers coming in, never lose sight of delivery to existing customers which remains top priority.
  • If required and driven by the P&L – hire resources to document, market and sell your capabilities to add teeth to your team which would thence throb with more exciting possibilities.
  • Continue to mentor, monitor and build.