読者です 読者をやめる 読者になる 読者になる

Test Automation

テスト自動化とか品質とか勉強会とかやってるエンジニア(Automation Architect)のブログです。

テストの期待値を分解すると言う事 ~Web Service QA Meeting Vol.1の感想~ #webqa

勉強会 Refactorable Testing Architecture

 本日、Web Service QA Meeting Vol.1という勉強会に参加して来た。様々なウェブサービス企業のQA関連企業で集まって、WebのQAについてあれこれ話そうよと言う勉強会だ(と思う)。

 ま、僕の悪い癖は「面白いな」と思った話については議論を盛り上げたいと思うと言うか、いわゆるマサカリを投げたくなる事なんですが(笑)

 マサカリ話はいったん置いておいて、面白いなと思った話について書いてみる。

 僕が面白いなと感じた発表の趣旨は僕の言葉で説明すると「テストの実行時間が長いので、テスト観点とテストレベルを見直し、適切なテストレベルで実行する事でテストの実行時間を短縮した」になる。別の言い方をすれば「アジャイル4象限の右上で実行していたテストを左上で実行する事で効率化した」だ。(発表者ならびに関係者の皆様、僕の理解が間違っていましたらゴメンナサイ。連絡頂ければ訂正します。)

 この発表で僕が面白いと感じたのは上の「テスト観点とテストレベルを見直し」の部分を「テストの期待値を分解し」と説明していた点だ。そう、1つ1つのテストケースについてテスト設計が終わった後でも期待値を分解する事は実施してもいい(のかもしれない)

 期待値を変更してしまうと、テストの網羅性の再評価等のテスト設計のやり直しに相当する作業が発生する可能性がある。けれど期待値を分解し、分解された期待値をテスト観点を元に整理し直すだけならば、テストの網羅性には影響がない。この発表の肝はまさにテスト設計のリファクタリングをやっている事だと思った。

 テスト設計は一度作ったら終わりではない。機能の設計をリファクタリングを通じて改善して行くのと同じように、テスト設計も継続的に改善して行くものだ。テスト設計の継続的な改善を通じてサービスの成長に貢献出来る事がウェブサービスのQAの醍醐味。そんな事を考えた実りある勉強会でした。

2015年前半戦 いいなと思った記事やスライドの個人的ブックマーク

勉強会

2015年前半戦いいなと思ったインターネット上の記事やスライドを個人的にブックマークしときます。

コンセプト+ テクノロジー

 

コンセプト

アーキテクチャとかデザインパターンとか

テストとか品質とか

Docker

 

 

ソフトウェアテストなんて誰でも出来る

勉強会

アマチュアとプロフェッショナル

 先週参加したカフェソフトウェアクオリティのお悩み相談コーナーで、「ソフトウェアテストなんて誰でも出来ると思われている」というものがあって笑った。

「○○なんて誰でも出来る」というフレーズは何にでもあてはまってしまう。

例えば

  • キャッチボールなんて誰でも出来る
  • ギターなんて誰でも弾ける
  • 英語なんて誰でもしゃべれる
  • サラリーマンなんて誰でも出来る
  • プログラムなんて誰でも書ける

などなど。

 結局これってアマチュアとプロフェッショナルの違いについての議論だ。

 テストエンジニアがその存在価値を認めてもらうには、プロフェッショナルな開発者やマネージャーには提供出来ない、プロフェッショナルなテストエンジニアだけが提供出来る価値、組織にもたらす利益を突き詰めるしかない。 

 プロフェッショナルなテストエンジニアの役割

 僕が最近感じるプロフェッショナルなテストエンジニアの役割を列挙してみる。(ここではテスト設計やテスト計画等の専門用語は使わない。)

バグを見つける

バグを見つける事は、それを見逃しリリースしてしまった時の損失を防ぐ事に直接つながる。損失をもたらすバグをテストで見つける事はソフトウェア開発プロジェクトにおいて最重要の役割の1つだ。

