情報処理技術者試験対策「ウォーターフォールモデルとＶ字モデル」

目次

https://1drv.ms/b/s!AivF3bzWXOzuhG1Xk5hscKYqkLkM

-------------------------------
次はソフトウェア開発のプロセスモデルについて書きます。
様々なプロセスが存在しますが、今回は最もメジャーなウォーターフォールモデルについて書きます。
日本でシステム開発をする場合、大部分のプロジェクトでウォーターフォールモデルが採用されており、試験だけでなく実務でも超メジャーな分野です。
　
ウォーターフォールモデルでは、実際にプログラムを作るまでは「要件定義（基本計画）」→「外部設計（基本設計）」→「内部設計・プログラム設計（詳細設計）」→「プログラミング（製造）」といった工程を踏みます。
ユーザの要求からスタートし、段階的に詳細化しシステム化の方針を決めるといった形で、トップダウンで開発を行います。
プログラムを作り終えてからは、「単体テスト(UT)」→「結合テスト(IT)」→「システムテスト(総合テスト、ST)」→「運用テスト(UAT)」といった工程を踏みます。
バグ頻発でテスト進行が妨げられることを防ぐために、細かい箇所からテストを行い徐々に統合するという形で、ボトムアップで開発を行います。
　
開発工程とテスト工程は、以下のように連関しています。
プログラミングの内容は単体テスト、内部設計・プログラム設計の内容は結合テスト、外部設計の内容はシステムテスト、要件定義の内容は運用テストで検証します。
これをＶ字モデルと呼びます。

 

誤りを修正する場合、後の工程になるほど手戻り工数が増え、修正コストが増大します。
（最悪なのは、リリース後に誤りが発見され、修正の必要が生じた場合です）
教科書的には、レビューを強化する等し、ある工程で埋め込んだ誤りはその工程の中でできる限り解消することが重要になります。
仮に後の工程で誤りが発見された場合は、その誤りについてなるべく早い段階で例外的に前工程に戻り、その誤りの修正に関わる要件・設計・実装を見直すことが重要になります。
大規模かつミッションクリティカルなシステム開発では特にこの原則を守ることが重要となります。
以下は東証のシステム更改の例で、前工程への手戻りを正式にプロセスに組み込むことで手戻り工数を削減する「フィードバック型Ｖ字モデル」が採用されました。

http://ac.nikkeibp.co.jp/cn/xdev10/pdf/10907-xdev-A-1.pdf

 　
なお、実務では、実現性が疑わしい箇所について開発開始前にプロトタイプを作成し、実現性をあらかじめ検証するという手法も使われます。
プロトタイプを作ることで、開発開始時に実現性の問題が出て手戻りが発生することを防ぐことができます。
　
ざっくりまとめると、先が見える場合は１つ１つの作業を確実にこなす、先が見えない場合は先回りして視界を良好にする、という姿勢がプロジェクトを進行する上で重要になります。

情報処理技術者試験対策「システムテストや同時期に実施するテスト」

目次

https://1drv.ms/b/s!AivF3bzWXOzuhG1Xk5hscKYqkLkM

-------------------------------
テストについては一通り書こうと思います。
今回は、システムテストについてです。
あまり面白いことは書けませんが…。
　
システムテストは結合テストの後に開発部隊が行うテストであり、システムが要件を満たしていることを確認するためのテストです。
以下の２つの要件を満たしていることを確認します。
（なお、バグの原因切り分けを容易にするため、モジュール単独で検証できることは前工程で行う必要があります。例えば、性能テストに関して、SQL単独の性能計測は単体テストの範囲です。）

• 機能要件
  システムが提供する機能に関する要件。
  ユーザインターフェースやその裏側の業務処理等。
  実運用を想定し、シナリオテストや実時刻テストを行うことにより検証する。
  　
• 非機能要件
  機能要件を実現するための土台として必要になる要件。
  性能テスト、負荷テスト、セキュリティテスト等により検証する。

