ソフトウェアテスト293の原則(第6章/第7章)

ソフトウェアテスト293の鉄則

■■第6章 テストドキュメント

主に、IEEE829規格を採用したために失敗したプロジェクト（この規格ではなくても各社のフォーマットをただ使っただけのプロジェクトにも必ず言える）を例にドキュメントについて書かれている。
要は、必要なものを、必要なタイミングで、そのプロジェクトにあった形で取捨選択し、常にフレッシュさを保て。とごく当たり前のことを言っていらっしゃる。が、こうやってちゃんと定義？できると上とか説得しやすいだろうから、覚えておこ

■145：IEEE829標準規格も使い方次第
この規格には

• 不必要なものは一つもない
• 必須とされている項目は一つもない
• テストドキュメントの骨組み、構成、用語の定義を提供しているもの

■146：IEEE829標準規格の問題点を理解せよ

• 規格はウォータフォール的アプローチが下敷きなのでドキュメント維持コストがかかる
• 規格は、必要な情報の準備タイミングや分析方法については触れていない
• 規格全てを満たすドキュメント作成の工数の説明はない
• ドキュメントを作ることが目的のように取られがちに読めてしまう
• ドキュメントの良否判断について述べていない

■148：テストドキュメントの要件分析に役立つチェックリストを覚えておこう
紹介の2冊から抜粋してあるところから、気になったところだけリストアップ。本は読んでおきたいところ

• 仕様書/テスト仕様書への設計変更の反映は、どのくらいの頻度で行われるのか
• テストドキュメントに書くべきなのは、テストの目的か、それとも手順か
• 新人にテストを任せる時には、文書でどのようなサポートをすべきか

アイデアのおもちゃ箱―独創力を伸ばす発想トレーニング

要求仕様の探検学―設計に先立つ品質の作り込み

■149：テストドキュメントの核となる用件を最大三つに集約した要約文を作ってみよう
これ面白い！自分のところのドキュメントにこんな明確な説明がつけられるだろうか。これ何にも言えることだよね。使おう、使おう
下記は例

1. このDocは、「現バージョンのバグを見つけ」「作業の引継ぎに使い」「テスト状況の追跡」のために作成する
2. このDocは、「少なくとも10年に渡り、製品やテストの保守作業を支援し」「新しいメンバーのトレーニング資料となり」「公的規制や訴訟に備えるための記録を作成」するためのものである

■■第7章 プログラマとの協同作業

この章は、プログラマとの付き合い方。自分はプログラマだからなるほどーと思った。逆にテストチームの人がこうしてくれたらとても嬉しい。

■153：自らの誠実さと能力を示さずに技術的信頼関係など築けない
これは、PG⇒testerにも全く同じことがいえる

• 事実だけを報告
• 再現性がなくても、再現させようとした過程は記録
• 悪いニュースはまず本人に伝える
• 知ったかぶりをしない

■154：バグを憎んで人を憎まず
あたしには、これ難しいんだよな。要はバグは、個人や組織の弱点なのでそれを改善するのはマネージャの役目ということ。つい非難したくなる。難しい。