如何让某人参与测试？
好的。我们的产品有效。 Beta 测试人员实际上正在完成他们的工作。下一次迭代的时间到了。但如何保证质量呢？我们需要一个测试员！
如何让刚入门的人开始测试？我不知道如何自己做（我是开发人员，而不是测试人员）！
我们是一个小团队：
- 2 名架构师（就像在建筑中，而不是软件，他们是这里的领域专家）弄清楚构建什么来构建
- 它
- ，还有一个新人在我们发布版本之前进行一些测试 我们谁都不知道
如何专业地做到这一点。到目前为止，我们拥有：
- 一堆跨越我们想要测试的配置的虚拟机
- 各种版本的 Windows
- 德语和英语，我们的客户可能会使用的两种语言
- 我们正在编写的主机软件（Autodesk Revit Architecture 2010，我们正在构建一个用于能量计算的插件）
- 描述一些内容的文本文档我所做的测试（安装了版本xyz，做了这个，做了那个，等等）
- 错误跟踪系统测试人员可以添加他发现的所有错误
我希望我们需要一个测试脚本。但如何呢？ WHO？什么？什么时候？
OK. Our product works. Beta testers are actually getting their stuff done. Time for the next iteration. But how to ensure quality? We need a tester!
How do I get someone fresh off the street started in testing? I have no clue on how to do it myself (I'm a developer, not a tester)!
We are a tiny team:
- 2 architects (as in buildings, not software, they are the domain experts here) figuring out what to build
- me building it
- and a new guy to do some testing before we push releases out
None of us has a clue on how to do this professionally. So far we have:
- a bunch of virtual machines spanning the configurations we would like to test
- various versions of windows
- german and english, the two languages likely to be in use by our customers
- the host software we are writing for (Autodesk Revit Architecture 2010, we are building a plugin for energy calculations)
- a text document describing some tests I did (installed release xyz, did this, did that, etc.)
- a bug tracking system the tester can add all the bugs he finds
I expect we will need a test script. But how? Who? What? When?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
你为什么要寻找“街上的人”？对我来说，这听起来有点像在问“我想雇用一名新程序员，我如何才能让某人离开街头并让他加快我的软件编程速度？”。为什么你要这么做，而不是雇佣一个已经是程序员的人呢？
在您的情况下，您对测试不太了解，我肯定考虑雇用在该领域有经验的人。
具体来说，我可能会寻找：
最后一点是可选的，但希望您的团队能够随着您的软件的发展而成长，因此找一个也可以在该角色中成长的人可能是有意义的（更不用说拥有经验来帮助您决定何时以及如何成长）质量保证团队）。
Why are you looking for "someone off the street"? To me, it sounds kind of like asking "I want to hire a new programmer, how do I get someone off the street and get him up to speed programming my software?". Why would you want to do that, over hiring someone who is a programmer already?
In your situation, which is that you don't know much about testing, I'd definitely think about hiring someone with experience in the field.
Specifically, I'd probably look for:
The last point is optional, but hopefully your team will be growing as your software grows, so it might make sense to get someone who can grow in the role as well (not to mention having the experience to help you decide when and how to grow the QA team).
那么，您想通过测试人员来扩大您的团队吗？您是否考虑过从咨询公司聘请测试专家？
Well, are you looking to expand your team with a tester? Have you considered just hiring a test specialist from a consultancy firm?
在让某人进行测试之前，请确保您满足测试要求。您至少需要：
规范：关于应用程序应该执行的操作的一些权威来源。这可能是一位专家，可以回答有关应用程序到底应该做什么的任何和所有问题，但写得越多、定义得越正式越好。
时间：测试需要时间。您无法在应用程序预计上线前 30 分钟将其交给测试人员并期望得到任何有价值的结果。如果您正在进行瀑布式开发，那么最终测试将需要大量时间。许多其他开发模型让测试与开发并行运行，这节省了大量时间，但无论您使用哪种模型，测试都比不测试需要更多的时间。
如果没有这两点，质量保证只是一个白日梦。
现在，如果您确实满足了这些要求，并且您正在尝试培训某人进行测试，那么这是我的测试速成课程。
从根本上来说，测试应用程序意味着您试图确保两件事：
程序执行其应执行的操作。
程序没有做它不应该做的事情。
这就是我使用的核心心态。以此为基础，我从行动的角度来处理事情，并尝试验证：
第 1 项直接来自规范：您确保程序执行其应该执行的操作。
第 2 项和第 3 项是测试艺术的用武之地。我可以执行哪些意想不到的操作和先决条件？我可以尝试输入错误的密码。我可以尝试直接输入一个所谓安全页面的 URL。我可以尝试将奇怪的 unicode 字符粘贴到文本字段中。我可以尝试将 SQL 或 JavaScript 代码放入文本字段中。
第 4 项是测试的无限无人区，这部分使完整的测试变得不可能。 （2 和 3 也是无限的，但思考起来并不那么令人沮丧。）这并不意味着你忽略它。你总是留意任何不寻常的事情。另外，有时灵感来袭，您会想到一种可能的方法来产生意想不到的效果：“如果我在该月第三个星期二的晚上 11:59:59 到凌晨 12:00:00 之间登录，会发生什么？哦，看，这使得我是管理员。”技术知识和对黑匣子的了解有助于想出类似的场景。
关于测试还有很多话要说，但这只是我能想到的最低限度：技术要求和解决问题的方法。
Before you get somebody to test, make sure you meet the requirements for testing. At a minimum you need:
A specification: Some authoritative source on what the application is supposed to do. This could be an expert that can answer any and all questions on exactly what the app is supposed to do, but the more that is written down and the more formally defined it is the better.
Time: Testing takes time. You can't hand off an application to the tester 30 minutes before it's supposed to go live and expect any worthwhile results. If you're doing waterfall development, testing will require a lot of time at the end. Lots of other development models let testing run in parallel with development, which saves a lot of time, but regardless of the model you use, testing will require more time than not testing.
If you don't have these two things, quality assurance is just a pipe dream.
Now if you do have those met, and you're trying to train somebody to test, here's my crash course on testing.
Fundamentally, testing an application means that you are attempting to ensure two things:
The program does what it is supposed to do.
The program does not do what it is not supposed to do.
That's the core mindset that I use. Building from that I approach things in terms of actions and attempt to verify:
Item 1 comes directly from the spec: You make sure that the program does what it is supposed to do.
Items 2 and 3 are where the art of testing comes in. What unexpected actions and preconditions can I perform? I could try to enter the wrong password. I could try to directly type in the URL of a supposedly secured page. I could try to paste odd unicode characters into a text field. I could try to put SQL or javascript code into a text field.
Item 4 is the infinite no-man's land of testing, the part that makes complete testing impossible. (2 and 3 are also infinite, but not as depressing to think about.) That doesn't mean you ignore it. You always keep an eye out for anything unusual. Also, sometimes inspiration strikes and you think of a possible way to cause an unexpected effect: "What happens if I log in between 11:59:59PM and 12:00:00AM on the third tuesday of the month? Oh look, it made me an administrator." Technical knowledge and a peek inside the black box help with coming up with scenarios like that.
There is a whole lot more to say about testing, but that's the bare minimum I can think of: The technical requirements and the approach to the problem.
理想情况下，您需要为测试人员提供：
Ideally, you'll need to give the tester:
在他们的 播客 #64 中，Jeff 和 Joel 讨论了（除其他外）优秀测试人员应该具备哪些技能具有。 文字记录也可用（大约在页面的中间）
In their podcast #64, Jeff and Joel discuss (among other things) what skills a good tester should possess. Transcript also available (about halfway down the page)