for adhoc testing
software testing
can anybody tell me how to test the software without document?
i m doing testing without document and i think its really challenging
and tough job to test the software without any test plan plz mail me
the right way to do this
regards
Arvind
Vladimir Trushkin
Thanks for asking this question. I was myself in such situation long
ago and the lesson I learned from it is the following:
- if you can change things change them
- if you cannot change things adapt to the them
- if you cannot (or simply do not want to) adapt find another job
If #1 and #3 are not options for you let's take a closer look at #2.
How can you adapt to not knowing what the application shall do and are
trying to verify that it does the right things and does them in a right
way?
The answer will be -- specify the behavior yourself and get it signed
it off by the stakeholders (project and product managers at least).
Then you will have the baseline to work with.
Otherwise you will be fishing in the dark having no idea how long it
will take to verify the product before shpping it. In most cases, in
result, you find yourself going in cicles around the confined area of
functionality and do not even note it. And when it's time to release
you just shut your eyes and anticipate the worst...
----
Best Wishes,
Vladimi
JTC ^..^
news:1160117334.0...@m73g2000cwd.googlegroups.com:
You must learn to understand the software and work with it. Speak to the
users, project manager and developers (assuming you know who they are),
Look at the business rules that govern that area of the business in which
the software is used. In Lessons Learned in Software Testing,
Specification is defined as either "Explicit" or "Implicit". With the
best will in the world specifications will not be thorough, you must
extend it. Look at similar systems, or previous systems, user manuals
etc.
I have worked this way for 3 years on a System which is developed in
house. I started with the company, and the project about half way through
implementation across the sites. The original specification was grossly
out of date at that point. I learned the system by writing a help system
(my first task). I learned the software so I could train the users, and
now I'm the key support member for the system. I know the software
really, well. However, there are still aspects that surprise me, that I
didn't understand how it worked.
Specification is from knowledge of the business, either from my own
experience and from Project Management and Development. We all have
different perspective of our knowledge of the software. I do support for
the system, including out-of-hours. Testing is manually done and I know
how to verify the data through SQL Server. I'm working on improvements in
those areas, but I am positive about what I've done so far, because I
know how things can be made so much better by doing things the hard way
(it frustrating but I've learned many lessons, in how I can improve
things - I hope). I'm working on that.
Ensure you carefully make notes of what you learn as you go along. This
is your own specification. There will be time you get results that you
are unsure about. In this case, ask questions, ensure the project manager
is satisfied that the results you are observing are correct. If in doubt,
do not assume it will be ok.
I recommend you get Lessons Learned in Software Testing by Cem
Kaner,James Bach,Bret Pettichord.
--
Regards
JTC ^..^
erk...@gmail.com
interesting here is:
Arvind did post this also in another group, so, it seems urgent.
But yet did not give any answer here in google groups, if the posts
helped her/him. I add at the bottom the answer in the other group by
me.
First some comments to the posts above:
"The answer will be -- specify the behavior yourself and get it signed
it off by the stakeholders (project and product managers at least).
Then you will have the baseline to work with."
-> actually very good idea,
but probably for Arvind the managers gave him the software without any
documents.
And I am not sure, if only asking project and product managers is
enough. Also other parties (at least the developer(s)) should be
included.
I mean if there is no documentation at all, how would Arvind know, that
the project and product managers would know everything. In the end the
developer programs and there may always be errors in communication
between e.g. developer and manager, so that developers perhaps
implement a functionality different.
But the other thing: if the managers sign something, the ytake also
responsibility, so this is a good start. Signing some things perhaps
helps, that some things get changed there. Then some people can get
accountable :-)
"I learned the system by writing a help system (my first task). I
learned the software so I could train the users, and now I'm the key
support member for the system."
yes, trying to explain the software to others always is a great help.
This is a very responsible job.
And I do find, everybody should work with customers, to understand
their problems.
"Ensure you carefully make notes of what you learn as you go along.
This
is your own specification. There will be time you get results that you
are unsure about. In this case, ask questions, ensure the project
manager
is satisfied that the results you are observing are correct. If in
doubt,
do not assume it will be ok. "
I would suppose, that if the software appeared without documentation,
that there will be a lot of time-problems and definitely there were
many before.
So, let's hope Arvind can find some time to make notes (where he will
definitely profit at next release)..
"I recommend you get Lessons Learned in Software Testing by Cem
Kaner,James Bach,Bret Pettichord. "
Actually give this to all people there - And also to other people :-)
I hope I did not alight on one's feet, if so, please write me back
here, so I can tell you, what my assumptions/expectations/perceptions
were, while writing this reply.
I mean there could be an error in my
assumptions/expectation/perceptions :-)
This was my answer to the original post (copy + paste):
****************************************************************
unfortunately in the following link, answers are only published later
http://tech.groups.yahoo.com/group/ISTQB-India/message/1729:
it is not impossible, though documentation/requirements is a great help
and should
always be provided, otherwise how can the tester be sure what is
correct?
First your test-goal should be clear:
see http://tech.groups.yahoo.com/group/ISTQB-India/message/1676
Then you could do following:
a.
get knowledge from somewehere else about the software: from developers,
product/project managers
if the software has previous versions: ask users, customer, support
so you can use this info to get more info on:
the software,
on the usage of software and
environment too.
b.
as said, if the software is not new developped, perhaps you can also
find some info on the bug tracking system:
old anomalies,
in which functions/areas are most of the anomlies observed (you know,
anomalies are social creatures :-) )
....
c.
after you have all these info, you could start with an
experience-based/unsystematic testing method like exploratory
testing/ad hoc testing
see:
in the syllabus for exploratory testing
or search in google or
visit:
http://groups.google.com/group/software-testing/tree/browse_frm/thread/036a59992aab3f23/b5c5f7a8aaa2c10b?rnum=1&_done=%2Fgroup%2Fsoftware-testing%2Fbrowse_frm%2Fthread%2F036a59992aab3f23%2F%3F#doc_0bd3fda9f8574273
d.
experience is a great value if there are no documents, so you can also
try this:
if there is similar software around on the market, why don't you try
this out and check on the same functions (if there are): do the
functions produce the same results in both software?
Results do not need to be the same always, but this is another
testoracle you could use.
e.
also you can use some systematic testing methods:
like blackbox (equivalence partitioning, boundary analysis,...) or
whitebox ( branch coverage,...)
please see in the syllabus for more of these
Since I am pretty sure, that I missed something, please add some other
possibilities, how to test without documents.
note:
Above I left out some steps which should also be considered when
testing - see the funcamental test process in the syllabus. I wanted
to give you a few methods of how to proceed as a starting point.
CU, Erkan
http://www.skilledtesting.com/