Oracle的Program Manager谈及什么是一个好的QE

很老的文章了,06年。刚好下周要面试,一边看一边分享吧。

https://blogs.oracle.com/melinchina/entry/what_s_important_to_me


What's I Look For in a QA/QE Engineer: A Program Manager's Perspective

One of our recruiters asked me to write an article about what Program Managers look for in QE or QA engineers. It's gonna go into some recruitment magazine we're putting out. I was surprised to discover that I actually had a lot to write and I thought I should post it in my blog. It's a long read but hopefully helpful for anyone who's applying for a QE or QA job at a technology company and expects to be interviewed by a program manager.

What's Important to Me in a Quality Assurance Engineer: 
A Program Manager's Perspective

As a Program Manager at Sun Microsystems I have worked in many capacities and managed many kinds of projects. I started as a Localization Program Manager then went on to be the Release Program Manager for one of Sun's newest and largest consolidations: the Java Enterprise System. Today I'm the chief-of-staff for Michael Hayden, the engineering director for the Operating Platforms Group here in Beijing. In all of these roles I worked closely with Quality Assurance Engineers and I've come to know what I can expect from a good one, at least from my perspective as a Program Manager. When I interview QE or QA engineers (for purposes of this article I'll refer to them collectively as QE) here's what I'm looking for.

Customer focus
QE engineers are the first customers of a product and they can be the strongest advocates for the end users. When QE engineers are writing their test plans, executing the tests, reporting results and following up on bug fixes, the customer's experience should be their main concern. They need to advocate for the customer at all times.

QE工程师是产品的第一客户,也该是最终用户强有力的支持者;故测试全过程中,用户体验应是第一宗旨。

