受託プロジェクトメモ。

　受託プロジェクトを初めて体験しました。経験不足でプロジェクト関係者にご迷惑をかけてしまいました。次回、同じ轍を踏まないよう整理しておきます。


□工程
　詳細設計から単体テスト実行までを行った。

　詳細設計
 　設計レビュー
　製造
　　コードレビュー
　単体テスト仕様書作成
　　単体テスト仕様書レビュー
　単体テスト実行
　結合テスト
　品質評価

□受託プロジェクトの感想。
　余裕のないスケジュールであり、これに起因する問題が多く生じた。
　スケジュール優先（特に初期の行程）のため、単体テストが結果的に手薄になった。
　　単体テスト実行する時間より単体テスト仕様書を作成する時間の方が圧倒的に長くかかった。
　　時間的な余裕がないため各工程で時間が不足していた。
　タスク内容と担当者のスキルの理解が不十分だったため、見積もりが不適切だった。
　　このため、各工程の品質が低下した。
　　担当者(私)のスキル(経験不足)が低かった(これ重要！)。
　少ないリソースで開発したため、各工程を同一人物で行うケースが多かった。
　　たとえば、単体テストを製造担当者が行った。
　単体テストの書き方チュートリアルがなかった。
　　未経験なので困った！
　単体テストにエビデンスが存在しなかった。
　　担当者任せ。単体テストレビューがない。
　詳細設計のレビューが、仕様のレビューになっていなかった。
　　実装時に再確認が必要になった。
　品質評価で不具合の分析を行い、その結果として単体テスト仕様書を修正した。
　　何のために？
　　解決しようとしているのが、今の問題か未来の問題かが不明。
　　品質レポート作成に２日費やすくらいなら製造・テストに２日費やす方が良いですよね。きっと品質も高くなるに違いない。

□問題点
　・属人性
　　単体テストが担当者まかせになっている点。レビューがない。
　・プロジェクト管理
　　タスクとリソースを理解し適切なスケジュールを設定していない。
　　初期段階ではある程度セレクトするが途中でリソースを獲得するのは難しい。
　・無意味なドキュメントをなくす
　　品質管理に必要な項目かどうか考える
　　だだし、これはお客様の都合(要件)に依存する。

□問題分析
　詳細設計者と製造担当者が同一人物のケース
　　メリット
　　　仕様がわかっているので製造時間が短くてすむ
　　デメリット
　　　仕様のチェックは緩い
　詳細設計者と製造担当者が別人のケース
　　メリット
　　　仕様のチェックは緩い
　　デメリット
　　　仕様がわかっているので製造時間が短くてすむ

□単体テストの書き方
　機能単位ごとに記載する
　　起こりえるケースを列挙する(MECE)。
　　分岐(if、switch文)
　　境界値チェック
　　同値地チェック

□参考資料
・単体テストにおけるCMM的アプローチ
　http://www.juse.or.jp/software/pdf/20_spc/8/7_b_report.pdf

　単体テストにおける属人性をテーマとしている。良い分析だが、組織で受け入れられるかどうかが問題。プロジェクトが失敗した場合に、責任を明らかにする必要がある場合どのようにするのか？

・ソフトウエアテストに求められている役割と課題
　第6回システム検証セミナー 2006.9.8
　http://www.veriserve.co.jp/jp/seminer/seminer_list/pdf/06.09.08_katayama.pdf


・短期・高品質に向けた単体テスト作業プロセスの改善
　http://www.jasst.jp/archives/jasst07e/pdf/A3-1.pdf

　確かに、テスト仕様書とJUnitのテストケースが連動するのがベストだが、運用できるのだろうか？

・現場ですぐ使えるソフトウエアテストツール
　http://www.jasst.jp/archives/jasst11t/pdf/s1.pdf

　便利なツールが無料で使えるが、ツールを使うことが目的にならないように注意する必要がある。たとえば、カバレッジを100%にするために、テストケースを増やすのはナンセンス。