This article focuses on some thoughts on the problems exposed in the development, management, and maintenance of testing tools to improve the efficiency of the testing department, as well as some personal improvement views.
write in front
The efficiency-improving testing tools mentioned in this article do not refer to the automated testing tools inherent in the department. The testing tools mentioned here uniformly refer to tests independently developed by testers after work to replace repetitive, tedious, and time-consuming manual operations. The purpose of developing the tool is to improve the efficiency of testing work. Not a testing tool for professional tool development department teams.
Testing tools manage exposed issues
Generally speaking, the overall quality of the testing tools released internally for efficiency improvement is not high, and the quality of tool functions, performance, ease of use, and maintainability are not high. Most testing tools are usually developed by those who use them easily, and the tool promotion is not high. It has not really improved the efficiency of other testers in the department. In response to these problems, I briefly investigated the reasons for my colleagues around me, and the main issues are as follows.
1. I don’t know where to get the tools. This is a problem of tool management in the testing department. There is no unified release path, and testers don’t know what testing tools are currently available in the testing department, or where to get them .
2. The tools cannot be used. Testers get the tools and don’t know how to use them. There are no instruction manuals or online help for some relatively complex functional testing tools. There are even menus, labels, and tool names developed by some tools that are very vague. I don't know what this tool is for. These are usually caused by testers not considering the usability of the tool when developing tools, making it difficult for other testers to get started. For example, a testing tool developer uses Python to develop a Windows platform tool but does not compile it into an executable .exe program for release. It is difficult for others to use it. First, they may have to download the Python program and other various dependencies that the program depends on. Class library. Many people don’t want to use a tool that is so troublesome. .
3. The tools are difficult to use and problems often occur. Test tool development may only be developed for a specific scenario and a specific business version when implementing the tool, so the tool is not generalizable. In addition, some tools interact too much and even rely on external conditions when using them, requiring the program to be set up to execute normally, etc. These are the reasons why they are difficult to use and no one uses them.
4. Tools are difficult to maintain (maintainability issues). Tool developers have different skills, abilities, and compliance with coding standards. To diversify the languages for tool development, the mainstream development languages such as Python and Java are fine. However, if the tools are developed in less commonly used languages such as AutoIt and vbs, the later maintenance will be very troublesome or even unmaintained. In addition, after all, the testers did not have a good understanding of the coding standards. The code was written how to write it, there were almost no comments for thousands of lines of code, and there was no development documentation, making it particularly difficult to maintain.
5. Tool requirements are developed randomly, the release path is not uniform, and the tool release format is not standardized. This is also a management issue. Without unified management of tools, many additional problems will arise. For example, as mentioned above, I don’t know where to get the tools, and there are no instructions for the tools. I have no coding skills, but I have identified shortcomings in my work and need to develop tools to whom I can submit requirements. . etc. . Here, it is not mandatory that some tools cannot be developed, but some tools can be developed. From the overall perspective of the testing department, it is definitely necessary to develop tools that focus the workload on improving the top N efficiency shortcomings of the testing department. .
Some opinions on tool development and improvement
The problems exposed above have been encountered in many products I have worked on, and they are not isolated cases. Let me share my personal views on how to solve these problems.
1. Unified management of tools. The testing department internally publishes tool development specifications, unified tool release paths, and tool release formats (tool name + version number, tool main functions, tool author, tool maintenance history, tool development IDE, etc.). It is recommended to use mainstream programming languages for development (Python, Java, etc.), and internally emphasize programming standards, etc.
2. Tool development improves ease of use. One is to reduce interaction but facilitate interaction. Reducing interaction mainly means integrating into the software without necessary input or input that can be solidified. Dependent steps can also be implemented directly in the tool. Convenient interaction mainly refers to providing an interactive window in the form of an interface when using the Windows system. This is the habit developed by programs used on Windows. For Linux, there is no problem with command line interaction, but the input prompt description of each step should be as simple and clear as possible. Try to achieve fool-like use. Consider it from this perspective when implementing it. You don’t expect that when you give someone a tool, you also have to teach them how to use it. .
3. Improve tool usability. This is a question of functionality. Usually these efficiency improvement tools are implemented by individuals who spend time after work. It is difficult to cover everything, but try to ensure that the main scene runs normally in most cases and can output the expected results normally. You can't just change the tool to a test version and it will cause problems. Others may not want to use it. The improvement of the tool can be optimized in the next iteration. This is a question that every tool developer should think about. . You also don’t expect that the tools you publish will cause problems as soon as others use them. . It’s also not good for your own image. . right
4. Improve tool maintainability. The requirements are not high, just add some more comments, and the code feels readable. Functions/classes should be divided as reasonably as possible. At least make sure that you can come back to look at your code in half a year or a year and be able to quickly understand and modify it. .
5. Regular promotion of tools. Regularly select some useful and universal tools for promotion. The fragrance of wine is also afraid of the depth of the alley. Every tool developer also hopes that the fruits of his labor can truly benefit others and have his efforts recognized by others.
6. Exchange coding skills. The overall coding skills of testers are still relatively weak, and tool development is still focused on a small group of people. This group of people can be brought together for more exchanges and discussions. You can also promote some basic coding training courses or some basic articles within the test, which can help testers who are interested in improving their coding skills.
summary
There are many problems exposed in the development, management, maintenance and use of tools, but they are actually nothing. After all, they are all developed by testers in their spare time. It's better to make it than not to make it. What is made can be iteratively optimized and improved with a little guidance. What is not advisable is to have no awareness of improvement and tolerate inefficient, repetitive, and tedious manual execution work. This will not do you any good. .
Due to time constraints, I wrote it in a hurry, and some points may not be expressed properly. If you are interested, you can communicate with me about these issues. .
[Full 200 episodes] A collection of super detailed advanced tutorials on automated testing of Python interfaces, truly simulating the actual combat of enterprise projects.