What kinds of people are involved in software testing?

Software testing like any other process of the software development cycle is a very critical and important phase and so does it has been dedicated an entire cycle called software testing life cycle. Without software you will not have any direction in the way of software development.

The overall efficiency of the software testing depends a whole lot on the professionals or individuals performing it. This article is about the people who are involved with the software testing.

1. Developer: A developer as the name suggests is responsible for taking care of all the development activities like:

(a)  Preparation of the test plan before the coding of the software system or application starts.

(b) Creation of the input test data as per the various software testing methodologies are to be used.

(c)  Preparation of the documentation of the expected outcomes of the different test cases.

(d) Testing the source code according to their personally developed schemas.

(e)  Documentation of the actual test results.

(f)  Validation of the code whose actual output is same as the expected outcome.

(g)  Filling up the project documentation repository with the results of the unit testing and the test data used as input.

(h)   Active participation in the process of the code reviews to ensure that the unit testing is complete.

2. Data architect or Data Modeler: Data architect is responsible for taking care of the management of all the issues regarding the architecture and build of the software system or application:

(a)  Testing of the scripts written in data definition language (DDL) as per their personally developed schema.

(b) Filling up the project documentation repository with the tested and validate DDL scripts.

3. Senior Developer or System Tester: A team consists of more than one senior developers or system testers and they are responsible for taking care of the actual software testing of the software system or application. They share some responsibilities with the developers:

a)  Active participation in the process of the code reviews like the developers for determining that the unit testing has been completed successfully.

b)  Preparation of the test plan

c)  Creation of the test data for input to input to test cases.

d)  Preparation of the documentation of the expected outcomes of the different test cases.

e)  Implementing the code in the testing environment

f)   Execution of the work streams that are comprised of the system tests along with their scripts.

g) Validation of the actual results of the tests.

h) Creation of the defects if required for some kinds of testing techniques like fault injection techniques, in defect management tracking tools etc.

(i)  Filling up the project documentation repository with the results of the system testing and the test data used as input.

4. Data base Administrator: They share the responsibilities of the following tasks:

a) Creation of the system, quality assurance, release testing, user acceptance and integration environments.

b) Execution of the scripts written in DDL or data definition language and DML or data manipulation language in the environments as specified in the test plan.

c) Preparation of the restores and back ups.

5. Integration Tester or Senior ETL Designer: They are responsible for:

(a)    Participation in the system test reviews for ensuring the completeness of the system.

(b)   Preparation of the integration test plan.

(c)    Creation of the integration test data.

(d)   Documentation of the expected outcomes of the integration test results.

(e)    Implementing code in the integration testing environment.

(f)    Validation of the actual integration test results.

6. Quality assurance people
7. QA software tester
8. User acceptance tester
9. Release manager
10. Production support specialists

Steps to become a better software tester - can do these over a period of time - Part 10

I have been writing a series of posts (Improve your testing skills) on how to improve your testing skills, with many advice items that will take time to implement, and some items that can be done fairly swiftly. It requires that the tester have the intention of making these changes, and showing their will and determination (since some of them will ask for the tester to put in extra effort). Some more tips for this series are:
- Ensure that you put in a lot of effort to be concise and yet clear in your written communication. A tester has a number of areas where good written communication is required, such as writing test cases, test plans, bugs, and so on. A person who is able to clearly communicate is normally seen in a much better light that somebody whose documentation takes effort to read, or is not clear enough that more information is needed before somebody else can work from that documentation.
- Be sure that you make an effort to check for previous behavior, when working on products where a new version of the product is being done. No developer likes a tester who claims to have found a new bug, and then after some discussion and time spent, it gets discovered that the defect was actually filed in previous versions of the product, and for some reason, was not deemed worthy of fixing in the previous version of the product. A tester will do a check for previous versions of the product having this bug, and also provide this information to the developer. This is true because development time is limited, and sometimes if a bug is present in many versions of the product, and customers have not really raised any issues about this defect, it may be possible to de-prioritize the bug and not put time for fixing the bug.
- Keep yourself updated with latest techniques. There is a lot of research in terms of improvements in testing skills on the internet and in specialist magazines, and a tester can improve their testing skills by reading the latest research and trying out some of the measures advocated by such research.

Steps to become a better software tester - can do these over a period of time - Part 3

In this series of posts (Improving testing skills), I have been writing about how to improve the testing capabilities of tester, and have presented some points that could help a developer. In this context, here are some points that could help the tester to improve their skills.
- The tester needs to improve their knowledge of the product. I once had a case where the tester had a series of test cases to execute and did not really have the time to get detailed knowledge of the product. So when there was a change in design and features, and the test cases had to be re-done, the tester did not have the knowledge to quickly make the changes. It took time, and the tester had to face flak because of the time involved, and was also berated for a poor knowledge of the product (and there was really no defence of this lack of knowledge).
- Domain knowledge of the area. A skilled tester will make the time to learn about the domain in which they are testing. For example, if an application is being written for the banking domain, then it would help for the tester to get a quick understanding of the concepts of the banking domain, especially the specific areas which the application is expected to cover. In my previous experience, I have seen that this helps the tester ask informed questions, and also be able to better review the test cases for completeness.
- The tester needs to focus on the more critical parts of the application first, and check those areas first in terms of testing. It is a reality that no application is 100% bug free (or rather, the amount of effort and cost required to make an application bug free is exorbitant), and hence it is key that the tester has found more of the bugs in the application that have a high priority and severity, and the bugs that are remaining in the application are less severe, and have a lower customer impact.

