JaSST'12 東海(ソフトウェアテスト・シンポジウム2012東海)@刈谷

DSC_0800.JPG

JaSST行ってきました!昨年に続いて二度めの参加です。
JaSST’12 Tokai
ちなみに、昨年の記事はこちらを参照ください。
昨年もそうでしたが、単に「ソフトウェアテスト」の枠にとどまらず多くのことを学ぶことができました。簡単ではありますが、特に印象に残ったことを紹介したいと思います。
基調講演
湯本剛氏による『ソフトウェアテスト、一番最初にやるべき大事なこと』と題した講演です。
ソフトウェアテストが直面している課題として、

  1. ソフトウェアの大規模化・複雑化によるテスト工数の増大
  2. 開発期間短縮化によるテスト工数不足

という2点が紹介されました。
これは何もテストに限らずソフトウェア開発全般に言えることだと思いますが、テスト工程は開発の最後に行われることが一般的なので、「工数の確保」というのは、より切実な問題なのだと思います。
一方、ソフトウェア開発プロジェクトのライフサイクルにおいて、欠陥の発見が早ければ早いほど欠陥改修コストを低く押さえられるのも事実なので、テストのやり方を改善することは、プロジェクト全体のQCD改善に直結するものと考えられます。
この「テストのやり方」にフォーカスして、もう少しブレークダウンしたものが次の分類です。

  • テスト開発技術(テストケースを開発する技術)
  • テスト実行技術(自動化などテストを効率的に実行する技術)
  • テストテストマネジメント技術(テストの戦略/計画、情報の共有/伝達や報告)

ひとことで「テストのやり方」といっても、色々な切り口があることが分かりますね。
効果的にテストを行うためには、そもそもの「テストの目的」や「テストの対象」を明らかにしなけばなりません。(これがいい加減だったり関係者間で共有されていなかったりするのが実態・・・)
このための活動が「テスト計画」で、テスト対象を「分析」して「設計」することで、初めて「テストケース」が出来上がります。テストケースをもとに「実装」したアウトプットが「テスト手順」です。
この辺りの話は、「ゆもつよメソッド」をキーワードに調べてみると色々な情報があります。
ここで「テスト目的」にフォーカスしたお話が続きます。
ISTQBにテストの必要性や目的が定義されているようですが、大きな括りとしては以下のようになります。

  • リスクの低減
  • 対象ソフトウェアが当初の目的を果たしていることの証拠
  • ソフトウェア品質の計測
  • 開発へのフィードバック

こうして見ると、テストを行うことによって、プロジェクトに対して様々な情報を与えてくれることが分かります。
計測した結果をもってステークホルダーへの説明を行うのはもちろん、テストで見えた結果や傾向からプロセス改善を行い、開発者のモチベーション向上にもつながる・・・
まさに、プロジェクト・マネジメントの世界における「プロジェクト実行」のアウトプットを生み出すものであり、それが「監視・コントロール」のインプットとなります。
言ってみれば、プロジェクトの方向性を示してくれる羅針盤のようなものですね。
講演では、テストは品質を写す「鏡」、テスティングは鏡を使って知る「行為」(ソフトウェアを実際に動かして検証する)、という比喩を使った説明がありました。

  • どこを見たいのか?
  • 見ることで何を知りたいのか?
  • 知ってどうするのか?

これが曖昧であったり関係者間で共有できていないことが、テスティングの難しさがあるようです。
「何をどこまでやれば良いのか?」が曖昧なまま取り組んでも、何事も上手くいくはずがありませんね。
特に、ソフトウェア開発は製造業と違い、毎回作るものが異なります。ということは、「何をどこまでやれば良いのか?(どれが最適か?)」がプロジェクトごとに違うということになります。
このことをを考えないまま過去事例をそのまま適用すると失敗するのは、自明の理です。
何をもって「最適」とするかは、そのソフトウェアを作る目的や背景によって様々だと思います。
さらに、ソフトウェア開発は複数人のチームで行いますので、この「どれが最適か?(テストの目的)」を関係者間で共有することが重要になってきます。
講演では、テスト目的を共有するために重要なポイントがいくつか紹介されました。

  • 目的を具体化する
  • 全体像を見せる
  • etc

