SoapUi is generally known as a tool for testing web services. Opinion divides on whether to call working with it a pleasure or a torture due to certain differences in professional background of those who gives that opinion. Personally, I believe that is it is a really good tool, but, unlike a washing machine, it needs its fantastic manual to be looked though at the very least: http://www.soapui.org/
Like many other IT tools SoapUi comes in two variants: paid and free of charge community edition. And on top of these two there are two ways of using it (which one you chose depends on your level of expertise). They are:
-- using it as any other UI-based tool
-- use it as extendible multi-purpose multi-tool with some UI for backward compatibility with the brains of normal users.
The latter will be discussed as a remedi against professional midlife crisis and the like.
Why meaning of life though? The thing is I see SoapUi and testing of web services as a great opportunity for those people who crave technical tasks, but can not get them either due to a limited skill with Java or because of all the tasty vacancies being filled in already. Practice proves that dissatisfaction with your job does not always result from shortcomings of your profession but from your lack of understanding what would make up for them. In other words, because you failed to identify the root cause of your dissatisfaction. Please note that it is assumed that the root cause is purely professional and not psychological (as psychological issues are out of scope for this post).
Thursday, January 8, 2015
Testers biggest grudges
For some reasons testers are believed to be less important than
developers. And the less important you are the less paid you get. Most
popular justification is that testers are less skilled than developers. I
think there is a kind of bias at work as there are more skilled and
less skilled people in either profession. And higly skilled testers
usually have experience with different areas of sowftware development
domain including technical ones. And still testing is considered to be
the second best profession compared with development.
Different factors play into it such as country specifics, company and product specifics, cultural specifics and so on, but for the limited scope of this post I will concentrate on the following:
-- history of an issue
-- specificities of test profession
-- specificities of testing mindset
-- professional evolution of a tester
Different factors play into it such as country specifics, company and product specifics, cultural specifics and so on, but for the limited scope of this post I will concentrate on the following:
-- history of an issue
-- specificities of test profession
-- specificities of testing mindset
-- professional evolution of a tester
Testing scientifically - Differential diagnosis in testing (troubleshooting scientifically)
Everybody lies
you know perfectly well where this comes from
Sometimes your testing goes smoothly and dully, but sometimes you just can't make head or tail of what you observe. It feels like there is some system behind but it is quite complex as if more that one factor were influencing the result. Sometimes it is extremely useful to realize there may be more than one problem behind. Luckily, testing was not created with the software industry so we may go for help to some older sciences.
In the medical world there is a tool known as differencial diagnosis or DDx[5]. It employs four basic steps that help to take our big chaos and sort it into several meaningful lumps. Having been translated from wikimedical to software testing language these basic steps[6] will look like this:
1. Find out all info about your piece of software (i.e. requirements, configuration etc)
2. Make up a list of observed symptoms (not just where it contradicts requirement but full description of actual behavior)
3. Make up a list of possible causes (aka "candidate conditions")
4. Prioterize these causes by serverity (i.e. impact or how it affects interested parties)
5. Eliminate causes one by one until you get the botton of it
Note: remember that there may be more than one cause. The fact that some cause was found but it did not explain all the symptoms may happen because
-- there is another cause responsible for the rest of symptoms
-- your guess is wrong
Note: sometimes you may get no result, it might mean that something was not taken into consideration or we do not posess all the required information
Note: Occam's razor may be of some help as well: "When you hear hoofbeats, look for horses, not zebras" [7]
--------------
Footnotes:
[5] Differencial diagnosis at wiki: <a href="en.wikipedia.org/wiki/Differential_diagnosis">link to the article</a>
[6] Original description of steps from wiki (same as [5]):
Differential diagnosis has four steps.
First, the physician should gather all information about the patient and create a symptoms list.
Second, the physician should make a list of all possible causes (also termed "candidate conditions") of the symptoms.
Third, the physician should prioritize the list by placing the most urgently dangerous possible cause of the symptoms at the top of the list.
Fourth, the physician should rule out or treat the possible causes beginning with the most urgently dangerous condition and working his or her way down the list.
"Rule out" practically means to use tests and other scientific methods to render a condition of clinically negligible probability of being the cause. In some cases, there will remain no diagnosis; this suggests the physician has made an error, or that the true diagnosis is unknown to medicine. Removing diagnoses from the list is done by making observations and using tests that should have different results, depending on which diagnosis is correct.
[7] Original quote from wiki (same as [5]):
As a reminder, medical students are taught the adage, "When you hear hoofbeats, look for horses, not zebras," which means look for the simplest, most common explanation first. Only after the simplest diagnosis has been ruled out should the clinician consider more complex or exotic diagnoses.
you know perfectly well where this comes from
Sometimes your testing goes smoothly and dully, but sometimes you just can't make head or tail of what you observe. It feels like there is some system behind but it is quite complex as if more that one factor were influencing the result. Sometimes it is extremely useful to realize there may be more than one problem behind. Luckily, testing was not created with the software industry so we may go for help to some older sciences.
In the medical world there is a tool known as differencial diagnosis or DDx[5]. It employs four basic steps that help to take our big chaos and sort it into several meaningful lumps. Having been translated from wikimedical to software testing language these basic steps[6] will look like this:
1. Find out all info about your piece of software (i.e. requirements, configuration etc)
2. Make up a list of observed symptoms (not just where it contradicts requirement but full description of actual behavior)
3. Make up a list of possible causes (aka "candidate conditions")
4. Prioterize these causes by serverity (i.e. impact or how it affects interested parties)
5. Eliminate causes one by one until you get the botton of it
Note: remember that there may be more than one cause. The fact that some cause was found but it did not explain all the symptoms may happen because
-- there is another cause responsible for the rest of symptoms
-- your guess is wrong
Note: sometimes you may get no result, it might mean that something was not taken into consideration or we do not posess all the required information
Note: Occam's razor may be of some help as well: "When you hear hoofbeats, look for horses, not zebras" [7]
--------------
Footnotes:
[5] Differencial diagnosis at wiki: <a href="en.wikipedia.org/wiki/Differential_diagnosis">link to the article</a>
[6] Original description of steps from wiki (same as [5]):
Differential diagnosis has four steps.
First, the physician should gather all information about the patient and create a symptoms list.
Second, the physician should make a list of all possible causes (also termed "candidate conditions") of the symptoms.
Third, the physician should prioritize the list by placing the most urgently dangerous possible cause of the symptoms at the top of the list.
Fourth, the physician should rule out or treat the possible causes beginning with the most urgently dangerous condition and working his or her way down the list.
"Rule out" practically means to use tests and other scientific methods to render a condition of clinically negligible probability of being the cause. In some cases, there will remain no diagnosis; this suggests the physician has made an error, or that the true diagnosis is unknown to medicine. Removing diagnoses from the list is done by making observations and using tests that should have different results, depending on which diagnosis is correct.
[7] Original quote from wiki (same as [5]):
As a reminder, medical students are taught the adage, "When you hear hoofbeats, look for horses, not zebras," which means look for the simplest, most common explanation first. Only after the simplest diagnosis has been ruled out should the clinician consider more complex or exotic diagnoses.
Subscribe to:
Posts (Atom)