最近兩天看了不少關于測試價值,該如何做測試,該如何參與開發過程的文章,再加上我自身的一些經歷,有感而發,聊下自己的價值觀。
文章一——T-Shaped Testers and their role in a team
這實際是一篇老文章,但里邊的觀點——測試應該做些什么,我是很是贊同。以下是節選并附上簡單翻譯(如果想看完整版,請點擊文章標題):
I've never been comfortable with the concept of a separate test team and associated "phases" of testing.
我太不喜歡“不同的測試團隊”和“不同的測試階段”的概念。
I believe that finding bugs is just one aspect of a testers role.
I don't think finding bugs is just the responsibility of the tester either.
測試不僅僅是找到BUG。
I also believe that testers should use their skills in other parts of the project cycle, whether that cycle is two weeks or two months or two years.
One person capable of fulfilling a few roles reasonable well seems like good value and a good asset to delivering value. Even in traditional environments with more structured roles T-shaped people can be found serving multiple roles.
測試應該更多參與到項目生命周期,做更多的事情。
Sadly, many people (not just testers) are pigeon holed in to their role, despite having a lot more to offer.
杯具的是大部分人被限制在他們角色中。
I believe that testers, actually – anyone, can contribute a lot more to the business than their standard role traditionally dictates. The tester's critical and skeptical thinking can be used earlier in the process. Their other skills can be used to solve other problems within the business. Their role can stretch to include other aspects that intrigue them and keep them interested.
I believe testing is more than finding bugs; it's about exploring the product, discovering what the product needs to be, discovering the market needs (i.e. A/B Testing), discovering what the product actually does, working out whether the product is suitable for the context of use, questioning the process, improving the process, helping to design the product, improving the product, helping to support it, helping to promote it and ultimately working with the team to deliver value.
我認為測試遠不止是尋找BUG,測試應該去探索產品,探尋產品應該做成什么樣子,探查市場的需求,看看產品真正能做到什么,看看產品是否合適當前的要求,質疑流程,改善流程,幫助設計產品,改善產品,幫忙支持產品,幫忙推進產品,并始終和團隊一起交付有價值的產品。
我們測試人員應該關注得更多,不僅僅停留來找BUG上,停留在測試執行,設計或者管理上。
文章二——On Testing Purpose and Documented Requirements
作者分享了,他為什么要跟BA談跟商務(Business)談,當他去測試一個軟件的時候。以下是節選并附上簡單翻譯(如果想看完整版,請點擊文章標題):
"But isn't that what the BA is supposed to do?"
Oh, excellent question.
Certainly a good BA can gain that information and pass it on to the team. However, with each layer or remove introduced in the information flow, something changes. Information may be lost. Other things may be added. The "clarification" may critically change part of the message. If I can get as close to the people doing the work as I can, I often learn stuff that is important to me as a tester that other people shrug off as unimportant.
信息會在溝通過程丟失。
If I can understand their needs better, I can exercise the software more efficiently. If the tests I write and run do not explicitly exercise "the requirements" are they really required? Are they interpretations of something?
如果我能更好地理解他們需求,我就能更加有效地運用這個軟件。
就我個人而言,很難想象一個不了解商業需求的測試人員,會做得很好,即使是初級測試人員,只是在執行測試用例。知道一個軟件、一個功能的目的,知道它是用來解決什么樣子的問題,更多的業務知識會為測試人員帶來很多的靈感。
文章三——The Value of Testing & Test Teams
原文作者提到了測試能帶來價值的5種方式,以下是節選并附上簡單翻譯(如果想看完整版,請點擊文章標題):
Each time a tester questions about an ambiguous, incomplete or missing requirement, she is adding value by questioning the process.
測試質疑模糊,不完成或缺少需求時,就是帶來價值。
Each time a tester questions the testability of a requirement or even a product, she is adding value by questioning the product requirements.
測試質疑需求或者產品的可測試性時,就是帶來價值。
When a tester reviews a design and questions the validity of the design, she is adding value by blocking a faulty design being built in to a faulty product.
測試審查設計,并質疑設計的有效性時,就是帶來價值。
Each time a tester questions the code, she adds value by stopping defects seeping into the next phase of product development. You might say,”Not every tester reviews the code.” True, but isn’t it common to have entry criteria for testing that requires evidence of code review or unit testing? If you are a developer-tester, you know how to peer-review the code.
原文轉自:http://blog.csdn.net/o2o_o2o/article/details/9208623