More Agile Testingを読んで2

30%くらいまで読み進めました。
今のところ、現在の実際の経験と差がないくらいで話しが進んでいるので、私の実際の経験に対してなんか安心感。

Part2: Learning for Better Testing

ここは、主により良いテストを書くためにどう学ぶか、ということに関して書いてました。必要なスキルであったり、勉強会のような形で技術の情報共有を行うことなど、組織的な視点からも少し。

Learn Coffee sessionのような、気軽に情報を共有できる場を作ろう、というのも面白い感じ。テストの人も開発技術に関して知識を有することが大事で、こういう場は技術のトレンドや、知らない情報を手に入れるのにもってこいの場所だとのこと。

テストって学んでいくとロジック側によっていく気がするのですが、何か手を動かす側とロジック側、適度なバランスで進めることができると良いですね。

Part3: Planning

Levels of Precision for Plan.

Test Scopes, Testing Approach, Risks, Regression, Feature to Test, Feature Not to Test, Data Validations, General Considerationsのような内容で、大枠のテスト戦略を作る話しが書かれてました。

製品/サービスのDelivery Cycleの話しから、そこに至るまでにどういうテストがされるかという大枠が書かれてました。詳細は後ろの章で。

ここで現れていたテストレベルなのですが、以下の形でわけていました。V時型に慣れている人の区分で表現すると、TaskがUnit、StoryがIntegrationというようにテスト対象とする領域が広がって依存関係も広くなっていく、という流れです。

  • Task Level
  • Story Level
  • Feature Level
  • Production Release Level
    • Single Team
    • Multi Team
  • System Level

Agile開発と言われる領域の多くでは、過去のアジャイルソフトウェア要求を読んだときの記事でも書いているように、Task、Story、Featureのような枠組みで機能を区分していくことが多い模様。なので、ここでいうテストレベルも同じ粒度で区分しているようですね。

Regression Testing
回帰テストのようなCheckingの領域を機械的に回していく、テスト自動化の仕組みに関してもさっと書かれていました。

Visualize Testing
テスト進捗の可視化として、Release-Level test matrixが例ではかかれていました。確認したい観点と、具体的な操作内容をマトリックスで表現してそれぞれに以下でマークしていき進捗を計る、というものもがRelease-Level test matrix。

  • good to go
  • done but may need more
  • broken
  • not applicable, doesn’t need test

Using Models to Help Plan

モデルを使って計画作成を助ける、という話しでした。

Agile Testing Quadrants

アジャイルテスティングではよく引用されているAgile Testing Quadrantsがあります。

本書ではこれをさらに進めた例を提示していました。例えばSupporting the TeamをGuide Developmentに書き換えていました。これは、著者らが経験を積む中でより適した表現として考えたかららしいです。(たとえば、以前のものはBefore / After developmentの区別がついていなかったり。)

多くのAgileチームはQ2の領域から考え始め、実装よりのQ1などに考えを進めていくようです。なので、Guideと表現するほうがより実際に沿っている、と判断したのでしょう。実際、私も同じような形で思考を落とし込んでいくので、しっくりきました。

http://www.informit.com/articles/article.aspx?p=2253544

今後は、Quadrantsとしてはこちらを引用するようにしよう。

他にも、このQuadrants以外にも書かれていました。

Gojko Adzic’s Agile Testing Quadrants

例えば、Gojko Adzic氏は、lean startup や contious delivery 環境に焦点を当てて、以下の点からQuadrantsを定義してます。

  • Business and Technology
  • Checking for expected result and Analyzing unknowns

http://gojko.net/2013/10/21/lets-break-the-agile-testing-quadrants/

FURPS+

過去、HPが提示したFURPSをAgileに拡張したもの。

http://agileinaflash.blogspot.jp/2009/04/furps.html

ACC(Attribute Component Capability)

システムを以下の3つの点でまとめて定義して話しをまとめて分析していく、というものです。

  • Attributes (adjectives of the system) are qualities and characteristics that promote the product and distinguish it from the competition; examples are “Fast”, “Secure”, “Stable”, and “Elegant”. A product manager could have a hand in narrowing down the list of Attributes for the system.
  • Components (nouns of the system) are building blocks that together constitute the system in question. Some examples of Components are “Firmware”, “Printing”, and “File System” for an operating system project, or “Database”, “Cart”, and “Product Browser” for an online shopping site.
  • Capabilities (verbs of the system) describe the abilities of a particular Component in order to satisfy the Attributes of the system. An example Capability for a shopping site could be “Processes monetary transactions using HTTPS”. You can see that this could be a Capability of the

https://code.google.com/p/test-analytics/wiki/AccExplained


ここまで読んでみると、過去、著者らが書いた時点のものよりも、よりサービスより(Web/Mobile含む)の話しが取り入れられているように感じます。過去の書籍よりも、ビジネスの話しや探索的テスト、テスト自動化の話しを中心にしているような。
探索的テストを先に読んでみようかな。

(2014/11/01 16:22 updated)

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中