ウォーターフォールの工程と各種テストについての勉強会資料

1. ソフトウェア開発工程と
テスト入門

2. テストに行く前に。
ソフトウェア開発のプロセスと工程について少しお話し
ます。

3. ソフトウェア開発プロセス。
ソフトウェアを開発していく時の進め方として、
いくつかの方法論、開発プロセスがあります。
プロセスというと難しく感じるかもしれませんが、簡単に言えば
どういう順番でシステム構築を進めるか、といった話です。
開発モデルなどとも呼ばれます。
代表的なものとして、以下のようなものがあります。
・ウォータフォール型（上から順に）
・プロトタイプ型（サンプル作って見せて直して）
・スパイラル型（小さなウォーターフォールの繰り返し）
・アジャイル型（XP、リーン、スクラムなど）

4. ソフトウェア開発プロセス。
これらの開発プロセスは、「情報処理技術者試験」の「基
本情報」でも触れられている基礎知識ですので、エンジニ
アならば予備知識として知っておきましょう。
基本情報資格はIT業界ではほとんどの会社で、新人が取得する様に推
奨される資格で、毎年２回実施されています。
これらの中で日本で昔から一番広く使われているものが
「ウォーターフォール型開発プロセス」
になります。
今回は、このウォーターフォールを例に説明します。

5. ウォーターフォール型とは。
ウォーターフォールでは、プロジェクト全体を
「要件定義」「基本設計」「詳細設計」、「製造（実装・コーディン
グ）」、「テスト」、「運用」、「保守」等の工程と呼ばれる単位に
分割します。
これらの分割された各工程を、１つ終わったら次と、順番に進めて
いくことで、システムを構築していく開発プロセスです。
WaterFallは滝です。
滝のように上から下へ、上流工程から下流工程まで開発を進めていく
ため、「ウォーターフォール」という名前が付けられています。

6. こんなイメージ。

7. 滝。。
(´・ω・｀)ｼｮﾎﾞｰﾝ

8. 各工程ではどんなことをするか。
要件定義：ユーザーの要求・要望を抽出し、システム化するうえでの
機能要件・非機能要件(ﾊﾞｯｸｱｯﾌﾟ方法、稼働時間etc)としてまとめます。
つくるもの：要件定義書とか。
基本設計：外部設計、概要設計などとも呼ばれます。要件定義書を
ベースに、画面のイメージを起こしたり、システムで出力する帳票を
設計したり、ユーザインタフェース（画面操作周り）やソフトウェアイ
ンタフェース（データ形式・やり取り）、システム間インタフェース（外
部・周辺システムとのやりとり）の仕様を起こしたりします。
ＤＢの論理設計（どんなテーブルが必要か）や機能分割（どんな機能に分
けるか）なども、ここに含まれます。
つくるもの：画面仕様書、帳票仕様書、インタフェース仕様書、機能仕様書
、ER図、コード設計書とか。

9. 各工程ではどんなことをするか。
詳細設計：内部設計、プログラム設計などが前後にきたり、そのもの
を意味することもあります。
基本設計書をもとに、プログラムを作れるレベル、より具体的なレベ
ルの設計を起こします。ＤＢの物理設計なども含まれます。
つくるもの：詳細設計書、エンティティ定義書（テーブル定義書）、ＤＢ物
理設計書など
製造：実装、コーディングなどとも呼ばれます。
詳細設計書をもとに、実際にプログラムを書きます。
つくるもの：ソースコード、スクリプト、実行ファイル（.exe）など
これをテストにあてはめます。

10. こんな関係になります。(Ｖ字モデル)
その工程で何を作るか、どんな範囲で成果物（アウトプット）を作るかに
より、どんなテストをするかが決まります。
それぞれ、上流工程と結びつけるとわかりやすいと思います。
対になっている上流工程が、テストで確認したいことを決めた工程です。

11. つまり、ざっくり言えば。
１つのプログラムが不具合がなく、正常に動くかどうか、詳細
設計どおりに作られているか確認するのが、
⇒ 単体テスト
単体テスト後、複数のプログラムをつなげて正常に動くかどう
か、基本設計どおりに動くかどうか確認するのが、
⇒ 結合テスト
システム全体として、きちんとユーザの要望、要求をみたして
いるかどうか、要件定義どおりの機能を実現できているか確認
するのが、
⇒ システムテスト

12. ほかにも。。。
総合テスト、ユーザーテスト、受け入れテスト、運用テスト、
セキュリティテスト、ユーザビリティテスト、
性能テスト、負荷テスト（ストレステスト）、
アドホックテスト（ランダムテスト）。。。。などなど。
テストの種類は、そのテストの目的によってたくさんあります。
代表的なものは前のページにあげた、単体テスト、結合テスト、シス
テムテストなどですが、自分が担当する工程によっても実際にテスト
をするかどうかは違ってきます。
とりあえず、単体テストと結合テストは覚えておくといいかなと思い
ます。

