『パーフェクトソフトウェア』を作りたいなら読みなさい

メディアマーカー用に文章を書いていたのですが、悪い癖で長い文章になってしまいました。
ということで、その文章をブログにしようと思います。

取り上げたい本は、ジェラルド・M・ワインバーグ氏の『パーフェクトソフトウェア』です。

私は、とくに以下の文章には感銘をうけました。

良いテストにするためには、リスクを軽減したいという要求と、過剰に情報を集めようとするリスクのバランスをとることだ。(p.6)

一般的にテストと呼ばれるものは、「品質を作り込む」ものではなく「品質を確認する」ものなのです。
テストをするだけでは、ソフトウェアの品質は上がらりません。
当間ですが、テストの結果を受け、ソフトウェアを修正しなければならないのです。
テストは、どこを修正すべきか、どのように修正すべきか、そして、その製品は出荷されるべきか、という判断のための情報を収集するための活動なのです。

ビジネスアプリケーションを作る世界では、ウォータフォール開発であろうが、アジャイル開発であろうがテストの必要性は疑いもないことです。
そして、開発現場における「テスト」としてTDDが出現してきた昨今、「品質を確保する」という使命は品質保証(QA)やテスターだけのものではなくなりました。
もちろん、今までも開発現場の主役である開発者にとっても、「品質の確保」は責務の一つであったのですが、TDDによりそれがより明確になったのです。
なにより、各々が携わる現場において、品質に目を向けて作業をする、という点は、品質の良いソフトウェアを作り込むうえでよいことです。
しかし、各現場において「テスト」という概念が生まれてことにより、開発現場や品質保証の現場、そこに携わる人々が混乱していることも事実です。

ワインバーグ氏が本書で取り上げるテストの概念は、そうした現場の混乱を解きほぐすものになるでしょう。
ワインバーグ氏は、テスターの仕事として以下の作業を取り上げています。

・発見のためのテスト
ソフトウェアを動かし、そのソフトウェアについて新たな情報を得るためのテストです。
たとえば、想定される業務シナリオをどおりに動くか、データ異常が起きた場合はどのようにアプリケーションが振舞うか、などをチェックします。

・絞り込み
想定される挙動とはことなる動きをソフトウェアがした場合、その原因はどこにあるかを調べます。
そのために、そのバグの再現方法と条件を調査し、バグの潜む箇所を絞り込みます。

・特定
バグがコード上のどこにあるか」、デバック作業などで確認します。

・重要度の決定
特定されたコードを修正することと、その修正のために入り込むリスクなどを判断します。
また、修正を行わなかったときのリスクも考慮に入れる必要があります。

・修正
修正を決定したコードを変更し、バグを取り除きます。
修正後は、バグを発見した時と同様のテストを行ない、バグが発生しないことを確認します。

・トラブルシューティング
トラブル発生時に、その障害を取り除いたり、回避したりするのための対策を行います。

・学習のためのテスト
バグを発見することを目的するのではなく、自らの興味に従ってソフトウェアの挙動を確認します。
ハッキングやリバースエンジニアリング、「遊び」ともいいます。

アジャイルな開発プロセスにかかわらず、こうした作業をいったい誰がやるのか、という点を明確化する必要があります。

TDDを例にあげれば、TDDで書かれるテストが本当に「発見のためのテスト」となっているのか、をよく検討する必要があるでしょう。
TDDのテストが、「発見のためのテスト」として機能しえない、と判断されるなら、別でその保障をする必要があります。
また、TDDが「発見のためのテスト」の一部と考えられるのであれば、TDDのテストコードの規約がひつようになったり、システムテストに含めるべきケースも変わったりするはずです。

また、システムテスト時には、「発見のためのテスト」はテスターがやる、「特定」については開発者がやる、など線引きを行う必要があります。
トラブルシューティングなどもどの立場の人間が行うか、またどのような順番で持ち回るか、などを検討しておく必要があります。
プロダクトに関わるすべての人が、責任を持つべきだ、といえば格好がいいのですが、責任の所在があいまいになります。
なによりも、「自分の仕事である」という自覚がない仕事をやらされると、その仕事を矯正されていると感じられ、メンバーの士気は大幅に低下します。

また、テストのコミュニケーションについて、以下のようなプロセスを取り上げています。
上記が、テストの作業を示すものならば、テストにおけるコミュニケーションにおける注意点と原則を示したものです。

・取り込み
能動的に情報を吸収する段階です。
この段階でもすでに情報そのものだけでなく、伝える人物や方法によって情報の取捨選択が行われている可能性があることに注意が必要です。
積極的に情報を収集するとともに、優先度による情報の整理も必要になります。
ただし情報にたいする「意味づけ」は行ないません。
そのためにも、1つの情報が意味することを3つほど考えて1つの意味にとらわれないように心がける必要があります。

・意味づけ
テストによって集められた情報を解釈し、情報が「何を意味しているか」を検討し、決定する段階です。
テストにたいする具体的な期待を明確にしていることが重要になります。
なぜならプログラムが「なにをするべきか」という目的によって、プログラムの動作がバグか否かが決定されるからです。
この作業は1人だけで行わず、複数のメンバーで集まって行なったほうが複数の観点から検討する必要があります。

・意義づけ
意義とはバグにたいして割り当てられる重要度のことです。
バグが製品にとってどれだけ深刻なものか、優先順位をつけ管理し、重要なものから対処してゆきます。

とくに修正の難しさと意義を混同して、難しいものを意義の高いものとして判断してはいけません。

また、意義は個々人の立場によって異なってきます。
それらの多くは、合理性よりも感情に基づいているからです。
そして、人々の感情は立場や受けているプレッシャーによって変化します。
この点を無視してはいけません。特に、意義づけを行うときは、自分自身の感情に目を向けることが必要です。

・反応
バグにたいする反応は、3つのフェーズに分けられます。
-見つけ(find)
-考え(figure)
-直す(fix)
難しいのは、このシンプルなプロセスを維持することです。

そのためには、なによりもプロジェクトの初期段階から正しくプロジェクトが運営されていなければいけません。
正しく運営されないプロジェクトは、終盤での混乱を招き、テストおよび修正のための時間を奪ってしまいます。
そして、とくに品質確認段階のテストで、その点を挽回することはとても難しくなります。

また、テストおよび修正のための見積を正確に行える準備が必要です。
プロジェクトの終盤では特に、「修正するに足るリソースが残されているか」を判断するための見積が重要です。
「修正のためのリソースがない」と判断されたバグが製品にとって深刻な場合は、その機能を外して出荷するか、最悪の場合は出荷そのものを取りやめる判断をする必要があるからです。

以上のようなテスト作業について、プロジェクトのどの段階でどのような立場の人々が責任をもって行うのか、そして、どのようなコミュケーションプロセスがテスト、ソフトウェアの品質に関わってくるのか、を考えてゆくことで、現場の混乱も緩和できるのではないでしょうか。
本書はそれらを整理し、実践することのヒントを与えてくれるはずです。

ソフトウェアの品質向上を目指す人達には、是非、手にとっていただきたい一冊です。

ランキング参加中。気に入ったら一押しお願いします!
人気ブログランキングへ

広告

コメントを残す

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

WordPress.com ロゴ

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

Twitter 画像

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

Facebook の写真

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

Google+ フォト

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

%s と連携中


%d人のブロガーが「いいね」をつけました。