このユニットでは、詳細設計をプログラムへ落とし込む「コーディング」と、コード品質を確かめる検証活動を学ぶ。レビューによる点検、デバッグによる欠陥修正、内部構造に着目したホワイトボックステストを『作って中身を検証する』流れとして理解する。頻出分野で工程と検証技法の関係がよく問われる。
詳細設計に基づき、プログラミング言語を用いて実際のプログラム(ソースコード)を作成する作業。
コーディングは、詳細設計でまとめた処理手順やアルゴリズムを、プログラミング言語の文法に従って具体的なソースコードへ書き起こす実装工程です。設計を「作る」段階の起点にあたります。 試験では、設計(何をどう作るかを決める)→コーディング(実際に書く)という順序関係が問われます。コーディング規約に従って読みやすく統一されたコードを書くと、後のレビューや保守がしやすくなる点も押さえましょう。
たとえ建築の設計図をもとに、大工が実際に木材を切り組み立てて家を建てる作業に似ています。図面(設計)を現実の形(コード)にする工程です。
記憶フックコーディングといえば設計をソースコードに書き起こす実装作業
作成したソースコードを他者が点検し、誤りや改善点を早期に見つける検証活動。
コードレビューは、書き上げたソースコードを開発者本人以外の人が読み、バグ・規約違反・分かりにくい記述などを指摘する検証活動です。プログラムを実行しなくても机上で欠陥を見つけられるのが特徴です。 試験では、テスト(実行して確認)と異なり、レビューは実行せずに点検する手法である点が問われます。欠陥を早い段階で発見できるほど修正費用が小さく済むという「早期発見の効果」も典型的な出題観点です。
たとえ書いた文章を提出前に同僚に読んでもらい、誤字や分かりにくい箇所を指摘してもらう校正のようなものです。自分では気づけない誤りが見つかります。
記憶フックコードレビューといえば実行せずコードを他者が点検する検証
開発者や関係者が集まり、成果物を共同で点検・評価して問題を洗い出す一般的なレビュー手法。
共同レビューは、開発者だけでなく利用者や関係者が一緒に成果物(設計書・コードなど)を確認し、合意を取りながら問題点を見つける活動です。共同レビューは関係者が共同で広範な成果物を評価するレビューで、コードレビューは対象をコードに絞ったレビューの一種です(両者は対象範囲が異なります)。 試験では、関係者が参画して認識を合わせ、欠陥を早期に発見する点が問われます。代表的なレビュー技法としてウォークスルー(作成者主導で説明しながら確認)やインスペクション(役割を決めて公式に検証)といった手法名も押さえると有利です。
たとえ発表前にチーム全員で資料を読み合わせ、内容のミスや認識のズレをその場で出し合う合同チェック会のようなものです。
記憶フック共同レビューといえば関係者が集まり成果物を点検する手法
プログラムに含まれる欠陥(バグ)の原因を特定し、修正する作業。
デバッグは、レビューやテストで見つかった不具合について、どこにどんな誤りがあるのか原因を突き止め、ソースコードを直す作業です。デバッガなどのツールを使って動きを追いながら原因箇所を絞り込みます。 試験では、テストが『欠陥を見つける』活動であるのに対し、デバッグは『見つかった欠陥の原因を特定し直す』活動だという役割の違いが問われます。テストとデバッグはセットで品質を高める点を押さえましょう。
たとえ家電が動かないとき、原因の部品を探り当てて交換・修理する作業に似ています。「故障に気づく」のがテスト、「直す」のがデバッグです。
記憶フックデバッグといえばバグの原因を特定して修正する作業
プログラムの内部構造(処理の流れや分岐)に着目し、論理が正しく動くかを検証するテスト技法。
ホワイトボックステストは、プログラムの内部のロジック(条件分岐や繰り返しなどの処理の流れ)に注目し、すべての経路や分岐がきちんと通るかを確認するテスト技法です。主に単体テスト工程で、内部を理解している開発者が行います。 試験では、内部構造を見ない「ブラックボックステスト」との対比が頻出です。網羅の度合いを測る基準として、命令網羅・分岐(判定)網羅などがあり、内部のすべての分岐を通すように設計する点が重要な出題観点です。
たとえ機械の内部を開けて、すべての歯車や配線が正しくつながり回るかを一つずつ確認する点検に似ています。外側からの動作確認ではなく中身を見ます。
記憶フックホワイトボックステストといえば内部構造に着目するテスト技法
関連の過去問演習は今後のアップデートで追加予定です。