Where can a small team test and where can the team?

Where can a small team test and where can the team?

Preface: Unfortunately, I don't know whether I should talk about it or not. I don't have full experience or theory in testing small teams, however, recalling the results of yesterday's discussion, I am still immersed in disappointment and distress, is it to enhance the self-testing capability and self-driving ability of developers or to increase testers to filter problems?

First, let's leave the demand analysis aside. Why should we leave this important link first, because small teams in China are faced with unavoidable serious problems:

Of course, our small team will still do demand analysis, but the proportion is too small. We must quickly iterate and hand over the product so that the customer can measure their needs based on the products we make. So the question is, how can we ensure the quality of software in the process of rapid development, that is, the so-called test, and how to make progress.

I put forward my own point of view at the meeting, starting from the developer, instead of looking for a problem from the requirement analysis, not to the tester for a problem. How to start with developers is to enhance the self-testing capability of developers and maximize the efficiency of developers. In a small team, developers are the core competitiveness of the team. Developers must have a strong self-driving force and be able to access the resources of the team, what needs to be done is not to analyze the code according to the requirements that may already have problems, or to review the code without feeling good, we are not reluctant to do code testing or integration testing. However, my opinion was severely discriminated against or opposed at the meeting, and the following points were made:

The solution we have summarized is that although the developer's self-testing is a good idea, it is not feasible, reducing the testing staff's other work and focusing on testing, if one person is not enough to add more personnel.

I don't give too much comments on the above points and reasons. I think it's just a matter of my own, and I don't know the difficulties of other groups. Maybe in their eyes, the situation in our group is as follows: "project complexity is far from enough, there are fewer people and fewer problems, and everyone knows the modules of others ".

I'm very disappointed. What I'm disappointed with is not that my point of view is not recognized, but that many members of our project team are not aware of their own problems. Over time, they will only work hard. I'm not saying how good I am. I used to hate Testing. Testing is not just the patent of testers. Why should I test it myself, I am not clear about the modules developed by many people. What should I do to understand the development content of others? Besides, I cannot understand the complexity of the modules, in addition, many problems are caused by problems in demand, which is not my responsibility.

In reality, this is the case. As far as I am concerned, I have been receiving my current project for nearly a year. During this period, the leaders helped me a lot, my colleagues have also helped me a lot. Today, we can basically control the development and quality of the entire futures trading platform. From the very beginning, our group has no demand analysts, and there are no so-called testers. How can we solve fewer and fewer problems? I think this is mostly due to my own efforts. When I took over the project, although the project was already running online, I did not dare to look back. During this period, both core members of the original development team left early and I had to assume many roles. In the past, some people said that we had fewer team members, so there was no problem in the Role Positioning of agile development, one person assumes multiple roles. I want to analyze the requirements, discuss with the customer, think about the solution, participate in the survey, participate in the architecture, and participate in a lot of development work, especially a lot of testing work, then there are bugs constantly modified. I once had a lot of trouble. Why should I help others clean up my ass? Why are my members so irresponsible to their own code, almost all of them are under development, I can't expect too much self-testing. This requires me to perform self-testing and other tests. Of course, my self-developed products also experienced low-level problems after going online, this also improves my self-testing capabilities.

In my opinion, how small teams schedule developers to maximize their efficiency is the strongest vitality of the company's development. Many times, many members complain about how short their time is and how many tasks are accumulated. But what I see is that most of the time members do nothing. Maybe if we have a tester in our group at the beginning, then I will also form a dependency test by others. Although I can't say how good our group's tests are and how strong their self-testing capabilities are, I just want the team to promote the consciousness of "self-testing" and "self-driving force, however, this idea is not widely accepted by many people.

Summary: After talking about the above nonsense, I don't know what I should say. I recorded these things, not complaining about the team, but setting alarms for myself, no matter where I will be in the future, the banner of "self-testing" and "self-driving force" must be held high, instead of complaining that the demand analysis is not well done, and then leaving the problem to the testers, it is not to blame the project's difficulty but to avoid developers' responsibilities.