Testing without SRS as a fresher tester?

Question

I am new to testing field and from a non-technical background how should I report bugs without SRS (Software Requirements Specification)?

Answer 1

Even without a formal document, there are always requirements. You just have to work harder to find them.

You can talk to people and ask, then document what you heard. And there are some requirements ("must not crash", "must be consistent with a prior version of the application") that are usually implied.

see: http://www.allthingsquality.com/2010/04/there-are-always-requirements.html

Answer 2

With any application you are testing you need to learn the system. How is it used and how it generates revenue. Requirements come from that.

Who is using the system. What are the persona's and what is important for them. Understanding the users and their roles is key to see if something is a possible defect in their eyes.

Reporting defects should include the following info:

1. Step by step reproduction (containing enough details for a developer to reproduce the issue)
2. Actual result (what is the end-result of the steps, this is the thing that is possibly wrong)
3. Expected result (the result the persona would expect instead of the actual result. This makes it easier for developers or product managers to verify you understand the requirement and if the defect is valid or not.)

When you are new to a system it seems advisable to communicate a lot with the different roles users, managers and developers to understand what is happening and why.

Instead of just blindly creating bug-reports I would talk to the people and ask them if they think you have indeed found an issue or requirement that is wrongly implemented. This until you are confident with the requirements of the system. Getting a lot of reports rejected is not fun and or helpful.

As I am confronted with a new product to test. I always start with quality interviews with the roles. Asking them what they expect from the system, but also explaining the three different types of software quality. With the goal to understand where the product currently stands and what the greatest gaps are in the quality process. If needed you could start creating formal requirement documents, but question yourself if alternatives like automated tests could be an better idea to safeguard these features.

Answer 3

My opinion is communication. To communicate with developer, customer, business analyst and so on. Communicate with customer to get:

Better domain understanding ,Better acceptance tests, Better end-to-end tests

And communicate with developers to get:

Better Test Automation code, Better Unit Tests

And communicate with business analyst to get:

Better domain understanding Better acceptance tests

Answer 4

Without SRS try to identify the business work flow on the system. Based on that report bugs. Always try to identify work follow of the system . Talk to a BA,PM,clients and finally to the developer.

Answer 5

I have this same issue lately, testing without SRS or the SRS lack of details.

I'll share my to-do list when meet this situation:

1.Know your client or at least think as a normal user that will use the App. Make a list about what most user do with this App.

2.Ask myself about Why I want to make this App?, how people use this App?, Is it good enough for me?, etc. And from this question I make a simple SRS, or I prefer to called it "my own standard".

3.Without SRS or the SRS lack of details, it means it will be a lot more bugs to catch, since QA define the App's standard it self, so the testing process will get more rough, to avoid miss the deadline, test it as soon as possible.

4.And if the 3 to-do list above still doesn't meet user requirements, it means get ready for Change Requirement and a lot of Overtime.

-When there is no standard, try to make one-

Answer 6

This is how I would normally approach.

• Talk to the developers : For me this is the starting point. This will give me an idea of what requirements they used and importantly access to the system design.

• Cross checking with the business/users on the discussions with developers : This will be the base for my testing. Discussions with the business/users will definitely help in defining and refining the requirements. Document the findings (at least email ) and get the consent from the team and the business. the requirements will not be a functional requirement spec, but at least you'll have some requirements to work with from a business perspective.

• Exploring : with the little understanding you have on the system, it's time to explore. There'll be lot of questions. But having questions will help understanding the requirements properly. At least it'll start a discussion among the key stakeholders which eventually refine the requirements.

• Refer the Defects : I usually refer both open and closed defects. More often than not, you can find the fine tuned requirements within the comment threads on defects.

key word here is, ask lot of questions.

Hope this helps.