Do you think that all excellent developers can become excellent testers?

Everyone knows how to perform tests, but they do not necessarily know what qualities they really need to be a good tester.

From the IBM WebSphere developer technology journal.

What qualities should excellent system verification testers possess?

After more than eight years of software development, I have worked in the design and development of various projects, and have grown from junior developers to senior developers. Finally, I became a software architect. During this period, I realized the importance and challenges of testing, and even volunteered to designProgramThe test is based on the consideration of "solving your own problems. About a year ago, I became the owner of the system verification test (SVT) group. I wanted to write this column because of chatting with a tester in my department, one of the former testers applied for a testing position in our department. When I asked the tester about the applicant (who was working in development at the time), she replied, "I don't know this person clearly, but he must be a good tester because he is a developer ".

I was shocked to hear such a comment, but later I found that this is a common view for development and testing groups. There are indeed many excellent developers and excellent testers, but in a certain aspect, they are not necessarily good in other aspects. Therefore, as a test Manager, I need to explain the challenges and unique qualities faced by becoming an excellent SVT tester, this is not just to attract high-quality talents to join the ranks, but also to share the pride it brings to us and perhaps to win more respect for the testing work.

Discover Customer Value

According to regulations, the SVT group is responsible for system-level testing. What is system-level testing? This is a common problem. In my understanding, the purpose of a system-level test is to ensure that the functions provided by the product are used to realize the established customer value.

So what is "Customer Value? The answer is one of the reasons why customers buy and use a product. For example, I have been using Microsoft Word for many years. Recalling my personal experience in using the software, the most annoying thing in earlier versions was that it was easy to crash during the editing process, in this way, all the work since the last save will be lost. Fortunately, this is no longer the case in the current version. Even better, it automatically saves documents on a regular basis, so that even if you forget to save the document when you exit, you can still restore the last automatically saved copy, this is a very good feature for me. This kind of customer experience makes me realize that although this product provides general functions, it is its unique feature that makes it stand out from many competing products, it is precisely these features that provide value that make its customers love this product. Therefore, for excellent SVT testers, the most important quality is to be able to clearly understand the customer value of each feature.

Although it is easy to find the customer value that each feature promises from the design document or the user manual's profile, effectively merge them into the core of the test design solution, it is not that simple. To achieve this, testers need to understand the technology adoption cycle and the current location of the technology in its adoption curve. He also needs to learn about competitive technologies that provide similar Customer Value and collaborative technologies that may be used together.

Test a wider range of scenarios

I have observed that a common mistake for new SVT testers is that they always look at a technology (or product features) from a local rather than an overall perspective ). As a result, the test focuses on the conformity between the product and the design, rather than the true value it provides. For example, when the persistence of container management is introduced in J2EE technology, the objective is to provide a simpler and more portable programming mode for database access, its competitive technologies are other persistent technologies, such as JDBC and persistent data objects. If the technology or feature is not easy to use and cannot be scaled or at least executed to accomplish the tasks that can be completed by the competing technology, it is unacceptable even if the customer buys the product, they will not use this feature either. Therefore, the task of the SVT tester is to discover the essence of the problem and report it before the product is released.

Can I work or work better?

Not long ago, a tester explained to me how she was testing the new security session feature and how she could contact the trust server in each call for authentication, in this way, Web services can be executed better and more securely. I doubt whether the additional call time to the trust server is too short to offset the time saved by this new feature, and whether the trust server has introduced single point of failure to the system.

For SVT testers, technical knowledge about this feature and its related features is equally important, and only technical knowledge is not enough. Using customer value as the core of feature testing also requires testers to consider more content. In some cases, they need to cross the boundaries of the Organization. When I raised concerns about the performance of a trusted server, the tester replied, "I am not responsible for testing performance, but it is the responsibility of the performance team ". Another time, a customer asked me about how the product handles transaction recovery under heavy loads. The tester executing this test scenario cannot answer this question because she did not perform a load test at all.

To some extent, this reflects that the definition in the Organization is greatly restricted. Of course, there are few organizational structures that can well handle various situations. I believe that excellent SVT testers not only test the features themselves, but also are highly vigilant against any issues that may impede the implementation of the features to the value of the customers they promise, whether it is a competitive technology with better performance than this feature, or a collaboration feature that is not well integrated, or the feature itself does not achieve the expected results, or has additional defects in the system.

Accelerated Learning

Just as features and products cannot work independently, they cannot remain unchanged. Products and technologies are moving forward faster than ever before. Excellent testers will keep learning. More importantly, they need to learn quickly. The learning environment of SVT testers is very challenging. There is usually no documentation available when this feature is still in the design phase,CodeThe library may be unstable, but SVT testers must study it. When they begin to really understand this feature, the release date is imminent. Therefore, many SVT testers learn the relevant features based on experience and through repeated tests. Although this is usually an effective learning method, it is not enough for testers to rely solely on this single learning mechanism, it is difficult to tell whether the behavior of a feature comes from design or error. This also implies another danger: whether to regard all the information from developers as correct. For this, I prefer to be a student.

