http://www.cnblogs.com/scios/p/5489933.html Reprinted
In the past two months, more than ten candidates have been interviewed one after another, with working years ranging from half a year to eight years, but few are satisfied. During the period, I sighed and recalled that only 3 of the more than 60 people interviewed last year met the requirements, such as the throat.
Are my requirements high?
My requirements are actually: good communication skills, familiar with common software development processes, certain requirements analysis and use case design skills, and basic linux and sql operation skills. Some coding skills will be added. This is the result of a long-term compromise with reality. If people are still smart, I'd love to take the time to train them.
interview result:
Sadly, the right person is really hard to find. What is even more regrettable is that I have seen many colleagues who have been in the industry for many years, but their abilities have not increased along with their working years. Some people who have been in the industry for five or six years sometimes feel that they are not as good as a young man who has been in the industry for one or two years. . The most regrettable thing is that most people don't have a clear career development idea.
Some details of the interview:
-
I have prepared a set of written test questions. Considering the different situations of the interviewees, the questions include the most basic test methods, as well as more advanced SQL application and design analysis. None of the test takers gave a relatively satisfactory answer. During the internal evaluation, we thought that a person with two years of work experience should be able to answer very well.
-
I generally ask some questions based on the resume to see if the resume is genuine. It will also ask some basic test knowledge to check the professional quality of the test taker.
Frequently Asked Questions:
- Tell me about your usual testing methods?
Ninety percent of people can only answer equivalence classes and boundary values. Only a few people can talk about other test case design methods, but no one can answer satisfactorily when asked in depth.
- Give a very simple small example, such as a login operation, and have the candidate answer how to design a use case using the equivalence class approach.
Surprisingly, less than one-fifth are still able to give a satisfactory answer.
- State the lifecycle of a bug (how do you manage bugs?)
More than half of the people can tell the common process, but ask some in-depth questions: such as how to combine defects with versions, test rounds, etc., how to deal with some special cases, etc., many people are confused, and these are basically commonly used in work. of.
- What's the longest project you've worked on? What problems did you encounter during this period that gave you the most headaches? How do you fix it?
Only about 1 in 10 people can give a decent answer (being able to identify the problem, ask what its adverse effects are, and be able to give some sort of solution is a good answer).
- What testing jobs are you interested in and where would you like to develop?
4 out of 10 people would say automated testing, 3 would say performance testing, 2 would say management, and one would say white box testing. And hope to provide corresponding training. Only very few people can name specific ideas and technical items.
- If you continue to ask: Are you talking about performance testing? Have you ever studied in this area?
Half will say that they have read some technical articles on the website, and half will say that they have read the loadrunner book. If you continue to ask, which book is it? What kind of article? What specific knowledge points can you talk about? 90% can't answer.
- Q: Which test book have you read? Which tech blogs? Which sites?
50% of people will say they have read QTP books (real QTP usage is almost catching up with Nokia usage!) and haven't actually used it at work, and then nothing else. Less than half of the people have not read a technical book in the last few years.
- If there are test candidates with management experience, I will ask some questions related to the management of the test process, such as giving the simplest question: What if the test time is not enough?
Only two or three out of ten people mentioned prioritization and test tailoring, and most of them responded that overtime must be done.
What I want to say:
- For your future, please clarify some personal ability ideas. What will you be like in five years, ten years from now? Is there a clear idea? Is there a level of someone you want to be in five years from now? If these lines of thinking are unclear, please look at the outside world to see how some people who have done very well on the test work, what abilities have they mastered? Learn them, chase them and try to surpass them. It's best to know them, and it's good to talk about the mountains and move forward together with like-minded people. In addition, the goal should not be too abstract, it must be decomposable and checkable.
- 多读一些测试书籍，测试的书并不是只有QTP！看看微软测试专家史亮推荐的书单，这些都是不错的好书：http://www.cnblogs.com/liangshi/archive/2011/03/07/1973525.html 有些书能够帮助你把测试知识框架搭建起来，比照一下你还缺点啥？
- 多读一些其它书籍，不限于技术书籍。如果想读的书有利于工作，推荐一些如何做思辨思维的书。《思考的艺术》《六顶思考帽》《你的灯亮着么》《学会提问》是我喜欢的4本书。它们会教你怎么独立思考，养成提问的习惯，而提问的习惯是我们现在的测试人员最缺乏的一件事情。人们往往拿了被测物就开始忙着写用例，忙着测试。而不是先探索它、研究它。当然IT技术也要掌握，如果你的IT技能能够赶上开发，你发现你做测试的思路会非常的宽广。
- 把书籍中的东西跟你的工作对比，把好的东西引入工作（这点是检验书本质量的好方法，也是促进你思考，促进你能力提高的好方法。）
- 关注大牛们的技术博客。国内写好测试博客的人不是很多（很多人其实很有水平，但是不喜欢写blog），但是国外有很多，有人整理了一个list也推荐给大家：http://ssnlove2008.blog.163.com/blog/static/3788942020093284842381/。
- 搞定你所在行业的领域知识：如常见IT技术，常见业务知识，这些知识掌握的越深，你的价值越高。测试技术是内功，但是你能直接为企业带来价值的最大之处是你对被测物熟悉程度，也就是你的领域知识！！！
- 没有方向？从你的工作入手，比如，你遇到的最大的难题是什么？我怎么解决它？我需要掌握什么样的技术解决他？我要推动什么样的组织改变来解决它？别人怎么解决它？有没有更好的方法？使用后我改进了那些？百度一下别人有没有同样的问题？尝试作对比，如果觉得他做得好，尝试联系那个人讨论一下。看看对方的进展。尝试把活儿干得特别漂亮。你能解决10个中等问题以后，你的能力会有大幅度提高。
- 尝试做笔记，或者写博客，要坚持！
另外的吐槽：
野蛮生长没有经过系统训练的同学非常多。这其实有很多因素，分析起来觉得有以下几点：
- 大学或者职业教育没有非常好的课程体系（有些培训机构还行，但是也需要提高），其实测试技能需要系统训练和长时间磨练才能有根本的增长，我们的职业教育或者再教育体系其实还是有很大空白的。
- 说句实话，大家的读书氛围不够浓厚。大家不喜欢看书。而读书是再教育成本最低，又非常有效的途径。相比于程序员，测试同学喜欢读技术书籍的比率明显的低，这是一个让人悲伤的事实。真希望这种现象能够改变。
- 很多人是不喜欢coding才转测试，或者是因为IT产业普遍薪水高才来做测试。不是真正热爱这份工作，不热爱其实做不好，因为兴趣是最好的老师。
- 很多人认为测试门槛低，young talent 不愿意干，测试吸引人才有点儿困难（我初入行的时候也有这种想法，也是当时被强拉来做测试的，当时想做的是coding和数据DBA相关工作并已经有了一些积累，）。说实话测试的入门门槛的确有一点点低，但是做好测试的门槛确是相当的高，随着系统越来越复杂，测试逐渐会比开发还难做，更有挑战性，我这么说你信么？
- 专业化社区还没有形成规模，测试人员没有能有效交流的平台。这是跟美国和欧洲的一个挺大的差距。他们的社区做得挺好的，我们也有了一些很好的起步。如一些热衷测试公益的同学，一些不错的会议，一些不错的线下活动，但还需要大大的发扬光大。
**************胜者先胜而后求战，败者先战而后求胜！**************