http://www.satisfice.com/articles/hrbt.pdf
Worth a read !!
Wednesday, July 6, 2011
Thursday, February 24, 2011
Friday, January 28, 2011
Tuesday, September 21, 2010
Why ask - Why testing ?
As we were talking about questions the software test engineer has to ask and how he needs to ask them, I was struck with the thought on what questions people ask test engineers and why?
Some of the questions I generally get asked all the time are :
Why Testing ?
Some of the questions I generally get asked all the time are :
Why Testing ?
What do you guys do ?
Why do you WANT to break software ?
Isn't it boring ?
Did you start out to do this when you were studying ?
Is it even engineering ?
etc. etc.
Why do you WANT to break software ?
Isn't it boring ?
Did you start out to do this when you were studying ?
Is it even engineering ?
etc. etc.
There are probably tons of blogs all around talking about the art or science of test engineering but here's my take on why people have these questions in the first place.
- Most people don't realize that each and everything that we use has to be tested. Creating any and everything is an iteration. Even GOD had to make several iterations before finally creating humans :) And the evolution goes on. Anything that exists can be made better. We started with a plain dumb telephone which was lying there in one corner of the house and fast forward 100 years and we have the "smart" phone. Somebody has to always say - "Yeah this looks pretty good, BUT we need to fix this/that and maybe add this to make it better". That is the place testers come in. They use the product, know how it is built, try to get at the flaws before everyone else jumps onto it and give suggestions/corrections to the creators on what can/should be done to make it better. Wonder why every healthy government needs to have an opposition party ? That's the exact same reason you need a good testing team - to debate your ideas, bring up situations wherein this policy/solution might not work, try to make it fair for the entire population/users,etc, etc.
- Software testing is (surprisingly !! ) NOT taught in schools. This is changing rapidly though but the people who are already in the field for many years and especially people outside it sometimes do not realise the value of it. Personally I think there should be a mandatory course for software testing for each and every software developer. The way I see it is- its not important how many lines of code you right in a day, what is actually important is how many of them actually work well in all the possible cases. How many times would you visit facebook if every other time you visited the site was either down or you ran into a bunch of errors while accessing any piece of information ?
- A popular myth is that the failure to a software is not as critical as failure in some other professions like civil engineering or medicine. With the extent at which we are relying on software these days, its getting more and more critical every passing day. Every sector from healthcare, telecom, aeronautics to banking have complex software systems running them. If these systems are not properly tested the outcome could be pretty embarrassing for the company who wrote the software and the one running it.
- People often think test engineers are people who were not good enough to get into development. This comes from a common misconception that test engineers read from a precreated script and just check if those things work fine and do not have to think much - It is repetitive and boring. Its actually quite contrary to that, you need to know the depth and breadth of the system to break it. It is an art as well as a science. All the hackers out there who break into production systems are basically expert testers who know defects which might not have been discovered by the other test engineers. For details on what a test engineer does refer this.
Like anything related to software, software testing is a fast evolving field. People who work in it or intend to work in it need to know its worth. There'll definitely be managers, co workers and in some cases even companies who do not realize the importance of testing but eventually they will and in a not so pleasant way. As the Digital Revolution reaches the masses and as the systems become more and more complex and interdependent the demand for a test engineer who knows his ways around and can find vulnerabilities and critical defects quickly will rise.
- Most people don't realize that each and everything that we use has to be tested. Creating any and everything is an iteration. Even GOD had to make several iterations before finally creating humans :) And the evolution goes on. Anything that exists can be made better. We started with a plain dumb telephone which was lying there in one corner of the house and fast forward 100 years and we have the "smart" phone. Somebody has to always say - "Yeah this looks pretty good, BUT we need to fix this/that and maybe add this to make it better". That is the place testers come in. They use the product, know how it is built, try to get at the flaws before everyone else jumps onto it and give suggestions/corrections to the creators on what can/should be done to make it better. Wonder why every healthy government needs to have an opposition party ? That's the exact same reason you need a good testing team - to debate your ideas, bring up situations wherein this policy/solution might not work, try to make it fair for the entire population/users,etc, etc.
- Software testing is (surprisingly !! ) NOT taught in schools. This is changing rapidly though but the people who are already in the field for many years and especially people outside it sometimes do not realise the value of it. Personally I think there should be a mandatory course for software testing for each and every software developer. The way I see it is- its not important how many lines of code you right in a day, what is actually important is how many of them actually work well in all the possible cases. How many times would you visit facebook if every other time you visited the site was either down or you ran into a bunch of errors while accessing any piece of information ?
- A popular myth is that the failure to a software is not as critical as failure in some other professions like civil engineering or medicine. With the extent at which we are relying on software these days, its getting more and more critical every passing day. Every sector from healthcare, telecom, aeronautics to banking have complex software systems running them. If these systems are not properly tested the outcome could be pretty embarrassing for the company who wrote the software and the one running it.
- People often think test engineers are people who were not good enough to get into development. This comes from a common misconception that test engineers read from a precreated script and just check if those things work fine and do not have to think much - It is repetitive and boring. Its actually quite contrary to that, you need to know the depth and breadth of the system to break it. It is an art as well as a science. All the hackers out there who break into production systems are basically expert testers who know defects which might not have been discovered by the other test engineers. For details on what a test engineer does refer this.
Like anything related to software, software testing is a fast evolving field. People who work in it or intend to work in it need to know its worth. There'll definitely be managers, co workers and in some cases even companies who do not realize the importance of testing but eventually they will and in a not so pleasant way. As the Digital Revolution reaches the masses and as the systems become more and more complex and interdependent the demand for a test engineer who knows his ways around and can find vulnerabilities and critical defects quickly will rise.
Wednesday, September 8, 2010
Its a question of a QUESTION
Sometimes I wonder, Have I become the eternal pessimist? Everytime I come across some good news, while in my heart I feel happy, my mind is already at work about whats wrong about it!! Everytime I talk to my mom and she tells me about some decision she made, I ask so many What-if questions that she gets angry at me but later starts reconsidering her decision. People close to me sometimes tell me why do you always want to play the devil's advocate? Sometimes they don't like my challenging their decision. Sometimes a question asked at the right time can save millions, sometimes it can bruise egos.
Everyone asks questions. Kids ask "why?" about everything. Why do i have two eyes? Why does it rain? Why is the water blue? Why do i have to go to school? And most of the times they will either come up with the next question or ask the question again and again till they are satisfied. But as grownups a lot of people feel uneasy about asking questions because they fear looking stupid. I was like that too. But as a test engineer you cannot afford to have that fear. For a test engineer there is no alternate to asking questions. For me my questions define the quality of work I do. Questions separate testers from engineers (look at the first post for my version of the difference). The key here is to ask the right question, to the right people at the right time. Before asking questions, do your homework. Below is a rough checklist I generally use :
-Check if the answer is out there somewhere!! Just because you have been lazy to read do not ask questions starting with "Hi, Probably this is already out there somewhere or I am just being stupid, but......?"
-Always ask a meaningful and specific question. Remember that putting too much info in the question itself does not mean that you know your stuff. Also it makes it difficult for the other person to understand and reply, and hence there are less possibilities of your getting an answer!!!
-Describe the facts explicitly and do not contaminate it with your guesses.
-Do not expect someone to look at your stuff and tell you what you are doing wrong.
-The earlier you ask the question, the better. Do not wait for later.
-Understand that there is a difference between simple/basic/fundamental vs stupid question. If you feel that you have done good research and still you cannot figure out: Ask the question!!
-First Google, then Ask :)
Also, right questions help clear up unrealistic expectations. I lot of times it happens that you are working on some feature and your manager/ product owner comes and asks you to work on something else. Some people would jump at the new task immediately as someone with higher authority asked them to do it. But just by simply asking a few right questions you can get a much better picture of where it prioritizes in your list of things to do!!!
Why are we doing this?
How is this different then what we do now?
Why was this not important before?
Who all are affected by this?
When is the right time to do this?
Why When What Who How...........................
.. this list can be as long as you want.
Do not stop until you get all the answers you are looking for.
Everyone asks questions. Kids ask "why?" about everything. Why do i have two eyes? Why does it rain? Why is the water blue? Why do i have to go to school? And most of the times they will either come up with the next question or ask the question again and again till they are satisfied. But as grownups a lot of people feel uneasy about asking questions because they fear looking stupid. I was like that too. But as a test engineer you cannot afford to have that fear. For a test engineer there is no alternate to asking questions. For me my questions define the quality of work I do. Questions separate testers from engineers (look at the first post for my version of the difference). The key here is to ask the right question, to the right people at the right time. Before asking questions, do your homework. Below is a rough checklist I generally use :
-Check if the answer is out there somewhere!! Just because you have been lazy to read do not ask questions starting with "Hi, Probably this is already out there somewhere or I am just being stupid, but......?"
-Always ask a meaningful and specific question. Remember that putting too much info in the question itself does not mean that you know your stuff. Also it makes it difficult for the other person to understand and reply, and hence there are less possibilities of your getting an answer!!!
-Describe the facts explicitly and do not contaminate it with your guesses.
-Do not expect someone to look at your stuff and tell you what you are doing wrong.
-The earlier you ask the question, the better. Do not wait for later.
-Understand that there is a difference between simple/basic/fundamental vs stupid question. If you feel that you have done good research and still you cannot figure out: Ask the question!!
-First Google, then Ask :)
Also, right questions help clear up unrealistic expectations. I lot of times it happens that you are working on some feature and your manager/ product owner comes and asks you to work on something else. Some people would jump at the new task immediately as someone with higher authority asked them to do it. But just by simply asking a few right questions you can get a much better picture of where it prioritizes in your list of things to do!!!
Why are we doing this?
How is this different then what we do now?
Why was this not important before?
Who all are affected by this?
When is the right time to do this?
Why When What Who How...........................
.. this list can be as long as you want.
Do not stop until you get all the answers you are looking for.
Monday, August 9, 2010
Thinker + Tester = Test Engineer(!= QA)
A year back I attended a very interesting 2 day training on testing, which has influenced this post to some extent. A lot of people are confused as what is the difference between a QA, tester, test engineer, and many other designations that have come up over the years. I will first start by trying to explain my understanding on the difference between a QA, Tester and Test Engineer (aka Software Engineer in Test, Software Quality Engineer,etc.).
QA: Someone that assures quality and hence the full form Quality Assurance. I believe QA is not a single person, for me it is a group of people with different authorities(product owners, managers, doc writer, engineers and many more) who combine there efforts to assure quality. I alone, as an engineer, cannot assure quality. I can write test plans, execute tests, write automation but cannot assure complete quality. Wikipedia defines engineer as “An engineer is a professional practitioner of engineering, concerned with applying scientific knowledge, mathematics and ingenuity to design and develop solutions for technological systems problems.” Also the word “engineer” is derived from the Latin root “ingenium”, meaning "cleverness". I am an engineer. So I can be clever, use my technical knowledge and design and develop tests and test plans, which other engineers, managers and product owners review and give a go or no go. Lets say a customer case comes from something that was not in the test plan than I am not solely responsible for that. I can assure, that the tests in my test plan have been executed and those areas are fine. It is the resposibility of the whole team to assure the quality, not a single person.
Tester: Any person who uses the system - Could be anyone. It could be the engineers, doc writers, customers, anyone. I turn into a tester when I execute the tests that I have designed and developed. At the same time I could give my set of tests to my manager and then he would become a tester. When those Beta products are released then even customers are your testers. Ever wondered where the weird term “Monkey testing” came from? My guess is that it came from this view that anyone can be a tester.
Test Engineer: Now that’s what I am. I am an engineer who thinks creatively and tries to break the system. I can dig into the code and find execution sequences that no one has ever traversed, I can come up with complex business and integration scenarios that the customer might run into, I can check for performance hiccups,etc. Basically, as a test engineer I try to find the cracks before the customers fall into it. I do not sign legal documents assuring quality. I design tests and test plans, execute them and go home. I take responsibility and ownership for making a feature robust and close to perfect, but everyone knows that there is never a 100% bug free software. I feel bad if a customer case comes in for my features and I think “Why didn’t I think of that and include that in my test plan. I should do that going forward.” but I won’t go to jail for that. I know of a lot of test engineers who feel they are the only ones responsible for the quality of the product, but sorry I beg to differ there.
This definitions are my own understanding and I am willing to tweak them with good reasoning. :)
Happy thinking and testing,
Anal-Utsavi
QA: Someone that assures quality and hence the full form Quality Assurance. I believe QA is not a single person, for me it is a group of people with different authorities(product owners, managers, doc writer, engineers and many more) who combine there efforts to assure quality. I alone, as an engineer, cannot assure quality. I can write test plans, execute tests, write automation but cannot assure complete quality. Wikipedia defines engineer as “An engineer is a professional practitioner of engineering, concerned with applying scientific knowledge, mathematics and ingenuity to design and develop solutions for technological systems problems.” Also the word “engineer” is derived from the Latin root “ingenium”, meaning "cleverness". I am an engineer. So I can be clever, use my technical knowledge and design and develop tests and test plans, which other engineers, managers and product owners review and give a go or no go. Lets say a customer case comes from something that was not in the test plan than I am not solely responsible for that. I can assure, that the tests in my test plan have been executed and those areas are fine. It is the resposibility of the whole team to assure the quality, not a single person.
Tester: Any person who uses the system - Could be anyone. It could be the engineers, doc writers, customers, anyone. I turn into a tester when I execute the tests that I have designed and developed. At the same time I could give my set of tests to my manager and then he would become a tester. When those Beta products are released then even customers are your testers. Ever wondered where the weird term “Monkey testing” came from? My guess is that it came from this view that anyone can be a tester.
Test Engineer: Now that’s what I am. I am an engineer who thinks creatively and tries to break the system. I can dig into the code and find execution sequences that no one has ever traversed, I can come up with complex business and integration scenarios that the customer might run into, I can check for performance hiccups,etc. Basically, as a test engineer I try to find the cracks before the customers fall into it. I do not sign legal documents assuring quality. I design tests and test plans, execute them and go home. I take responsibility and ownership for making a feature robust and close to perfect, but everyone knows that there is never a 100% bug free software. I feel bad if a customer case comes in for my features and I think “Why didn’t I think of that and include that in my test plan. I should do that going forward.” but I won’t go to jail for that. I know of a lot of test engineers who feel they are the only ones responsible for the quality of the product, but sorry I beg to differ there.
This definitions are my own understanding and I am willing to tweak them with good reasoning. :)
Happy thinking and testing,
Anal-Utsavi
Subscribe to:
Posts (Atom)