TPI NEXT ざっくり要約 ~その2 第1部「TPI NEXTとは」

 「TPI NEXT ざっくり要約」第二回は,第1部「TPI NEXTとは」を簡単に紹介します。


 まずは第1部の目次を確認しましょう。第1部は二つの章が設けられています。

  • 第1部 TPI NEXTとは
    • 第1章 テストプロセス改善は次のステップへ
    • 第2章 テスト作業とTPI NEXTの位置付け
      • 2.1 テスト作業のスコープと価値
      • 2.2 テストプロセス改善のスコープと価値
      • 2.3 テストプロセス改善の支援に必要なリファレンスモデル

 第1章「テストプロセス改善は次のステップへ」は,TPI をTPI NEXT に更新するにあたって,強化したポイントを述べています。即ち,この第1章がTPI NEXT のウリを端的に解説しているといえましょう。

 詳細は書籍を参照していただくとして,以下の6つのポイントが挙げられています。

  • モデルそのもの
  • 段階的改善
  • 独立性
  • 改善提案
  • クラスタ
  • キーエリア達成のコツ(enabler)

 これらについては簡単な解説がありますが,筆者が最も変わったと感じたことは以下です。

 「モデルそのもの」:「A」「B」「C」「D」と表現されていた成熟度レベルはわかりやすそうでわかりにくいものでした。TPI NEXT では「初期レベル」「コントロールレベル」「効率化レベル」「最適化レベル」といった具体的な成熟度レベル名が導入されています。これにより,TPIを知らない人にも,分かりやすくなりました。

 「独立性」:TPI は(当たり前ですが)かなりTmapが意識された記述となっていました。全体とおして汎用的な記述となったことで,特定の手法(Tmap)を前提としなくても適用できるものとなりました。

 「クラスタ」:様々なキーエリアにおける整合性のあるチェックポイントを束ねたものです。(クラスタにいては,後の章で解説します)。このクラスタの考えの導入により,テストプロセス全体について,段階的,継続的な改善の戦略を立てやすくなりました。

  以上が主な強化ポイントですが,現在の印象としては「全体的に分かりやすい方向に整理された」「モデルや記述がシンプルになった」「より汎用性が高まった」というところです。

  この章では最後に『TPI NEXT のコンサルタントやIT部門のスタッフにキーエリアの優先順位付けをすべてゆだねてしまってはいけない』とあります。この一文からも「現場主導」であることが強く意識されていると考えられます。


 第2章「テスト作業とTPI NEXTの位置付け」はタイトル通りテスト作業(Testing)とTPI NEXT の位置づけについて述べています。

 まず最初にテスト作業はSDLC(Software Development Life Cycle:ソフトウェア開発ライフサイクル)の一部であるとし,またビジネスゴールに沿っていなければならないとしています。なので,TPI NEXTが提供するモデルをBDTPI(ビジネス主導のTPI)と呼んでいます。また,『TPI NEXTで説明していることは,コントロールされたテスト作業と,テスト作業の段階的改善である。』とあり,そのモデルをBDTPIと呼んでいます。

 2章では,まず最初に「テスト作業のスコープと価値」について説明しています。

 TPI NEXT ではテスト作業については,テスト対象に要求された振る舞いと実際の振る舞いの差異を把握することであり,テストチームには要件や設計仕様等,つまりテストベースが必要としたうえで,『テスト作業とは,品質とそれに関連するリスクの実体を把握して,助言を提供するプロセスのことである。』と定義しています。また品質への対策が3種類あるとして予防措置,検出措置,是正処置の三つを紹介しています。

 テスト作業はリスクも考慮しなければなりません。テスト作業はプロダクトリスクにかける保険とみなすことができるからです。保険金(テストにかけるコスト)をどの程度かけるかはプロダクトリスクや組織にとっての重要度等によって変動するが,テストプロセスにはそれを反映させなければならないと解説しています。  また,テスト作業はいつどのように行うべきかをV字モデルを例に説明しています。

 次に「テストプロセス改善のスコープと価値」について説明しています。

 プロセスは「ゴールにつながる一連の行動や手順」と定義し,テスト作業をどのように実施したとしてもそれはプロセスであり,多くの組織でそれを改善する必要を感じているとしています。

 理想的にはテスト作業はプロダクトリスクに焦点を合わせ,プロダクトリスクと足並みをそろえ,ビジネス要件に基づいていることが望ましく,ビジネス要件はテストプロセス改善のきっかけとなるビジネス主導要因と強い関連性を持ちます。また,実際にテストプロセス改善を考えるときは,「テスト作業はコストが高すぎる」「充分案時間とリソースがない」とか「テスト環境が必要なときに利用できず,テストデータの整合性に問題がある」などの課題にたどり着きます。

 BDTPIモデルは,これらのビジネス主導要因やきっかけ・課題に対して対処するための手段を提供します。(※筆者注:少々このあたり,日本語訳でも意味を取りにくいですね)

 その他,アドホックなテストプロセスと構造化されたテストプロセスの違いや,後者の利点について述べています。

 最後に「テストプロセス改善の支援に必要な参照モデル」について説明しています。

 参照モデルといっても,要するにBDTPIのことを指しているのですが,以下の性質を考慮して設計されています。

  • 客観性
  • 選択肢と優先度
  • 詳細度
  • 現状の素早い把握
  • 独立性
  • ビジネス主導要因の検討
  • 他のSDLCプロセスとの連携

これらは前版のTPIモデルにも組み込まれているものですが,BDTPIではより強化されたものとなっています。


 以上,第1部についてざっくりと要約してみました。第1部はTPI NEXT のコンセプトについて書かれているため,わかりにくい部分が多いですが,要約していて強く感じたのは「よりビジネスを意識してテストプロセス改善を実施しなければならない」というメッセージです。実に当たり前と思う方もいらっしゃる方もいるかもしれませんが,テストチームのようにビジネス決定から遠いところにあるとついついビジネス面を忘れてテスト作業を実施してしまいがちです。その意味で,BDとついているのは意識づけとしても価値があるのではないかと思います。

 次回は第2部をざっくりと要約します。

Comments

No comments yet. Why don’t you start the discussion?

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です