無駄なテストをしない

いくら徹夜で頑張って大量のテストを実施したからってバグをみつけられなければ、それはプロジェクト全体から見ればコストとしか見られない。無駄なテストをしない選択をする事も重要な役割だ。

バグを見つけるタイミングを計画する

「どんな」バグを見つけるかと同じくらい「いつ」バグを見つけるかも重要だ。プロジェクトが終るタイミングで見つけたって遅すぎる。適切なタイミングでバグを見つけるように計画するエンジニアはプロジェクトの進捗の円滑化をしてくれる貴重な存在だ。

バグに関する知識の蓄積

テストは失敗する事をチェックして終わりではない。バグの特定とバグの修正をする必要がある。バグに関する知識や経験を多く持つテストエンジニアは、バグの場所を特定したりバグの修正方法について、品質を向上させる為のアドバイスをする。

開発者とテストエンジニア

  「ソフトウェアテストなんて誰でも出来る」なんて開発者に言われるのかしら。もしそうならば僕ならテキトーに言い返すなあ。「バグなんて誰にだって作る事が出来るw」と。

 ま、実際にはバグだって「誰にでも作れるバグ」と「プロフェッショナルな開発者にしか作り込めないバグ」がある。昔、あるプログラムの1つの処理のテストとして作って実行した5万件のうち1件だけ失敗した時には、自分もすごいと思ったけれどもそのプログラムの開発者もすごいと思った。どうしたら、そんな複雑なバグが作れるのだwと。 テスト結果を見せた時はその開発者も「いいテストするねー」と笑ってた。

 開発者はその最大限の想像力でプログラムを書くし、テストエンジニアは開発者の想像力のギリギリのところを狙ってテストをする。プロフェッショナルな開発者とテストエンジニアの関係ってそういうものだと思う。

アジャイルテストのテスト設計の話

Refactorable Testing Architecture

Incremental test design

 昨年度追加されたISTQBのFoundation Level Extension Syllabus Agile TesterのAgile Testing Practicesの項にはテスト設計に関する興味深い記述がある [1]。

Incremental test design: Test cases and charters are gradually built from user stories and other test bases, starting with simple tests and moving toward more complex ones.

アジャイルテストのテスト設計の特徴として

  • ユーザーストーリーをテストベースとして用いる事
  • シンプルなテストケースの追加から始まり、より複雑なものへと変化して行く事
  • Incrementalである事

が挙げられている。

アジャイルテストについておさらい

 アジャイルでは顧客に価値を届ける最小単位の要求をユーザーストーリーと呼ぶ。スプリント等と呼ばれるタイムボックスの中で、複数のユーザーストーリーの開発を行う[2]。

 アジャイルテストではこのユーザーストーリーをテストベースとして用いる。ユーザーストーリーに記載されている顧客目線でのシステムの期待される振る舞いを、テスターはテスト可能なストーリーへと変換する。ExampleやBDDなどの記法とコミュニケーションを通じて顧客、開発者、テスター間で期待するシステムの仕様について合意する[3]。また、シンプルなハッピーパスのテストから始め、そのテストがパスしてからエッジケース等の複雑なテストケースに進む[4]。

 厳密にはアジャイルテストではないが、アジャイルテストの原型となっているのがテスト駆動開発(TDD)だ。テストを先に書く事によってレビューとリファクタリングを繰り返しながら設計を改善していく事が可能であると言われている [5]。

 アジャイルテストにはもう一つ、アジャイルテスト4象限という大切な概念がある。アジャイルテストが取り扱うテストを4つのグループにカテゴライズし、テスト計画を立てて行くというものだ[6]。

  • 開発者のためのテスト=内部品質
  • 顧客のためのテスト=利用時品質

のようにカテゴライズし、それらのテストをいつどのように実施するか計画を立てる事を推奨している。

アジャイルテストのテスト設計の特徴

