Developers, testers are testing your patience?

Developers, testers are testing your patience?

Author: Sonja Thompson
Translation: purpleendurer, version 1st
Tags: developers, testers, Sonja Thompson

After a break, I came back to my desk and found several new emails in my inbox. One of them immediately caught my attention. This is the name of a colleague who was scheduled to test a script I wrote. There are three emails in the inbox that he sent within six minutes. The first email only says "That script cannot work ." According to the postmark, the second one was sent two minutes later. "I cannot let that script run! But now it seems to generate garbage !" In the third message, I shouted, "Ravi, everything is fine. I am reading the wrong directory !"

Although I was annoyed by the tester's rush to send these messages, I was also happy for a while because of this series of emails. "The tester will try to break the monotonic of the day," I think.

However, aside from jokes, if you are a developer, I believe you met some testers who seem to define the test as "test developer. Their dictionary seems to be as follows:

Test term test the art of developers or their patience

You send the program to them, and they are responsible for putting the program into testing-by double-clicking the executable file or entering the name of the executable file on the command line, and pressing the Enter key. Then a quick response is provided. "Lavi, the program cannot work normally! "

Of course, the error may be a comma, a colon, or some other simple things that you do when you track football scores rather than code. In this case, I am sure you will regret it and make up for it. However, it is also common or possibly more difficult when testers look at things other than program execution or program results.

I have encountered many examples. Some simple operations by the test department can help him or her to pass the reported obstacles, or at least explain the cause of the apparent program failure. This includes checking whether the system has reasonable available disk space, read the information that you want your program to display when you encounter problems during running-you are a thoughtful developer-or you want to view log files.

The tester considers and traps all possible errors according to the developer. He also hoped that developers would create enough traces to track errors and trace back the causes. However, I believe that at least part of the tester's responsibility is to try to identify the problem and its causes as much as possible.

The tester should at least accurately report the problems encountered during the test. Usually a program or a group of programs will perform several intermediate steps before the end. If the program runs incorrectly, the tester can try to determine which steps are completed before the exception is terminated. This not only provides developers with clues about errors, but also accelerates error resolution and completes the development and test cycles.

In addition to occasional lack of cooperation with testers, developers may encounter situations where testers seem to lack some basic skills. A developer once told me his experiences with an unfamiliar tester. This project is being tested and running on UNIX. It includes a series of programs and Unix shell scripts, and the program and script running sequence is encapsulated in the exclusive toolkit. When a tester encounters a problem, contact my colleagues for assistance. The best option is to track the package step by step and try to manually run each program or script in sequence. When I heard the tester say, "How do I manually run the script? He was shocked.

This may not seem like it, but I do sympathize with the testers. They have an unenviable profession. They need to run the same program repeatedly to find errors that may never happen. In addition, when the developer is dizzy, the tester will help to discover these errors before the customer. However, if they pay more attention to the fields I have already mentioned, we can all live more easily.

Http://blogs.techrepublic.com.com/tr-out-loud? P = 665 & tag = NL. e055

Developers: Are testers testing your patience?
Author: Sonja Thompson
Category: contributors, TR out records, Guest Post
Tags: developer, tester, Sonja Thompson

I got back to my desk after a short break and found several new e-mails in my inbox. one name instantly caught my eye. it was a colleague who had been assigned to test a script I had written. there were three e-mails from him, all within the space of about six minutes. the first e-mail just said "the script does not work. "The second one, which was time-stamped about two minutes later, read," I had Not made the script executable! But now it seems to produce garbage !" And the third exclaimed, "Ravi, it is all fine! I was looking in the wrong directory !"

Purpleendurer Note: 1. catch the eye of: attracts the attention...
2. All very fine: Good (good, though...)
3. Look in: By the way

Though I was annoyed about the haste with which the tester had shot off these messages, I did take a moment to chuckle to myself about this series of e-mails. "testers do try to do their bit to break the monotony of the day," I thought to myself.

Purpleendurer Note: 1. be annoyed about the matter
2. chuckle to oneself: sneer, smile in the dark alone

However, jokes aside, if you're a developer, I'm sure you 've come into our SS some testers who seem to define testing as "testing the developer. "their dictionary seems to read:

Testing n. The art of testing the developer, or his patience

You send them a program, and they dutifully put it through the test-either by double-clicking on the executable or typing in the name of the executable on the command line and hitting Enter. and then comes the Pat response, "Ravi, the program does not work!"

Sometimes there's something more than just that terse statement-a brief line or two describing what happens when the program executes, or perhaps an even more elaborate explanation. there may even be a screenshot, which hopefully shows you what's wrong or at least where to start looking. rarely is there any mention of efforts made to analyze the problem or to eliminate some factors and isolate the cause of the problem.

Purpleendurer Note: 1. More than just: not just
2. Mention of: mentioned

Of course, the error cocould be a comma, a colon, or some other simple thing that you missed when you were tracking the football score rather than your code. in such cases, I'm sure you are suitably contrite, apologize, and try to make up in some way. however, just as often or probably more so, difficulty arises when the tester is watching something other than the program execution or the program's results.

Purpleendurer Note: 1. In some way: in a sense, some

I 've come into SS when instances where simple actions on the tester's part cocould have helped him or her get past the reported obstacle, or at least explain the cause of the apparent failure of the program. this includes des checking to see if the system had a reasonable amount of free disk space, reading the messages that you-the thoughtful developer that you are-made the program display when running into problems, or viewing the log files that are, after all, meant to be read by the user.

Purpleendurer Note: 1. Come into SS: encountered (accidentally discovered)
2. Get past: Pass
3. Mean to: Important to... be meant to do: What do you want to do

The tester depends on the developer to think of all possible errors and trap them. he also expects that the developer will create enough of a trail to be able to track an error back to its cause. however, I believe it's at least a part of the tester's duty to attempt to identify the problem correctly and also the cause, if possible.

The tester shocould, at the very least, accurately report the problem that he or she comes into SS when testing. often a program, or a set of programs, passes through several intermediate steps before concluding. if the program runs into an error, surely the tester can attempt to determine the steps that were completed before aborting. this not only gives the developer a clue about what cocould have gone wrong, but it also helps speed up the resolution of the error, as well as the conclusion of the development and testing cycle.

Purpleendurer Note: 1. pass through: pass through (through, flow through)

Apart from the occasional lack of cooperation from the tester, developers might come into various SS situations where the tester appears to lack some basic skills. A developer colleague once told me about his experience with an inept tester. the project being tested ran on UNIX. it consisted of a bunch of programs and Unix shell scripts that were put together inside a proprietary package, which ran the prog Rams and scripts in sequence. when the tester ran into problems, he contacted my colleags for compliance, who in turn suggested that the best option was perhaps to step through the package and try to run each program or script manually, in sequence. he was flabbergasted when the tester responded, "How do I run the script manually?"

Purpleendurer Note: 1. Proprietary packages> self-owned/exclusive Toolkit
2. In turn: Turn in turn; vice versa
3. Step through: Step by Step

While some questions can be raised about the project manager's choice of tester, it isn' t unreasonable to perform CT that the tester has a basic knowledge of the environment on which the program or project runs.

However, some problems related to the project manager's choice of the tester may arise, and it is no reason to expect the tester to have a basic understanding of the program or the running environment of the project.

It may not seem like it, but I do sympathize with testers. they have an unenviable job, having to run the same program again and again, looking for errors that may never show up. and testers do help discover those instances when the developer bungled before a client does. but if they wocould pay some heed to the areas I have mentioned, life cocould be a lot easier for us all.

Purpleendurer Note: 1. Pay heed to: Note (note)