Busy, unknowingly in the new company has been 3 months. Especially these days, extremely busy, but I will still spare a certain amount of time to do some development. Later mature, I plan to output a hand-developed series to share with more test children’s shoes.
A few days ago, I was chatting with a friend in the group and heard a key word. I believe that this is also a lot of testing children have experienced, feeling test is easy to develop contempt, not respect.
Since there is no technical content to share today, I would like to chat casually, as a testing soldier who has been working for more than 3 years, to talk about my feelings.
Listen to what testers and developers are teasing each other about.
1. Greetings from development
As I was busy with various businesses, I knew a lot of developers. Contact more, we will talk about the topic. Because they also work with different testers, I occasionally hear developers make fun of testing.
“That XX, slightly wrong, direct backhand is a bug single, don’t ask”; “You this calculate what, you did not see that XXX, said the problem is a screenshot, speechless”; “Ah, now the test does not look at the database? Front-end pot bug mention to me why?” . .
I don’t know if you’ve ever heard this kind of joke, but I think it’s very real, and I’m sure there are testers out there who do it. Don’t ask, ask even I once…
In fact, for the above test performance of children’s shoes, I think there are usually two situations:
- Don’t know how to locate the bug, after pointing out the problem can only be thrown to the development themselves to troubleshoot
- Know how to locate, but do not locate further (too busy or too lazy to move)
2. Greetings from the quiz
Just recently, we had a new test boy in our group. Although he is new, but the resume is very good, in Ali, Huawei have been. Then when the party heard the new children’s shoes ridicule upstairs XX development, a few small functions can have more than a dozen bugs. Even more bugs, the most exasperating is, was found the bug also do not admit, for a while secretly changed their own, and then tell you that this function is no problem… Have you ever met a developer like this?
For this developer’s performance, I think it might go something like this:
- Poor professional ability, many bugs
- Professional ability is ok, not serious, no self-test, no sense of responsibility
- Character is not good, this person to do any work may cause the people around the cooperation of repugnance.
Ii. The “Enmity” between ME and Developa
In fact, we talk about a “cooperation” in daily work, but for the test of this job, you are still very “face”.
If the business you are testing is a highly self-demanding, technically competent developer, your case will generally run smoothly with few problems. On the contrary, poor development ability also honey confidence, you will be very tired, all kinds of immeasurability.
In my memory, I contact to the development of children’s shoes as a whole are still good, at least communication has not been unhappy. So, generally speaking, I get along pretty well with these developers, so there’s no “infernal affairs.”
But for the kind of “cancer” mentioned above, nature can not be used to. If they don’t test themselves, THEN I will find out why they don’t test themselves. If it is really because I am too busy, I think I can give some understanding. If it’s the kind of person who doesn’t test himself and uses the test as a “nanny”, sorry, smoke test three times but, back to the accident. Pull all the personnel involved in this demand in the group, explain the reason, develop self-test directly online.
In fact, the above situation is naturally the last thing I want to see, but this is because the other party is really angry, resulting in your work can not proceed smoothly, but I believe that most of the developers are very responsible, everyone is a demand, the function is no problem, as scheduled online.
What do I do in my work?
First of all, I don’t think the testing format is fixed at all. It needs to be adapted to the current format.
For example, my last employer, although it was a third-line Internet company, was also listed in Hong Kong stocks with stable business and thousands of employees. Such a company usually has a lot of standardized processes, such as from the proposal of requirements to the final online, can be better in accordance with the standard process down, the specific process we all know, there is no need to repeat.
Now it’s a different story. I’m a startup. I’m in round C. Too many requirements, not enough testing manpower (always hiring, difficult to find the right one), the process is not standardized, these shortcomings all have. You can’t do anything with the old one.
For example, in my recent job, what do I usually do in testing?
1. Urgent demand, short time online — Key words [Communication]
This happens in both stable and start-up companies, but more often in the latter. At this point, familiarity with the requirements is definitely a priority. Whether or not you are directly involved in the requirements review, communicate effectively with those directly involved in the requirements.
Find the requirement enabler, determine lead time, lead time, plan test time, and a distribution of test priorities for the requirement. In addition, but also found some risk points or test coverage of the place thrown out in time, work together to find a way. Don’t have a choke point stuck in your mouth. If it leads to a delay, the pot is yours.
2. Simple requirement description, not careful — Key words
This situation is also accompanied by the above situation, because it is difficult to have complete requirements document description, prototype diagram, etc., so this time development in the design may not be fully considered. Well, since I can’t just leave it behind, I can only try my best to help.
For example, in a recent requirements test, I had to test a Job interface, which is used to generate tasks according to policies. Data is very important, and this part of the test was a core focus.
Focus on the treatment of key needs, not only to see the display on the function page, but also to query a variety of tables, to determine the accuracy of data. This requirement was due to the poor preparation of test data. In the early stage of communication with the development, I understood the relationship between various tables involved and wrote SQL to build test data by myself.
When verifying the result, I will also check the log, and remind the developer to make up the key points if there is no log, so as to facilitate verification. Then in the test again and again, comb the processing logic of the interface. The seemingly correct processing logic, when designed enough scene data to test, sure enough, found two logical omissions.
The development of children’s shoes Lianzan found good, immediately find the product to confirm whether the need to make up this logic.
In addition, when I query a variety of tables, the development of children’s shoes also asked me: “you also check the library? I see a lot of tests don’t check the database, it’s good.”
3. Find problems, how to better raise bugs — key words [Caution]
Bugs, that must be a big part of our work. If I find the problem, I don’t think I need to mention the bug list immediately. First of all, I will mark the end of my case brain map to find out what the problem is. Then combined with my time schedule, I decided to locate the depth of the bug. At the very worst, you have to make sure that the problem is reproducible.
In fact, the common way to locate the bug is to see the request, confirm the parameter return, check the data, look at the log, in order to roughly determine who is the problem, at this time you bill of lading will be better. Of course, there must be some questions I’m not sure about, so I’ll probably refer to the most direct person for this feature.
Besides!! Add: “You may not be responsible for this problem, but if you find it is not your fault, you can simply pass it on to the right person.”
It’s not uncommon to have time to write test cases. In my opinion, under such requirements, after you are familiar with the general situation, you can write while testing. In the worst case, you must record the points tested and the scenes considered, as well as important communication content, screenshots and so on. This is the proof of your work details, but also the evidence of your future blame.
4. Accidentally show off your code
The most immediate reason many developers despise testing is that it doesn’t write code. When I was testing a special project in my last company, I cooperated with the high T developer in the group. When I finished the project, he said that HE thought I was a good test, and he thought that a test that could not write code could not be considered as a qualified test.
In fact, the big man’s remarks in my opinion is a little extreme, but it does represent part of the development of the idea.
Even now, during the idle period of debug development, I will open my editor and continue to write some useful code. Some developers will be curious to see it and ask: What code are you writing? This time you can pull a wave, do not brag about yourself, that you use the code to do something beneficial to improve performance and so on, although your development level is not high, but developers at this time you will be impressed, give you a can write code label.
However, let’s not forget that the ultimate goal of testing learning to write code is to improve performance, improve work efficiency, do something meaningful to everyone, make the code play value. Never put the cart before the horse. Write for the sake of writing.
Four, summary
The train of thought is more messy, think of which to say which, finally point at the theme, how not to be despised by the development.
First of all, I think testing children should never underestimate themselves, in fact, you can think about this, most developers work every day is business CRUD, with your business testing is not high where, if you change a development job, you can also reach their level after skilled. There is no distinction between noble and humble jobs, so there are so many people in the Internet industry, does everyone have to do development?
Moreover, your job content is not limited to your development, you should learn code, skilled, simple algorithms can also do some. The most important thing is never to be satisfied with the status quo, even if you go into other fields.
Finally, in the testing work, play your role as a responsible, prudent and helpful person to the team. Who would look down on you for such a person?
The above are my personal insights, welcome to share their work status content.