Good high-level communication
When a QE engineer escalates an issue to a Program Manager he or she should have a good high-level description of the issue and where he or she needs help, if at all. Here's an example of a bad way to approach a Program Manager when a QE engineer has encountered an issue:
QE engineer (comes into Program Manager's office, looking very frustrated): “I was just testing the build and I clicked on the 'send' button but when I sent the mail all the characters are garbled. Prasad said in the bug report that he fixed it but it's not fixed! What are we going to do?”

The following questions will start running through the Program Manager's mind: “What product are you testing? What build are you testing? Is that the latest build? What 'send' button are you talking about? Who is Prasad? Have you talked to Prasad about this? Are there any differences in his environment and yours? Are you able to verify fixes for any of the bugs that are supposedly fixed in this build? What can I do to help in this situation? How much longer do I have to work until I can retire....?”

Here's how that could have been better:
QE engineer (comes into Program Manager's office looking very calm and in control): “I've been verifying bug fixes this afternoon in the latest build of product X. Most of them are fixed, but I've got an issue with bug 637xxxx. The responsible engineer said in the bug report that it would be fixed in this build but I'm still seeing it. I'm going to talk to Prasad now to find out why he thinks it's fixed but I wanted to give you a heads-up that if this bug really isn't fixed, it might be cause for a re-spin. I'll get back to you in an hour or so.”

Here's what's running through the Program Manager's mind now: “I'm so glad this guy is in control of the situation. I know he'll come to me if it gets out of control. I'm gonna send good feedback to his manager when the project is over. I love this job.”

QE对上级汇报问题的时候应该有良好的沟通能力和凝练的语言表达,说清楚事情来龙去脉和关键细节,希望对方做什么。如果可以,告诉对方自己会继续跟进,一定时间内给予对方进一步的反馈。(要hold住到hold不住为止啦~但是要让对方心里先有个底,问题不会来的太突然)

Good peer-to-peer communication
A good QE engineer has to have good written and spoken communication and at Sun we have so many global, remote teams that written communication becomes especially important. The importance of good written communication is obvious when a QE engineer writes a bug report. If the responsible engineer has to follow up with questions in order to reproduce the bug, the original bug report wasn't thorough or detailed enough. I won't try to give a class in QE 101 here, but everyone who has studied QE knows the kind of info that makes a bug report successful. The summary needs to be clear, the priority and severity need to be appropriate and justified, the steps to reproduce the bug must be included. Any details about other environments where the bug is not reproducible are also very helpful. Basically, remember what you learned in your QE classes at university and apply it on the job.

While written communication skills are obviously key, spoken communication is also crucial. QE engineers must be able to give updates at team meetings and at times they'll need to call other QE engineers or development to talk through a problem live. Without good spoken communication skills you can leave your audience more confused than you found them.

同事之间良好的表达和沟通能力在撰写bug报告的时候尤其重要。总结需要明晰,分清主次,有轻重缓急以及写明白如何重现bug,重现bug的环境等。

口头表达也很重要,比如在汇报进展等场合下QE需要现场解释bug,如果不能很好地沟通只能让听众更加困惑。

Good English
QE engineers don't need to be able to have philosophical debates in English but they do need to have a good English vocabulary and decent pronunciation. Don't worry about impressing people with your stellar vocabulary - stick to simple words and phrases and get to the point as quickly and efficiently as you can. Don't forget some of the most useful phrases that a member of a software development team will ever use:
“Sorry, I don't understand.”
“I need help.”
“It's under control.”

词汇量和准确发音。简单直白切中要点就很好。有时候要说“不好意思我没有明白”“我需要协助”“全场hold住的”。

Proactiveness
It's not enough to identify a bug; good QE engineers need to know how to get bugs resolved. Quite often this means you'll have to go to development engineers to help them understand the issue and to help them understand the importance or urgency of a fix. Never assume that the ball is in someone else's court and you can sit back and wait for the resolution. Program Managers notice who is moving things along in a project, and they make sure those people's managers also know.

积极主动。发现bug不是全部,最好是能知道如何解决这个bug,很可能你要去开发那边帮他们理解这个问题并且让他们知道要解决这个问题有多紧急和重要。并不是高高挂起就好了。

Knowledge/Hard Skills
An outstanding QE engineer knows the product they're testing, the best way to test it, and the best way to report the results. I've run across QE engineers who couldn't do simple calculations like tests passed/tests executed or tests executed/tests planned. These skills are what I like to call hard skills and they are something each QE engineer should bring with them to the job.

优秀的QE对他们test的产品应该了解到知道如何最好test它以及最好的汇报结果。

Ability to identify risks
A good QE engineer can identify risks early and identify ways to avoid or mitigate them. For example, if a test team is going to need a certain kind of hardware for a particular release, that information needs to come to the project team and the Program Manager at the very beginning of the release when there's still time to order and set up the hardware. If a test team highlights too late that they're lacking hardware or resources, there's generally no way to avoid the risk. The best the team can do is try to mitigate it.

提早做防。例如,需要特定的硬件做一个发布,这件事情一开始就要和大家说好,否则错过订购和安置的机会。

Reasonable attitude
I've heard QE engineers say, “This bug just has to be fixed” however they can't explain why the fix is so critical and they aren't willing to talk about alternate solutions like implementing a workaround or releasing a patch or documenting something in the release notes. None of these solutions are perfect but there is also no perfect software. Good QE engineers know how to partner with the Program Manager and the rest of the team to find the best solution for the customer, they don't stonewall or shut down when their opinion isn't taken at face value.

讲理的态度。如果说你的bug非要立马解决,那请辩解为什么这个至关紧要,难道没有迂回避绕的方法么?没有任何软件是无瑕的。好的QE知道如何合作来找到最好的解决方案,而不是非要面子。

In summary, I hope these points will be useful to you as you search for a job as a QE engineer. And if your search brings you to Sun I look forward to working with you!

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
在信号处理领域,DOA(Direction of Arrival)估计是一项关键技术,主要用于确定多个信号源到达接收阵列的方向。本文将详细探讨三种ESPRIT(Estimation of Signal Parameters via Rotational Invariance Techniques)算法在DOA估计中的实现,以及它们在MATLAB环境中的具体应用。 ESPRIT算法是由Paul Kailath等人于1986年提出的,其核心思想是利用阵列数据的旋转不变性来估计信号源的角度。这种算法相比传统的 MUSIC(Multiple Signal Classification)算法具有较低的计算复杂度,且无需进行特征分解,因此在实际应用中颇具优势。 1. 普通ESPRIT算法 普通ESPRIT算法分为两个主要步骤:构造等效旋转不变系统和估计角度。通过空间平移(如延时)构建两个子阵列,使得它们之间的关系具有旋转不变性。然后,通过对子阵列数据进行最小二乘拟合,可以得到信号源的角频率估计,进一步转换为DOA估计。 2. 常规ESPRIT算法实现 在描述中提到的`common_esprit_method1.m`和`common_esprit_method2.m`是两种不同的普通ESPRIT算法实现。它们可能在实现细节上略有差异,比如选择子阵列的方式、参数估计的策略等。MATLAB代码通常会包含预处理步骤(如数据归一化)、子阵列构造、旋转不变性矩阵的建立、最小二乘估计等部分。通过运行这两个文件,可以比较它们在估计精度和计算效率上的异同。 3. TLS_ESPRIT算法 TLS(Total Least Squares)ESPRIT是对普通ESPRIT的优化,它考虑了数据噪声的影响,提高了估计的稳健性。在TLS_ESPRIT算法中,不假设数据噪声是高斯白噪声,而是采用总最小二乘准则来拟合数据。这使得算法在噪声环境下表现更优。`TLS_esprit.m`文件应该包含了TLS_ESPRIT算法的完整实现,包括TLS估计的步骤和旋转不变性矩阵的改进处理。 在实际应用中,选择合适的ESPRIT变体取决于系统条件,例如噪声水平、信号质量以及计算资源。通过MATLAB实现,研究者和工程师可以方便地比较不同算法的效果,并根据需要进行调整和优化。同时,这些代码也为教学和学习DOA估计提供了一个直观的平台,有助于深入理解ESPRIT算法的工作原理。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值