Home > Archive > Software Testing > June 2007 > if testers dont have any document related to product
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
if testers dont have any document related to product
|
|
| riteshsshukla@gmail.com 2007-06-20, 8:15 am |
| Hi
Please let me know that if testers dont have any document
related to product and want to start testing of that product so what
is the best solution to test that product and how they can ensure that
which is the important section of the product.
thanks in advance........
-Ritesh
| |
| Michael Bolton 2007-06-20, 8:15 am |
| > Please let me know that if testers dont have any document
> related to product and want to start testing of that product so what
> is the best solution to test that product and how they can ensure that
> which is the important section of the product.
Do you have any ideas of your own?
---Michael B.
| |
| Maglez 2007-06-20, 8:15 am |
| If you haven't documentation, the best solution is to write it down
yourself.
To avoid leaving out some important part, you should interview some users,
which mean you have first to find out who the real final user is, perhaps
through the Marketing department, which most likely doesn't exist, so you
have to do it yourself :-)
The thing can get very complicated and time consuming so you have to make a
plan and put the most priority and urgent things on the top.
As sure you haven't much time, the documentation that you write won't be
final user documentation, which takes very long, it will be documentation
only to allow you write your test cases, documentation like State diagrams,
List of functionalities, High level system data flow, etc... from there you
plan your test cases but the most important thing is to properly communicate
to the client that the lack of proper documentation plays against the
project, lack of documentation reduce the product's quality and that for
that reason the test phase will take longer, since you have to write down
documentation, as it takes longer, the project cost more and... well, low
quality products are more expensive that quality products.
Good luck.
<riteshsshukla@gmail.com> wrote in message
news:1182320269.479874.237030@q19g2000prn.googlegroups.com...
> Hi
>
> Please let me know that if testers dont have any document
> related to product and want to start testing of that product so what
> is the best solution to test that product and how they can ensure that
> which is the important section of the product.
>
> thanks in advance........
>
> -Ritesh
>
| |
| Pradeep Soundararajan 2007-06-20, 8:15 am |
| Isn't that an opportunity for you to show your skills to the
management?
<< how they can ensure that
> which is the important section of the product. >>
By starting with asking questions to people whose money is being
pumped in/out for the product to hit or make money in the market and
by ending ( re-starting ) with a question "Is this good enough?"
-- Pradeep Soundararajan - http://testertested.blogspot.com -
+91-98451-76817
"Pradeep's first language is not English--his first language appears
to be testing." -- Michael Bolton
On Jun 20, 11:17 am, "riteshsshu...@gmail.com"
<riteshsshu...@gmail.com> wrote:
> Hi
>
> Please let me know that if testers dont have any document
> related to product and want to start testing of that product so what
> is the best solution to test that product and how they can ensure that
> which is the important section of the product.
>
> thanks in advance........
>
> -Ritesh
| |
| H. S. Lahman 2007-06-20, 10:13 pm |
| Responding to Riteshsshukla...
> Please let me know that if testers dont have any document
> related to product and want to start testing of that product so what
> is the best solution to test that product and how they can ensure that
> which is the important section of the product.
You can't test software if you don't know its requirements. If you don't
have requirements, you are going to have to get them somehow. There are
only two choices: get someone else to provide the requirements or
extract them from the problem space yourself.
If you are in an SQA group, you are in the wrong trade union to do
requirements elicitation, analysis, and specification. So you should
look for someone in the organization who can provide you with the
requirements.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
| |
|
| This may happen in real life. One possible option is to learn
something of the product from existing bug track system while previous
releases were tested. You may have a general idea about how to find an
issue.
zheng
On Jun 20, 10:55 am, "H. S. Lahman" <h.lah...@verizon.net> wrote:
> Responding to Riteshsshukla...
>
>
> You can't test software if you don't know its requirements. If you don't
> have requirements, you are going to have to get them somehow. There are
> only two choices: get someone else to provide the requirements or
> extract them from the problem space yourself.
>
> If you are in an SQA group, you are in the wrong trade union to do
> requirements elicitation, analysis, and specification. So you should
> look for someone in the organization who can provide you with the
> requirements.
>
> *************
> There is nothing wrong with me that could
> not be cured by a capful of Drano.
>
> H. S. Lahman
> h...@pathfindermda.com
> Pathfinder Solutionshttp://www.pathfindermda.com
> blog:http://pathfinderpeople.blogs.com/hslahman
> "Model-Based Translation: The Next Step in Agile Development". Email
> i...@pathfindermda.com for your copy.
> Pathfinder is hiring:http://www.pathfindermda.com/about_us/careers_pos3.php.
> (888)OOA-PATH
| |
| H. S. Lahman 2007-06-21, 10:13 pm |
| Responding to Zz...
> This may happen in real life. One possible option is to learn
> something of the product from existing bug track system while previous
> releases were tested. You may have a general idea about how to find an
> issue.
True. But my impression was the OP was talking about a new product.
Also, to get any sort of reasonable sampling one needs the bug tracker
to post all defects in all phases of the development rather than just
post-release bugs.
If there is an existing product, I suspect reverse engineering would be
a better way to glean a reasonably full set of requirements than from a
bug tracker. However, reverse engineering is a tool of last resort for
obtaining requirements for a variety of reasons, especially if the SQA
team does not have a lot of software experience.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
| |
| Jorgen Grahn 2007-06-22, 10:15 pm |
| On Wed, 20 Jun 2007 14:55:54 GMT, H. S. Lahman <h.lahman@verizon.net> wrote:
> Responding to Riteshsshukla...
>
>
> You can't test software if you don't know its requirements.
Sure you can!
> If you don't
> have requirements, you are going to have to get them somehow. There are
> only two choices: get someone else to provide the requirements or
> extract them from the problem space yourself.
OK, phrased like that I can agree. The first statement can be
interpreted by the reader as "until someone hands me a final, complete
and official blessed requirement specification, I don't have to do any
work".
> If you are in an SQA group, you are in the wrong trade union to do
> requirements elicitation, analysis, and specification. So you should
> look for someone in the organization who can provide you with the
> requirements.
You lost me here again. It doesn't matter what organization or union
I'm in. All that matters is if I write down something and call it
requirements, enough people accept them as official.
And if I don't have that power, I can still test. Using common sense,
comparing with similar systems, interviewing users, protocols and
standards ...
/Jorgen
--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!
| |
|
|
| H. S. Lahman 2007-06-24, 4:32 am |
| Responding to Grahn...
>
>
> Sure you can!
>
>
>
>
> OK, phrased like that I can agree. The first statement can be
> interpreted by the reader as "until someone hands me a final, complete
> and official blessed requirement specification, I don't have to do any
> work".
That's an interesting interpretation of "don't know".
>
>
> You lost me here again. It doesn't matter what organization or union
> I'm in. All that matters is if I write down something and call it
> requirements, enough people accept them as official.
Software development requires a substantial set of skills and
experience. SQA requires a substantial set of skills and experience that
is different than software development. Requirements specification
requires a substantial set of skills and experience that is different
from both software development and SQA. That's why software developers
shouldn't be writing acceptance tests, SQA people shouldn't be writing
software, and neither group should be writing SRSes.
> And if I don't have that power, I can still test. Using common sense,
> comparing with similar systems, interviewing users, protocols and
> standards ...
And they will be crappy tests because you are not trained and don't have
the experience to do it properly (assuming you are an SQA specialist).
If one is in that sort of powerless SQA situation I would expect a sense
of professionalism would lead to a job search.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
| |
| Michael Bolton 2007-06-24, 7:17 pm |
| > > And if I don't have that power, I can still test. Using common sense,
>
> And they will be crappy tests because you are not trained and don't have
> the experience to do it properly (assuming you are an SQA specialist).
> If one is in that sort of powerless SQA situation I would expect a sense
> of professionalism would lead to a job search.
I think your definition of testing is sufficiently narrow that, at
least in some cases, your sense of professionalism will lead to many
job searches--but you might not be the person who decides that you're
going to have to search for a new job.
The purpose of testing is, typically, to reveal some kind of quality
information about the product, usually on behalf of someone else.
Quality is value to some person. Even a novice can reveal important
information about a product with respect to its use by a novice. A
domain expert might not have terrific testing skills, but might reveal
important information about the relationship between the product, the
domain, and some user. A testing expert might not have a lot of
information about the domain, but might apply other testing skills to
the product that would reveal information about that product. As a
tester, the fact that you do (or don't) have some information about
the product might be very interesting information indeed. The
tester's job is not merely to compare the product's behaviour against
some document. Machines can very largely do that, and if that's all a
tester does, he or she should expect to be replaced by a machine.
---Michael B.
| |
| Vladimir Trushkin 2007-06-25, 8:18 am |
| On Jun 20, 9:17 am, "riteshsshu...@gmail.com"
<riteshsshu...@gmail.com> wrote:
> Hi
>
> Please let me know that if testers dont have any document
> related to product and want to start testing of that product so what
> is the best solution to test that product and how they can ensure that
> which is the important section of the product.
>
> thanks in advance........
>
> -Ritesh
Many reasonable things were said here. Here are my 2 cents.
Once faced the situation like this, I would focus on creating my own
set of requirements. As it was already mentioned the best way is to do
it outside the team that will be checking the product against it. Even
if you are not able to convince another team to do, it you may resort
to review of the results of your work, same way as we usually do for
the product requirements. Once you have all the questions of
correctness and completeness of your document resolved, you've got
something to work with.
The problems appear when no one in your organization knows anything
about the product. Say, you have just inherited it from another
development team no more available for contacts. In such a case, you
will need to reverse engineer requirements from the working product or
interview the end users as it was already mentioned here. You may even
hire an expert user for part time to help you develop requirements.
In the conclusion, I would warn you not to go for test design and
especially test execution until you have a clear set of requirements
that you believe is correct and complete and that every stakeholder
agreed upon.
----
Best Wishes,
Vladimir
| |
| H. S. Lahman 2007-06-26, 8:14 am |
| Responding to Bolton...
> The
> tester's job is not merely to compare the product's behaviour against
> some document.
The <SQA> tester's job is to validate the product against requirements.
If one does not have requirements one cannot do that job properly. If
one does not have the training and experience to elicit, analyze, and
specify requirements, one cannot do that job properly either.
Product quality, of which SQA testing is one smallish part, is both a
business problem and a process problem. Management needs to understand
what is needed to achieve acceptable product quality and ensure that the
processes are in place across the organization to achieve it. If the
shop does not have such a commitment, it is time to find another shop
that does.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
| |
| Jorgen Grahn 2007-06-26, 8:14 am |
| On Mon, 25 Jun 2007 14:46:43 GMT, H. S. Lahman <h.lahman@verizon.net> wrote:
....
> Product quality, of which SQA testing is one smallish part, is both a
> business problem and a process problem. Management needs to understand
> what is needed to achieve acceptable product quality and ensure that the
> processes are in place across the organization to achieve it. If the
> shop does not have such a commitment, it is time to find another shop
> that does.
And how many places like that exist? How many projects have
requirement specifications which arrive at time and aren't full of
holes large enough to drive a medium-sized truck through? And so on.
You must be working in a different, more mature, area compared to the
one I am in. I can't say I've ever worked in a place with the kind of
maturity you describe, and neither has any tester I personally know.
/Jorgen
--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!
| |
| Vladimir Trushkin 2007-06-26, 8:14 am |
| On Jun 26, 10:34 am, Jorgen Grahn <grahn+n...@snipabacken.dyndns.org>
wrote:
> On Mon, 25 Jun 2007 14:46:43 GMT, H. S. Lahman <h.lah...@verizon.net> wrote:
>
> And how many places like that exist? How many projects have
> requirement specifications which arrive at time and aren't full of
> holes large enough to drive a medium-sized truck through? And so on.
>
> You must be working in a different, more mature, area compared to the
> one I am in. I can't say I've ever worked in a place with the kind of
> maturity you describe, and neither has any tester I personally know.
I worked in both environments in my life and I would never ever allow
things to return to the state of chaos. There is no valuable
experience one can get working in an immature organization like this,
except probably for problem-solving and saving-butt skills. I would
better change it or leave.
----
Best Wishes,
Vladimir
| |
| H. S. Lahman 2007-06-26, 10:18 pm |
| Responding to Grahn...
>
>
> And how many places like that exist? How many projects have
> requirement specifications which arrive at time and aren't full of
> holes large enough to drive a medium-sized truck through? And so on.
Unfortunately very few. But it is worthwhile trying to find one. I spent
two decades in one before retiring. It was a good place to be and that
was reflected in the turnover. The average tenure was roughly ten years;
I was the only one there who had ever worked for a different company;
and our primary source of attrition was people moving on to become
managers elsewhere in the corporation. My major professional regret is
that I wasted two decades of my career in zoos before that shop.
<Hot Button>
It is a  commentary on NIH, ego, inertia, and devotion to the status
quo that most good shops today are not in the US or Europe. The
situation is very similar to the way it was in the '40s for
manufacturing. QA gurus like Deming and Jurand already knew exactly what
was needed to improve manufacturing quality but the establishment in the
US and Europe didn't want to hear it. So the gurus went to Japan and the
rest of the PacRim.
Those countries had fledgling industries and they were eager to find out
how to do it. Better yet, they had no existing infrastructure to change
and no inertia to overcome. (Both Japan and S Korea essentially rebuilt
from nothing after wars; the southern PacRim had little modern
manufacturing to start with.) As a result they listened to the gurus and
set those industries up properly. By the '70s they were eating the
lunches of US and European manufacturers.
The same thing has happened today in software. SQA gurus have known a
lot about how to build software products for decades but the software
establishment in the US and Europe doesn't want to hear about it. So the
SQA gurus went offshore and found fledgling software industries with no
existing inertia that were willing to listen to what they had to say.
Today by some estimates as much as 40% of US software production has
moved offshore. Quelle surprise!
</Hot Button>
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
| |
| Michael Bolton 2007-06-27, 4:27 am |
| > You must be working in a different, more mature, area compared to the
> one I am in. I can't say I've ever worked in a place with the kind of
> maturity you describe, and neither has any tester I personally know.
The only thing I would question here, Jorgen, is your use of the
highly loaded word "mature". Mature could mean many thing. One
meaning could be "a later stage of development"; another might be "a
more developed sense of responsibility"; and yet another might be "so
calcified that it never responds to customer needs"--as in "we're more
mature than our customers are." There's also a difference between
(appropriately) limited requirements and a state of chaos.
---Michael B.
| |
| Michael Bolton 2007-06-27, 4:27 am |
| > <Hot Button>
> It is a commentary on NIH, ego, inertia, and devotion to the status
> quo that most good shops today are not in the US or Europe. The
> situation is very similar to the way it was in the '40s for
> manufacturing. QA gurus like Deming and Jurand already knew exactly what
> was needed to improve manufacturing quality but the establishment in the
> US and Europe didn't want to hear it. So the gurus went to Japan and the
> rest of the PacRim.
Isn't it the case that Deming and Juran were involved in manufacturing
industries, not in software? Isn't it the case that software is a
service, rather than mass production of concrete widgets? If so, is
there any possibility that we're talking about radically different
concepts here?
> The same thing has happened today in software. SQA gurus have known a
> lot about how to build software products for decades but the software
> establishment in the US and Europe doesn't want to hear about it. So the
> SQA gurus went offshore and found fledgling software industries with no
> existing inertia that were willing to listen to what they had to say.
> Today by some estimates as much as 40% of US software production has
> moved offshore. Quelle surprise!
Yeah, c'est une surprise, all right. It's particularly surprising
because it's completely unsupportable. What are your sources for all
this (mis)information? For example, 40% by what measure? When someone
gives you figures like that, do you ever question them? Who's
providing the figures? What might their motives be? To which
software gurus do you refer? Is there any chance that the principles
that gurus have been touting for decades no longer have the same
relevance that they did decades ago when mainframes were the only
computers, when programs were a few thousand lines long, when the UI
was a green screen (or punch cards), and when it was possible (albeit
impractical) to render all of the states in a program into a wishbone
diagram? Have you USED a wishbone diagram lately? Do you think that
we might have learned something other than folklore in 30 years, or is
it still appropriate to repeat the myths as though Boris Beizer were
Aristotle? If software development in Asia is so great, how come my
(Asian) cellphone's user interface is intolerable, and how come the
damned thing pops a Java exception (not even a reasonable error
message) every time it's unhappy? Where was the software in my phone
developed? Where was it tested?
---Michael B.
|
|
|
|
|