Tester’s growth: professional development 5 levels
转者按：测试工程师的职业发展的五个阶段，作者大致将发展分为五个阶段，然后还讲了一下每个阶段如何升级的想法，也许会对大家有用，看看吧．Submitted by Ainars Galvans on Mon, 18/12/2006 - 13:58. general software testing | people issues
作者：Ainars Galvans
来源：http://www.testingreflections.com/node/view/4731
Christmas and a new year is a time when I consider my achievement and plan further goals, don’t you?! My primary concern this time is related to my family, but I don’t forget my work as it is so much a part of my life.
I’ve been thinking a lot about improving myself as a tester. It may have different faces: contractors improving technical skills or as employees aiming next skill level/position or management position. I’m however a big fan of Becoming a Technical Leader as described by Weinberg . “An Organic Problem-Solving Approach” is how I envision guru tester and I do believe that I’ve developed toward one a lot. So I want to share model of my own development, which may or may not fit yours. I do believe however that anyone could gain by compare this with his own development.
Have you red about Five stages of grief (denial, anger, bargaining, depression, acceptance)? It has nothing to do with five levels of professional tester, does it? Well here are my vision of those five levels (and I leave to you considering why I’ve mentioned stages of grief):
0) Initiation-denial: any developer could do testing, which is boring so there are testers who does the boring job
1) Novice-enthusiasm. Wow, there are so much more tests that professional tester could imagine of doing which have pretty good probability to reveal defects that developer would never find
2) Apprenticeship - learning. Professional tester is not only a bug-hunter. He should be able to do through testing. Optionally (depending on work context): he is able to estimate, report progress, find workarounds for blocking defects, gathering information from all possible sources instead of relying on specifications, participating reviews, measurement programs, etc.
3) Practitioner – pragmatism. Able to prioritize the through testing according to the context. For example discover critical defects sooner and not so critical defects – only if time permits. Particularly it is enabled by guessing test priorities – starting with tests that are more powerful or otherwise better in the given time/context.
4) Master (guru) – leading. This is the most tricky level. First of all by leading I mean something that Weinberg describes as technical leader as opposed to manager. Guru is a person who is indirectly doing much more than his position formally describes. For tester it may be doing part of BA, MIS, or even PM job duties (defect prioritization, even triaging ; risk management; development progress monitoring; etc.). A guru tester could become the right hand of a project manager. The tricks are however: it depends on context and should a guru be moved to other project the guru position will be lost and even if guru stay in the same project – an ongoing effort should be put to maintain this position.
Moving between levels
Level 0 is one that I have been at doing testing. It is very simple to move to the next one by simply reading any good book on test techniques. That’s why I marked it 0 not 1. Next moves requires both (a lot of) practice at previous level and a change. According to Weinberg technical skills are not developed linearly. There are “jumps” and “plateaus” which I imagine as “change” and “learning through experience”. So the levels 1-4 are my jumps/changes. The jump from 1 to 2 was initiated by moving to a new project: different, larger with bad quality identified as major issue. That was a real challenge for me and for my skills that I was sure are great before. Only in this project I realized how much I yet have to learn. Later, when things got to normal in that project (a year or more), my frustration outgrowth into searching internet for readings. Reading Kaner, Bach, stickyminds, and more was not however the main reason for next change. Answering QAForums questions was. I found somehow that thinking of problems that others run into help me solve issue of lack of problems in my own project. On the other hand it helped me to realize that there are still a place for improvements in my own project.
Moving to another project was again reason for my next change. There were some issues for myself in previous project that I was only able to solve by addressing them from the very beginning of the project. Lack of testing resources was also a great reason for me trying new ways of solving testing issues – management would otherwise never agree on that.
Moving further or trick with levels 3 and 4
When I wonder – what would happen if I would move to yet another project? Could there be the level 5 or something? I believe the answer is no. Once I will move to another project I’ll drop initially to level 3 if not 2, because level 3 and especially 4 requires a lot of realization of project context. More over the context changes even if you stay in the same project. So if I stay in a project and don’t change myself enough I will eventually drop to level 3. Because guru level is a level were everyone expects miracles from you: e.g. testing with twice as little resources. But people get used to the same miracles and will eventually take it for granted. Testing with twice as little resources will become the baseline and if you will be a few days late – you will be late.
Epilogue
I recall James Bach asked me if I’m a king of testing in Latvia. I hate to think about myself as one, although I may be the most recognized tester in region (the question however – recognized by whom). There is certain benefit from public recognition if I ever will consider becoming consultant. Meanwhile my only goal is our project success. I do believe that what we need to achieve that are heroes and I’m ready to be the one. If 40 hours per week plus even more to get to work and back it about half of my life I don’t count time I’m sleeping. I don’t want to waste half of my life participating failure projects that give no satisfaction and smile to those developers and managers who do not respect you. I know I’m able to turn everything right.
Tester skills not only change what are the tasks he is able to do. The formal name of a task may be the same – perform functional testing, but the result will differ a lot based on levels I’ve described below. And the results will influence project success, although project managers would hardly admit that. 圣诞节和新年是思考我在过去的一年里的成就以及计划我以后长远目标的时间,难道你没有这么做吗 ?在这段时间里,我最关心的是我的家庭,当然工作也不能被丢在一边,因为工作也是我生活的一部分.
作为测试人员如何提高自己?关于这个问题我考虑的太多了.我考虑过以下几个方面的内容:作为负责人怎样提高自己的技术技能?或者是作为一个职员怎样让自己的的技能水平上升一个台阶,或者提高自己的职位甚至管理职位?我最大的梦想就是成为一个象Weinberg描述的技术领头人-- “An Organic Problem-Solving Approach” is how I envision guru tester and I do believe that I’ve developed toward one a lot"(不懂).所以我想把我自己是怎样发展自己的经验给大家共享.我的经验可能并不适合你.但是我确信每个人可以通过比较自己的发展和我的发展来有所收获. “An Organic Problem-Solving Approach” is how I envision guru tester and I do believe that I’ve developed toward one a lot"
我认为测试人员应以寻找一个系统的解决问题的方法为目标,我确信自己已经做了许多.
(sdlkfj1 翻译不准,请见谅sdlkfj1 ) 你读过悲伤的五个阶段(拒绝,愤怒,交涉,消沉,接受)吧?它与职业测试人员的五个阶段没有关系,是不是?那好,下面是我提出的五个阶段(并且由你自己来思考我为什么提及悲伤的五个阶段)
0)开始遭拒: 任何一个开发人员都能做测试,这是一个讨厌烦的工作,所以由测试人员来做.
1)新手的狂热:哇哦,有那么多职业测试人员难以想像的极有可能揭露开发人员绝对发现不了的bug的测试.
2) 拜师学艺:职业测试人员不仅仅是一个bug寻找者.他应有能力贯穿整个测试过程.一般地(依赖于工作环境):他能够预测/报告工作进度,发现影响进度的缺陷,收集所有可能源代码的信息而不是依赖于规范,参与评审,制定进度等等.
页:
[1]