これらを踏まえ、アジャイルテストのテスト設計には以下の特徴がある。

顧客のテスト設計への参加

 アジャイルテストでの重要なテスターの役割は、顧客のビジネス的なシステムへの要求を非エンジニアである顧客にも理解可能なExampleやテストに変換する事だ。これにより、テスト設計への顧客の参加が可能になる。

開発開始前のテスト設計の実施

 アジャイルテストではスプリントの開始前、つまり開発の開始前にテスト設計を行い顧客、開発者と合意する。ここでいうテスト設計は一般的な意味での網羅的なテスト設計ではなく、

  • テスト観点の洗い出し
  • Happy path(やCritical path)のExample

のみしか含まないかもしれないが、あえてここではテスト設計と書く。

 これはテストプロセス視点で見ると、テスト設計を通じて仕様についての抜け漏れや間違いのレビューを早期に実施している事になる。

ユーザーストーリーとテストの追跡性

 ユーザーストーリーをテストベースとしてテスト設計を行うため、ユーザーストーリーとテストの追跡性が担保される[7]。そのため、ユーザーストーリーへの変更要求に起因するようなテストスクリプトへの変更や、ユーザーストーリーレベルでのテスト設計の変更が容易であるという長所がある。また、ユーザーストーリーの範囲で、単体テストやコンポーネントテストの継続的なリファクタリングが行われる[8]。

Happy path から Edge caseへ

 Incrementalなテスト設計と呼ばれる理由の一つがここにあると考えている。アジャイルテストでは、スモークテストで実施するようなhappy pathのテストとedge caseのテストのテスト実施を段階を分けて行う。実際にはテスト実施だけでなく、テスト設計も段階を分ける事が多い(と身の回りでは感じる)。

 テストの優先順位付けを行いリスクの大きいバグを早期に発見する事で、より俊敏で安定した開発•テストプロセスを築く事が出来る。

スプリントごとのアドホックなテスト設計の追加

 アジャイルテストのテスト設計がIncrementalであると言われるもう一つの理由がここにあると考えられる。テスト設計はスプリントの開始前にユーザーストーリーをテストベースとして実行される。そのため、テスト設計はスプリントごとに追加される。

アジャイルテストのテスト設計が苦手な事

 こうやって書いてくると良い事ずくめに感じられるアジャイルテストのテスト設計だが、これらの特徴に起因する苦手な事が存在する。

スプリントをまたいだ機能のテスト設計が苦手

 ユーザーストーリーをテストベースとしてテスト設計を行うので、どうしてもスプリントをまたいで実現される機能のテストが苦手という特徴が生じる。この弱点は通常は問題にはならない。優秀なプロダクトオーナーやアーキテクトは、システム要求をよしなに分割してストーリーは作られているはずである。例えば、機能BとCが機能Aに依存している場合、

  • スプリント1: 機能A の開発とテスト
  • スプリント2: 機能B の開発と 機能AとBの結合テスト
  • スプリント3: 機能C の開発と 機能AとCの結合テスト

といったように。しかし、ここで、

  • スプリント1: 機能AとCの一部を開発
  • スプリント2: 機能BとCの一部を開発
  • スプリント3: 機能AとBの一部を開発

のように、ユーザーストーリーがきちんと整理されていないと、結合テストをいつやるか?結合テストのスコープは何か?といった問題が生じる。(そんなのScrumじゃないと言ってしまえばそこまでだが、Scrumじゃない事を見落とすと非効率なテスト設計の本質を見失う。)

