How to perfrom testing activities, when we dont have any requirements documents and the product is very old

Hi All,

I have recently joined the organization, its a very good product, finance domain, but its a very old product. there is less documentation, no requirements, and the entire QA is like a new concept for them.

Please can some one advice me how can we work with this kind of situation, how to start.


I’ve been in this situation, and it’s never a fun place to be.

That said, you’ve got options - here’s what I’ve done in this situation:

  • Talk to people - you’re new to the organization, but there are people there who have been in the company long enough to be able to tell you about the product. Ask around your team to find out who is the best person to ask for the specific information you need (with a legacy product like this, you’re most likely to want to know why things are done the way they are - there will have been compromises and workarounds that have been built over the years and are now just “the way it works”.

  • Tour the software as a user - In the absence of formal documentation, you can use the software itself as your specification. If there’s a date field, what date format does it require. What are the logically valid dates (for example, if you’re recording a loan application and the software requires the applicant’s date of birth, the applicant should be at least x years of age).

  • If you have access to the application database, you can use database field sizes to tell you the maximum input length of text fields, for instance if the last name field in the database is a varchar(64), then the last name that’s entered into the application shouldn’t be more than 64 characters. Older software doesn’t always include field length specifications because back in the bad old days browser enforcement of attributes could be… erratic. (Of course, if it’s desktop software, there are other factors involved).

  • As you investigate the software, if you find something that doesn’t make sense to you, ask around. It could be behaving exactly as it’s supposed to. Or you could have found a bug.

  • Document what you’re doing and your observations. In something as large and complex as this, you won’t remember everything. If you get something wrong, you can always correct it - the key thing initially is to build yourself a map of what the software is supposed to do (I ended up with several hundred wiki pages which have proved to be insanely valuable over the years).

As a general rule, your best option is to start with what documentation you have and then treat the application as your requirements. From there, you can build out a set of testing documentation that acts as a guide to newer testers. If you’re really lucky, your documentation can become the basis of user manuals written by your technical writing team (I’ve had that happen. At one of my previous jobs it got to be quite common for the tech writers to ask me for my notes to use with their manuals - because my notes described how to set up the new feature and the potential problems that could be caused by failing to configure it properly).


Talk to people, talk to people, talk to people!


Previous replies have been great so far and the emphasis is on speaking to people.

A key thing I what do is try and get a basic understanding of what the software does and what value it is supposed to bring to the business, then use this information and put yourself in the mind of the end user and make some educated assumptions. Then explore the application and write down assumptions and questions. Meet with people and then discuss the points you have raised, document everything you can for future reference.

If I may ask, what is your current objective? Learn the application, create regression test pack etc.

A few things that I would try to sort out in such a situation.

  1. Why are you there, who expects what from you? Understand who your main customer is.
  2. Who has knowledge that you can use? In a lot of cases my goto would be any Product Owner or similar. If you have access to the support organisation you can typically get a good view of what your customers mainly have problems with. For more technical things operations that actually run the product and developers that develop the product.
  3. Get access to production, or if that is not possible, access to an environment that is similar to production. Again operations are a good partner here. This is so that you can explore the product yourself to start to establish oracles.
  4. Figure out how you deal with data in the system. My experience is that for these kinds of system the software is only half of the equation, the other half is all the data in it. If they are not used to provision environments often then more likely than not you need to control your data. Operations or if you have database admins / developers is a good place to look for that.
  5. Is there any training material? Good places to look is support and sales / account managers.
  6. Explore the product. Two methods I prefer is to do tours from testing tours. (Feature tour, claims tour, data tour) or alternatively do something like guided learning, as in give yourself a mission and try to accomplish it in the system. Like “How many ways can I get this report” or “How do you add a new customer in the system” etc. That way you get some focus which will speed up learning.

Also a friendly reminder, resist the temptation to make up for what you are lacking, as in there are no requirements, so you will try to have someone or yourself write requirements. I have seen this pattern many times and it always fail. At this stage, document whatever you want, with only yourself as the reader. This ensures that you can be as fast as possible and you know who and what they will use the documentation for. Later when the picture is clearer you identify that their need to be more formal documentation, you have a good source material to draw from, and you also know why and what purpose that documentation will serve.

1 Like

Hi thanks for the response, the objective is to create a statergy, to create and update the existing test cases, but the problem is the changes have never been documented, unit testes are not documented and well tested. so its a great mess. and No idea where to start, we have started with one product. but the existing reg. suit is not at all working to move forword, its like. we need to do every thing from the scratch.

Thanks fro the reply, it will greatly help and i will took into the suggestions made.

hahahaha, sure thanks venkat, i will

Thanks Ola
Great input, i will follow that.

Would love to write a long technical story and repeat this great advice, but instead a one liner or two.

  • You, are in the right place and time, and you have been asked to fix a truly huge problem.
  • Don’t forget to pace yourself, and don’t forget to step back and look around for bits you missed every so often.
  • It’s not your job alone, you will find allies, but you need to be the determination, energy and direction.

Don’t forget to check any online help files that were designed for end users.

And I agree with talking to helpdesk and other customer-facing teams. In particular, ask if there are any recurring complaints users have where the answer is “we’re sorry, but the software wasn’t designed to do that”. Legacy apps may not have had the requirements-gathering done properly (if at all); and if the product is especially old, user requirements could have shifted over time.

This process may only identify issues that would go into the backlog rather than addressing actual bugs in the system now, but this sort of information will be useful a year down the line when everyone connected with the product can lift their eyes from the immediate problems and think about the strategic direction the product is going in. This may be a major product overhaul, or it may even be a complete replacement with a new product; either way, this sort of information will be useful to whoever has the job of running the upgrade/replacement project and your foresight in asking those questions and recording those answers will gain you allies in the organisation.


I thought Kates response was excellent.

Just one thing I’d add, do not set expectations that you will learn everything fairly quickly, talking with a tester who had been over a year on a product earlier this week and he is still discovering new things and features.


@andrewkelly2555 - absolutely don’t expect to learn everything quickly!

What typically happens with large, complex products is a tester gains a broad understanding of how the software works over a year or more, and gradually gains deeper knowledge over time. I’ve been in my current position for 9 years, and I’ve got a reasonable handle on the software I test, but there are many areas where I have to check the documentation (about half of which I’ve written for my own purposes - those hundreds of wiki pages including database dictionaries and regression guides that cover the main things to watch for when changes are made to each feature).

As a rule, a tester will end up with deep knowledge of the new features they test, a moderate level of knowledge of existing features they’ve tested changes to, and shallow knowledge of parts of the software they’ve had little to do with. Over time, that changes - but it can take a lot of time.


Lots of excellent advice already, which I’ll try to not repeat but will have to a bit so I can give a full answer.

I suggest that you look at 3 key questions to help you start to identify what you have. You’d then need to use the answers to make something more detailed, e.g. how you test it.

  • Who are the important people? The obvious one is the key kinds of user, but also the people who operate it, the people who sell it and the people who provide user support on it. What does the system do for each of those kinds of people / what does it expect from them? How do they interact with the system? GUI? API? File import / export? A report? Are there bits of the system that only certain kinds of people should be allowed to use?
  • What are the important lumps of data? This is at only a very broad level, rather than the details of e.g. database fields. So things like brokers, end users, insurance policies, etc. What would you draw up on a single normal-sized white board to describe the data that the system is concerned with? Then look at the entire lifecycle for these bits of data - when and how do they enter the system, get read, get updated, get copied / exported from the system, get deleted from the system?
  • What are the important interfaces with external systems - either other systems provided by your company, or systems provided by third parties. Again, don’t worry so much about the details, just the broad outlines. E.g. we host their website as an iframe in our site, we call their API, they call our API, single sign-on, file import / export etc.

This is just to write something for your own benefit to describe what’s there. Then you need to work out the best way to test things, which is a separate stage. Although I expect that you will go backwards and forwards between the two - you learn more about the system when you think about testing it.

Other things to consider are regulations and law.

Financial software has to comply to certain rules. Some companies have their own rules in place. This could also be the case for certain branches like banks. On top of that there are rules from a National Bank or another financial regulatory body.

The last years privacy has become more important for software suppliers. Laws like GDPR and CCPA have consequences for developing and testing software. For example, the test data cannot contain production data, unless there is a legal ground for it.

My suggestion is to find the relevant privacy laws and regulations, which are applicable on the software you test.


I would recommend asking around on the #exploratory-testing channel of the MOT Slack. Michael Bolton has been incredibly helpful for me as I have worked to build a QA team up from the ground in a small company, and others who hang out there have given me great advice as well.

You’ll want to get very familiar with what users are expecting from the product, and with the highest risk areas: what are the implications for users if a particular area is broken? I’ve been looking into Michael’s resources for a Test Charter approach, which seem excellent.

I love this video of one of his workshops: No Test Cases Required: Test Session Chartering - YouTube


Thanks for this interesting information!

UX design is a crucial component of a successful product. It is a vital step in the development process, as it helps your team build a product that users love. It can also boost the productivity and efficiency of your users, and boost customer retention and profitability. In the end, UX design helps companies make the best possible decisions and launch a minimum viable product without any hassle or cost. There are a lot of benefits to using UX design services for your business.