The ideal test organization in agile testing

In recent years, a word is very popular in software projects-Agile. Large and small projects usually contain the keyword "agile". In fact, agile itself is an idea of optimization, which is the product of software engineering development to a certain stage. In the face of the changeable market, all want to respond quickly to the market or customer changes. But how to really agile in the project, in addition to the methodology, there are a variety of external conditions constraints. The reality is that many research and development teams focus only on methodological learning, without paying attention to how organizational structure should change to meet the needs of agile testing. Some people may say that agile does not emphasize that everyone should be developed and tested? But this is only in the ideal situation. In real projects, there must be a division of testing and development. So this article wants to talk about in the agile test, our test organization should be how to build, can reasonable work division, give full play to everyone within the organization's strengths. That is, in the agile testing environment, we should use what kind of people, to do what kind of things, to achieve maximum efficiency.

In recent years, a word is very popular in software projects-Agile. Large and small projects usually contain the keyword "agile". In fact, agile itself is an idea of optimization, which is the product of software engineering development to a certain stage. In the face of the changeable market, all want to respond quickly to the market or customer changes. But how to really agile in the project, in addition to the methodology, there are a variety of external conditions constraints. The reality is that many research and development teams focus only on methodological learning, without paying attention to how organizational structure should change to meet the needs of agile testing. Some people may say that agile does not emphasize that everyone should be developed and tested? But this is only in the ideal situation. In real projects, there must be a division of testing and development. So this article wants to talk about in the agile test, our test organization should be how to build, can reasonable work division, give full play to everyone within the organization's strengths. That is, in the agile testing environment, we should use what kind of people, to do what kind of things, to achieve maximum efficiency.

There are two things to consider when considering the organizational structure of a team: what to do and who to do it. In fact, many people are not familiar with agile testing, even when it comes to agile testing, what exactly are we referring to and what to do to make the tests agile. So let's take a look at the first question: What to do, that is, what we talked about when we talked about agile testing.

In a relatively famous book on Agile Test Practice, "A practical Guide for testers and agile teams", it is clear that all test types for agile testing are divided into four-quadrant tests, grouped by test content, which can be divided into technology-oriented Operation (technology-facing) and business-oriented (business-facing) testing. In technology-oriented testing, we mainly include the familiar unit/component test, PSR (performance, security, reliability) test, usability test, and so on. In business-oriented testing, it includes manual exploratory testing, User-story and system testing, as well as automated BAT and regression testing, among other things. Because the characteristics of the test type here are very much related to what kind of person to do, so in the next section I will discuss the characteristics of various tests in detail.

Knowing what the agile test is doing, the scope it refers to, we can then select the right person to complete it based on the characteristics of the things we want to do. Here need to pay attention to a principle is: try to play everyone's specialty, let professional people to do professional things, overkill is not advisable. Figure 1: The Agile Development Organization chart, and then see why these people are being arranged to do this.

Figure 1. Agile Development Organization Architecture Chart

The first is technology-oriented testing. Why is it technology-oriented? Because these test types need to go deep into the code level or need tools to implement, and the specific business logic and business processes are not related.

Unit/component test (person in charge: developer)

This part of the test was done by the developer themselves. The reason is simple, and the developer is most aware of the structure and code logic of the code. We do not have to specifically arrange the so-called white box test or unit test engineers to help develop these things, these are the things they should do, to the big say that everyone should be responsible for quality. And, especially in the model of test-driven development, we definitely can't let testers do these things, and that is not worth the candle. Because if the test code was not written by the developers themselves, then it would cost more to debug or to find root cause. So remember, in test-driven development mode, to develop and test that piece of stuff that doesn't have a test crew, as testers do not have to think about the need to read code, from the boss or from the perspective of the organization manager, it is simply a waste of money, testers should do is, how to better help develop to understand the requirements, That's what agile often says about user-story, and how to design tests to verify that the product actually finishes the user-story, and then that's what's going on in business-oriented testing.

PSR and various "ility" tests (person in charge: Related test type experts)

Performance, security, and a variety of user experiences, usability robustness testing is self-evident about the importance of products, and these types of tests are often highly professional and highly complex. To do well, not only use a little tool, will record the script, or read the code can be achieved. It requires testers not only to use the tool is very skilled, more important is to understand the system architecture and the circumstances of the system running environment, such as desktop programs, in security is often closely related to the security of the system itself, the requirements of the testing of the system also have to know, web procedures, Performance bottlenecks are more closely related to system hardware and software, protocols and so on, do not have a systematic grasp of these relevant aspects and learning, do not do well. Therefore, if the organization has conditions, can be specialized in these non-functional system testing experts or senior engineers responsible for these types of tests, can be more ideal test results, otherwise the biggest possibility is to go through the motions, not the actual effect.

Take a look at business-oriented testing again. Business-oriented testing is familiar to and understood by most testers, but there are several types of test engineers, entry-level, advanced, automated, manual, and how to distribute according to different test types?

Et/user-story/system test (person in charge: experienced/Advanced test engineer)

In agile testing, the importance of these kinds of tests is self-evident. Like exploratory testing, which is even more important than system testing in agile testing, is the core test type for agile testing systems and businesses. Exploratory testing is characterized by the tester can be tested in advance of the system without any understanding, through the side of learning while testing, quickly in a limited time according to the priority to maximize the problems in the system, so that the efficiency is very high. Of course, the requirements of testers are very high. It may not have a test case, but there must be a lot of the test idea that leads the tester to think, and only if the tester has a very rich experience can he guess where the bugs are most likely to be found based on the fewest clues. and fast learning and summary ability is an indispensable condition, this is doomed to only by experienced senior Test engineer to be competent. User-story analysis requires testers to have good communication and understanding ability to translate the customer's expressed or potential customer needs into the description of our user "stories" and business logic for reference by developers. System test will not say, we all know, need to have a thorough understanding of the system being tested so in these test types, is a test engineer the ability of a comprehensive test, although not related to the code and automation, but must require testing experience, testing methods to master the business proficient personnel to carry out.