スプリントをまたいだテスト設計の最適化が苦手

 テスト設計の重要な役割として、テストカバレッジを担保しながらテストケース数を減らすテストの経済学の考慮がある[9]。しかし、アジャイルテストではスプリントをまたいだテスト設計の最適化が苦手である。

 何故か?第一にユーザーストーリーに対するカバレッジを100%にする事を大前提としている事、次にユーザーストーリーに対する追跡性を重要視しているため、システム全体でどのようなテストがどれくらいの規模で行われているのかを可視化する事が苦手な事に起因している。

 例えば今回のスプリントで追加した10件のテストケースによって、前回のスプリントで作成した100件のテストのテストケースを削除しても同等のパスカバレッジを担保出来るといった状況であっても、一般的にテストケースの最適化は行われていないのではないかと思う。

 こう考えている理由は、○○百億件のテストを自動化しナイトリービルドで実行しているエンジニアから「実はテストケースの減らし方が分からない」という話を聞いた事があるからだ。この会社では、テストの最適化をテスト実行の優先順位付けで行っているのは有名な話だ。

 また、実践アジャイルテストの 著者のJanet Gregoryの"Traceability"というタイトルのブログエントリが興味深い。ユーザーストーリに対する"Traceability"そのものは重要だが、"Traceability Matrix"のような全体を俯瞰するための表はいらないと述べている[10]。

アーキテクチャのテスト設計が苦手

 賛否両論あると思うが、アジャイルテスト4象限の第4象限に非機能要件のテストが定義されているのにも関わらず、アジャイルテストは非機能要件のテストが苦手だと指摘されている[11][12]。

 この問題は根が深い。アーキテクチャが自律的に、継続的に進化するのであれば、当然その反映であるシステムの品質、例えばパフォーマンスや運用性と言った品質も継続的にテスト、モニタリングされる必要がある。

 これは、アジャイルでのアーキテクチャの肩身の狭さのため、アーキテクチャの反映であるシステム品質がおろそかにされがちな為なのでは、と考えている。この問題の解決策として、パフォーマンスやユーザビリティ等の非機能要件もユーザーストーリとしてバックログに追加する事が提案されている[13]。

まとめ

 アジャイルテストではユーザーストーリーを中心に据える事で、

  • 顧客がテスト設計に参加
  • テスト設計を通した仕様のレビューの前倒し
  • Incrementalにテスト設計

をし、アジャイルなテスト設計を実現している事を挙げた一方で、

  • スプリントをまたぐテスト設計の最適化
  • ユーザーストーリーとの関連が低いアーキテクチャ等の品質のテスト

が苦手な事を述べた。

 アジャイルテストを導入するにあたっては、その長所はもちろんだが苦手な部分についてもきちんと考慮する必要がある。苦手な部分を無視するとテストの作り過ぎによる炎上やテストの抜け漏れを引き起こす。それらにきちんと対処すれば迅速で安定したテストプロセスの構築を可能にする。

 一方でこれらのアジャイルテストのテスト設計の苦手な部分は、これからアジャイルテストが体系化していくにあたっての課題であると考えられる。現在までアジャイルテストはどちらかというと「開発者側のもの」という印象があったが、これらの課題を解いていくにはテストや品質のスキルも必要になると考えられる。

リフェレンス

2次元の表によるテスト管理の限界

Refactorable Testing Architecture 継続的システムテスト

ソフトウェアテスト業界の古き大発明

 どの業界にも大発明が起きる瞬間がある。オーディオ業界のステレオスピーカー、映像業界のDVD、携帯電話業界のソフトウェアインターフェースなどなど。これらの破壊的な発明はそれまでの常識を覆し、全く新しい利便性や効率性をもたらす。過去使われていた方法は淘汰され、長期間に渡って多くの人に親しまれる。こういった大発明は劇的に世界を変える一方、多くの人に長期間親しまれてきたため、次に起きそうな革新を阻害するという事がしばしば起きる。誰だって長期間親しんで来たものが変化する時には少なからずの抵抗を覚える。

 「2次元の表によるテスト設計とテストケースの管理」はまさにこれにあたる。これだけ多くのテスター、テストアナリスト、テストマネージャーに親しまれ、長く使われて来たのはおそらく「革新的な発明」であり「とても便利なツール」だったからだ。しかし、次世代のテストを考える場合、この大発明を棄てる事も選択肢として考えなければならない。

