トピックス

ソフトウェアテストシンポジウムJaSST’11 Tokaiにて，代表幹事の山本(雅)と運営委員の森川が、ポスターセッションとSIG(Special Interest Groups)に参加しました．

実施報告

1. ポスターセッション

開催時間：13:00～13:30

山本(雅)と森川はASDoQの活動を紹介しました．ほとんどの方がASDoQの名前さえもご存知無く，直接説明した方と周りで聞かれていた方を合わせて15名程度の方にASDoQの存在を知っていただくことができました．

ディスカッションを通じ，ほとんどの方が文書品質に対して高い関心を持っておられる様子をうかがい知ることができました．何名かの方からは，ASDoQに参加したいというご意向も頂戴できました．

その一方で，立ち上がったばかりの研究会のため本当に成果が出るのかわからない，参加したくても会社の理解を得にくい，という意見もいただきました．

多くの企業様に理解・協力していただけるよう，このような会で継続して広報活動を行います．

2. SIG「テスト工程の開発文書品質」

開催時間：16:15～18:15
SIGオーナー：山本(雅)，森川
SIG参加人数：12名（SIGオーナーを除く)

 概要

山本(雅)の進行の下，次の項目を実施しました．

• 文書品質の現状の説明
• テスト工程の現状の確認テスト工程で作成される開発文書と作成順序
• 上流工程の開発文書に対して感じる問題点
• まとめ

当初の計画では，テスト工程における開発文書の品質を参加者がどう考えるかを，主に聞く予定でした．しかし，参加者が置かれているテスト工程の現状確認に予想以上の時間を要しました．ただし，上流工程の開発文書品質に，テスト工程は影響を受けていることは確認できました．

テスト工程の現状の確認

「仕様書がない」，「仕様書に書かれていることは全てではない」という状況において，テストが行われている現状を知り，我々２人は唖然としました．

上流工程の開発文書の品質が良くないために，テスト技術者は困難な作業を行っています．テストエンジニアは，不完全な文書を基に，テストを考えなければなりません．そのため，どうしても「テストが漏れる → 不具合が見つからない →　品質低下 」という悪循環に陥っています．

たとえ，テストに必要な情報が上流工程の開発文書に記載されていたとしても，複数の仕様書に散らばっているケースが多いようです．そのため，テストケース（テスト条件の組み合わせ）の洗い出しがとても難しく，テスト漏れが発生しています．

テスト工程で作成される開発文書と作成順序

SIG参加者は，テストを次の手順で行っていました．作成される開発文書が明らかになるように，話をお聞きしました．開発文書をカギ括弧で囲み以下に示します．ただし，時間不足のために，我々の理解が不十分な点を含みます．

(１）「テスト計画書」の作成
「テスト計画書」には，次の項目が記載される：テスト対象物の概要，テスト戦略，テスト期間 など

(2) 「テスト仕様書」の作成
「テスト仕様書」には，次の項目が記載される：テスト対象物の概要を明確にしたもの，具体的なテストのやり方(テスト環境など) など

(3) テスト工程に対応する上流工程の開発文書のレビュー

(4) 「テスト設計書」の作成
「テスト設計書」には，テストの要求分析を実施した結果が記載される．

(5) 「テストケース仕様書」の作成
「テストケース仕様書」には，次の項目が記載される：前提条件，入力，期待出力，手順書，スクリプトなど

(6) テストの実行
テスター＝テストを実行する人
実行結果＝テスト結果（出力値の羅列）

(7) 「テスト報告書」の作成
テスト計画に対する報告書という位置づけ．
「テストプロジェクト完了報告書」とも呼ばれる．

上流工程の開発文書に対して感じる問題点

 参加者の方に，普段，上流工程の開発文書に対して感じている問題点を，付箋紙に書き出してもらい，模造紙に貼り付けて整理しました．そこから，上流工程における開発文書とその作成者に対して，次の問題点が見えてきました．

問題点１：品質の悪い開発文書が書かれている

• 文書の読者にわかりやすい記述がされていない．
• 他の文書に定義されていることが記載されていない．全体像が網羅できる記述が無い．
• 暗黙知の記載が省略されている．
• 日本語や記法がわかりづらい．解釈は読者に任せられている．
• 用語統一がされていない．
• 文書の不具合が多い．
• 上位工程の文書と下位工程の文書で，記載内容がずれている．作成者が異なるため．
• メール等でやりとりした情報が，設計書に反映されていない．
• 箇条書きの条件項目にて，AND条件とOR条件が区別されず，混在している．
• 正常系しか書かれていない．
• 非機能要求が書かれていない．

問題点２：開発文書を意図的にあいまいに記述し，責任逃れをする人がいる

• テスト実施後にしか，仕様書を完成する気がない．
• レビューさえ通ればよい．
• レビューに参加できる人が少ない時間に，レビューを設定する．

問題点３：言い訳をして，開発文書を書かない人がいる

• “工数が足りない”という理由で，品質の低い文書を作成していることを悪いと感じていない．

問題点４：開発文書の改訂によって生じる影響に無関心な人がいる

• テストエンジニアがテスト設計・実施をしている間に，設計書が平気で変更され，何処が変更されたのかを教えてくれない．
• テストエンジニア自らが間違い探しをしなければならない．量が膨大すぎて大変．
• 変更履歴にはざっくりしか書かれていないので，どう変更されたかがわからない．

まとめ

• 上流工程の開発文書の品質が低いため，テスト工程にしわ寄せが来ている．

• テスト工程内の開発文書も品質が高いと言えない．

3. JaSST’11 Tokaiに参加した所感

ASDoQの取り組みを多くの方に知っていただけ，非常に関心を持っていただけたことがよかったです．是非ASDoQに入会いただければと思います．

また，テストエンジニアが抱える問題の原因の１つに，上流工程の開発文書品質の低さがあることがわかりました．また，テスト工程内の文書についても同様の品質問題を抱えていることがわかりました．そのため，ASDoQの活動によって，文書品質を向上できれば，テストに関する多くの問題が解決できそうだと感じました．ASDoQの活動の必要性を再確認できました．

（森川）