Why is it getting harder to transfer testing to product?

Some students who work in testing may move to different transition directions such as project manager, project management, team management, or product transition.  In this article, I combine my experience in transitioning products to analyze why it is getting more and more difficult to transition products for testing positions. I hope it can bring you some inspiration.

Source: www.sohu.com

I would like to share my feelings in the past two years and then try to analyze the reasons behind them. The position is only the definition of what you do from the outside world, what kind of work we do and what kind of life we have is more crucial to our own mindset and degree of willingness.

This is a long-prepared article. As early as last summer, some partners in testing positions asked me whether they could transform to work on the product area. A test leader from the A-side also talked to me about a similar issue, discussing how to make testers have better business thinking. Although the starting points of the two friends are different, they both reflect the close connection between the two positions.

Because I graduated from the development profession, I started my career in testing, then gradually transitioned to project management through the control of testing + requirements, and finally embarked on the product when the right opportunity came.

Therefore, the testing position holds a different meaning for me. I have engaged in, recruited, understood, and experienced the awkward situation of this position in the Internet team, and naturally, some thoughts sprouted in my mind.

I know many students in testing, who later engaged in different development directions, such as project manager, project management, team management, but most of them continue to work in the position of testing, and some of them have achieved the position of test supervisor and senior test engineer. There are also a lot of transformed products like me, but most of the transformation was done some years ago.

In the last two years, the proportion of testing to product has been declining, so today I take this opportunity to talk about why it is more and more difficult for testing positions (mainly functional testing) to transform into products, and I also try to answer the questions of the previous two partners.

01 The relationship between testing and products

In terms of software development process, we design the product and test and verify the deliverables of this design, both of which can be attributed to "business-oriented" to some extent. In the previous article "How Requirements Post Empowers Implementation Teams", we also mentioned that the two are inseparable.

If you have a testing mindset, the product will make the program more detailed and better when developing the final design plan, especially for the handling of exceptions, if we think ahead, then the requirements review will be more proactive.

I recently read the year-end summaries of my teammates, and several of them mentioned that their requirements documentation rules were not detailed, and that there was insufficient consideration for exceptions.

Therefore, staff in both product and testing positions can communicate more and complement each other with different thinking and perspectives on how to approach the system.

I believe that a qualified tester knows the details of the system and the processing logic best. Because of the scale of our common system, most of them only allocate few functional testers, the development probability only understands their own modules, and the product probability only understands the business process and the coupling relationship between each function. Therefore, in the last two years, we often consult the opinions of testing when conducting some functional iterations, and initially explore the feasibility and workload of the system, which is also based on this reason.

02 Excellent test gradually become less

I interviewed roughly 100 testers in 2021 and 2022, with base locations in many cities, and from my intuition, there are fewer and fewer reliable functional tests, which made me wonder: why?

It may be the reason of the overall base, it may be the reason of the industry's attention and development prospect, or it may be other reasons that I didn't notice, resulting in more and more testers really made the industry joke " the tool people of the click", they rarely thinking about the reason behind the function and the problems behind the business.

It is also possible that you did not meet a good team and good leaders. I believe that there will be a lot of questions in the process of testing, but after asking them, will anyone really have the patience to answer them? Many team leaders often say: "You just follow the requirements, this is not what you should consider...thus gradually destroying the desire for knowledge in the hearts of them.

There are also many companies and team managers who position testing as a "process-oriented part" and recruit and employ people just to complete the testing task. Where there is a demand for testing, people are sent there, and they may test one project a month and leave immediately afterwards to go to the next workplace.

This situation is difficult for testing practitioners to form an efficient experience accumulation. If it is a similar business, you can cultivate business thinking through different customer requirements and customized scenarios; if it is a different business, it is hard to understand in a short time, and in the end, the project is done a lot, but what you learn in the end may not be much.

That is, the business continuity is not enough, more repetitive work brings only the accumulation of experience, and it is difficult to form a breakthrough growth.

