テストについて

社内で勉強会をさせてもらった。

「テストについて」とのことだったので、SEC BOOKS の中の

『組込みソフトウェア開発における品質向上の勧め（テスト編～事例集～）』 の
Part１「テストの役割と限界」の章を使って、流し読みしながら解説するという形をとった。

頭の片隅で「○○○（うちの会社名）のテスト品質ってなんだろう」ってことを考えながら読んでいきましょう

というお題を出しておいて。

また、この資料の中に出てくる『組込みソフトウェア開発向け品質作り込みガイド(ESQR)』の解説も合わせて行なった。

以下、話したことを簡単に残しておく（基本的には上記資料の内容に基づくもの）。

• テストの意味や自分たちの品質担保について、お客様に説明できるようになろう
• テストに過度な期待をしない
• テストに完全はない
• どんなに優れた手法・技法を用い、どんなにコストをかけても、バグがゼロになることはあり得ない
• テストにかけられるコストには限りがある
• 各テストフェーズの目的、位置づけを明確にしよう。ここまでのことをやりました、という説明なのだから
• 各テストフェーズや、設計など他工程の役割を明確にし、お互いで補完しながら品質を高めよう
• やったことの評価（例えば、効率の評価）って、なかなかできないよね
• 特性に合わせたチェックリストをつくろう、ということだけど、BSP やドライバ開発の特性ってどんなものがあるのだろう
• テスト項目抽出の方針を持とう → 計画しよう、考えよう
• テスト資産の蓄積 → 自動化しよう、テストプログラムがあればやっぱり便利、可能な範囲でいい（手間と効果とのトレードオフ）
• テスト自動化の要件＝RISE
• テスト項目を間引く → リスク、重要度等から、優先度をつけよう → 計画しよう
• カバレッジは、網羅度の達成そのものが目的ではない
• 数値達成を目的にしない、品質はコントロールするものであり、数値結果はその材料
• ESQR の例にもあるように、測定値を元に、対策をとることが大事
• ESQR の「高品質作り込みのためのヒント」のテストのチェックリストより
  • #1　 楽しくテストをしているか → やっぱりメンタル面は大事、場づくりは PL の仕事
  • #12　テストですべての品質をおさえようとしていないか、テストに過度な期待を抱いていないか → テストの限界を知って、総合的に組み合わせた品質マネジメント計画を運用することが大事

こういう話をしようと思ったのは、（テストのやり方や評価基準と通して、）
プロジェクトの進め方が各プロジェクトにおまかせの今の状況をどう思うか、考えてみてほしかったから。

もちろんうちの会社だって、ある程度のプロセス標準を持っているし、
品質管理部門が、要所々々でレビューに入ることで、会社としての情報収集や指導等を行なっている。
もっときっちりした、ヘビーなプロセスを持つべき、という話でもない。ただ、

　　社内の他のプロジェクトがどうやってるのか、何もシェアできてないよね
　　「組織としての記憶」というものが蓄積されていないよね

ということをどう思うのか、少し考えてみてほしいと以前から思っていたからだ。

（「組織のプロセス資産」については、また別の機会に考えてみようと思う。）