Interview Questions & Answers Software Testing Techniques

How will you Start Testing without any Functional Specification?

One of the most common situation, how will you start Testing without any functional requirement specification or any related documents? No wonder there are sometimes these kind of situations, ex. Resource attrition, no-documentation-with-agile-projects, etc. The only hope in these situations is ‘Exploratory Testing’. Since there are no documents to refer, refer the application directly 😉 Explore it, Test it. Gradually the flows make sense and we actually start testing it. Other option is to sit with Business analysts and developers to get application understanding – listening to experts instead of reading a document. Personally I like to build a document thereafter, so that someone joining after me doesn’t have to face this kind of challenge!

Sushma Prasad | Test Analyst

In such a situation, I would rely on the following possibilities to start testing the application:

  1. Talking to business analysts/subject matter experts who can provide a brief demonstration of the application can be helpful in this scenario in addition to saving time
  2. Exploring the application and referring to the acceptance criteria/use cases/user stories go hand in hand. Exploration can be helpful to uncover hidden and unknown flows while the use cases can provide insights into business-critical flows
  3. Re-testing the defects that were reported earlier in different cycles of testing, can provide lot of insight into the functionalities and could be a starting point for testing the application. This can also be helpful to analyze the impacts different parts of the application can have on others in addition to getting familiar with the test data/environment.
  4. Another possibility is referring to/exploring an existing application which can serve as the basis for the functionalities of the current application. This existing application could be a legacy application which is being re-vamped to a new technology
  5. Experience and knowledge gained from past applications could add value in testing the current application. There is a certain amount of industrial domain knowledge gained through testing certain applications of the same domain, which could be applied to various applications

Rahul Anikhindi | Consultant Specialist (Test Lead) at HSBC Technology India, ISTQB, TOSCA Specialist L1/L2

There should be at least BRD or TOM to refer to. Not necessary that the flow while doing exploratory testing is correct. Sitting with BAs is also a right thing to do. In many cases the Visio flowcharts comes handy to replicate the flows on application.

Meeta Mukund Dayama | QA Tester at Secret Location| Freelance Software testing coach

I have developed an approach to it. Definitely exploratory testing is the first thing we do directly or indirectly, but to go through defects filed is also one of the way to learn the software. I believe that whenever a tester creates a test case he/she needs to mark it priority high and generic or specific. Generic would be those that we will have to run each time for smoke testing. Specifics may be for sanity testing. So, the test cases marked generic and high priority plus the defects filed along with exploratory testing is the best tutorial. I used to do perform the steps of defects and it was as good as learning and performing (or being productive from day 1) since we are indirectly regression testing.

Sandhyareddy Kethu | Software Tester

Money testing is good to find unexpected bugs in unknown application. But people should not make it a habit. Monkey Testing is only good once formal tests are completed. I.e. at the end, just to catch some one-off unexpected bugs.

Vishal Bendre | Test Engineer at TOMTOM

Discussion with development and business analyst may help you up to certain level, you have to explore it in several ways can give you better insight.

Bathin Vattivella | Senior Manager at RealPage, Inc.

Now a days maintaining up-to-date documentation in line with the application functionality is nightmare as the features and functionalities are growing to meet market and client demands. Business Accepting Testing tools induction/maintenance will give us some leap for QA knowledge management.

Divya Kheria | Senior QA Professional

Many times just going through an application is not enough. Exploratory testing is a good way to approach such situations but sometimes applications are very complex and it would take a lot of time to understand all the functionalities. Hence, discussing with BA or any SME is important.

Software Testing without Functional Requirements

Brijesh Deb | Agile Testing Evangelist – Helping Teams Test Better!

Testing without any documentation is indeed something that almost all testers deal with at a certain point in time in their career. Why there is no documentation is an altogether different point of discussion… Some don’t document in the name of Agile while they very well know that Agile calls for minimal documentation not no documentation, while others are simply too lazy and blame it on the quickly changing requirements. It is as if these kind of people have never heard of simple tools such as mind maps.

So how do you test when you have no test basis? Answer: Collaboration… Collaboration with PO, BA, Developers and also with customers. Talk to these people and you’ll find your tests right there. Use your experience and skills to formulate ways of finding out what can stop the product from working.

Exploratory Testing is a great idea no matter what level of documentation you have on your product. After all testing is not just about having a set of passes against certain written tests, it’s about finding the unknown in the applications. If the product or a similar product is in the market, find out about the journey of the product. Look at existing or historical defects, find out defect clusters.

