I've worked for companies that have little documentation for their applications, and most of it is probably comments in code.
How is a person, who is placed in the quality assurance department, suppose to verify that an application is doing what was intended to do; if there are no requirements documents and they are just told to "play around" or "read the user manual"?
"Playing around" and documentation like user manuals can definitely provide a start to developing tests, but they should just be a beginning. Properly testing that an application is doing what it is supposed to requires more domain knowledge. End users who have been using the application and know what it is supposed to do can be a good source for creating tests. Requirements or early specifications for the application can also be helpful in generating tests. In order to make sure that the stakeholders are actually getting what they want (and to make sure you are not testing the wrong assumptions) from testing, once the tests are planned out, the requesting manager/stakeholders should approve and sign off on the tests.
A strategy that I commonly use is that I will put my "end user" hat on and then test the system like it was an application that has been deployed to the general public.
I will make a number of assumptions as to why things are the way they are, and document them. I will then take those assumptions and have them checked by whoever I can, ideally subject matter experts, stakeholders and end-users.
So esentially I document assumptions, which are used in leiu of requrements and align my testing to them.
Whilst this is far from ideal, at least I can get some of the job done.
Approaching the application methodically and with intent can yield a significant amount of the information that you need. Start with simple questions - any application should/ almost certainly will have the most commonly used functions on obvious display - follow every option in the menus for a while. Start to map what features you know the application has. Only the very worst designed software will hide away its most significant features (I've never seen this happen).
Draw information by speaking the software stakeholders - ask the developer of a feature for a quick demo, discuss with the project manager what success for this project should look like, if you have contact with the end users/ project sponsors discuss what is important to them. Take every opportunity to learn from each project stakeholder you work with.
Obtain domain knowledge perhaps by drawing on your own experience or use Google to find out what the application's or project sponsor's direct competitors are.
Ask a question of the application that you feel it should be able to answer. Take note of the response. Follow this with another question. Then another question. Build better questions from the answers that the application gives you.
If there really is nothing to create tests from but your intuition, you may find that things are missed. Learn from these experiences too - make sure your tests learn from these experiences. Encourage the development teams you work with the learn from these experiences.
Communicate what resources you need to be able to test effectively, over time and over successive projects you should start to find that the things you need to test effectively will start to be provided. Keep offering constructive feedback on the support, information and applications that you receive. Never stop learning and never stop be willing to teach.
Also, I can't agree with the statements above about Agile projects providing not enough documentation. In my experience Agile project provided better documentation as it is focused, to the point and relevant. If you find your being given an application to test on Agile project and you don't know what it is meant to do, realise that you're probably not on an Agile project.
First, look for general requirements and work to document them. Some of these requirements come from previous versions of the application, some come from generally accepted usage. For example:
If it's a web site or application, some additional requirements might include:
Then, interview the project manager or developers and find out what they intend to do with this release. Document the intentions and use them as requirements.
Solicit input from anyone who is a stakeholder in the project. Share everything you find with everyone and revise it as needed.
Does the product have a Help file or a User Guide? If so, that's a good source of requirements.
Do Sales materials exist for the product? Certainly the product should do what these materials say that it does.
Sometimes, writing all of this up as assumptions can go a long way toward gaining a consensus as to the "real requirements" you can use to test against.
Once the system is at all testable, do some exploratory testing. As you find "undocumented features", add them to the list of topics to be discussed.
Find out if the product is internally consistent. (This is an area I find to be very useful) Even if I know nothing at all about a product, I assume it must be consistent within itself, and within the environment in which it must operate.
Look for external standards within which the product must operate. If it is a tax or accounting program - tax law must prevail and generally accepted accounting principles must apply.
Ideally, all of these issues have already been considered and written into the formal Requirements documentation which is handed to you. But if not, don't give up. Dig in and discover!
http://strazzere.blogspot.com/2010/04/there-are-always-requirements.html
This is an extremely common problem in software development. There are many testing resources in an organization: support team, end users, documentation writers, and the bug database. Utilize these resources to help determine potential problem areas and common use cases to focus your testing.
Our team started dealing w/ this issue by having testers either create a wiki page online or create a Q&A section on the existing wiki spec that the developers created. All questions about vague areas in the spec are asked there, and all answers are documented there. If you get an answer "offline", you would document it there, then email the person who gave you that information and possibly CC other interested parties (e.g., the dev, the business owner) asking them to verify that you got the information recorded correctly. Every so often, (every day or two at least, maybe more frequently depending on company culture), the testers email out the link to the Q&A page to the business owner, developers, appropriate management, etc., until all the questions are filled in. Call out key questions to answer in the email.
I found that specs started to improve as this process was more heavily used, as people anticipated the kinds issues the testers were asking about. The developers started getting better specs (or any spec at all!) from the business owners, and delays in testing were better understood, since no one will reasonably expect you to test without good information.
The proper ways are, Do a Exploratory testing, understand the business needs and the impacts, interact with programmers, clients, use your own knowledge to get the things right. Eg. for a shopping cart website you could check how amazon.com works for various commonly accepted functions like product search, display etc.
It depends on how your brain is wired. Personally, I start by drawing pictures. After reading the documentation and playing around with the site, I like to diagram what I understand about the product. I grab the biggest sheet of paper I can find and draw a graph of entities managed by the product, relationships between entities, user roles, actions performed by those users. As I draw the diagram, I will encounter issues I don't understand. I keep a list of those issues, and once the list is long enough, I find an expert who can help me with them. (If you interrupt someone every time you have a question, you risk annoying them.)
If the expert has time, show them the diagram. They'll probably be impressed that you invested the time the understand the product, and it may tell them that it's worth their time to answer your questions. They may be able to spot mistakes or omissions too. (They may even ask for a copy.)
Of course, if the product is big, you may not have time to diagram that whole thing. That's ok; you can start with the piece your boss has asked you to focus on.
Once you have the diagram, it's a lot easier to put together a high-level test plan, followed by individual test cases.
Communication and exploration. I have begun working on each of my project with no or negligible documentation. My approach has been the following:
This helps creating a sanity test. Then take one module at a time, and expand the tests.
Document as you go, the Test Cases need not be verbose and you can skip detailed steps initially - the main goal being to document what is required to be verified. These initial TCs can serve as a platform for learning, a checklist, and a reference for documenting the undocumented specifications.
Yeah what the others wrote basically. Also, when you are on an AGILE project you will encounter as less documentation as it can be. So you have to get creative on how to test applications.
All the above are very good starts and ideas on how to begin from zero. Basically you have to talk to people and generally assume things.
BUT! Be weary! Testers NEVER assume anything and never believe in one thing. Always make sure that you have multiple perspectives to one feature.