Generally speaking, testing itself is a relatively low barrier to entry in the Internet industry. As the saying goes, everyone is a product manager, and as opposed to that, everyone can also be a functional tester. Therefore, many other industries that want to enter the Internet will give priority to the position of functional testing, so there is a lot of lack of understanding of software engineering.

At last, it may also be because they can't see a higher career path, so many students lack long-term goals, and gradually accept their current situation and no longer move forward.

In short, the number of good testers is decreasing, and the product circle is now more supply than demand. With the imbalance between supply and demand, it is difficult to transform ordinary tests, and good tests are unwilling to transform (they are unwilling or the leaders are unwilling).

The above statement may have the logical fallacy of "taking a part for the whole" and "subjective assumptions", because I come from a testing background, and I hope that the testing industry can produce more talented people. It is true that there are many excellent testing partners, from function to performance, automation, security and other areas with good development, but more is the proportion, is the overall appearance, but I hope these remarks will not incur abuse to myself.

03 Testing is better suited for requirements analysis

If testing wants to transition to product, a process is crossed in the middle, and this process is "requirements analyst".

I believe the easiest position for functional testing to transform is the requirements analyst. In addition to the obvious features, logic, and details, there is external communication that will give you a hand in the transformation.

Especially for outsourcing projects, the testers within the project team will have many opportunities to interface with the testers and business personnel of Party A to communicate defects and discuss reasonable scenarios. In this process, both their expression ability, adaptability and business understanding will be significantly improved.

My previous transition is because through frequent communication with customers, I gradually changed from receiving problems to solving them, and gradually started to discuss requirements with project managers and explain the modification plan to developers.

So if functional testing really wants to change jobs, my most recommended one is requirements analyst.

04 Requirements analysis and product managers between the "window paper"

But there are no small differences between requirements analysis and product managers, as I mentioned in an article last year, which involve differences in team models, differences in work focus, and most importantly, differences in thinking habits and goals.

Although many companies' product managers are doing the work of requirements analysis, there is still a layer of "window paper" between real product managers and requirements analysts, which is very thin, but it is still two dimensions without piercing it, and it is possible to interoperate only after piercing it. Just like my product team, I've been working on my annual goals for 2023, and my goal is to do the product, not the requirements.

At this stage of my understanding (may not be correct, welcome to discuss together), the biggest difference between requirements analysis and product managers is the way of thinking and action goals, the difference between the two leads to different job responsibilities and daily content.

Requirements positions are more of a key part of project-based management, while product positions are more of a key part of R&D management, and are in different environments, leading to the difference between both of them.
Even though both positions are writing documents, drawing prototypes, collaborating with other positions, and interfacing with customers or users, requirements may be more concerned with contract scope and products with business boundaries; requirements may be more concerned with delivery efficiency and products may be more concerned with standardization; requirements may be more concerned with customer input and products may be more concerned with user input.

The transformation between demand thinking and product thinking is also difficult for us.

(Special note: the above content has the problem of generalization, I hope you can understand the spirit, not to dwell on the specific wording. There is no superiority or inferiority for the requirements and products, just different models under different teams of different companies.)

So testing is more suitable for transitioning to requirements analysis, and if you are really interested in product, you can then transition from requirements analysis to product. Of course, many companies' junior products are more like requirements analysis in nature, so if you can find such a company, it is a good opportunity to start from junior product manager.

05 The working environment of testing has changed

With the development of the industry in recent years, more emphasis has been placed on the separation of duties and responsibilities in the team. Although testing has the right and obligation to mention defects from the business perspective and experience perspective, it is easy to make other positions in the team impatient over time, and if the testers meet some relatively dogmatic leaders at this time, it is likely that they will not give too much freedom to them.

For some third-party outsourcing testers, they often work with multiple projects, teams or even companies, and the starting point and interest point of each project may be different. In addition, the project team does not want the testers to be too "critical", "serious" and "suggestion-oriented" in order to get online faster.

