7

I am new to this field and I have decided my career as software tester. What are the role and responsibilities as an software tester

According to my assumption:

1) Analyzing the Requirements from the client
2) Participating in preparing Test Plans
3) Preparing Test Scenarios,test cases
4) Defect Tracking
5) Preparing Suggestion Documents to improve the quality of the application
6) Communication with the Test Lead / Test Manager
7) Conducting Review Meetings within the Team

Apart from the above points any other things I need to care about as a software tester?

Improve this question
2
  • 3
    Welcome to SQA Stack Exchange. Please see the FAQ sqa.stackexchange.com/faq. There are entire books devoted to this subject. If you can narrow the scope of your question, we can help you better. – Laura Hensley Oct 30 '12 at 13:58
  • 1
    How have you decided on a career in software testing if you do not know the roles and responsibilities? – squeemish Oct 31 '12 at 17:39
6

Thank you for the opportunity for me to delve into the theory of testing and Quality Assurance. As you seem to be mostly interested in the role of a test specialist in software realization projects, I will keep the scope of my answer in that general area. Please keep in mind that most here is written from my opinion and experience and less based on books.

First about quality

Before we can start testing we need to understand the concept of Quality. Quality can be defined as the distance between the actual object under test and the customer's expectation of the object. This means that you should be measuring how well the object fits the expectation to determine the quality. To do this, you should be aware of the expectation, which is often captured in requirements. Now you can see that when your requirements are not fitting the expectation, neither will the end result of everyone's efforts.

What is testing and why would you do it?

In my opinion, testing is more about measuring than it is about suggesting improvement. Everyone has a specialty and the Business Analyst should be very skilled in delivering great requirements and suggesting improvements. This pushes your point 5. out of the window.

As a tester, you should be clear, in every new project you work, what your assignment is.

  • Are you expected to add to great quality software? Be prepared to meet with the customer to find out his expectations.

  • Are you expected to add to a low defect count? Write loads of test cases based on the requirements and specification.

Find out what type of tester you are and make sure you fit in your team, you will do fine.

Kind regards, Koen Prins

Improve this answer
1
  • 2
    It's true that suggesting improvements might not be in a tester's job description, but keep in mind that job descriptions are rarely clear-cut, and people often wear multiple hats to some extent. It's not uncommon for someone whose primary job is testing to suggest or even implement improvements, especially in small companies. Also, the line between improvements and fixes can be surprisingly blurry, especially if the product lacks a formal specification, which makes the situation even fuzzier. Other than that, good answer. – user867 Nov 1 '12 at 0:54
6

The two obvious steps that you seem to have missed out:

  • Perform the tests. Much may be done auto-magically, but manual testing is still a key aspect at integration and system test levels.
  • Report the results. Whilst automated tests may generate a results file, you'll need to interpret and present the results in a format that is appropriate to the audience.

As with Developer roles, Testing roles will be about documentation... lots of it!

Improve this answer
4
  • Lots do documentation ? Really ? Depends on the org and methodology, maybe I'm lucky but I don't gave much at all ( but have worked at places that drown in it ) – Phil Kirkham Nov 2 '12 at 11:28
  • 2
    You're lucky... in aerospace/defence and automotive you measure software by the thickness of the documentation :( – Andrew Nov 2 '12 at 11:47
  • How much does that documentation contribute to the success of the project/software? – lontivero Nov 15 '12 at 1:51
  • It very much depends how the project looks at it. If done in the right order, it can be VERY beneficial and cost effective. If looked upon as a box ticking exercise, to be left until later, it is a complete waste of time. Sadly too many companies think "box ticking" – Andrew Nov 15 '12 at 7:10
3

INHO the testers' responsability is the sameone that all other roles' responsibility: to contribute as much as possible to the success of the project.

That is, keep an eye on the ROI of every one of your activities. Keep a balance between the cost and benefit the project (and the whole team) will get for those activities. Keep aligned with the project and customer needs.

  • Every time is harder to get a formal requirements document then, be flexible.
  • Probably the customer don´t care about your test cases. How important are they? Is it possible avoid them all?, some of them?
  • Sometimes customer needs the software right now, he thinks time to
    market is more important than quality. Ask yourself which could be
    the best approach for that kind of project.
  • It is usual in lots of projects release a new version every week for a huge amount of users. Design your verification strategy for these situations.
  • Avoid bureaucracy and focus on what really matter.
  • Work closer with developers, they need your feedback as soon as possible.

Those are the responsibilities.

Improve this answer
1
  • "Avoid bureaucracy and focus on what really matter." That's not a responsibility. That's an approach. – dzieciou Nov 14 '12 at 6:44
1

In my opinion the tester should be a more active role with these aditional responsibilities.

(Note: this idea is not state of the art but a vision)

  • Analyzing the Requirements from the client. When the requirements are written down make shure that the requierements are smart and automatic testable by using bdd-style / Gherkin-style language. These smart requirements should become part of the contract between develpment and customer.
  • Design/Architecture: Make shure that the software is easy testable.
  • Verify that the defintion of done is obeyed of every released feature.
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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