また、本番環境でのテストもシステムテストで行う必要があります。
テスト環境と本番環境で環境差異（関連モジュールやライブラリのバージョン差異、ネットワーク構成の差異等）がある可能性があり、それがシステムの機能に影響を及ぼす可能性があるためです。
サービス提供時間にテストを行うことはできないため、サービス提供時間外にテストを行うことになります。
場合によっては、テストのために例外的にサービス停止することも検討します。
　
ついでに説明しますが、ユーザ部門による運用テストも同フェーズで実施します。
運用テストでは、開発されたシステムで実運用できるかを検証します。
また、保守開発（本番サービス中のシステムに対する改修）の場合は、リグレッションテスト（退行テスト）も実施します。
リグレッションテストは改修した箇所が他の箇所（現行サービスで問題なく提供できている機能）に影響を及ぼしていないかを確認するためのテストで、同一のインプットで同一のアウトプットが出ることを確認します（現新比較）。

情報処理技術者試験対策「結合テストの進め方（スタブ・ドライバ）」

目次

https://1drv.ms/b/s!AivF3bzWXOzuhG1Xk5hscKYqkLkM
-------------------------------
せっかく単体テストについて書いたので、次は結合テストについて書きます。
主にスタブとドライバについて書きます。
　
結合テストは、モジュール間の整合性を検証するために行います。
モジュール間でインターフェースの実装に相違がないか、業務データの取り扱いに相違がないか、といった所を中心に見ることになります。
モジュール単独の品質が担保されていないと、バグ発生時に原因の切り分けが困難になったり、結合テストで本来検証するべきこと（モジュール間の整合性確認）が検証できなくなったりして工数がかさみますので、単体テストでモジュール単独の品質を担保することが前提になります。
　
連携するモジュールが未完成（単体テストで品質を担保する所まで行っていない）場合は、仮のモジュールであるスタブやドライバを使って当面の間はテストを継続することになります。

• スタブ
  下位モジュール（呼び出される側）の代わりとなるモジュール。値を返却するだけ等の形で簡単に実装する。
• ドライバ
  上位モジュール（呼び出す側）の代わりとなるモジュール。処理を呼び出して返却値を表示するだけ等の形で簡単に実装する。

スタブやドライバを作成すれば、連携するモジュールが未完成でも、完成したモジュールから先に結合テストを進めることができます。
スタブやドライバの実装が単純であればスタブやドライバにバグが潜んでいる可能性も低くなるので、バグ発生時にはテスト対象のモジュールに問題があると推測することができ、原因切り分けが容易になります。
　
教科書的には、スタブはトップダウンテスト、ドライバはボトムアップテストで用いられ、トップダウンテストは原因切り分けが容易だが並行してテストを進められない、ボトムアップテストはその逆とされています。
が、実務の上でこのことを意識したことはありません。
（ボトムアップテストでもトップダウンテストでも、状況に応じてまとめてテストしたり１つ１つ着実にテストしたりするので）

情報処理技術者試験対策「ブラックボックステストのテストケース設定」

目次

https://1drv.ms/b/s!AivF3bzWXOzuhG1Xk5hscKYqkLkM

-------------------------------
前回の記事で予告した通り、今回はブラックボックステストの話をします。
　
ある変数の値の大小により分岐が行われる場合に、下記の２つの考え方によりテスト設計を行います。

• 同値分割
  各々の分岐先について、任意の値を一つ抽出し代表値として採用する。
  （怖い上司度≧6か否かで分岐が行われる場合、怖い上司度が5以下の任意の値のケースと、怖い上司度が6以上の任意の値のケースでテストする）
• 境界値分析
  分岐先が変わる境界となる値を代表値として採用する。
  （怖い上司度≧6か否かで分岐が行われる場合、怖い上司度=5のケースと怖い上司度=6のケースでテストする）

試験対策としては以上を覚えておけば良いのですが、バグは境界値で起こる可能性が高いことから、実務では境界値分析しか使いません。
また、テストケースも2ケースでは不十分で、実務では定数項-1、定数項と同じ、定数項+1の3ケースでテストすることが望ましいです。
（コーディングミスで≧を＝と書いてしまった場合に、2ケースでは見つからないことがあります（というかありました）。怖い上司度の例だと、怖い上司度=7のケースをテストしないとミスが見つかりません。）
　
前回の記事の繰り返しになるのですが、実務では複数の判定条件の組み合わせを考える必要がある場合があります。
この場合、組み合わせを漏らさないようにするためには、デシジョンテーブルを作成することが有効です。
例えば、以下のような例の場合、

