Problem solving: a skill or a habit?
Submitted by Ainars Galvans on Mon, 16/04/2007 - 09:29.
general software testing | people issues
Whenever there is a problem you can’t solve quickly you have two choices: give up and demand a support in this problem solving, or you may try to solve it yourself first (and only give up once you have tried). You could succeed for example in case you were able to analyze the problem to find the right search criteria for Internet search and find a clue on Internet. You will succeed if you could find clue in your past experience. So the only skill involved I could think of is the information searching skills! If only you don’t rely on a random/intuitive guessing luck...
So I believe problem-solving is a habit. Habit of not giving up too soon; habit of relying on your technical experience, habit of searching for more experiences at internet.
So they claims this to be a skill they posses...
I remember a person during interview said he has got a very strong problem solving skills. In an instant I wondered if that is a skill at all. Because I know I’m very strong at solving certain types of problems: combinatorics problems solved by undergraduates (as I teach solving them), problems with the product I’ve been testing for years, problems with tools I’ve been using: Load Runner, Defect Tracking System, etc. Problem solving requires two things: a lot of experience and ability to employ that experience during problem-solving.
Or ask you what – when you got a serious technical problem – who do you ask to solve it: a person having generic skill in problem solving or a technical person.
What it has to do with testing?
This post is only an intro to my next post (under construction) about informed guess. However some skills that tester requires is closely related to (if not the same as) problem-solving skills. For example making non-repeatable problem repeatable. Depending on how technical the problem (or the reasons actually) is of course. If a problem is only repeatable on one host (given that unit under test is configured the same way) it may appear that reason is OS configuration (including domain access etc.), 3rd party configuration, or the hardware itself (including network, monitor, printer, etc.). If it is seldom repeatable the reason may be as you have seen above local time, other user activities, OS activities (scheduled and not scheduled), etc.
Also investigating actual reasons for a detected problem is a problem solving experience, isn't it?
So I believe problem-solving is a habit. Habit of not giving up too soon; habit of relying on your technical experience, habit of searching for more experiences at internet.
So they claims this to be a skill they posses...
I remember a person during interview said he has got a very strong problem solving skills. In an instant I wondered if that is a skill at all. Because I know I’m very strong at solving certain types of problems: combinatorics problems solved by undergraduates (as I teach solving them), problems with the product I’ve been testing for years, problems with tools I’ve been using: Load Runner, Defect Tracking System, etc. Problem solving requires two things: a lot of experience and ability to employ that experience during problem-solving.
Or ask you what – when you got a serious technical problem – who do you ask to solve it: a person having generic skill in problem solving or a technical person.
What it has to do with testing?
This post is only an intro to my next post (under construction) about informed guess. However some skills that tester requires is closely related to (if not the same as) problem-solving skills. For example making non-repeatable problem repeatable. Depending on how technical the problem (or the reasons actually) is of course. If a problem is only repeatable on one host (given that unit under test is configured the same way) it may appear that reason is OS configuration (including domain access etc.), 3rd party configuration, or the hardware itself (including network, monitor, printer, etc.). If it is seldom repeatable the reason may be as you have seen above local time, other user activities, OS activities (scheduled and not scheduled), etc.
Also investigating actual reasons for a detected problem is a problem solving experience, isn't it?