This kind of work environment also largely makes testers more willing (or obliged) to adhere to the boundaries of their responsibilities: all based on the requirements document.

If the requirements document has been written, I need to test, if not, I will not test; if the writing is not reasonable, I will give feedback to the requirements staff or business people to decide. This may be a difficult hurdle for most functional testing students to break through.

06 Do you really want it?

Those who are outside the city want to get in, those who are in the city want to get out, and there are many such people in all walks of life who have the idea of changing careers. But what we need to seriously consider is: is this really what you want to do?

Take the test to the product for example, we need to analyze why we want to change? Is it because you feel that this position is not valued? No room for development? Being angry all day long? Not respected by the development? Or because of what?

Analyze the reasons, and then further analyze the underlying logic behind it, you may find that the ultimate problem is still in yourself. Even if you change your position and company, the problems you encounter now will most likely be encountered again, because our underlying logic and habits of thought have not changed.

It is not enough for us to rely on external forces alone to drive our own transformation. So there must be a strong willingness from the inside out in order for you to sustain the struggle in the face of subsequent difficulties. Being superficial will eventually make you less willing to actively seek change.

If you are now the head of a testing team and want to equip your subordinates with some product thinking so that they can better carry out their subsequent work. My advice at this point is still to first make sure they really want to have product thinking, or how to make them have this will, and then confirm your working environment to determine whether they allow, or are suitable for testers to have product thinking. Only after that is the question of how to cultivate it and how to transform it. If we just put forward some requirements and ideas, it will be difficult to push forward the real implementation.

There are many ways to develop product thinking and business thinking, and I also need to keep strengthening in product thinking. Today, let's not discuss how to do it, recently I'm reading the book Underlying Logic, for thinking, products, laws and other aspects of some new understanding, when I finish reading, and then talk with you how to develop product thinking.

07 Position is only the definition, it is important to think for yourself

Referring back to the word "transfer" in today's title, the final point I want to make is：
The position is only the external definition of your work content, what kind of work we do and what kind of life we have is more crucial to our own mindset and degree of willingness.
Even if you transfer to another job, without switching thinking and habits, you will still face many problems, or even more serious problems; on the contrary, when we develop relatively better habits, develop a more mature and comprehensive mode of thinking, even if you do not transfer to another job, you can have your own way to deal with the current problem.

And for these problems, my another advice is active, active to face, active to accept, active to communicate, only then can active to solve.
For example, we can take the initiative to communicate with our superiors, indicating our wishes and ideas, and find out how the leaders reply.
For example, we can take the initiative to chat with product colleagues, talk about his gains in the work, confusion, and even the journey of doing the product, to see whether these stories is what you want to have.
You can also review your work gains, confusion and journey, through the review to find out where the problem really lies?
Find the key issues, it is easier to solve the problem.
The above is what I shared today. Because I have been out of the testing position for many years, I analyze more from an observer's point of view, so please understand if there are any mistakes in the content and give me some guidance.

Conclusion

This article is only for some actual situation analysis, and does not involve the test, requirements, product three positions of the merits of the judgment. The birth of all excellent projects, all good products are inseparable from the collaboration of various positions and their respective duties.
Today, although we are discussing the phenomenon between testing and product, we can also objectively reflect the doubts of many other positions and other practitioners. In fact, no matter which position, only their own in-depth exploration, self-driven growth, long-term planning, persistence, can truly master the "core competitiveness".
This core competency will enable you to deal with most external factors and get out of your inner anxiety and uncertainty. As for how to do it, it varies from person to person. Here I share two paragraphs from Underlying Logic, hoping to bring you a little help.
To learn to choose is often to learn to give up: choose one and give up the others. Choosing is sometimes more important than trying, but giving up is sometimes more important than choosing. We should be brave enough to choose, and then enjoy the benefits and take the downside.
When you make an effort, you want instant recognition from everyone, and when you come out of a problem, it is not to think about the slackness of a few months ago. This is a thinking mistake that many people are prone to walk into.