以下のようにデシジョンテーブルを作る必要があります。
（3×2×2=12通りの組み合わせを記述）

実際に全ての組み合わせをテストするわけではないですし、実際にはデシジョンテーブル作成時にいくつかのケースを端折ったりするのですが、慣れない内は全組み合わせをデシジョンテーブルに書くべきです。
デシジョンテーブルに全組み合わせを記述しておけば、必要なテストケースを選定する時に頭が整理されますし、他の人（先輩や有識者）に見てもらうこともできます。

情報処理技術者試験対策「ホワイトボックステストのテストケース設定」

目次

https://1drv.ms/b/s!AivF3bzWXOzuhG1Xk5hscKYqkLkM

-------------------------------
新人に単体テストを任せると大抵テスト漏れでやらかして同じような指導をしているので…これを期に今まで指導してきた内容を記事として残します。
ブラックボックステストについては次回の記事で説明するとして、今回はホワイトボックステストの話をします。
　
例として、以下のような分岐を考えます。
自分の責任で遅刻した時（迷子や寝坊）に言い訳をする処理です。

ホワイトボックステストのテストケースの設定方法としては、以下のものがあります。
・命令網羅
　全ての命令を1回以上実行

・判定条件網羅(分岐網羅)
　全ての経路を1回以上通過
・条件網羅
　判定条件中の全ての条件について真/偽それぞれ実行
・判定条件/条件網羅
　判定条件網羅＋条件網羅
・複数条件網羅
　判定条件中の条件の全ての組み合わせを網羅
　
今回の例では、それぞれ以下のようなテストケースの設定となります。
　
ちなみに、カバレージツールは、テストケースの網羅性を客観的に判断するために使用します。
大抵のカバレージツールでは、C0カバレージとC1カバレージを計測します。
C0は命令網羅、C1は判定条件網羅を計測します。
原則としてカバレージは100%を達成する必要があります。
（ただし、単体テストでは発生しない例外条件がある等の理由で100%を必達としない現場はあります）
しかし、仮にC0・C1が共に100%だったとしても、必要なテストが網羅されたわけではないということは上記の例を見れば明らかだと思います。
カバレージ的には、寝坊フラグ=trueのケースをテストしなくてもOKということになってしまいますが、カバレージの結果だけを見て単体テスト完了としてしまうと後で痛い目を見ます。
例えば、いつもの集合場所で待ち合わせる場合にも「いやぁ道が入り組んでて…」という言い訳を返すバグが総合テストで見つかったり…。
そうならないために、プログラムの目的を理解した上で、必要なテストケースを各自の判断で盛り込む必要があります。
　
なお、今回は一つの判定条件に注目しましたが、実際にテストケースを考える時は複数の判定条件の組み合わせを考える必要がある場合もあります。
例えば、以下のような例の場合、怖い上司かどうかで言い訳関数の挙動が変わるかどうかも見る必要が出てきます。
（怖い上司の時にしっかりとした言い訳を返してくれるか気になりますよね…？）

ただし、ある判定条件の結果が別の判定条件の結果に影響を及ぼさないなら、判定条件の組み合わせを考える必要がありません。
上の例で怖い上司の判定条件の代わりに今日の運勢の判定条件であれば、（運勢次第で言い訳を変える人でなければ）この２つの判定条件の組み合わせを考える必要はありません。

情報処理技術者試験の出題分野の目次

情報処理技術者試験対策の記事を書くにあたり、ひとまず出題分野の目次を作成しました。

今後、記事を上げる度に、目次にリンクを追加していきます。

https://1drv.ms/b/s!AivF3bzWXOzuhG1Xk5hscKYqkLkM

改めて書き出してみると、ハードウェアから経営学まで、本当に広い分野の知識を求められていますね。

これらの出題分野について理解していれば、（IT業界で生きていく上では）どのような業務にあたっても他の人より前の位置からスタートできますし、他の業務の人と話す時にも共通言語で話すことができるようになります。

合格を目的にするのであれば、午前問題でしか問われないような分野や午後の選択式問題で逃げられる分野については過去問を丸暗記するだけで十分なのですが、それでは勿体ないと思っています。