A better learning method is to start with the problem that this feature is intended to solve, whether it is a business or technical problem, and then understand the key idea of how this feature solves the problem. Features express the specific forms of these key ideas. In other words, good SVT testers will spend more time studying problems, not solutions. Testing is a way to measure the capability of using this feature as a problem solution.

Development and testing scenarios

The SVT tester developed a good test scenario to efficiently exercise this feature, which requires a comprehensive understanding of the features and their related features and the problems it intends to solve. In most cases, the test scenario does not work as expected. This is the purpose of the test, that is, to identify specific problems. Excellent SVT testers can analyze the roles of each component in the system, identify problems, identify bottlenecks in the system, and collect relevant evidence to confirm their predictions. If the system continues to behave in the opposite way as expected, the tester can redesign the test plan or question the design of the feature. In short, excellent SVT testers are also excellent system analysts. For example, one of our testing applications focuses on testing J2EE functions (such as EJB components, web services, and so on. However, the system has a bottleneck in the data access logic, so when the CPU usage is high, this test scenario becomes a stress test, although the stress characteristics are not the task of this test.

Weigh risks and Practicality

Another challenge that all testers often face is practicality and priority settings. Generally, it is almost impossible to test "all cases ". The entire range of tests that can be performed is usually too large, and it is difficult to complete the test work within a given period of time. When multiple features are combined, the test scope will become larger, its permutation and combination increase exponentially. For middleware products such as WebSphere Application Server, you can build various applications on the basis. The Design of applications is unlimited. Therefore, the question is how to prioritize test scenarios and how much test work can optimize costs and benefits. This still depends on the value of the customer, the technology adoption cycle, and the issues that the feature intends to solve. However, priority may be canceled and important test scenarios may be missing. Therefore, there is always some uncertainty, however, excellent SVT testers will note the existence of risks, actively identify relevant risks, and manage them based on progress. Before the product is released, they record assumptions and omissions, and confirm and correct the information based on customer feedback after the product is released. This inherent uncertainty will eventually be compensated by the use of checks, balances, and prevention measures in the proven SVT methodology.

The tester should be a programmer.

I firmly believe that excellent SVT testers should be excellent programmers, and I think it is for the following reasons:

• It cannot be fully understood unless a technology is used.
• Without basic programming skills, testers cannot conduct research, debugging, and gradually determine the root cause of the problem, which will help developers better solve the problem.
• Testers need to have sufficient programming skills to communicate effectively with developers and, more importantly, win the respect of the Development Group.

Based on my experience, for testers who do not have good programming skills, their testing efficiency is relatively low, and their opinions are often ignored by developers, for testers with good programming skills, they can solve the problem faster and their feedback is given greater attention.

Without a doubt, programming skills are very important for testers of middleware Products, but technical skills are equally important for testers engaged in end-user product testing. All software products are constantly developing, and the cost of regression testing is correspondingly higher and higher. Without an appropriate automated testing method, it is difficult to reproduce the testing results reliably and perform efficient regression. With the maturity of products and the increase of customer base, the cost of regression testing has become very high. If the automation of various testing tasks is not realized, the product innovation and in-depth improvement will be blocked. Without the support of appropriate programming skills, developing and maintaining automated testing scenarios may cost a lot, or even less cost-effective than manual testing. Repetitive manual regression testing not only makes testing tasks boring, but also costly, so that managers must face the difficult choices between regression testing, new testing, or service costs.

Be a diplomatic partner

Last but not least, an excellent SVT tester needs various quality skills: communication, negotiation, and interpersonal skills. This is very important for any job. Many people may not associate these skills with software testing, but these are also very important skills for testers, because their main task is to convince others that there are indeed some places that need to be modified. The developer's goal is to create a product, while the tester's goal is to find the problem. Excellent testers will be able to communicate issues clearly, negotiate changes with strategy, and effectively eliminate different opinions without creating a tense atmosphere. Excellent SVT testers do not work only according to the guidance of developers. On the contrary, they are real partners of developers and work together to improve their products.

Back to Top

Conclusion

In general, excellent SVT testers have an in-depth understanding of the Customer values provided by each feature and take these values as the core of the testing work, even if this means that more work must be done. Testers are not only good at quick learning, but also have been concerned about the problems that need to be addressed from the beginning to the end of the learning process. They carefully manage risks and confirm assumptions that they are excellent system analysts and programmers, and they have superb communication, negotiation and interpersonal skills.

Responsibilities can be divided, and a person cannot possess all these skills. But this is a challenge. Who can say that testing is simple? As a SVT test Manager, the most important part of my work is to acquire and develop these skills and help my team. SVT testing is more complex than most people think. I hope this article will help illustrate the scope of testing tasks and the skills required to complete these tasks well. I hope that those who already have these skills do not think that he or she is very good and don't want to be a tester, and realize that during the development cycle, testing is a dedicated and important part.

References

• For more information, see the original article on the developerworks global site.

• IBM developerworks WebSphere

About the author

		chinhua Q. wang is a senior SVT manager of IBM who works in the WebSphere Application Server product development organization in Austin, Texas. She manages a group of SVT testers and is mainly engaged in testing the web service and service component architecture. Prior to this, she was a senior software engineer and principal developer of the WebSphere development organization.