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.
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.
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.
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.
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 https://mlsdev.com/services/mobile-app-development, 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.