Steps to become a better software tester - can do these over a period of time - Part 2

In the previous post (Improve testing skills), I had provided some steps in how a person could be a better tester. In this post, I will continue on this line and provide some more points on how a person could improve their testing skills.
- Being able to explore the boundaries of what has been provided. So, for example, an average tester will test only as per the test cases provided while skilled testers start to feel whether the test cases are adequate or not, when required, they provide updates that add to the test case coverage to ensure that the overall product quality increases. Such efforts are noticed, and in many organizations, there is measurement of the amount of such efforts that are made by individuals.
- Try and feel like the end use customer. A lot of testers start to feel much closer to the Dev teams, to the individual dev who wrote the code that they are testing, and so on. Instead, even while maintaining a relationship with the developer, they need to feel like the end customer; looking at the workflows that the customer uses, seeing things from their view point. Such testing is much more effective in catching defects that would be faced by the end user and lead to a much better impression of the product in the perception of the customers.
- Relationship with the developer and integration with the development phase. During the design and development phase of the product, the tester should be fully involved. The tester can bring their own value added to the product development strategy, and learn a lot more about the reasons why the design has been done in the manner in which it is done. During the development phase, the tester can also learn about which area does the developer feel that more emphasis need to be done, which area was written in a hurry or is more complicated, and so on. Such knowledge gives the tester a much better impression of the product and leads to a much better skill at testing the product.

Steps to become a better software tester - can do these over a period of time - Part 1

If you are a good software tester, it shows in your career graph. In most cases, the manager of the software testing team will be able to recognize when a tester prepares extensive test cases and covers as much of the testing field as anybody can. Further, when you take feedback from the development team, they are also able to provide feedback that such a person is indeed the one with whom they would like to work, since such a skilled tester will be able to ensure that their feature is as rock solid as possible (such a tester would have identified as many bugs as possible in their feature, and early).
Anybody can be a good tester, as long as the person is determined to make improvements and consistently follow a number of steps. Do these, improve yourself, and you will find that your popularity, your prestige will go up, and so will the respect that other people have for you.
- When such a tester reports defects, provide as much relevant information as possible. The worst kind of tester is somebody who reports just the exact defect; if you want improvement, report the consistency with which the defect happens; report the steps that lead to the defect, report any input and output parameters. When a developer receives all such information, it helps them to reproduce the defect easily which in turn leads to faster fixing of the defect. If a tester is uncooperative or does not provide all this information, they will find that developers hesitate to work with them.
- Note whether the defect could be because of the system configuration. I have seen this many times. When the tester finds a defect, the better ones are able to estimate whether this is a defect in the functionality, or could have happened because an earlier build was on the system or there was some other similar problem. In such cases, the skilled tester will try the problem on another system and see whether it can be reproduced there as well.
- Overall improving the system. When somebody designs a set of processes, they do it based on some experience as well as how they would like the system to work. When somebody works as per the system, they can always find improvements in how they would like the system to work. A good tester will be appreciated by their manager if they can find improvements in the system and processes. This leads to them developing a reputation for somebody who thinks, which is a very useful reputation to develop.

What is Requirement Metrics? What is Requirement Profile Test?

Requirements measurement focuses on three areas: process, product and resources.
- Requirement size can be a good input for estimating software development effort.
- As software development progresses, the requirement size can be tracked down.
- As design and development occur, we would have a deeper understanding of the problem and solution.
- A large number of changes indicates some instability and uncertainty in our understanding of what the system should do or how it should behave.

Requirements can be used to determine if the requirements are ready to be turned over to them by designers and testers. Requirement Profile test is a technique employed to determine the readiness to turn over requirements to the designers or testers.
For Designers
- System Designer Rate 1: It means the designer understands the requirements completely.
- System Designer Rate 2: It means that there are aspects of the requirement that are new to designer, however, they are not radically different from requirements that he has defined.
- System Designer Rate 3: It means that there are aspects of the requirement that are very different from requirement that the designer has designed before, however he understands it and is confident that he can develop a good design.
- System Designer Rate 4: It means that there are parts of this requirement that he does not understand, not confident that he can develop a good design.
- System Designer Rate 5: It means that he does not understand the requirement at all and a design cannot be developed.

For Testers:
- System Tester Rate 1: It means that he understands the requirements completely and that he has tested similar requirements previously.
- System Tester Rate 2: It means that there are aspects of the requirement that are new to tester however, they are not radically different from requirements that he has tested before.
- System Tester Rate 3: It means that there are aspects of the requirement that are very different from requirement that the tester has tested before, however he understands it and is confident that he can test it.
- System Tester Rate 4: It means that there are parts of this requirement that he does not understand, not confident that he can devise a test to address this requirement.
- System Tester Rate 5: It means that he does not understand the requirement at all and he cannot develop a test to address it.