来自编辑的信 - 2021年3月

近来之前,我帮助在硅谷的加州大学Santa Cruz延伸的加州大学软件工程计划中开始了软件质量证书。我在顾问委员会。在将课程放在一起,一些人建议了测量和指标课程。自从我在计划中教一些课程以来,他们让我撰写并领导课程。当他们这样做时,我没有意识到迅速 - 或者有多大声 - 我回答说“不!”

The whole room froze and looked at me. I laughed. I told them that there was no way I would go near that class––not even with a 10-foot pole.

测量的问题是每个组织都是独一无二的,每个产品都处于不同的成熟程度并具有其自身的有意义的测量需求,团队成员对其决定的个人偏好,不同的工具已经预测了他们的想法或仪表板的预测报告或仪表板you may want to know… what I’m getting at here is that it’s all context-driven. Reporting from QA and Test Teams serves many purposes, but reporting must also support the business goals. Thus, measurements and metrics must be relevant to these goals. The reporting needs to be actionable, meaning that the data informs decision-makers and arms them with what they need for:

  • 评估产品准备走, no-go, not yet, etc.),
  • Ascertaining process efficiency (that testing and development are getting done as efficiently as needed), and
  • 精确范围的项目大小,人员配置,资源,工具需求,设备等


Better than inventing some acronym, from my experience, the reporting you do must be:

  1. Correct.This may go without saying, but I could tell you horror stories of the incorrect or missing information or measurement leading to problems.
  2. Easy to generate or capture.Once you have defined the measurements to report to the team, they need to be easy to capture. If you regularly have to manually grab a piece of data from one tool and manually grab another piece of data from another tool, then put them into an Excel spreadsheet and calculate something to send the decision-makers or team members… think again. Capturing and calculating reporting needs to be automated.
  3. 了解。您正在报告此信息的团队成员需要了解它所做的,并不意味着 - 也许甚至可能是多少良好的数字,并且错误的数字可能是什么样的。它超级常见的是,这些测量或指标被报告并被团队的各种成员误解,因为他们从未完全解释过,也没有得到关于实际测量的协议以及为什么的协议。
  4. Used!The reporting is used for action. The right people do things, make decisions, make changes, get staff, get time, bless a release, or hold a release based on the numbers we are giving them. If it turns out that people are not making decisions based on these numbers…
  5. Reevaluate.改变它们。如果人们没有采取行动,如果有太多的误解,或者你没有得到你打算的结果,可以获得一个易于理解的不同措施,并且团队将能够用于决策。请记住,没有“最佳实践”,只有持续改进。

Reporting is complex because it is always context-driven and often political. My biggest advice for reporting is to be Lean and be careful.

This issue is packed full of content aimed at helping QA leaders ensure their team’s efforts are actively (and accurately) communicated to business decision makers. Our cover story,如何停止“飞行盲人”核算时was written by LogiGear’s SVP of Sales Clayton Simmons and offers actionable insight for QA leaders who may be struggling to find the “perfect mix” of metrics when reporting to decision-makers.中点危机:自动化如何能够做出更多手动测试工作由Michael Larsen编写,并探讨如何防止在我们的自动化程序成熟时手动执行任务。怎么看was written by Kristin Jackvony and is aimed at entry-level QA professionals who are trying to find ways to make their work known and climb the corporate ladder. This issue’s Blogger of the Month, Wes Silverstein, explores the important role that QA has when it comes to planning Automation sprints inThe Role of QA in Sprint Planning.Our infographic,5 Incredibly Useful KPIs for Test Automation,探索我们在您的QA报告中使用的最高推荐的测试指标,包括公式和原因,为什么他们有关。最后,查看TestArchitt 9.0版的新功能和功能TestArchitect Corner.

We hope you enjoy this issue––happy testing!

Michael Hackett
Michael is a co-founder of LogiGear Corporation, and has over two decades of experience in software engineering in banking, securities, healthcare and consumer electronics. Michael is a Certified Scrum Master and has co-authored two books on software testing. Testing Applications on the Web: Test Planning for Mobile and Internet-Based Systems (Wiley, 2nd ed. 2003), and Global Software Test Automation (Happy About Publishing, 2006). He is a founding member of the Board of Advisors at the University of California Berkeley Extension and has taught for the Certificate in Software Quality Engineering and Management at the University of California Santa Cruz Extension. As a member of IEEE, his training courses have brought Silicon Valley testing expertise to over 16 countries. Michael holds a Bachelor of Science in Engineering from Carnegie Mellon University.

The Related Post

Integrated teams Something we’ve learned in the Covid-19 pandemic is that we have to work together-whatever together means. Very few teams stayed co-located; even teams in the same town worked at home. We’re all working remote. Hopefully all the thinking, tools, work and effort we put into having offshore teams work together benefited us here. ...
There is a growing software development dynamic of teams without Testers. When I first went into Software Quality, I learned one thing right away: My role was user advocate. My main job was to find bugs. This is the Lean principle called Amplified Learning. We learn about behavior by testing. Even then, validation was not ...
Every year, LogiGear Magazine devotes one full issue to Test Automation. We could do more than one, and perhaps even that would not be enough. The problems around automation have become increasingly complex. And now, automation is much more integrated into the software development process. For over a decade teams have been faced with “do ...
As fast as Mobile is growing, the platform is still immature and is evolving at a very rapid pace. While there are whole countries that have migrated large government services to mobile, countries ranging from Estonia to Turkey to Kenya have many longtime mobile users have yet to use mPay or other mobile payment systems. ...
DevOps can be a big scary thing. Culture change, constant collaboration— whatever that means— a big new set of tools… it’s a lot. What most teams want is to have a smooth running software development pipeline. I have stopped using the phrase “DevOps,” and now I say “Continuous Delivery.” There are many reasons for this.
Methods and strategy have been my favorite topics since I started working in testing. It’s essentially engineering problem-solving. It’s both looking for efficiency and attempting to measure effectiveness. So, how do we develop a set of practices to solve our Software Testing engineering problems?
A lot has changed since I began staffing test projects. From hiring college students and interns for summer testing programs, to building networks of offshore teams around the world, and from having 24-hour work schedules to having instant crowdsourced public beta or bug bounty testing—things have changed.

Leave a Reply

Your email address will not be published.Required fields are marked*