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
[2. How the application will be used in an ideal world?]
ReplyDeleteWe 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.
@Dhanasekar
ReplyDeleteHow 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
@Sunjeet
ReplyDeleteNow 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
"We need to provide the application the way the customer wants it, not the way we want it to be"
ReplyDeleteParimala, 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
@Thejaswi
ReplyDeletedo 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
@Sunjeet
ReplyDeleteAnd 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
“They do not know how to put it across to technical people about what they want.”
ReplyDeleteCould 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
Hi Pari,
ReplyDeleteRightly 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
@Thejaswi
ReplyDeleteHow 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
@Sunjeet
ReplyDeleteDoes 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
Hi Pari,
ReplyDeleteNice 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...