2次元の表

2次元の表によるテスト管理の特徴

 様々な情報をすべて2次元の表に詰め込む。これが2次元の表でテストを管理する事の特徴だ。以下のような異なる属性が一つの2次元の表で管理されているテスト設計をみなさんも見た事があるのではないだろうか?

  • テスト環境
  • テスト観点
  • テスト条件
  • テスト技法
  • テスト事前条件
  • 期待値
  • テスト手順

すべての情報が一つのテーブルによって表されている事が大きな特徴だ。

2次元の表によるテスト管理の利点

 すべての情報が一つのテーブルによって管理されているので全体の見通しが良いというのが大きな利点の一つだ。特にマネージャーはこのテーブルを見るだけで、どのようにテストしているのか一目瞭然に分かる。テスト観点やテスト条件を見れば何をテストしているのか分かるだろうし、テスト手順や技法を見ればどのようにテストしているのか分かる。

 また、この2次元の表によるテスト管理の利点としてもう1点、テスト設計者とテスト実行者を分ける事が可能になる事がある。 なるほど。どこかで聞いたような話だが、テスト設計とテスト実行の役割を明確に分ける事により、テスト実行の部分をスケール出来るようにする。「人月の神話」を信じているような、レガシーな大規模開発ではありえそうな話だ。

利点の前提条件

 しかし、この利点を効果的に得る為には一つの条件が前提となる。それはテスト設計に変更が入らないという事。少し条件を弱めれば、テスト設計の時点でテスト設計への変更要求がある程度予測可能である事である。

 ウォーターフォール開発が一般的であった時代には少なくともプロジェクトマネージャー、アーキテクト、QAマネージャー間では合意可能な前提であったのだと思う。しかし、アジャイル開発のようなテスト設計への変更要求が大前提の開発スタイルではいくつかの大きな問題を引き起こす。

2次元の表によるテスト管理の問題点

①テスト条件の追加•変更更要求に対し、変更箇所が多い

 テーブルを非正規化してしまっている事の弊害として、テスト設計変更要求に対して変更箇所が多いというメンテナンス容易性の問題がある。例えば、新しい仕様の追加によりテスト条件を1カ所追加したい場合、正規化しているテーブルに対してならば1カ所だけ変更するだけで済むものも、非正規化しているテーブルに対しては、select文で条件に合致するレコードを抽出し、条件に合致するレコード全てに対してテスト条件を追加する必要がある事と同じ問題が起きる。

②テスト設計の継続的改善が難しい

 また、テスト設計の継続的改善が難しい事も問題である。テスト設計は一度実施したら終わりというものではなく、継続的に改善する必要がある。これには2つの理由がある。

  1つ目の理由は、テストの実行結果によってテスト設計も改善する必要がある事である。テスト実行前にバグを発見可能と予測して作ったテストケースと、実際にバグを見つけたテストケースとの間にはきっと差分がある。その差分によりテストケースを追加する事は当然であるが、加えてテスト設計も見直す必要がある。

 2つ目の理由は、プロダクト側のアーキテクチャ変更に伴うものである。アーキテクチャが変われば当然求められる品質も変わる。テスト設計自体を変更する必要性が生じる。

③テスト自動化への移行の問題

 テスト自動化が成功していない事例をいくつか見たり聞いたりしてきたがその原因の一つに、手動テストが前提の"テスト設計者"と"テスト実行者"のロールモデルをそのままに、テスト自動化プロジェクトを実施したというものがある。

 よく聞く「手動のテスト実行よりも、テストスクリプトの実装の方がコストが高い」という話。今まで通りのテスト設計をして、テスト実行をテスト実装で置き換えるという前提であれば、その比較は正しい。しかし、僕はこの比較についてかなり懐疑的に考えている。「手動テストに最適化されたプロセスのコスト」と、「自動テストに最適化されていないプロセスのコスト」の比較にどんな意味があるのだろうか?

 テスト自動化へ移行する場合、少なくとも

  • テストスクリプトを実装するエンジニアにとっての必要最低限な情報は何か?
  • テスト設計プロセスの中で、テスト実装者が実行した方がプロセスが最適化されるものは何か?

