Skip navigation.

Problem solving: a skill or a habit?

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?

One more collegue's comment

I was agreeably surprised to receive e-mail comment from colleague from another company (the same city - Riga). He is greatly complementing what I've called as simple as "to find the right search criteria" may be quite complex task also requiring experience(e.g. to guess in which log to look at: OS, DB, Application, etc... and if log level should be increased). And adding even more analyse of problem-solving process

Sometimes I have seen not very good practice of "guessing a list of
possible solutions" for particular technical problems. I have seen that
quite many people are just trying to guess all possible reasons for some
technical failure and continuing to do it for many days without any
progress and without any understanding when they will solve the issue.

Because of my previous technical background I am helping to solve technical
problems by myself as well. If I face a technical problem then at first I
also try to guess the reason using my intuition and then try to solve this
potential reason and verify if this solved the problem. But if I fail to
guess the reason for couple of times then I stop guessing and take
pragmatic approach. Typically I go one level down and find what actually
went wrong on lower level. It typically takes much more time to do
investigation on lower technical level compared to "good intelligent
guesses" but using this approach you have better chance that you will solve
the problem at some point in time.

One simple example - one screen form is failing with SQL error message
"data not found" without any further information what was not found.
Typical "guessing" approach for such kind of problem is start to check all
possible setup forms and master data forms to find out if some setup or
master data are missing. Pragmatic approach would be to stop guessing and
turn on SQL statements tracing and find out in trace log which actual SQL
statement failed with this "data not found" error message and then to find
out the source code which issued this SQL statement. And then you will
hopefully know what was not found and how you should correct it.

Comment by a collegue: skill as well

I've got feedback from my colleague from development team - Due to temporal issues he did not post it himself. So let me quote and comment:
"I beleave that in general almost all of our conclusions and even inventions are somehow based on previous experience. So it is more generic then just "problem solving".
I beleave that there are also general problem solving patterns which are not bound to a problem type. E.g. very simple: guess a list of possible solutions and try to research them one by one. As I see not everybody have skills or welling in using of such patterns. The problem is that numer of technologies we work with is so large that it is not allways possible to find exact person for exact technical area. In such cases we need persons with generic problem solving skills."
We also discussed more generic problem solving skills e.g. make a conclusion: not just gathering different bits of information, but also synthesys of a new information. Maybe It's because I've developed the problem solving skills back in childhood (solving math problems) that I take them for granted.
Lat but not least he wrote
"Sometimes I say to developers:
We don't do programming, we solve problems!
(Sometimes programmers think that they should do only coding)"

Comment viewing options

Select your preferred way to display the comments and click 'Save settings' to activate your changes.