何も「テスト目的」に限ったことではないですね。
最後に繰り返しになりますが、テストは品質を写す「鏡」であり、そこで出てくる結果はプロジェクトが正しい方向に進んでいるかどうかを示す羅針盤。
テストの目的を明確にして共有することが、プロジェクトの成否を左右すると言っても過言ではないでしょう。
経験発表
きょんさんによる『アジャイルなテストの見積りと計画づくり』の発表です。
当日使われたスライド
私は普段アジャイルに縁の無い環境で仕事をしていますが、この発表にもあった「方針とフィードバックをいかに早く共有するか」は本当に大事だと思います。この場合は、プロダクト・オーナー、開発者、テストエンジニアという3者の視点での「共有」を想定していました。(大きなプロジェクト全体だともっと多様なステークホルダーが登場するのですが・・・)
面白いのは、テストの見積り(工数?)を相対見積りで取り組んでいること。
テストに関する様々な要素(パラメータ数や組み合わせ数など)を「テストポイント」(ストーリーポイントのテスト版?)として点数を付け、定量化します。
その上で、1日だけ広く薄くテストすることで生産性(ベロシティ)を測り所要日数を見積もるというやり方で、見積りの実現性を担保します。
テスト設計を「リファクタリング」するというのも、アジャイルらしいですね。
何事も「まずやってみる」ことが大切ですね。
要求仕様書のレビューにはどんな視点が大事?
今回のSIG(Special Interest Groups)は、このテーマを選択しました。
ある程度予想はしていましたが、定員を超える13名が参加しました。やはり「要求仕様の抜け漏れ」はどのプロジェクトでも大きな関心ごとなのだと感じました。
SIGオーナーは「TEF 北海道ソフトウェアテスト勉強会(TEF道)」のお二人。遠路ご苦労様です。(´∀`*)
さて、このSIGは「要求仕様書レビュー」に関するオーナーからの問いかけに、参加者が答えて皆で議論していくという形式でした。
特に多かった意見や、議論が盛り上がった意見をあげてみます。
◆要求仕様書レビューで何を見つけているか?

  • 利用者の目線で仕様に不備がないか?
  • 仕様に漏れがないか?
  • UIまわり/使い勝手
  • 相手に伝わるように書けているか?
  • どのようにテストすれば良いかが分かる内容か?
  • そもそも本当に必要な機能か?
  • 誰の要求に基づく要件/仕様か?
  • スケジュールやリソース的に実現可能か?
  • etc

特に「本当にユーザーが必要とするものなのか?」という視点でレビューに臨む人が多く、議論もそこを中心に展開されたような気がします。
その中で、清水吉男氏が提唱するUSDM(Universal Specification Description Manner)表記法が話題になりました。要望>要求>要件>仕様と落とし込んでいくことで、仕様の裏にある要求を明確にすることができるようです。その要求が発生した「理由」を併記するのも特徴的で、顧客の「真の要求」を洗い出す手法として活用されている参加者も数名みえました。
自分も以前USDMに関する清水さんの著書を読んで実践しようと試みたことがありますが、結局長続きしませんでした。(何となく「良さそうだ」というのは実感できましたが・・・)
これを機に、また取り組んでみようと思いました。※実践している人が実際にいるとモチベーションもあがりますね!
◆目的をもってレビューしているか?
どんな目的をもって要求仕様書のレビューに臨んでいるか?という問いかけです。次のようなことを意識してレビューを行なっているという意見が出ました。

  • 何のためのレビューか
  • 誰向けの要求仕様書なのか
  • 何をチェックするためのレビューか
  • チェックすべき項目は?
  • 自分はどんな立場でレビューするのか
  • etc

「要求仕様をレビューする」ことに対して、普段は他の人を意見を交換する機会が皆無なので、今回のSIGは非常に刺激的かつ新鮮でした。
ひとことで「レビュー」といっても、その目的や観点を明確にし共有することは非常に大切です。また、使い勝手だけでなく、品質特性や保守しやすさ、コスト面など(これは私自身の意見でしたが(;^ω^))、様々なレビュー観点があることを知り、大変有意義な時間を過ごすことができました。
さいごに
情報交換会も含めて、今年も有意義かつ楽しい時間を過ごさせていただきました。
自分の場合、テストエンジニアという職種の人と接する機会が普段滅多にないため、こうした場でお話を聞くことでテストエンジニアの方々の熱量(明らかに開発者やマネージャとは異質!)を感じ、また新たなモチベーションを得ることができたような気がします。
(終)
**参考書籍**