についての議論を踏まえ、自動テストに最適化されているプロセスを定義し比較する事が必要である。

まとめ

 僕はこれらの「2次元の表によるテスト管理の限界」について、テスト設計がリファクタリング不可能である問題、とこれから呼ぶ事にする。

 継続的インテグレーションが導入されているプロジェクトでは、リファクタリングを定期的に行い技術的負債を返済しながらプロダクトの品質改善を行うのと同様に、テスト設計も定期的に改善されていかなければならない。そう、きっとテスト自動化プロジェクトとスクラムはとても相性がいいのだ。

 次回のエントリでは、アジャイルテスターの人達がどのようにテスト設計とそのリファクタリングについて考えているのか、何も考えていないのか、について書く。

参考情報

http://qualab.jp/materials/SOFTEC2012-2.pdf

JaSSTソフトウェアテストシンポジウム-JaSST'15 Tokyo レポート

品質をカイゼンするフィードバックを作る

継続的システムテスト

全4回のウォータースクラムフォールをガチでディする連載の最終回です。前回までのエントリーはこちら。

  1. プロトタイプはリアルプロダクトたりえないのか? 〜そのテストはプロジェクトのリスク管理に貢献していますか?〜 - Test Automation
  2. 「継続的デリバリー」から考えるソフトウェア開発の入り口、出口問題 - Test Automation
  3. 品質改善をしないアジャイル ~ウォータースクラムフォール~ - Test Automation

「正しいアジャイル」は品質向上プロセスをどのように回しているのか?

前回のエントリで、アジャイルで品質向上サイクルを回すための方法として「TDDにも品質についてもハイスキルなエンジニアのチームを作る」を挙げた。まず、正しいアジャイルではTDDによってどのように品質向上サイクルが回るのかを考えたい。

 TDDは「テストを書く」「テストを通す」「リファクタリング」の黄金の三角形を回しながらソフトウェアを開発するプラクティスだ。「テスト駆動開発」の名前のためかテストを最初に書く、つまり「テストファースト」な特徴に注目が集まりがちだが、その本質はレビュー観点を区別した品質向上サイクルにあると考えている。

 TDDはまず最初にテストを書く。しかしただテストを書くだけではない。優秀なエンジニアは、仕様に抜け漏れがないか?設計は妥当かを考えながらテストを書く。これはいわゆる「仕様書•設計レビュー」に相当する。

 テストの実装の後、機能を実装しテストを通す。ここで熟練したエンジニアはただテストを通すだけでなく、書いた機能のコードについてマルチスレッドやメモリーリーク等のバグがないか「探索的テスト的なレビュー」を行う。

 テストがパスした後、そのテストが失敗しない事を確認しながら内部設計の改修を行う。これはすなわち、ソースコードの「保守性をレビュー」している事に他ならない。

 TDDではこの黄金の三角形のサイクルを小さくリズミカルに回しながら開発を行う。

f:id:kokotatata:20150301165135p:plain

 このプロセスは非常に優れている。優れたエンジニアはTDDによって、ソフトウェア品質モデルに含まれる「プロセス品質」「内部品質」「外部品質」について、「テストを書く」「テストを通す」「リファクタリング」のアクションでそれぞれレビューをし、小さな品質向上のフィードバックを継続的に回す事が出来る。

 

f:id:kokotatata:20150301170237p:plain

  そう、TDDの本質はエンジニア個人が小さな品質向上のフィードバックループを継続的に回す事にある。