13. 人はなぜテストをするのか。
不具合のことをバグ（Bug）といいますが、
バグがないシステムはありません。
プログラムのミスだったり、設計書の誤りだったり、
ユーザーのお願い（要望・要件）をちゃんと聞けていなかったり、
その原因はさまざまです。
正常に動いても、それがユーザーの要望と違っていたら、
それは不具合でしかありません。
テストをすることで、これらの不具合をなくすことを目標にします。
そうすると、何をテストすればいいかは自然とわかります。

14. １点注意。
工程の呼び方や、種類、分かれ方は、会社・現場によって
違います！！。空気を読んであわせましょう。
基本設計
BD(Basic Design)、UI(User Interface Design)
詳細設計
DD(Detail Design)、PD(Program Design)、
SS(System Structure Design)、PS(Program Structure Design)
単体テスト
PT(Program Test)、 UT(Unit Test)、FT(Function Test)
結合テスト
IT(Integration Test)、SI(System Integration Test)
システムテスト
ST(System Test)、PT(Product Test)

15. 某ふじつうの開発プロセス。

16. 某みかかデータの開発プロセス。

17. 単体テストいくよぉ
ヽ(｡・｀ω´･)ﾉ！

18. 単体テストとは。
プログラムを書いたあとで、そのプログラムが仕様どおりに書かれて
いるか、仕様どおりに動くかどうか、異常終了や強制終了などしない
かどうか、作ったプログラムを１つ１つテストするのが、単体テスト
です。
やり方としては、大きく分けると２つあります。
１）画面（ブラウザなど）から、作ったプログラムを操作していろ
いろな値を入力したり、ボタンを押したりしてちゃんと動くかどうか
確認する
２）プログラムが正しく書かれているかどうかチェックするための
プログラムを書いて動作を確認する
２はちょっと難しいので、ここでは、１の例で説明します。

19. なにをつくるか。
画面を操作して確認する場合、作ったプログラムが正しく動くかどう
かを見るために、あらかじめ入力するパターンを考えておきます。
例えば、電卓アプリの場合、
「１＋１＝」とボタンをおしたら、２が表示されます。
「２＊３＝」と入力したら、６が表示されます。
入力する値と、その結果どう動けばいいか、
そのパターンを洗い出してExcelなどに書いていきます。
その１つ１つをテストケースといい、
それらを書いて並べたドキュメントを単体テスト仕様書といいます。
テストの結果や実施日などを書く場合は
単体テスト仕様書兼結果報告書などとも言います。

20. なにをかくか。
どんなテストをすればいいかは、仕様書・設計書を正として、
仕様どおりに動くかどうか、電卓なら
１＋１＝３ではなくて１＋１＝２となるかどうかなどを確認します。
テストケースとしては例えば、
「１＋１＝を入力した場合」や、
「１＋１を入力し、＝ボタンを押下した場合」などと書き、
想定結果として、
「２が表示されること」
などと書きます。
ほかに、実施日、テスト結果がOKかNGか、テストをした担当者名
などを書いたりします。記入例は後ほど。

21. どうやってつくるか。
「単体テスト仕様書」は、ほぼExcelで作りますが
そのフォーマットは、その現場で使っているものがあればそれに習っ
て同じように作ります。
指定のフォーマットがなければ、何をどんな観点でテストすればいい
かを担当者に確認するなどし、それを書けるようなフォーマット
（A４横とか）で自分で作成します。
どんなテストをすればいいかも、その現場の組織の文化や進め方、
そのプロェジェクトによっても様々なので、すべて同じフォーマット、
同じやりかたでOK、なんていうことはありません。
その辺は、臨機応変に対応する必要があります。

22. 方法論とか。
テストの方法論として、代表的なもの
・ブラックボックステスト
・ホワイトボックステスト
などがあります。
実際にはこの中間をとる、グレーボックス的なことも多いです。
ほかにも、テストの目的によってもどんなテストをするかは変わって
きます。
・ユーザーの要求が満たされているかどうかの確認
・不具合が正しく修正されているかどうかの確認
・追加仕様が正しく実装されているかどうかの確認
など、その時のテストの目的を考えるようにしましょう。

23. ブラックボックステスト。
ブラックボックス：ユーザー視点のテスト
入力する値によって、出力する値が正しいかどうかを確認する
テストで、中身の処理がどうなっているかは知らない状態で
ユーザ視点でテストを行います。結合テスト以降に多いです。
例えば、「電卓アプリの足し算」をテストしたい場合、
１＋１＝２です。（仕様）
この場合、
「入力が１と１の場合に、出力は２になることを確認」
といったテストをすることになります。
ブラックボックステストの場合、
どうやって２を計算しているかは考えません。

