Original link (of a person): https://juejin.im/post/5d4e2ea76fb9a06b2f5fa018
Yesterday saw an article called "How to do a test like the sister programmer" , think of the points are in place, first of all I am a programmer, then stood a qualified programmer's point of view, how do you view these ideas do, the students did not read the article above, you can draw two minutes to read the next article easy and fun, today I would like to take this opportunity to talk about my point of view, and also stood the test of expression under the point of view, how do programmers like to test sister ? We also talk about interesting stories.
Article ideas start talking about the test sister
1. Test developed by analogy flattering sister said:
What does it mean to say? Test raised a bug, but changed the development of three (three represent multiple) bug, the other two are hidden yet found a bug. Lack of experience in the development of small brother modify this bug, I felt little impact range, a simple modification; and after experienced developers find and quickly ran to notify the test sister, said: "This bug affects a lot of business functions, would you please suspend the relevant functional testing, let me fix after the test. "
Sister heard music, I thought: "I just have another test tasks need to be tested, or busy with other first, otherwise futile trip here again, if no other projects on hand, just at the moment you can go a cup of tea at rest. "
I think there are two questions above:
1) the ability to judge the whole key programmer
2) Good communication skills is more important
If the development of small brother to solve a lot of bug-related, but why did not tell the test, the test sister silly bug where several test out the same roots, close to the end, summarize the number of bug, developers say three bug count one, the test said no, why you three are the three count one, my futile so long to find a bug, even if a unfair, a tongue war is about to erupt.
Think about this, really interesting, in fact, developers sometimes care about the number of bug, I remember before my colleagues dispute almost since the bug and test occurs, in fact, come to think is not necessary, we have to stand on each other's point of view, if not necessary, to do their most important.
2. Test do not like to "buy" one get a developer:
Sometimes the development of a complete change bug, regression testing after the discovery really solved, but the tragedy is that, just clean up the front yard, back yard and fire, followed by another function is not used. This phenomenon is very common in the work, saying that white is ill-considered development, lack of experience, or are not familiar with the business. So to remind colleagues of the old iron have good control of their own code, think things over and then go to the line and the code, or test you will often find debt collection.
3. Test love stories:
Testing say you tell me, how you produce bug, otherwise bug does not close, do not understand the development of mood, head Lenz nothing to write, test sister forced to look ignorant. I think there is really no reason impolite remarks bug, not even conducive to teamwork
First: Test hard test problems, want to know why, but it finally get is a word done, definitely not a gentleman.
Second: statistical test would like the entire project quality situation, bug severity and classification, or the environment caused due to the code level, if the code level are caused by careless or inconsiderate caused even did not even do so on caused Wait
Third: project summary, the development go back and look at the bug, if a long time, had no idea what caused it, if you want to summarize the thinking behind the look of fog also, in case questioning the leadership of the day, I heard Some time ago the project encountered a bug, a deep pit, so that you spent a lot of effort, your deeds filled pit under to share with us. If you do not record the root cause, we must also go to brood for a while, presumably leading your attitude is not the same
The above is today's topic introduction, long-winded so much, could not help but find themselves at a pen to write more, today's topic is the following:
How do programmers like to test sister?
If time is really a test to see my sister the following text, may be a bit serious, my request a little more, do not hit me
- Business mastery
- curiosity
- Good communication skills
- BA has the skills
- Accurate analysis capabilities
- A quiet heart
- never give up
- Strong sense of responsibility
- Sagacity of foresight
- Risk management
- Yan high value
Below we explain the above analysis of the quality of the test with the life cycle of a project:
Business mastery
Develop favorite familiar test business, as they would be busy line and the code, do not have time to tell you this, this business rule is how (some say, the business rules should not find a product? Products have not or are not familiar with the time, which the product is the problem, and to finish this article, I guess offend a lot of people, I endured the pressure, ha ha, a joke, a big project frequent personnel changes, the rules completely rare sort of people are understanding); familiar the business can stand on a higher point of view to testing and analysis to identify system problems.
curiosity
I doubt everything and actively confirmation, insightful; the main purpose of testers for testing is found to be defective software, rather than to prove that it is not defective. If you do not hold skeptical attitude is not a qualified testers, I believe are necessary to test the skill, but a strong degree of difference only.
For example, a developer needs to modify a small measure put to the test sister, she said: "I modified the function A, 2, 3 to be tested under the relevant scene, you help me test." Sister ask: "Big changes do, what the risks are, you did a self-test, it will affect other functions, need to test other features, please?" The development of a small brother, thinking how so many questions, and then said: " I think Ha, you such a question, I suddenly think of it affects another function, you have to test it next, if an impact on the disaster. "
At a time when the development of the test do not believe, he said, what changed, what you test, a good obedient Yeah, you better according to their own judgment on the business analysis required to test what point, in short, treated with skepticism. Once upon a time before work I encountered similar problems, resulting in a few days on-line user feedback function has a bug, I realized that the last time changes caused.
Good communication skills
Testers often need to deal with different departments. How to be more precise, more concise, more precise to describe the bug, and to ensure that developers can accept the bug you found, it will need to rely on good communication skills to express and persuasion. Therefore, good communication skills is particularly important.
I think communication is divided into two areas:
1) written communication
General company found a bug will mention the work order to the developer, giving the bug in detail, and this ticket is the test of a test level, then what kind of work order development was like it?
Let me talk a good example of the work order:
We look at this bug ticket What is the problem?
Standing on the perspective of development I think this ticket issue are the following:
- Description is not clear, only a title get away, do not know what the account, which address the promotion, nor link to, but also to develop guess in the end which address, which allows developers to test user
- Promotion rights in the title of the two, nor what kind of mark
- What are the rules demand, not clearly marked
Development of hope can be found in the core work order information, can immediately reproduce the problem, if ambiguous, incomplete information will cause the face to face communication costs.
2) oral expression
Good eloquence expression, so you better improve work efficiency and makes it easier to listen to understand what you say is important.
BA has the skills
BA就是业务分析师的意思，这要求测试人员有分析需求的能力，哪些需求是真需求，哪些需求是伪需求。真需求就玩命的测，伪需求在时间允许的情况下尽量的测。这个要求有点高，不过这个可以提高产品的质量，降低项目风险。
精确分析能力
很多公司的bug不进行分析的，即使分析也不给开发看，我觉得这不合理，首先讲下为什么要分析？
为了发现bug产生的根源，及早采取调整和控制措施，预防和控制问题的蔓延和新问题的产生，揭示软件质量、过程质量、人员能力、组织能力之间的关系，加强软件精细化管理，促进人、过程、组织持续性改进。
那么如果没人分析汇总，又没人团队参与总结，产品质量，团队成长能进步吗？
所以作为一名开发觉得，测试的分析能力是团队进步的催化剂。
一颗安静的心
浮躁的人总是找不出隐藏在深处的bug，良好的耐心，专注力是测试必备素质， 每天测试对着n个设备反反复复对着同一个产品使用研究，不腻也烦了，真佩服他们这么专注和坚持了下来，开发表示佩服。
永不妥协
曾经遇到过这样的问题，开发说这个问题有点复杂，不好改，这个场景极少出现，一改的话要延期了，要不先放一放，等后面有时间了再改，测试要不要妥协放一马？强势一点的测试会占优势，妥协意味着你成功的把质量不好这口黑锅华丽的背在了自己的身上，后面时间久了就没人跟进这个问题了。
强烈的责任感
一般说男人要有责任感，你还怎么把测试妹子扯上责任感了呢？ 测试承担为产品质量把关的角色，而对产品负责的基本要素就是要以质量先行。 如果测试没有责任心，敷衍了事，这将会把测试工作交给用户来完成，很可能引起非常严重的后果，影响公司的声誉。如果真有问题发生到用户身上，要即使的跟进，并做好后面修复工作的备案，不能逃避责任。
卓识的远见
一个好的测试，不仅仅停留在产品表面测试，有时候需要透过现象去看产品底层的结构，去发现异常测试场景，边界测试，安全问题测试等等。作为一名开发，我最喜欢测试的bug有水准，就是很难发现又比较严重的那种，这样才能反映我开发考虑问题的缺失和不足，有成长的空间，需要测试来推进改善。
还记得这张图片不，波音737飞机重大坠机事故，不得不说因为软件质量漏洞导致，测试开发难咎其责。确实有些问题很难找出，需要很大的技术含量和经验。 同时很体谅我们的测试不容易，出了事故后还要背锅。
风险管理能力
在做项目测试的时候，一个好的测试同学需要有发现项目质量上可能出现的风险的能力。另外当发现了项目风险的时候，我们还需要能够将风险管理起来，让风险可以被控制，可以被解决。
颜值高
最后一点颜值高，可以自动毁灭bug，这招恨，bug见不得长得好看的妹子，吓都吓跑了。
以上就是今天总结的测试人员拥有什么样的素质和能力，才会更惹人喜欢，职业中混的更好。有人说开发和测试 水火不容，不过我觉得测试更像是开发的秘书或者左膀右臂，帮助开发改进自己的系统，他们需要好好配合，才能好好的走下去。
END
如有收获，请帮忙转发，您的鼓励是作者最大的动力！
长按下图关注公众号 架构师的修炼