How to Make an automated testing tool that can kill people

Address: http://gigix.thoughtworkers.org/2010/5/29/how-to-create-a-test-tool-which-sucks/

 

You are not ambitious in a big company.ProgramMember. Those who joined the company in the same year worked hard on the core business, were scolded by customers, worked overtime, delivered, celebrated, and rewarded. However, you don't know how to be put into a corner department called "test tool development" and do some work that does not affect your company's performance. You hate it. You want revenge. You need to get everything you should have.

Now I will teach you how to do this.

 

First, you need to start a project to develop automatic testing tools. It is not difficult for bosses to believe in the importance of automated testing. There are countlessArticleWhen talking about this with books, the consultants you ask for will certainly talk about it. These are your helpers. The really difficult part is "independent development ". You can use a hundred trials. Tell the bosses that a self-developed tool can be maintained and supported by themselves. Only in this way can we grasp the lifeblood of core technologies in our own hands, instead of paying for maintenance support-be careful not to mention those open-source tools, because if the bosses really understand the meaning of the word "open-source, your entire big plan is ruined. Take IBM's rft as the target. In addition to the various benefits I will talk about later, the IBM consulting price is enough to help you scare the boss and start the project.

 

Then, you need to carefully select an automated test execution engine. You need such an engine, because you cannot create one by yourself-the workload is still the second. If you can even do this, you will not be depressed in this corner department. At the same time, this engine cannot be too stable or open, which is an indispensable element of your big plan. So, you see, as I said, rft is the best target: its openness makes sure it takes several months for you to embed it in your own tools, and no one else will try to do it in the future. What's more, when you report to the bosses that you have hack IBM software, thus saving licence fees, how happy they are.

 

Next, you need to invent your own test script syntax. It is certainly easy to use the rft syntax, but people who use it will find that they are actually using rft, and then find relevant information on the damn internet. This cannot happen. Always remember that your goal is to make yourself important. The syntax you invented should be based on XML. Not only is the implementation simple, but it also ensures that the test script cannot be read and restructured, so that the people who use this tool kneel at your feet and ask for your support. I will talk about the advantages of using XML later.

 

Of course, you do not want to use NotePad to edit XML for demonstration. Therefore, you must also implement a test case editing interface that supports drag and drop operations. A test step is represented as an icon, and several icons are dragged into the test case, so that a test case can be used. Do not forget that the function of executing the use case must also be implemented on this interface. It is important not to implement a command line to execute the use case for laziness. Now you can demonstrate what the leaders will like. "Dragging the mouse is actually much slower than entering the keyboard !" A silly consultant shouted. The leaders won't understand his words. Ignore him, let alone argue with him. It will only cause you trouble.

 

Now this tool can be used in a small range. Those troublesome users complain: "I have to repeat these operations every time! I want to merge them into one step !" Calm. Don't scold them (though you always want to scold them ). Remember? Making the test cases unrefactored is part of your big plan. Now you have to smile. We have considered this issue for a long time. Our tools can encapsulate several steps into something bigger with business meanings ...... Well, let's call it "Operation Vocabulary. Now I will help you with this abstraction and encapsulation. Of course, the operation should also be carried by XML, and a compilation, packaging, or encryption should be performed before it is provided to users. In short, they cannot see the source files. So that they can always rely on you.

 

Small-scale trial is very important. You must work hard to help users write test cases, encapsulate operations, and find all the resources you can find to help them, then, let us describe all the results of your 20-month investment as the magical changes brought about by your tools. Rest assured that you only need to do this once (or twice ). To put these stupid guys under your feet, sometimes you have to pay for them first. This is a policy.

 

After the trial is over, you go back to your office. These stupid users will constantly seek help from you to update encapsulated operations. This is a part of the design. Now you should create a central server to store all their test cases and operations on the server, so that they can get the test case script from the server every time they perform the test. Then tell them that this is cloud computing and testing factory. Of course, these dummies don't know What cloud computing is, but they will find that you are helping them update their operations faster, and then they will think that this is the result of cloud computing. Collect what they thank you for, and you will soon be able to use it.

 

Now everything is ready. You can report it to your boss. This report focuses on two keywords. This is also a common term for promoting this tool in the future. Be familiar with it.

 

Keywords: "fourth generation automated testing tools ". You need to tell the boss that you are using Java, Ruby, C #.Programming LanguageTo write test cases. That is the third generation (just compile the test cases for the first two generations ). The fourth-generation feature is "Operation-based vocabulary"-the stuff that can be dragged on the graphic interface, even though you know that it is a piece of XML that is hard to read, cannot be modified, or even to merge SVN.

 

Keyword 2: "Test Factory ". In this case, open the interface and connect it to the central server so that the boss can view the test cases of the pilot project. "Sitting in the office will let you know the test progress of all projects ." This sentence is a killer. Bosses will love it and will help you promote it.

 

As long as you are promoted to more project teams, you will become red. Now the importance of the previous design decisions is gradually reflected. Because the test cases cannot be reconstructed, any project that wants to use your tools has to ask you for help in terms of operations. Therefore, you can set up a department, attract more people to work hard for you and become your own leaders. But you are afraid that others will use it too frequently, so you will be exhausted. Don't worry, because rft is unstable, because each execution must be connected to the central server for use cases, because it cannot be put into continuous integration through command line or ant, because dragging with the mouse is much slower than using the keyboard, the automated testing process is very slow, and you can enjoy your new office with peace of mind.

 

Don't rush to enjoy it. It's just the beginning. The thoughtful design decisions ensure that many projects do not use your tools seriously. At this time, as a red star in the implementation of advanced automated testing concepts, you can just blow your hair in the ears of the boss, let them force all projects to use. There are many forced ways to do this, but you must remember to take a vocational skills test for testers: you must learn to use your tools to rate your salary increase. The key to this trick is to force them to use it, and make sure they don't have time to learn about other testing tools-you certainly don't want these dummies to come up and say, "This open-source tool is much better than ours, and there are so many moreCommunityIt is easy to maintain and support. Why not use it ", right?

 

After forcible promotion, your support needs will surge. In this case, you have to train the customer service team. Let them distinguish the user's header. If it is a project that the boss attaches importance to, if the office is very close to you or the boss, it should be strongly supported. If it comes from the support needs of remote mountainous areas, Let's cool it down. These remote mountainous areas often come up with some strange demands. For example, "can you not connect to a central server to execute use cases? We cannot connect to the company intranet here ". Let the younger siblings reply "no" directly. People who cannot connect to the company's intranet cannot complain to leaders effectively, so don't worry about them.

 

Okay. Now you have been successfully promoted from an edge programmer to a red guy in the company. Not only is there a bunch of younger siblings behind the horse, but also a bunch of project leaders have to ask for your priority. What is the pleasure of delivering one or two projects and opening one or two celebrations? Congratulations. You have not only changed your fate, but also the fate of the entire company.

 

Oh, I almost forgot the most important thing ...... Do not use your testing tools to perform automated tests on your projects. Microsoft's foodies call this behavior "eat your dog food", but what you do is poison. If you eat it, it will kill yourself. Remember, remember.