代码之家 › 专栏 › 技术社区 › Alex C

如何作为一个项目的“QA工程师”而不是一个“测试驱动开发团队”的成员?

software-quality qa unit-testing

4

Alex C · 技术社区 · 14 年前

如果我问错了这个问题,我深表歉意。(可能是职业建议和QA特有的小堆栈溢出之一)我最近花了大量时间学习和实现我们项目的单元测试框架。

在引入单元测试框架之前,我们的方法是编写代码、手动测试、提交,希望不会出现故障或上行。一个非常被动的系统。

现在,我们都明白了需要测试的东西,自动化测试是高效和好的。然而,目前的角色似乎是“你做测试”和“编写自动化测试”

做手工测试是可能的,但感觉难以承受(因为总是有bug),很像是我的技能利用不足。

我很难完成请求的第二部分。如果代码不是设计成可测试的,那么编写自动测试是很困难的。

我有QA的责任-但是-我只能找到测试驱动开发的资源。

5 回复 | 直到 14 年前

1

Grant Crofton 14 年前

我认为让开发人员跟上单元测试的速度将是您最关心的问题!这样,每个人都是赢家。

在这之前,实际上您正在使用遗留代码,michaelfeather的书 Working Effectively with Legacy Code

您可能已经知道这一点,但也可以查看行为驱动开发(behavior-Driven Development,BDD),它包含了许多关于创建自动化集成测试的内容,我认为您会感兴趣。

2

johnsyweb 14 年前

名字的问题 测试驱动开发 和 单元测试 设计它们本质上是开发者的责任。

QA分析员的角色在任何实践TDD的团队中仍然是最重要的,这将是一个重要的角色作为一个认真的质量保证员,在你发现自己失业之前的一段时间!

看一看 验收测试驱动开发 并考虑在需求阶段更多地参与编写自动化验收测试,也许可以使用诸如 FitNesse .

3

1

Grzenio 14 年前

我理解QA的角色是提供更高级别的测试,以确保软件满足客户的需求,因此您不会真正测试单个类,而是模块或整个应用程序。即使开发人员不提供单元测试,您仍然应该能够自动化端到端测试(这通常包括自动化测试环境的设置等)-但是您的工作将更加令人沮丧:)

4

1

ndp 14 年前

根据我的经验,人们不会一夜之间就开始写测试——说服他们是一个过程。程序员最终会不情愿地尝试,但他们要成为拥护者和正式实践者还需要数周或数月的时间。这并不意味着你应该放弃,只是要认识到这是一场艰苦的战斗,需要上级的支持,以及团队内部的一些好的倡导者。

5

1

Péter Török 14 年前

几年前我也在做类似的工作,所以我能理解你的烦恼。为了让开发人员跟上单元测试的速度,我建议指导和结对编程会议。为一个设计糟糕的类编写第一个单元测试是一件非常痛苦的事情。如果有你们两个的话,那就更容易了,也更有趣了——更不用说在最初的重构中降低犯愚蠢错误的几率了。

你也必须有强有力的管理层支持——没有这些,尝试是没有意义的。管理层必须理解,构建单元测试是一个现在只有在未来几年才会有回报。如果他们坚持要像以往一样在最后期限前保持压力,你将不可避免地失败。如果开发人员压力很大和/或缺乏动力,他们就无法学习和实践新的技能和思维方式。