New to the field of QA, I've been asked to do SQA for a project that I'm unfamiliar with and that is close to completion. An example of a specific functional task to be tested looks like the following:

51: Rename Excluded Words at the Topic and Subtopic levels to be Not in Topic and Not in SubTopic

I could see how if I was the developer who built the project or had I been roped in on this since the beginning, then it'd be fairly obvious to "Click here" and then "Click this button in the drop down" followed by ... etc, etc. But because I'm new to this project and it's relatively large, I don't know the steps required to actually get the part where I "rename excluded words".

The above is just an actual example, but my goal here is to gain some insight that I can apply to my practice in general.

If the SQA is new on a project already in development, should the developer provide steps needed to perform the function to be tested?

6 Answers 6


No, absolutely not. One of the reasons for developers and testers to be different people is because it's very easy for someone who developed some function to know how it should work, and test the happy path, the one that they know should work. I'm not saying they'll do it intentionally, just that part of the reasons that QA exists is to go down the paths that developers don't think about.

With that said, yes, there needs to be some way for you to figure out what it is you're supposed to be doing. And in this case, you may have a wonderful chance to either test the documentation that's available, or to test the UI. If the thing under test is being developed for people with no prior knowledge of the thing being tested, then you're a very good person to come in and represent a new user. If you can't figure it out, then that suggests that either the documentation is lacking, or the UI is confusing. Or both.

Alternatively, if the thing under test is only supposed to be used by people with knowledge of it somehow, then you need to acquire that knowledge. Other people on your team should provide it to you.


I've noticed that the advantage to have a person that is focused on quality and testing is having a point of view different than the developers one.

However, since you're new in the project someone (not necessarily a developer) should take some time to help you understand the functionality, also you can rely on previous test cases, if there some, and in user's guides. Probably you'll need a lot of help executing the tests, but if you understand the functionality under testing you'll be able to come up with pretty good test cases.


  1. Understand the purpose and requirements of the functionality you're going to test. Rely on people, not necessarily developers, , documentation, including previous test cases, and user's guides.
  2. Try designing for own test cases (what to do no how to do it). Ask someone to have a look at them in order to select the ones that are applicable and the ones that are not. Here you'll see how you're unfamiliarity with the product will produce unexpected test cases no one has considered
  3. Ask for help at executing the test cases. Here is where you're going to need more help since you do not know how to perform the operations.

Hope my insight will help



Usually steps required to test should be provided by system analyst - they are the goal for developer to attain.

You need to receive good user-level training about how to use the system you are supposed to test, so SA can give you short description of the action required to test some interaction and you should be able to translate it to detailed actions.

One of your tasks as a tester is to make sure that SA described requirements unambiguously, including description of the expected behavior (which is base of your tests) and that developer coded according to those requirements.

If some activities are described in not enough detail, ask for explanation (and learn so next time you know it).


Take your example:

Rename Excluded Words at the Topic and Subtopic levels to be Not in Topic and Not in SubTopic

As a tester, you're supposed to use the system similar to a customer. Does the customer get a step by step instruction how to do this?

  • If no: Then the function must be intuitive, and testing that it is indeed intuitive can be considered part of the testing.
  • If yes: If the customer has access to support calls, or - unlikely - a good documentation, use the resources the customer has available.
  • If yes, but I have no idea what these words on the test mean: Then you lack domain knowledge. As tester you should use the software like a customer, so you have to learn what the customer does and what words the customer uses. Ask your business analysts, fellow testers, developers, and anyone else in the company to learn the language of your domain.

Last but not least, if developers write the tests in an entirely separate domain language which is different from the customers', then they screwed up and need to fix that. A simple "can you please reword that so people get what it means the first time they read it?", should do the trick. In some development ideologies the tester is close to the developers, so you can just turn around and ask them. Do ask them to clearly specify what they need tested, but do not ask them for step by step instructions - you don't need them, because it's your job to make different steps and break things.

I was a developer, later project manager. Personally, the best testers I worked with wanted to know what the software does, but refused to let me tell them how to use it. And then they came back with all kinds of requests about tooltips and such. That's also how I learned about Ctrl+Insert and Shift+Insert.


From Agile point of view, developers, business analysts and QAs are integral parts of one team.

  • Everyone is responsible for quality, so it is not someone's responsibility to come up with a test, it is everyone's responsibility to come up with a test.

Even the developers do not always have all the information needed to come up with steps to perform functional test.

I suggest:

  1. It would be difficult & disturbing to ask any of team-mate each time for requirement
  2. Read requirement documents, feature related existing test cases, gain an understanding of this function(s) & flows for features which are under test
  3. If you have any doubt, talk to a business analyst, if there is none, talk to your team leader to arrange a meeting with whoever in charge of this feature
  4. After you have clarified your doubts from a business perspective, go talk to developers if that is still necessary.
  5. Always stick to documents, state transition/data flow diagram available and freezed feature functionality document

In Agile

Cross functional team works together as a single unit. Close communication with the user representative to understand the features. For testing perspective SQA need to understand the business logic and functionality of the application. So you can ask.

In the beginning, people may face some difficulty to adopt this methodology, but through practice you will see SCRUM doing wonders. It keeps the resources very focused and you can actually see your application growing. Many a time’s organization encourages team to have few hours as self-study and development as a scrum task and allocate few hours. During the review, team members also demonstrate what they have studied, and sometimes present any tool or application which they have developed.

I personally appreciate this approach as it gives the people a chance to enhance their knowledge and also present their skills.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.