08 October, 2009

Get your Context Right

Once upon a time, there lived a beautiful Princess. The Supreme Commander of the kingdom lusted on the Princess, while she fell in love with one of the greatest warriors of her kingdom who trained soldiers for war. She admired him for his bravery and courage. This resulted in a battle between the commander and the warrior on a tall mountain which is 10 times bigger than Mount Everest. After a futile attempt to kill the warrior, the commander took revenge by piercing a dagger in the Princess’s heart. She lay motionless at the edge of that mountain while the warrior killed the commander. The warrior runs towards the Princess to say that he loves her…. something that he never confessed to her until that time though he loved her. And the Princess dies and slips from the edge of the mountain. The warrior sees the Princess falling down, runs back a few steps and jumps from the mountain hoping to reach out to her. He somehow manages to go close to the falling Princess, but not close enough to catch hold of her.

I was fully involved watching this scene in a multiplex theatre when my niece shook me up with a question. ‘Did you know that the warrior can never reach out to the Princess if he jumps with an initial velocity 0?' I was like 'What? Why do you think so?' She said ‘The dead Princess slipped off with an initial velocity 0 (inertia of rest). However, the warrior went running and jumped off the mountain with a certain velocity say ‘X’ (inertia of motion)'.

She continued ‘If the warrior jumped with initial velocity 0, then the distance between him and the dead Princess would be same until the Princess reaches the ground. If the warrior jumped with an initial velocity ‘X’, then the distance changes and he will be able to get closer and even reach the Princess’. It was a truly ‘WOW’ moment. I am pretty bad at physics thanks to my teachers who only forced and tortured me and my class mates to learn formulae by rote and vomit it in exams. It is also my mistake that I never questioned what I was taught (shame on me!).

Imagination, Analogy, Practical thinking is infinite. This experience left me thinking for quite some time. As a tester, I set a mission for myself to ‘Test whether the warrior catches hold of the Princess’s hand and report my observations’. Just like any movie buff, I got busy watching the warrior reach out to the Princess. What if I did not know anything about initial velocity? What if I did not know under what circumstances the Princess fell off the mountain? What if the Princess jumped at her own will? What if the warrior suffered a shock, died and then slipped off the mountain. I would end up watching them falling until they reach the ground without focusing on my mission.

It is important to understand the context be it testing or problem solving or even a crime scene investigation.

1. What problem is the application intended to solve?
2. How will the application be used in a real world?
3. Who is the target audience for this application?
4. What is the environment/platform in which the application will be used?
5. Where does the application stand with regard to competitor products catering to a similar target audience?
6. What is the expected scalability for the application in the near future?
7. What kind of performance is expected of the application?


Without knowing answers to many more questions like these, testers can only do superficial testing leaving out critical defects in the application intact. Imagine the plight of the customer who buys this application?

We talk about getting laid off in our organizations. We do not talk about why the organization laid off or even shut down the entire office. We ask about why the organization did not retain people with the profits it made the last to last before year(correct me if this phrase is wrong). We do not ask why the customers did not buy the application. We need to provide the application the way the customer wants it, not the way we want it to be. If we do provide the way we want it to be, it will be with us. It will never go to the customer and by god's grace(sales/marketing) even if it does, it will come back to us. Do we want the application to come back or the appreciation?

Get your Context Right,
Parimala Shankaraiah
http://curioustester.blogspot.com