When you speak with others involved in the project, don’t just ask them about functionality, and ask them about the possible risks. These will give you an opportunity to uncover non-functional requirements too. Talking about risks IMO is possibly the best source of tests. And guess what… A thorough risk analysis gives you a set of prioritized tests cases which you can use as your smoke test suite for any quick and dirty testing.

Use tools such as mind maps to record your conversations and observations. Lastly, the most important tool in any such situations is your “brain”. Never stop using it. There’s a huge number of ideas there. You might just need to tickle it!

Shashi Bhusan Chowrasia | Senior Quality Assurance Engineer at Emplay Inc.

I too agree with you, in an agile environment, one should always be exploring the application, get some overview from the Developers, product managers, and the best way to be on same page is during scrum. Once we know of all possible features in the application, we can start by identifying core test cases, test manually or start automating.

Sheshi Kumar B | Senior Test Analyst at Hastraa Consulting Services

Both approaches are good to start testing without any documentation. But “Exploratory testing” is more convenient & more productive.

Anuruddh Singh | Test Analyst at Infosys

PAIR PROGRAMMING

Meeta Mukund Dayama | QA Tester at Secret Location| Freelance Software testing coach

But how is that an approach for a Tester?

Brijesh Deb | Agile Testing Evangelist – Helping Teams Test Better!

Meeta, I’m sure what he meant was pair testing… Where a tester can pair up with a developer and they can work on a feature together.

Meeta Mukund Dayama | QA Tester at Secret Location| Freelance Software testing coach

Brijesh, is it really practiced?  I have heard of pair programming, swapping of requirements to test, open crowd testing. If it is on desk testing by what you mean then I as a tester will still never be convinced. Because the code that works on the developer’s box may or may not run on my machine or client’s.  But thanks for clearing!

Brijesh Deb | Agile Testing Evangelist – Helping Teams Test Better!

Meeta, Yes it is practiced. I have seen it with teams working with TDD and BDD as their approach to development. And yes the qualification of code is done by the tester on the test environment and not on the developers’ box.

One caveat though, this requires domain expertise and basic understanding of code… So of course you’d need a mature team which is cross functional.

Meeta Mukund Dayama | QA Tester at Secret Location| Freelance Software testing coach

Brijesh, so the question remains, what if the new tester is not having the skills to understand the code in Pair testing environment. Assuming the tester is good at coding so then the organization or a mature team would definitely recommend the tester to do white box testing. What about black box testing….  From what I could sense is a gap about knowing and understanding the application is then side tracked because a developer would be rather busy to develop the application rather than explaining the entire feature and begin start coding. Please elaborate.

Brijesh Deb | Agile Testing Evangelist – Helping Teams Test Better!

Meeta, the point that I would like to draw your attention to is the caveat. For smooth execution of the projects it is ideal to have mature teams which are cross functional and self-organized. And if that’s the case, black box tests are not hard to execute because testers would certainly possess that skill I would assume.

However, I agree with you that in most cases this is the difficult part. We have testers who are new and have no exposure to the domain or code. So testers must devote their time to understand the product through collaboration, defect review of older releases, market analysis of the product if it’s out there and be open to the idea of exploring the code down the road. Difficult yes but certainly achievable.

Having said that the most important thing for a tester is to master “Test Craftsmanship” so continuous learning is extremely critical.

Steven Mason | QA Engineer at Adgistics

From my experience you can find out the basic functionality of a product by reviewing the automation package they have when deploying it. If they don’t have one – building one with developers and BA provides a structure of your application and then you only need to worry about modifications.

Arindam Karmakar | Director of QA and Test Engineering at Higi

I think in today’s world these are very easy. There might not be documentation but either business or end users or developers or operations will know the purpose of this application or portal. So I would start with every group to learn quickly and try to Test overall functionality so that we cover severity-1 and sev2. Then I will sit with Dev and Architects to understand touch points, internal and external integrations, upstream and downstream flows as much as I can to do some end to end regression or risk based testing. Even I would explore unit test cases to derive system test cases. I hope this helps.

Shama Ahsan | Lead Quality Assurance Engineer at MindStorm Studios

User experience testing, moreover a quick  meeting with dev ops or BA’s may be helpful.

Looking for a Job Change in QA/Testing technology? Get Regular Job notifications @ WhatsApp!

One thought on “How will you Start Testing without any Functional Specification?”

  1. I just started working independently on this new project. The user stories are not elaborate enough to cover all test criteria. Like browser security criteria, keyboard inputs not handled etc. In such case, the developers do not consider this & is not developed. So even if we have test cases to cover this, we cannot test. How do we handle such scenarios?

Leave a Reply

Your email address will not be published. Required fields are marked *