チームで品質に関するフィードバックを回す

 エンジニア個人はTDDによって品質に関するフィードバックループを回す事が出来る。しかし、要求分析、設計、品質とどこかのスキルに特化したチームが複数ある場合、チームレベルでのフィードバックを回すにはどうしたらよいのか?

 答えはもうすでに、アジャイルテストの細谷さんと永田さんが出して下さっていた。

  1. 品質に関する要求もバックログで管理し、スプリント中に実施する
  2. 品質エンジニアも設計チームに参加し、積極的に品質に関するフィードバックをする

 1.の意味は2つある。1つ目は開発プロジェクトの最後に品質の門番としてのQAを実施するのではなく、開発初期からテスターが品質の視点でプロジェクトに関わる事。2つ目は、品質に関する要求をプロジェクトの初期から明示的に管理する事。ここで言う品質は、パフォーマンスや運用性などの非機能要求も含まれる。

 ただし、1.だけでは本当の意味でのアジャイルな品質向上にはならない。アジャイルの品質向上活動の本質は、動作するソフトウェア上での迅速なフィードバックにある。だから、アプリケーションをデプロイ、品質を評価し設計にフィードバックする。

参考文献:

 先日、永田さん、細谷さんとお話をし、アジャイルでの品質向上の本質がフィードバックループにあるという事に確信を持った。また、下記ののコラムが非常に面白いので、興味のある方は是非読んで頂きたい。

その中で一番中心になったのが、なぜ、アジャイル開発では設計から要求仕様書が出ないのだろうか、というストレートな疑問でした。その中で細谷さんは、フィードバックの設計という話をされました。ソフトウェア開発では、いたるところでフィードバックループがあります。アジャイル開発はそれを早く(アジャイルに)回すのです 

第161回 シンクロニシティな世界アジャイル、欠陥エンジニアリング、そして要求開発編(全4回の第4回)|SQiP:Software Quality Profession

リーンとカイゼン

 この「品質に関する迅速なフィードバック」を回す事は、日本の製造業がずっと大切にしてきた「品質を作り込む」という思想そのものに他ならない。そしてその思想は、同じ思想の源流を持つ「リーン開発」の中に受け継がれている。(川口さんの有名な絵画を拝借します。)

f:id:kokotatata:20150301184318p:plain

Agile and Lean from altitude 12,000 feets // Speaker Deck

 例えばJoseph Yoder氏は"QA to AQ"という考え方の中で「非機能要求も整理し、バックログで管理しなければならない」という事を主張している(JDD2014: QA to AQ: shifting from quality assurance to agile quality -…)し、James O. Coplien氏は「Lean Testing」という考え方の中で「テストもリーンになる必要がある」と主張している(Beyond Agile Testing to Lean Development — Rakuten Technology Confere…)。

 そう、アジャイルやリーン開発と、品質の継続的なフィードバックを作る事はとても相性がいいのだ。そういえば、先日インドのテストエンジニアコミュニティの方とお会いしてリーン開発でのテストの話をしている時に、「リーン開発のテストではカイゼン=Continuous Improvementを作るのが重要」という話が上がり、あぁ、リーンとカイゼンはソフトウェアの継続的な向上の為の二輪となるコンセプトなんだなと改めて感じた。

 ソフトウェア開発プロセスの中に「品質をカイゼンするフィードバックを作る」。古くて新しいソフトウェア品質の考え方だ。

品質改善をしないアジャイル ~ウォータースクラムフォール~

継続的システムテスト

 ウォータースクラムフォールをガチでディする全4回連載の3回目です。はい、そうです。前2回のエントリは今回ウォータースクラムフォールをガチでディする為の前振りです。ウォータースクラムフォールの説明は以下のページをご覧下さい。


実用主義者が勝ったのか?Water-Scrum-Fallが一般的に

ウォータースクラムフォールの問題点

 ウォータースクラムフォールの問題点は上記の記事のこちらの一節に凝縮される。

