The title is inspired from Angels & Demons where they talk about the "God particle". The topic is inspired by so many testers asking or answering to, "How much important is domain knowledge?", "Can we test without domain knowledge?", "What happens if we test a product or technology without domain knowledge?" ...
Every person who writes in public and in forums have been asked these questions about the importance of domain knowledge to test a product. Going through those forums, you'd know that there are answers like : Yes, domain knowledge is very important to test a product OR Oh yeah, you know without domain knowledge I couldn't have found the show stopper I found a few days back...and others saying, "I did manage to learn quickly, so it doesn't matter as long as you too can", "I think it depends on what you are testing"...
Passing time by failing to respect others time
The question I have to most testers out there is. If we, who reply to all those questions of yours, say that it is very important that you should be an expert of the domain to test the product, are you really going to become one or even try to?
You are aware that bug investigation skills are important, without we having to say that, what have you done about that? or would you go pick up the test framing skills?
I am convinced that there are many hundreds and thousands of testers who are a trap not just to themselves but to others wanting to help testers. Every testing related forum is infected with people asking questions who actually don't intend to do anything about it despite unintentionally (or maybe intentionally) wasting a lot of passionate testers time & energy. There are genuine people in there but in a rare occurrence. Most genuine people aren't asking questions but answering them and not all who answer questions are genuine. You may want to consider me among those who are answering questions but not genuine, if that pleases your ego.
I have respect for CDT mailing list and Software Testing Club. There are serious people, asking, answering and watching. I just hope there are a few more forums like that.
Why do we have labels?
Some testers are in a trap of calling themselves "Telecom testers", "BFSI testers", "Web App testers", "Mobile App Testers", and what not? The question I have is, should it matter? BTW, I call myself an exploratory tester because its an approach I follow to test any software & not a domain.
As how programming is a mindset and a good programmer wouldn't call themselves "Java only programmer", testing is a mindset too. Oh, there is a skillset along with the mindset.
Henrik Andersson of Sweden is going to do a Webinar on October 12 : Do we need labels? Are we all not testers? I read the abstract of the webinar and was excited. I envy Henrik a lot. He is the guy who is blessed to be in the happening places - be it PSL, AYE or CAST. Other than that he is the energetic test consultant & partner at a testing consulting firm based in Sweden. I think you all should register and listen to what Henrik has to say.
Henrik made me ask these questions: Why am I calling myself an exploratory tester, rapid tester, and whatever fancy stuff I had been calling myself when I know all testing is to some degree exploratory? What is the need for me to do so?
I need a label to differentiate myself or to communicate to people what I specialize at. My label helps my potential clients to gain interest to check about my services based on their needs. My label acts as a filter. People know what questions to shoot me. So far I have received very few emails from people asking if I can help them record and play QTP scripts. Most emails are about seeking help on how to develop themselves, think & test. I love to talk to them because they teach me things I want to learn.
So, I see label as a filter but I am against the labels that filter my own opportunities to learn. For instance, if I call myself a "Multimedia Tester", I would have blocked my learning on many technologies and contexts that I have experienced. I am starting to use "Brainual tester" these days. I am also giving a lightning / lightening talk in GTAC this year about it. James calls it Sapient and I call it Brainual. We both worship the same God but we call them in different names. I prefer the word "Brainual" because it is quicker to replace the word "Manual" to those who see "Manual" as a hand activity of testers than brain. People are used to saying, "Lets automate those manual test cases" but I expect the reluctance to set it to say, "Lets automate the brainual work thats being done now". Their own ego would hurt them. They don't want to be seen as a fool.
Filter-less
Being a consultant and added to that the twist and turns I have had in my testing life has got me to test software ranging from wireless, mobile applications, medical devices, multimedia, Retail, CRM, desktop applications, dating applications, billing solutions, video surveillance, stock market, auction systems, kiosks, cloud computing, testing tools, games and what not. I have never bothered what domain each of them belong to as long as I have
- An understanding of general principles of how software works (which I constantly refine)
- A skill to quickly learn and convert the learning to tests & churn more learning out of it.
- Ability to build models of learning to speed up my learning.
I try understanding how people who invented things might have thought. I fancy thinking that all these technologies have emerged out of observing something. Some of the key observations about human being and living things have led to many inventions and discoveries. Should I tell you that birds were an inspiration for Wright Brothers?
The human connection to technology
# 1 DHCP as to how it has evolved out of human behavior : When we go to the theater to watch a movie, we ask the personnel at the ticket counter to check if there are tickets available for a specific movie (sending request from a client to the server) of what we want to watch and our preferred time (details about client to see if server has anything for us).
The human connection to technology
# 1 DHCP as to how it has evolved out of human behavior : When we go to the theater to watch a movie, we ask the personnel at the ticket counter to check if there are tickets available for a specific movie (sending request from a client to the server) of what we want to watch and our preferred time (details about client to see if server has anything for us).
The ticket counter personnel in the theater gives us a ticket based on availability (assigning an IP address from the available pool) with the seat numbers to watch the movie.
In the ticket, there exists a seat number ( IP address ), duration of validity ( lease period ). If you prefer to watch the movie again and in the same seats ( Static IP ) you need to advance book or renew your tickets
( ipconfig / renew )
# 2 Why do connectors have a male pin & a female pin? How did gender come in to technology without having observed humans and how they interact?
I have a huge list of things that computers/ technologies do which are based on how humans communicate or how humans could have. Think of SIP protocol or a client server host architecture and relate it to human communication. You'd probably enjoy as much as I do.
Simplification
In Rapid Software Testing class of Michael Bolton & James Bach, there is an interesting dice exercise. I didn't crack it the first time but on learning the meta pattern, I am likely to crack it for any pattern or will get closer to solving it.
I have my own version of the dice game but with a different learning objective - simplicity. Based on running the exercise on thousands of testers in India (and a few folks outside India), I am making a conjecture that I see people struggling to cope up with simplicity.
The first set of thoughts that comes to a human mind is not necessarily simple and the next set of thoughts are usually more complex than the previous ones. So, I think humans keep building on the already existing complexity of their previous thought.
Unless you train your brain to think simple, you are unlikely to crack many things you can.
The reason I am telling this here is because those who set out to learn a new domain forget that there are simpler sub systems of the domain they already know either because they also exist in other domains they have tested or have used such products extensively. You may want to figure out the meta pattern of software & how they are supposed to work.
Practice to be fit
I run an exercise in my workshop in which I allow people to do freestyle exploratory testing. At the end I ask them the techniques they consciously used while testing. Although many of them know many techniques to test, at least the first 10 minutes of most testers freestyle exploratory testing is, "Clicking here and there to see if a bug dances out on the screen" If a few bugs do dance, "Wow, you see I did exploratory testing". I think of that as an inferior self standard setting to understanding exploratory testing.
How do we use what we already know to achieve better results? PRACTICE!
The biggest shame for ISTQB / CSTE certification bodies doesn't come from those who oppose it but from those who are certified & don't show traces of having gained anything from it. I have consulted at least for a few organizations here in India who hire these certified testers. Not a single test case document that these certified testers have produced has anything related to what they might have learned from the certification.
There is a scripted test design technique that is a best practice and the most widely used one although it doesn't have a name - copy paste a sentence of requirement document into expected results column and then write the test steps accordingly. This is the most successful trick ever invented in testing.
As a side note: Do you play any outdoor sport? Have you taken a long break from it and then went back to it? You might have been good at it at some point but when you get back after a break, you no longer feel the same comfort you had. If I were to speak to Indian testers alone for a moment, how does it feel to hold a cricket bat and face a fast bowler after taking a break from cricket?
Bits & Pieces
I admire ants. They have a way to deal with problems. They don't say, "Oh my God! That cake is about 1000 times bigger than my size. How can I eat it?". They break the huge cake into bits that they can process, carry it home and then come back for the next bit. Doing it bit by bit helps them to achieve the goal of moving the entire cake into their colony.
While testing a product whose domain / technology that I don't know, I try to remember the ants. I learn one bit, use that bit to frame tests. The tests I perform with the bit I learned, help me learn about more bits of the system and I choose to eat bit by bit or byte by byte if my mouth has got bigger.
I may know nothing about a system when I start but at the end I can learn so much about it that it would amaze me or my audience if I tell what I discovered going bit by bit. I demonstrated this in one of the workshops where I learnt the user base of the website, traced the kind of users, identified why those users might be coming to the site, what kind of problems such users might be facing, what kind of tests to be run, what could be the most important problems that is making the audience to not give more sales + found 14 issues + 10 questions to the developers - all in one hour. I had enough feedback to the development team that they got busy working on a few things that gave me the time I wanted to go learn what I wanted about the product.
Live oracles
What are the business analysts doing? Are your sales and marketing folks so busy that they don't have time for you? How much do you interact with them? Have you invited them for a paired testing? Have you talked to them about the importance of they being with you for an hour in a month while you are testing?
If that's one set of questions, here is another set: Why in the world do you want to know everything about a domain when you know its not possible for any human being to do that?
Fooled by foolishness
Some organizations who hire testers only because of their domain knowledge, are fooled in other ways such as, those testers probably know little about testing to be called as testers. Its opportunity cost. I have spent all my time trying to be a better tester, you ask me to troubleshoot a network router, I may end up testing it or learning about it by testing it. Ask a network admin to test a router, she may end up troubleshooting or reconfiguring it.
Some organizations who continue to think that domain knowledge is the most important skill for a tester to even apply or be interviewed by them are blind to the fact that most issues that their customers are reporting has probably got nothing to do with having testers with extreme domain knowledge in the team.
There are tons of testing problems these organizations are not paying attention to, while they see their problems are because they don't have enough testers with enough domain knowledge.
The domain particle
Do you have a domain particle that makes you think "domain knowledge" is the important thing for a tester to perform well?
I don't want to take it out. I want it to be there so that I can help you mutate it. If you could help yourself mutate it, and make the domain "learning" instead of "BFSI", "Telecom", "Multimedia", "Whatever"... I think you would have cracked what you are likely to in 20 years from now. That's an opportunity to be wise without needing to age for that.
Did you say that?
Those who speak about exploratory testing are asked, "Are you saying there is no value for scripted testing?". Those who speak about using brains to test are asked, "Are you saying there is no value in automating tests?". Those who speak about Check Automation are asked, "Are you saying checks are not tests?" while the speaker/author didn't mean any of that. Those who speak against certification are asked, "Are you saying people shouldn't get certified at all?". Those who speak about wasteful documentation are asked, "Are you saying documenting is a bad idea?". Reading some of the above paragraphs, some of you might have had a question, "Are you saying all ISTQB/CSTE testers don't know test design?"
So, whatever anyone says, there is a group of testers aggressively waiting to ask such questions. They are not doing anything wrong. They are just being themselves. Some representatives of the group are likely to ask me, "Are you saying domain knowledge is not needed to test the product?" and I am going to punish them by asking them to re-read this big post.
BTW, I am looking to hire testers of Banking / Web Application domain testers. Please send me your resume as soon as possible.
Also, if you are a tester from Hyderabad and want to meet Rahul Verma, Dhanshekar and yours truly on 27th evening, email me. We wont mutate your particles! We will be attending Google Test Automation Conference in Hyderabad.
Post bio for my self reference: Took 5 days to write the first draft, changed the style and contents 3 times, 1 external review, 3 self review, 5 hours of editing and finally publishing it. Published from my cousin's place in Delhi. Laptop: IBM Thinkpad
( ipconfig / renew )
# 2 Why do connectors have a male pin & a female pin? How did gender come in to technology without having observed humans and how they interact?
I have a huge list of things that computers/ technologies do which are based on how humans communicate or how humans could have. Think of SIP protocol or a client server host architecture and relate it to human communication. You'd probably enjoy as much as I do.
Simplification
In Rapid Software Testing class of Michael Bolton & James Bach, there is an interesting dice exercise. I didn't crack it the first time but on learning the meta pattern, I am likely to crack it for any pattern or will get closer to solving it.
I have my own version of the dice game but with a different learning objective - simplicity. Based on running the exercise on thousands of testers in India (and a few folks outside India), I am making a conjecture that I see people struggling to cope up with simplicity.
The first set of thoughts that comes to a human mind is not necessarily simple and the next set of thoughts are usually more complex than the previous ones. So, I think humans keep building on the already existing complexity of their previous thought.
Unless you train your brain to think simple, you are unlikely to crack many things you can.
The reason I am telling this here is because those who set out to learn a new domain forget that there are simpler sub systems of the domain they already know either because they also exist in other domains they have tested or have used such products extensively. You may want to figure out the meta pattern of software & how they are supposed to work.
Practice to be fit
Quoting Parimala, "What you know is not as important as what you can do with what you know".
I run an exercise in my workshop in which I allow people to do freestyle exploratory testing. At the end I ask them the techniques they consciously used while testing. Although many of them know many techniques to test, at least the first 10 minutes of most testers freestyle exploratory testing is, "Clicking here and there to see if a bug dances out on the screen" If a few bugs do dance, "Wow, you see I did exploratory testing". I think of that as an inferior self standard setting to understanding exploratory testing.
How do we use what we already know to achieve better results? PRACTICE!
The biggest shame for ISTQB / CSTE certification bodies doesn't come from those who oppose it but from those who are certified & don't show traces of having gained anything from it. I have consulted at least for a few organizations here in India who hire these certified testers. Not a single test case document that these certified testers have produced has anything related to what they might have learned from the certification.
There is a scripted test design technique that is a best practice and the most widely used one although it doesn't have a name - copy paste a sentence of requirement document into expected results column and then write the test steps accordingly. This is the most successful trick ever invented in testing.
As a side note: Do you play any outdoor sport? Have you taken a long break from it and then went back to it? You might have been good at it at some point but when you get back after a break, you no longer feel the same comfort you had. If I were to speak to Indian testers alone for a moment, how does it feel to hold a cricket bat and face a fast bowler after taking a break from cricket?
Bits & Pieces
I admire ants. They have a way to deal with problems. They don't say, "Oh my God! That cake is about 1000 times bigger than my size. How can I eat it?". They break the huge cake into bits that they can process, carry it home and then come back for the next bit. Doing it bit by bit helps them to achieve the goal of moving the entire cake into their colony.
While testing a product whose domain / technology that I don't know, I try to remember the ants. I learn one bit, use that bit to frame tests. The tests I perform with the bit I learned, help me learn about more bits of the system and I choose to eat bit by bit or byte by byte if my mouth has got bigger.
I may know nothing about a system when I start but at the end I can learn so much about it that it would amaze me or my audience if I tell what I discovered going bit by bit. I demonstrated this in one of the workshops where I learnt the user base of the website, traced the kind of users, identified why those users might be coming to the site, what kind of problems such users might be facing, what kind of tests to be run, what could be the most important problems that is making the audience to not give more sales + found 14 issues + 10 questions to the developers - all in one hour. I had enough feedback to the development team that they got busy working on a few things that gave me the time I wanted to go learn what I wanted about the product.
Live oracles
What are the business analysts doing? Are your sales and marketing folks so busy that they don't have time for you? How much do you interact with them? Have you invited them for a paired testing? Have you talked to them about the importance of they being with you for an hour in a month while you are testing?
If that's one set of questions, here is another set: Why in the world do you want to know everything about a domain when you know its not possible for any human being to do that?
Fooled by foolishness
Some organizations who hire testers only because of their domain knowledge, are fooled in other ways such as, those testers probably know little about testing to be called as testers. Its opportunity cost. I have spent all my time trying to be a better tester, you ask me to troubleshoot a network router, I may end up testing it or learning about it by testing it. Ask a network admin to test a router, she may end up troubleshooting or reconfiguring it.
Some organizations who continue to think that domain knowledge is the most important skill for a tester to even apply or be interviewed by them are blind to the fact that most issues that their customers are reporting has probably got nothing to do with having testers with extreme domain knowledge in the team.
There are tons of testing problems these organizations are not paying attention to, while they see their problems are because they don't have enough testers with enough domain knowledge.
Everyone of us choose to be not fooled by something and that exposes us to be fooled by something else.
The domain particle
Do you have a domain particle that makes you think "domain knowledge" is the important thing for a tester to perform well?
I don't want to take it out. I want it to be there so that I can help you mutate it. If you could help yourself mutate it, and make the domain "learning" instead of "BFSI", "Telecom", "Multimedia", "Whatever"... I think you would have cracked what you are likely to in 20 years from now. That's an opportunity to be wise without needing to age for that.
Did you say that?
Those who speak about exploratory testing are asked, "Are you saying there is no value for scripted testing?". Those who speak about using brains to test are asked, "Are you saying there is no value in automating tests?". Those who speak about Check Automation are asked, "Are you saying checks are not tests?" while the speaker/author didn't mean any of that. Those who speak against certification are asked, "Are you saying people shouldn't get certified at all?". Those who speak about wasteful documentation are asked, "Are you saying documenting is a bad idea?". Reading some of the above paragraphs, some of you might have had a question, "Are you saying all ISTQB/CSTE testers don't know test design?"
So, whatever anyone says, there is a group of testers aggressively waiting to ask such questions. They are not doing anything wrong. They are just being themselves. Some representatives of the group are likely to ask me, "Are you saying domain knowledge is not needed to test the product?" and I am going to punish them by asking them to re-read this big post.
BTW, I am looking to hire testers of Banking / Web Application domain testers. Please send me your resume as soon as possible.
Also, if you are a tester from Hyderabad and want to meet Rahul Verma, Dhanshekar and yours truly on 27th evening, email me. We wont mutate your particles! We will be attending Google Test Automation Conference in Hyderabad.
Post bio for my self reference: Took 5 days to write the first draft, changed the style and contents 3 times, 1 external review, 3 self review, 5 hours of editing and finally publishing it. Published from my cousin's place in Delhi. Laptop: IBM Thinkpad
Telecom tester - May be a label for some but for me it means the person has highly specialized knowledge. Telecom is a big word and not every tester knows everything in Telecom world. However, what it means to me is - The person knows (for the area he has worked in) Protocols, RFCs, Tools, how these protocols work with other protocols, what are the equipments, more on embedded systems testing.
ReplyDeleteThis knowledge can't be acquired in a few months. It requires a lot of study, practice and learning. IMO, this label is not useless.
@Vipul,
ReplyDeleteI understand and agree to what you mean but the problem with most of these people is despite reading and understanding the RFC and protocols they hardly have any clue about the meta pattern because they don't need it.
They don't need it as they want to remain in it. However, for such people, the domain takes over testing.
They feel inferior to move out of embedded testing and test web applications.
Their label hurts them during recession. A "multimedia tester" was laid off during recession, he needed a job badly due to his family situation but couldn't find it because at that time, no recruitment for multimedia testing was happening.
He had to wait for a couple of months. Later when jobs started opening up, he got into it again.
Why not pick multi specialization at least for your family sake if not for passion?
I heard there was a discussion recently in Bangalore by a few testers who discussed about meta pattern :)
Hi
ReplyDeleteI agree that domain knowledge isn't necessary to do good testing.
But it is necessary in order to do excellent testing, that also encompasses Suitability, Completeness et.al.
It also makes me think of the difference between passion for testing, and passion for a product.
You need to know what you love.
@Pradeep,
ReplyDeleteInteresting post, indeed!
At every career step of mine, I had to take a decision, "Should I choose a depth-wise approach or breadth-wise approach?". I chose the latter one to move across various "domains of testing" - functional to performance to functional/performance/security testing of security products.
There are a lot of others that I know of, who have taken a conscious depth-wise decision. E.g. there's a person whom I know of - He's a performance engineer specialising in Oracle databases. This gets as specific as you think of. As for developers, I know of atleast one person who is interested only in kernel level development and given an option to move to user-mode, he quit the company.
Whether a career decision is right or wrong is subjective. "Domain" in itself is an ambiguous word and can mean a lot more beyond the business domain of the application under test. There are people who choose to specialise and many crucial projects would be in need of specialists than know-a-little-about-alls like me :-).
I have had the same experience in dealing with testers testing anti-virus software. Domain knowledge is a very important thing for such testers. Especially for the ones that are testing beyond the GUI. Such testers are the best candiates for becoming "product owners" in the agile world.
So, although I have chosen a career path so far, as you have suggested in this post, I feel that the industry is in need for specialists along with testers like you and me. Atleast I don't myself fitting in many such situations where a specialist would.
In your recent posts, you have brought many of key questions/challenges/dichotomies that the testers face. I admire you for this.
Regards,
Rahul Verma
Pradeep, "are you saying domain knowledge is not needed to test the product?"... just kidding!
ReplyDeleteI think the biggest problems is the boxing, the labeling, more than the domain itself. I can't oppose gaining expertise in my domain from my experience (I also don't want to), but labeling myself on it would, as you say, limit my scope of learning and acting.
And with that, I find that "organizations who continue to think that domain knowledge is the most important skill for a tester" are quite a good relief, in good position compared to the trend I see most, of organization who think computer science degrees or coding skills or knowledge of a very specific testing tool is the most important skill.
I'm a specialist: I specialize in learning quickly about whatever domain in which I find myself. This has a number of advantages.
ReplyDelete1) I'm comfortable switching domains.
2) I can bring knowledge about other domains into the domain in which I'm working.
3) I tend to ask a lot of naive questions that help to jar people out of their preconceptions and assumptions.
4) I have to learn the domain for myself, and thereby construct a unique model for testing within it. With that, I find problems that other people might not find.
5) When I'm documenting my work, I focus on capturing the things that I found hard to understand, thereby (heuristically, at least) providing something helpful to the next tester.
6) As Pradeep has suggested, I don't get pigeonholed as a "financial services tester" or a "memory management software tester".
7) I get to learn about a large number of domains, which make my own life more interesting.
8) I don't get stuck quite so often in my own preconceptions.
9) Every new domain teaches me something about the domains in which I've worked previously.
Now, if you'd like nine reasons why it's really good to specialize, I could give you those too. (I'd encourage those who advocate specialization to be specific about the advantages.) There are plenty of ways for testers, whether specialist or generalists, to be useful.
---Michael B.
Yet another nice post!!
ReplyDeleteIMHO, domain knowledge is certainly helpful but it doesn't mean a tester wouldn't able to test (or even better) without it. While an application needed a tester to test, first we looking for the tester who have previous experience to test similar application or who have the domain knowledge, if not have such one, then we looking for the tester who is able to learn the application and it's domain as quickly as possible to do effective testing (it may take more time than with domain knowledge). In this connection your Ants example is very much interesting!!
About the labeling of "Exploratory Tester", are not all human testers engage in some level of exploratory testing? OR if i call myself as a "Exploratory Tester" does it mean that i will never do any scripted testing irrelevant in any circumstances or i will never documented any of my tests? To me, it depends on the certain contextual factors, project type, client type and/or in any unavoidable circumstances.
- Selim
Hi Pradeep
ReplyDeleteA very high thoughtful post this time too.
Manual testing to Brainual testing---> Really this type of transformation is hardly needed in Indian Software testing industry.
If you do not mind can you publish a post about your video surveillance testing experience?
Thanks
Ram
@Ram,
ReplyDeleteYou were probably excited when you commented and I appreciate that. I could suspect your excitement because you wrote "hardly" instead of "hard".
On video surveillance, I am bounded by NDA. What I could do is to check with my client and let you know.
Thanks for the notification and my apologies for the mistake done(i could have reviewed the comments before publishing it).What I meant to convey is that type of information is really a need for the indian software tesing community.
ReplyDeleteIn one of the project which required core networking skills we had a test team who read, talked and may be slept over only networking concepts. There was a feel of disgust in them towards articles or talks such as bug advocacy, software test forums, testing articles/events etc. The so called testers/network domain specialists I am now confused what to call them were more interested to attend and showcase their knowledge of networking concepts in network communities rather than testing events.
ReplyDeleteTo me learning a domain and testing applications from the domain are two separate tasks. I have seen many who learn the domain well but when it comes to thinking of a test outside may be say the RFC or a conformance doc and they drop.
I also loved the ant example.
Thanks for sharing such a wonderful post.
My thoughts,
ReplyDeleteGive me any product - I can test it without what most of the people call "Domain Knowledge". Now, to add value to my testing for a specific product I might go learn rapidly about the product or use similar products and learn more to generate additional / more test ideas.
This is all simultaneous. I do not need so many "X" hours to read about the product and then think "X" hours about it and then start testing. All happens in parallel.
Even some of the so called "Domain Experts" that I have seen do not know how to test. Now, it's just theory that they have and no demonstration of what their theory talks about. Now who would want such people?
Thanks!
Good post and an interesting topic pradeep
ReplyDeleteI slightly disagree...because if you have domain knowledge there are certain advantages to it...learning curve goes down,more ideas than a person who is new etc...BUT again I like the essence of this post which breaks the myth that "If you are a X domain tester you are not eligible/suitable for Y domain testing"
why I call this a myth because, this has been practiced for quite a long time without questioning why? This post from my perspective is all about answer to why?
...Thanks for this post with some simple yet powerful examples
-shiv
I have respect for CDT mailing list and Software Testing Club. There are serious people, asking, answering and watching. I just hope there are a few more forums like that.
ReplyDeletehttp://www.softwaretestingclub.com/forum/topics/most-recognized-testing
Sure. Serious people, asking, answering and watching.
@Anonymohus
ReplyDeleteI am a good person. No, wait, I killed an ant today.
One more ant.
ReplyDeletehttp://www.softwaretestingclub.com/forum/topics/certified-ethical-hacker
Yet another googlable ant.
ReplyDeletehttp://www.softwaretestingclub.com/forum/topics/web-security-testing?commentId=751045:Comment:89865
@Anonymous,
ReplyDeleteYou display intentional blindness through your behavior. I may also want to suspect selective amnesia :)
I forgot about my intentional blindness since I have this problem of selective amnesia. Apologies.
ReplyDeleteSomehow keep finding these regularly on the very respectable Software Testing Club where there are serious people, asking, answering and watching.
http://www.softwaretestingclub.com/forum/topics/which-is-better-istqborsix
Sorry to contest your thought though. I guess I will learn to just shup up and follow the experts.
Yes World. Softwaretestingclub is the place to be ... where there are no people passing time by failing to respect others time ...
where posting junk is always rare occurence and it always done by genuine people seeking help and allowed to do so after checking genuinity by the serious people, who are answering and watching.
@Anonymous,
ReplyDeleteWhat's your problem? Why don't you just be bold enough to put your full name, who you are and then say whatever you are saying?
If you want to help others understand something hidden, hiding yourself to do that is a bad idea.
Hi Pradeep,
ReplyDeleteI simply adore the passion you enthuse in fellow test engineers to be passionate in what they do.
Coming to this topic of having domain knowledge I can recall an experience during an interview which I attended , I was interviewed by a lady who probed indepth about the testing concepts apart from few practical cases and how I would handle or test them .i answered her ,she was happy, since it was the first jumpm from the company i was working you can as well imagine my way of handling the interview (apart from technical),I asked that I was not probed on domain knowledge at all though it was mentioned in Job descrition that knowledge of certain domains was necessary to which she smiled and told "whicever domain you are into your job would be to test it,hence few scenarios I gave though not related to your domain was to find out how you go about doing your job".
She was satified and I too was glad to have been interviewed by lady who knew what and how to interview.
Nonetheless Pradeep ypour posts always infuses fresh energy to us fellow test engineers otherwise I see sadly my own people looking disenchanted with this profession a sorry state and way the mindset of people today is.
You are doing a yeoman service by guiding people like us.
Thanks once again.
Key question this post is trying to ask and address (IMHO )is NOT about whether or not domain skill is a must for a tester.
ReplyDeleteThe question is - how does a skilled tester manages to switch from one domain to another. The question is how a tester can add value to new domain that a tester is asked to work on. The question is about how quickly one can learn a new domain given his/her learning skills, utilize knowledge of previously learned domains.
I get pretty irritated when people make blanket statements "how can you test this app when you do not have any domain knowledge". I would reply - "of course, I can. Give me what to test and some time ...I can show what I do." While it might take a tester to learn new domains - a skilled tester can compensate for that lead time by bringing a new perspective that often gets ignored by so called "domain experts".
While we talk so much about lack of domain skills for testers - there is not much debate about the reverse. Why do not hear lack of testing skills for domain people? Probably because testing is perceived to be easy !!!
Skilled testers constantly invest in "learning" - for them it is lifetime quest. The hype around so called "domain experts" often irritates such testers who constantly strive to learn new domains and are not afraid of (as Michael B suggested) new domains.
Much of the hype around domain is created (IMHO) by domain experts themselves. They might be feeling threatened by this new breed of testers who learn quickly, challenge core beliefs and myths and are not afraid of new domains. For those holding specific domain knowledge as something "indispensible" - such surge of non domain experts making inroads into their world can be career threatening. In nutshell - it is about how much or whether to have domain knowledge or not. It is about how to exploit existing knowledge to learn new things.
I feel as more and more people challenge the myth of domain knowledge and penetrate the fortress of the domain experts - the point will be made. Having said all of this – I would not hesitate to add domain experts are our friends - we can learn lot from them. Our (testers) life will be tough without them. A pair of a "willing to learn" domain expert and skilled software tester is what is need to the industry today.
Shrini
Hi All,
ReplyDeleteIn the true sense domain knowledge is not an absolute pre-requisite for software testing.
If you have it does help in many situation in speeding up the understanding process & possibly doing complex workflows/scenarios of that domain.
But also at times it hinders testing by blinding you from uncovering new or other possibilities of errors & omissions.
As for the hype generated about domain knowledge being important, as pointed out, mostly it is people who want to guard their own existence. This predominantly happens in a few domains like finance, telecom etc.
My own personal experience of not being tied to any domain has stood the test of time too.
Nice post. I think its all about balance. I think I have specialized in certain areas but I would not be limited to those because of my willingness to learn and adapt. Isnt that what change and lean is all about .... its adopting and changing with time. If I am offered a specialized job I will accept it.. but that does not stop me from growing in the same organization.
ReplyDelete