1. Exploratory Testing could be solution for this. 
    *  An interweaving of test design and test execution.
This is in contrast to a process in which the tests are all
designed first, then run later.
    * A notion that the tester is learning about the product
by testing it.
    * An emphasis on creativity and spontaneity.
    * (Sometimes) An expectation that exploratory testing
will change the allocation of effort. Testing thus precedes
some parts of test planning.

2. NO software can be 100% bug free.

no software is 100% free,there is nothing call assumption 
for s/w u can't assume and write testcases.it has to have 
initial documents for every S/w to be devloped or 
indevlopment stages.
same question was asked by me?they selcted me...

I partially agree with preeti answers.(doesn;t mean I am
underestimating preeti comments, she is right form CMM level
point of view, think for companies which are start up or
middle level company).( Hope preeti can understand)

First of all let me give answer to question no. 2 As preeti
said which is true no software or application is 100% free
from bugs. We do come across lot of bugs when it is already
running or using,those bugs will be noted down and will
document it and solve it and release it as next version.
Because of this we do have lot of release and version
concept.  So no application is 100% free from bugs.

NOw let me answer the 1st question which is realy a critical
question but the answer is

There are companies where development and testing done
without having BRS and SRS, it doesn;t mean that they are
stop developing the application?( as per preeti comments)

Whenever we are not having any kind of documentation from
ourside these are the points that can be useful to test 

 1. Analyse the application well and understand what the
application is trying to do.

2. Write down your understandale level in a word doc. like
what the application does, what each and every module is
handling and what are the tabs it has and its usage (
everything which you can write it).

3. Inform the other team members to follow the same
stratergy and collect all the documents. 

4. Send this documentation to your superior( test manager,
project manger) and give them to confirm it with clients for
which the application is done or doing,Is this the
application should be and ask for confirmation before you
more forward.

5. Take the confirmation documentation from there and then
as usual generate design doc, test cases and rest of the
other activities which normal test engineer does.


IN one way we have to be act as QA, Bussiness Analayst role
. When you can do this well you can be a QA easily.

This is the processs most of the middle level company does.


Hope it might help you, If there are any other ways let me
know so that I can also learn it.