多くのアジャイル導入は実作業者によって主導され、実作業者が最も緊密に作業する領域、つまりソフトウェア開発ばかりにフォーカスすることから、このようなことが起きるのだとForrester社は見ている。リリース管理やプロジェクト計画のような領域は、未だに伝統的な手法で行われているのだ。

ウォータースクラムフォールの問題は、プロジェクト関係者がソフトウェア開発ばかりにフォーカスする事で、テストや運用計画、リリース管理等のソフトウェアの品質改善に直接貢献するプロセスが全く回らない事。

 スクラムでスプリントを分割しイテレーションで開発するのは

  1. プロジェクトの外部要因の変化への対応を容易にする
  2. プロジェクト内からのフィードバックループにより改善する

が大きな目的だ。しかし、多くのウォータースクラムフォールプロジェクトでは1.にばかり注目し2.の意味を軽視している。

 プロジェクトの始めに、一番大きな仮説についてプロトタイプを作る事はもちろん外部要因の変化に対応するため重要だ。だがそのプロトタイプをきちんとテストし、アーキテクチャや運用設計についてフィードバックループを回さなければ、そのプロトタイプはシステムの品質には寄与しない。( 連載第一回目の記事:プロトタイプはリアルプロダクトたりえないのか? )

 スプリント中でいくら単体テストを自動化したとしても、コンポーネントの結合やシステム運用レベルの仮説はまだまだ残っている。機能やユースケース等の外部品質はもとより、使用性や運用性などの利用時品質は実際にデプロイして、試用してみなければその評価や改善をする事は出来ない。(連載第二回目の記事:「継続的デリバリー」から考えるソフトウェア開発の入り口、出口問題  )

 ウォータースクラムフォールには品質改善のフィードバックループというソフトウェア開発の重要な概念が抜けてしまっている。

ウォータースクラムフォールが品質を向上させない理由

 スクラムはソフトウェア開発プロジェクトのプロセス品質を向上させる為の素晴らしいプラクティスだ。ストーリーを定義しベロシティを計測する事はプロジェクトの進捗の予測性を改善するし、レトロスペクティブはその自己的な改善活動を促進するだろう。定期的なクライエントへのデモは要求とのギャップを改善し、手戻りを大幅に減らすだろう。

 しかし、スクラムは内部品質外部品質の向上には寄与しない。それらも改善する為にはXPのCIやTDDを導入する事が必要だ。CIはコンポーネントの結合に関するリスクを大幅に減少させるし、TDDはプロセス品質内部品質外部品質を劇的に改善する素晴らしいプラクティスだ。

 問題は、多くのウォータースクラムフォールと呼ばれるプロジェクトでCIやTDDが正しく導入されていない事。開発とQAが独立した組織では対立構造を作りやすいためCIやTDDの導入は困難だ。また、テスターの設計•プログラミングスキル不足により、テスターが品質に寄与出来るようになるまでプロジェクト終盤まで待たなければならないというのも問題だ。同じように開発者の品質への理解不足は間違ったアジャイルを促進しTDD自体の品質向上を徹底的に妨げる。

 結局のところ、スクラム、XP、そして品質についてもスキルの高い開発者ばかりを集めて、正しいアジャイルを実践する以外に品質を向上させる手段はないという結論になってしまうのかもしれない。

ウォータースクラムフォールを乗り越える為に

 いや、その結論でこの問題を結論づけるのは早計だ。では設計やテスト、品質それぞれ一つのスキルに特化したメンバーが集まっているチームで品質を上げて行く為にはどうしたら良いのか?そのヒントは品質大国日本の生産工程そしてリーンにある。

 ウォータースクラムフォールや間違ったアジャイルに欠けている品質改善のフィードバックループを作る為にはアジャイルテストを越えて、継続的システムテストそしてリーン開発へと進まなければならない。

 全4回連載、最後のエントリとなる次回ではスキルに特化したメンバーが集まったチームでの品質改善フィードバックについて述べる。

次回エントリはこちら

kokotatata.hatenablog.com