14 comments:

  1. [2. How the application will be used in an ideal world?]
    We always test in an ideal world,i think this should be
    "How the application will be used in real world?"
    or Correct me if I didn't understand the context here :(
    Regards,
    Dhanasekar S.

    ReplyDelete
  2. @Dhanasekar

    How the application will be used in an ideal world?]
    We always test in an ideal world,i think this should be
    "How the application will be used in real world?"


    Agree. Changed it to real world

    ReplyDelete
  3. "Do we want the application to come back or the appreciation? "

    Further to your post..

    Shit happens...it is life .... it is not unusual to earn flak when you release ...lets assume that shit has happened (could be anything...test team;s fault...agressive sales pitch/timelines ..incorrect,unknown requirements,environment etc ..does not matter)

    OR
    plainly what if we dont know the context and have flunked ?

    Now comes the critical part..how to we mitigate the disaster...dust ourselves up and gather everything that is torn apart & perform again...prevent it into taking catastrphic proportions..

    Here is where post release support/customer issue trouble shooting/post mortems/lessons learnt for future release etc comes into picture ...

    customer issue/problem resolution is make or break for a company .

    These aspects also have to be as strong(if not more) and robust to all the initial jazz that we do .

    thanks
    sunjeet

    ReplyDelete
  4. @Sunjeet
    Now comes the critical part..how to we mitigate the disaster...dust ourselves up and gather everything that is torn apart & perform again...prevent it into taking catastrphic proportions..



    Good points. No software is perfect. I agree that it is about trust building with the customer. Once the application ships to the customer, the general attitude atleast for the first one year is like 'We paid for it, you better fix whatever we ask you to'. Without good Customer Issue Escalation and Resolution process in place, it becomes hard to gain reputation for the application and the organization.

    Thanks,
    Parimala Shankaraiah

    ReplyDelete
  5. "We need to provide the application the way the customer wants it, not the way we want it to be"
    Parimala, do you really think that customers know everything they want? Is this statement valid in every context?
    To quote Henry Ford, "If I had asked people what they wanted, they would have said faster horses."

    Thanks,

    Thejaswi

    ReplyDelete
  6. @Thejaswi
    do you really think that customers know everything they want? Is this statement valid in every context?


    That is a cool question Thejaswi. More often, customers know what they want. But they do not know how to ask for what they want. They do not know how to put it across to technical people about what they want. And yes, it depends on the context. It may or may not be valid for every context.

    Thanks,
    Parimala Shankaraiah

    ReplyDelete
  7. "They do not know how to put it across to technical people about what they want"

    I think Tejaswi's question stands 100% true..

    Well...as far as I know ...customers are rarely in touch with "technical" people for what they want...their first/persistent point of contact is mostly non-techie people...e.g.sales..BAs..PMs...support etc...

    and rarely tech or QA leads..i.e. the hard core techie people

    And saying that customers dont know how to put it across....is a little lame to be honest...well customers would always have a vague idea of what they want...the onus is upon the solution providers etc to ELICIT what they really want or not want !

    ReplyDelete
  8. @Sunjeet
    And saying that customers dont know how to put it across....is a little lame to be honest


    I disagree. This sounds like a trial and error approach to me. Though the customers are talking to BAs or PMs, they are usually technically aware of what they want. Though their emphasis is on the funtional aspect or something of their interest, they do include a few technical people to get their message across.

    In one of my previous organizations, we used to have TAMs (Technical Account Managers) who represented the customers and dealt with the PMs directly. They were not only knowledgeable functionally, but also tech-savvy. Apart from that, atleast 1 Tech lead and 1 QA lead used would take part in the Product related discussions at any time. Again, this was a practice in that organization. It is possible that this depends on the organization and/or the customer and how willing both the parties are to go out of their way to create a win-win situation.

    Thanks,
    Parimala Shankaraiah

    ReplyDelete
  9. “They do not know how to put it across to technical people about what they want.”

    Could we reconsider this statement?
    How about companies where technical team is not involved with customers? In cases of product-based companies, where innovations are made, who never know who their customers would be until the product is released and sold?

    “Well customers would always have a vague idea of what they want...the onus is upon the solution providers etc to ELICIT what they really want or not want!”

    I agree with Sunjeet. Most often, testers could be solution providers or add value to solution providers. Based on their intuition, prior experience, product comparison abilities and analytical skills, customer need could be satisfied rather than customer’s wish.

    “I disagree. This sounds like a trial and error approach to me.”
    Trial and error could lead to better innovations.

    Thanks

    Thejaswi

    ReplyDelete
  10. Hi Pari,

    Rightly said. Many a times it is important that we understand the core objectives of the application before we start to test.

    I have worked on a project where the system was intended for the Management of AIDS patients. Now when I started testing it, I had a few questions which went unanswered like:

    1. How do we know if a patient is a AIDS patient or not.
    2. Whether the drugs prescribed by the system are accurate.
    3. Since everybody knows AIDS cannot be cured, what if the data collected after a month or so does not indicate any of the AIDS symptoms. In this case will the system say this patient is not an AIDS patient which is as against the fact.

    When these questions were answered, I really enjoyed testing the system.

    Thanks,

    Rajesh
    http://testeazy.blogspot.com

    ReplyDelete
  11. @Thejaswi
    How about companies where technical team is not involved with customers? In cases of product-based companies, where innovations are made, who never know who their customers would be until the product is released and sold?


    I am thinking that in this case, though the product is ready to ship and a new customer walks in, he/she would provide a list of requirements to the organization and ask them to customize the features as per their expectations. Even if engineering folks are not involved in direct discussions, the final customization requests would still come to them through the BAs or PMs. Based on the feasibility of requirements, they would either customize or even implement them as brand new features. I do not think that anything can be released to the customer without involving the technical people at the end of the day.

    I agree with Sunjeet. Most often, testers could be solution providers or add value to solution providers. Based on their intuition, prior experience, product comparison abilities and analytical skills, customer need could be satisfied rather than customer’s wish.

    I dispute the fact that testers are solution providers. Testers are not solution providers. Testers are information providers. This information will be used by the decision makers to evaluate the health of the product.

    Trial and error could lead to better innovations.
    Trial and error can lead to innovation, but that should not become a process to follow. This is what I meant.

    Good Stuff,
    Thanks,
    Parimala Shankaraiah

    ReplyDelete
  12. Wont say that testers are 100 % solution providers ....but in places that I have worked previosuly/currently working , testers have been empowered with the authority to SUGGEST solutions .
    "Testers are not solution providers. Testers are information providers."

    Does that mean testers can not suggest enhancements ?? or propose workarounds

    "solution providing" is not just coding/implementation....but includes everything from requirements gathering to maintenance and all the bits and pieces contributed from each and everyones in the team/teams that leads to the product/project being a reality

    Personally , I wont strait-jacket myself to being just a information finding tester ..
    e.g -
    I remember a recent scenario where in a triage meeting , an issue was discovered by me ( a critical one...saying this should not behave like this ) Because the functionality was new...had no concrete requirements neither the requirements guy nor devs had an idea as to what should be correct & alternate behavior.
    In this instance ,test team put their hand up ...came forward and suggested an alternative ( to a fair technical degree) which was accepted and is in production right now .
    But for this to happen your organization has to have faith in the test team and tester's voice needs to be heard !

    hope this helps...

    ReplyDelete
  13. @Sunjeet
    Does that mean testers can not suggest enhancements ?? or propose workarounds


    Sorry for the delay. Testers are always entitled to their opinions, suggestions, enhancements or even conceive a completely new feature altogether. Providing these does not mean that it will get implemented right away. If it did, then you are the solution provider. If it does not, then you have ideally passed on the information to the decision makers/management which in turn helps them take better decisions. You as a tester are not the decision maker anywhere here.


    In this instance ,test team put their hand up ...came forward and suggested an alternative ( to a fair technical degree) which was accepted and is in production right now .

    Though the test team suggested an alternative, it was not the test team who accepted it. It would ideally be Product Management for the most part who decides how and when it will be implemented. Correct me if I am wrong. This is how I have seen it happen in my career so far.

    Thanks for this fruitful discussion,
    Enjoy discussing with you,
    Parimala Shankaraiah

    ReplyDelete
  14. Hi Pari,

    Nice post.

    I failed miserably in solving the logic and theory behind Rajnikant's stunts. These stunts not only puzzled me but also many including scientists, physists and mathematicians i believe :-)

    Jokes apart. Believe me, it's more complicated when we interact with people compared to systems/MC's. The other thing is, we shouldn't mix right/wrong things, ethics, morals and business any time. The way management convey things with their emloyees and their clients differs many times. Don't want to elaborate on this one but this is the truth.

    These very words, information and solution providers are used interchangeably many times and both works many times and both doesn't work some times. Say for example, while we be testing we might gather some crucial information and provide that to customers and they might ask you for the better solution if available. Depending on their immediate requirement and the budget your suggestion might be implemented or some times not. That results in information providers and solution providers.

    Cheers,
    Vijay...

    ReplyDelete