24. ブラックボックステスト。

25. ホワイトボックステスト。
ホワイトボックス：網羅性（カバレッジ）の確保を主眼としたテスト
こちらは、入力する値、出力する値だけでなく、中身の処理が正しい
かどうかを確認するテストです。
分岐処理や、繰り返し処理なども含め、プログラムの１行１行を
すべて通るようなテストをし、不具合なく動くことを確認します。
「電卓アプリ」をテストしたい場合でも、
「入力が１＋２の場合に、出力は３になることを確認」だけでなく、
「もし１ｘ２だったら」、「もし１÷２だったら」、などの分岐
（if文）がプログラムに書かれていた場合、それをすべて通るよう
なパターン分のテストをすることになります。

26. ホワイトボックステスト。

27. ホワイトボックステスト。
ただしすべての処理をとおっても、それが仕様どおりかどうかはまた
別の話で、仕様が間違っていたら不具合なので、仕様通りかどうかを
確認できるテストケースを詳細設計書などからつくる必要がありま
す。

28. テスト技法。
テスト技法とよばれる、テストケースをどうやって洗い出すかの方法もいろい
ろあります。今日は軽く。
・境界値、同値
例）「パスワードは８文字以上１６文字以下」
パスワードの文字数のパターン（境界値）⇒７、８、１６、１７
パスワードの文字数のパターン（同値）⇒１０、２０（条件の範囲内と外）
・デシジョンテーブル
条件とそれを満たすかどうか（満たす場合Ｙ、そうでない場合Ｎ）のルールを
表形式で並べ、その条件のときにどうなるべきかをケースとします。
例）年齢５０歳以上(条件)で男性の場合(ルール)、チケット半額(結果)
・組み合わせ（順列、組み合わせの。PとかCとかのあれ。）
「ｘｘが１で、ｘｘが２で、ｘｘが３の場合、こうなる」といった複数の条件
の組み合わせパターンが存在する場合、わかりやすく必要なパターンを洗い
出すために、直交表という表を記述します。

29. 同値と境界値。
4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

33. デシジョンテーブルの例

34. 単体テストの結果。
テストをしたら、そのテスト結果を記録として残すようにします。
このテスト結果の記録のことを、
「エビデンス」
といいます。意味は、「証拠」とか「根拠」とか。
エビデンスは、
テスト結果が表示されている画面（ブラウザ）のキャプチャ画像
だったり、
テスト実行前・実行後のデータベースのデータの内容
だったり、
その時によって、記録はとらない場合もあります。

35. かるぅく結合テストいくよぉ
ﾈｰ(*≧∀≦)(≧∀≦*)ﾈｰ♪

36. 結合テストとは。
「結合」という名前のとおり、単体テストが終わった複数のプログラムを組み
合わせた場合に、仕様どおりに連携して動くかどうか、ちゃんと別の画面に移
動するか（画面遷移）、プログラム同士でデータの受け渡しがちゃんとできて
いるか、異常終了や強制終了などしないかどうかなどを確認します。
単一のプログラムというよりも、それらを組み合わせたもう少し大きな機能と
いった単位でのテストになります。
また、外部システムやサブシステムとのやりとりをする部分のテストなども含
みます。（サブシステムは例えば受発注サブシステム、在庫管理サブシステム
など、システム全体の中の一部の機能です）
テストのやり方としては基本は画面（ブラウザなど）から、作ったプログラム
を操作していろいろな値を入力したり、ユーザーが操作するレベルでの確認作
業になります。

37. 結合テストとは。
テストケースの洗い出しは、基本設計ベースにユーザー操作の流れと複数の画
面のやりとり・画面遷移などを確認する観点で行います。
単体テストよりは粒度が大きくなりますが、テストデータは操作の流れが再現
できるようなものを事前に準備して（作って）おく必要があります。
例）見積入力後に受注入力の操作を行うパターン
①見積入力
・仕入商品の登録
・保守商品の登録
・単価の手入力商品を登録
↓
②受注入力
・見積入力の内容が表示されていることを確認

38. 結合テストとは。
結合テストのテストケース、もしくは「結合テスト仕様書兼結果報告書」を自
分で作成する機会は少ないかもしれません。
ですが、結合テストの実施だけならすることもあると思います。
結合テストの位置づけや、その書き方など単体とはだいぶ違うことに注意しま
しょう。
テスト仕様書のフォーマットは結合テストの性格上、単体と同じような書き方
ではなく機能同士のやりとりの確認や基本設計レベルの要件の確認が主となる
ため、もう少しシンプルになります。
「結合テスト仕様書兼結果報告書」も、その現場によってテストの粒度や書き
方も違うので、担当の人に確認してから作るようにしましょう。

41. いや、ないって。
未定！(`･ω･´)ｼｬｷｰﾝ
ご清聴ありがとうございました。