デバッグとは？方法と取り組み方、体制、テストエンジニアの仕事や将来性を解説

新しいWebサービスやアプリケーション、ゲームなどが次々生まれ、日々の生活を豊かに、楽しくしています。 生まれたばかりのアプリケーションやゲームがトラブルなく動くのは、販売やサービス開始に先立って、十分なテストやデバッグ行われているからです。 反対に、どれだけ良いプログラムも、バグだらけだとユーザーは離れてしまいます。 今回は、アプリケーションやゲームなどのソフトウェア開発のデバッグについて解説します。

デバッグとは

デバッグとは[/caption] デバッグとは、システムやアプリ（以降、システムと略す）を開発する際に、プログラムコード内のバグ（不具合）を見つけて修正する作業を指します。 理想としては、バグの全く無いプログラムを作ることですが、実は現実的では有りません。 コーディングしただけのプログラムが完全無欠でバグを一切含まないと思わないことが重要です。 例えば、プログラミング初心者が犯しがちですが、プログラムに求められる機能を果たす「正常系の作り込み」ばかりに気を取られ、それ以外（異常系）へ配慮が疎かにされがちです。 この結果、思考漏れや抜けが発生し、それがバグとなります。 これらは、ある程度の経験値を積めば回避できる部分もありますが、どれだけベテランであったとしても、バグは発生してしまうのです。 バグには、その原因を突き詰めてゆくと、コードの作成時に紛れ込んだものもありますが、コーディングする以前の設計書や仕様書に記載漏れや誤った指示に起因するものもあります。 また、構造が複雑なプログラムの場合、バグ修正のために手を加えると、予想外の所に波及して別の新しいバグを生むこともあります。 このため、分かりやすいプログラムを書き、バグを入れない、入っているバグを排除するように管理することがプログラム開発に求められます。

システム開発成功の鍵は開発工程の管理

システム開発には様々な工程があり、一般的には工程毎の管理が行われます。 このように、工程毎に管理し各工程でテストし不具合を解消することで、 ・出来上がったシステムが不具合だらけ ・予算オーバーや納期遅れ という失敗を招かないようにしています。

システム開発工程とデバッグ

システムの開発は「設計フェーズ」「製造フェーズ」に分かれており、ユーザ解放されて「利用フェーズ」に移ります。 設計フェーズには「要件定義」「基本設計」「詳細設計」などの工程があります。 「どんなシステムにするか」を企画・設計することからスタートして、システムの構成を考え、詳細なモジュールのレベルまでブレークダウンします。 設計フェーズでは、机上作業のレビューを行い、設計ミスや漏れを排除します。 製造フェーズには「プログラミング」「単体テスト」「結合テスト」「システムテスト」「運用テスト」などの工程があります。

製造フェーズとデバッグ

製造フェーズとデバッグ[/caption] ここでは、製造フェーズの工程を概観し、デバッグが誰によって、どのように行われているか見ていきましょう。 製造フェーズには以下の工程があります。 大規模なシステムの場合、単体テスト以降はテストエンジニアがデバッグに参加します。 テストエンジニアの仕事はバグやバグ原因の欠陥を探し当てる事です。 コードに手を入れて修正するのはプログラマーやシステムエンジニアの仕事です。

プログラミング工程

製造工程の最初の工程で、プログラム設計書に従って各モジュールのコードを作成します。 コード作成が終わったら、プログラマーが自身の作成したコードを目で追って問題や不整合がないか調べ、必要に応じて修正します。

単体テスト工程

コードレビューの終えたモジュールが対象です。 各モジュールを単独にコンピュータで動作させて、モジュール設計書に示された機能を持つか、指定された時間内に所定の動きをするかなどを確認します。 「デバッグコードの挿入」や「デバッガの利用」により動作をチェックします。 不具合が見つかったら、コードの修正を行います。

結合テスト工程

結合テストでは、単体テストが終わった新規モジュールや外部モジュールなどを結合して本番環境同様に組み合わせて、動作を検証します。 「デバッグコードの挿入」や「デバッガの利用」により動作をチェックします。 不具合が見つかったら、コードの修正を行います。 検証する内容は、 ・全体を通して正しく機能するか：実装ミスや機能不全 ・モジュール間のデータの受け渡しは大丈夫か：インターフェースのミス ・マルチスレッドなどの並列動作で不整合は起きていないか：タイミング制御不良 ・応答速度は基準に達しているか：性能不良 などです。

システムテスト工程

設計フェーズで作られた外部設計書や内部設計書に書かれている内容に従って、 ・他のプログラムと結合したり、 ・ネットワークと接続したり、 ・ユーザーインターフェースを確立したり、 ・所定の機器などを結合して システムを完成させた後に行うテスト工程です。 この工程で行うテストには以下のものがあります。 ・システムテスト：本番に近いシステム環境や疑似データを使うテストです。 →外部連携や想定される異常事態に対しエラー処理が適切になされているか、ユーザーインターフェースがユーザーの様々な操作に耐えられるかなどもテストします。 ・負荷テスト（性能テスト）：大量データや大量の同時アクセスなどでシステムに負荷をかけた場合にも、性能要件を満たすことを確認します。 これ以外には、実際にユーザーが使う時の操作シナリオを使って、その過程で不具合が無いかを調べる「シナリオテスト」や作り上げたプログラムに十分なセキュリティ対策が実装されているかどうかを確認する「セキュリティテスト」などもあります。

デバッグの技法

デバッグの技法[/caption] ここでは、デバッグの技法について説明します。

テストケースの作り方

テストケースとは「ソフトウェアのテストをどのように実施するか」を書いた手順書です。 【テストケースの種類】 ・正常系：想定入力に対して期待通りの出力をするか ・異常系：想定していない入力に対して問題なく対処できるか 【テスト漏れを防ぐ】 ・システムやビジネスに詳しいメンバーが参加してテストケースのレビューを行う 【不要なテストを減らす】 ・テストに詳しいメンバーにレビューに参加してもらい、チェックしてもらう。 ・同値分割：入力をグループ化して、同類のものは纏めて一件にする。 例えば、一桁の自然数の場合、0・6・10を入力してテストする。 ・ペアワイズ法：不具合は幾重にも重なると考えられますが、生起確率の高い「二重までの重なり」を想定してテストケースを作る。 ・エラー推測：経験上エラーが起きそうな箇所が分かれば、そこに的を絞る。

バグの再現条件を見つける

バグには確実に再現するものと再現しにくいものがあります。 まず、バグが確実に再現する条件を見つけましょう。 再現条件が分からなければ、バグの修正は不可能です。

不具合箇所を絞り込む

プログラムを走行させて動きをチェックすることで不具合箇所を絞り込む方法です。 大規模なプログラムでも、小さな機能ブロックに分割して作られているなら容易です。 例えば 「入力処理と演算処理は正常処理したが、出力処理の途中で不具合が起こった」 という具合に不具合箇所が絞り込めるからです。

デバッグコードを利用する

プログラムコード中の要所要所にデバッグコードを埋め込む方法です。 例えば、埋め込んだ場所を特定できるコードを埋め込んだプログラムを走行させれば、画面表示からプログラムが該当箇所を走行したことが分かります。 デバッグコードが画面に表示される順番から 「想定外の動きをしている」 ことや 「あるデバッグコードを出力した直後に異常停止した」 ことなどが分かり、不具合の解明が進みます。 要所要所でデバッグコード以外に変数の値を表示させることもあります。

デバッガを利用する

デバッガ（debugger）とはバグを見つける専用ソフトです。 デバッグする人を意味する「デバッガー」とは異なりますので注意して下さい。 このソフトを使えば、プログラムに手を加えることなく 「実行中の命令をハイライトさせたり、変数の値を表示させたり」 できます。 処理時間の長いプログラムでも、「希望位置までは通常処理させ、チェックしたい箇所だけワンステップずつ命令を実行できます」から効率良くデバッグを行うことができます。

バグを修正する

バグの原因箇所が特定できたら、コードを書き換えてプログラムを修正します。 コードの書き換え時に、新しくバグを挿入する危険もあります。 このため、コード修正後に再度テストして、期待通り動作するか確認しましょう。

デバッグ体制

デバッグ体制[/caption] 大規模なシステム開発の場合、システム開発全体を取り仕切るのはプロジェクトマネージャです。 その下に、テスト管理者がおり、テスト全体とエンジニアを管理します。 システム開発のテスト工程に関わるエンジニアのことをテストエンジニアと呼びます。 テストエンジニアの担当する業務内容は、 ・発生し得る不具合を予測して、最適なテストを計画・設計する ・実際にテストを行い、不具合を見つける ・開発者へ報告し、プログラムを修正してもらう など多岐にわたります。 中でもテスト計画・設計のできるテストエンジニアはテストのスペシャリストとして高い待遇を受けています。 なお、大きなプロジェクトの場合は専門のデバッガー（Debugger）やテスター（Tester）と呼ばれるテストエンジニアを投入することが多いです。 しかし、小さなシステムを開発する場合はプログラマーやシステムエンジニアだけで行うこともあります。

「テストを行い、不具合を見つける」という仕事

「テストを行い、不具合を見つける」仕事では、具体的にどのようなことをするのでしょうか。

仕様書や設計書通りに動作することを確認

仕様書や設計書に示された通りの操作をして、示された通りの結果になることを確認します。 正常処理ばかりで無く、例外処理や異常処理についても仕様書や設計書に示された通り動作することを確認します。

どのような操作してもエラーやバグが出ないことを確認

パソコンをユーザー端末にしているシステムの場合、キーボードやマウスが入力デバイスになります。 ユーザーインターフェースのテストでは、キーボードやマウスをどのように操作してもエラーやバグが出ないことを確認します。 次のような膨大な確認作業を、実際にキーボードやマウスを操作して行い、操作内容と結果を記録に残すことがテスターやデバッガ―の仕事です。 【ゲームの場合】 ゲームの利用者は乳幼児から大人まで極めて広範囲で、想定範囲を超えて利用される可能性があります。 このためユーザーインターフェースのテストは極めて広範囲です、 キーボードは100以上の選択肢を持つ、マウスは縦横無尽な動きをしますから、この組み合わせは膨大なものになります。 なお、ゲーム業界では「バグを見つける人」をデバッガーと呼ぶことが多いです。 【ゲーム以外の場合】 利用者の年齢層はゲームよりも高いですから、利用のされ方は或る程度想定できます。 マウスやタブを利用した入力欄への移動、入力欄に入力可能な文字種類や文字数、マウスによるボタン選択など或る程度限られた操作に重点を置いたチェックとなります。

テスターとデバッガ―の違いは？

デバッガーは、 単体テスト工程～システムテスト工程 の全工程に参加して、モジュールのレベルでバグを検出したり、バグの原因となる欠陥や誤りを特定し、プログラマーやシステムエンジニアに修正依頼します。 修正後もデバッグを繰り返し、バグが見つからないようにします。 テスターは、アプリが完成してから、完成したアプリを操作してバグを探すだけになり、業務範囲としてはテスターの方が狭くなります。

テストエンジニアの処遇・将来性

テストエンジニアの処遇・将来性[/caption] システム開発のテスト工程に関わるエンジニアをテストエンジニアといいますが、その処遇や将来性は能力により様々です。

テスト設計ができるテストエンジニア

テストエンジニアでもテスト設計ができる人には色々なキャリアパスが用意されています。 資格試験もあり、それに合格するために勉強することで、キャリアアップの助けになるスキルを身に付けることができます。

キャリアパス

・テストリーダー：テスト実施者→テスト設計者の次のステップ ・テストマネージャー：テストリーダーの次のステップ ・プロジェクトリーダーやプロジェクトマネージャー：高いITスキルや事務能力も必要 ・品質コンサルタント：業務系や組み込み系で品質確保・改善を支援 ・セキュリティ：ECサイトやWebサイトを不正アクセスから保護 ・テスト自動化（SET）エンジニア：テスト自動化・結果の分析・修正を担う ・ソフトウエアテストのスペシャリスト：組込分野や金融分野で多く活躍

資格

お薦めの資格は下記の4つです。 ・JSTQB認定テスト技術者資格 ・IT検証技術者認定試験（IVEC） ・基本情報処理技術者試験 ・ソフトウェア品質技術者資格 資格の取得には次のメリットがあります。 ・資格取得の際得た知識を業務に活かせる ・収入アップを目指せる ・キャリアアップを期待できる なお、資格取得のための勉強をすることで、 ・開発に関するスキル ・テスト環境を構築するスキル ・問題解決のスキル などが身に付くでしょう。

デバッガ―とテスター

先にも述べましたが、デバッガーとテスターは共に 「ソフトウエアのバグの叩き」 が仕事ですから、資格やプログラミングスキルなどは必要ありません。 テスト設計ができるテストエンジニアと比較すると、市場価値は低く、いわゆる「誰にでもできる仕事」とみなされることが多いです。 しかし、適性はありますので向いていない人はかなり業務的に苦労することが考えられます。 長期間デバッガーやテスターを続けることはおすすめできず、キャリアパスへの最初の足掛かりと捉えるべきでしょう。

キャリアパス

プログラマーやシステムエンジニアの見習いとして参加すれば、プログラム開発を実体験できます。 プログラミングの未経験者でも、プログラミングスクールなどでプログラミングスキルを身に付ければ、 「将来プログラマーやシステムエンジニアを目指す足がかりを得る」 ということは可能でしょう。 なお、プログラミング経験のある新卒者に、教育訓練の一環として採用直後の短い期間はプログラマーの見習いとして、テストエンジニアを経験させる企業もあります。

適性

【素早くメモする習慣】 バグを発見した場合、 「どのような操作をしたときにどのようなバグが発生したか」 を正しくプログラマーやシステムエンジニアに伝える必要があるからです。 【記憶力と集中力】 単純作業を長時間繰り返すことで意識が朦朧としがちです。 例えば、業務用システムで100項目を入力することができる画面があった場合、各項目が ・未入力でエラーが出ないか ・全角は入れられるか ・半角は入れられるか ・数値は入れられるか 上記4項目をチェックするだけでも、100×4で400テストパターンが生まれます。 テストが厳しい案件の場合、これらを全てスクショを撮ってエクセルにまとめる・・・ということもあります。 これには、単純作業でミスをしない集中力と「どこまでやったのか」を記憶しておく能力が必要になります。 【同じゲームなどを一日中操作し続ける根気強さ】 ゲームのテスターの場合、朝から晩まで同じゲームなどをひたすら操作し、記録するのが仕事です。 場合によっては、RPGが苦手なのにプレイを求められる・・・など、苦手な作業でも長時間のプレイが必要になります。

将来性

エラーやバグを確実に多く見つけるテスターやデバッガーなら収入も安定しています。 一方で、前述したように、「誰でもできる仕事」と認識される事も多いため、一生をテスターやデバッガーとしてキャリアプランを考えるのは、個人的におすすめは出来ません。 エンジニアとしての市場価値は上がらず、技術も身につきません。 履歴書に書けるような実績ができるわけでもなく、給料も高く有りません。 だからこそ、実務経験が無いエンジニアや新人が社内での実績や人間関係を作るために行う仕事と言う認識を持ち、その上でしっかりとエンジニアとしての勉強を続ける必要性があるでしょう。

テストエンジニアはAMELAに

テストエンジニアはAMELAに[/caption] 今回は、システム開発に欠かせないデバッグについてお話してきました。 テスターは、エンジニアとしての市場価値が付きにくい反面、スケジュール的に急に人数が必要になることも多いです。 もしも現在、テスターやデバッガーが必要になった場合は、是非AMELAにご相談いただければと思います。 AMELAではIT人材派遣も行っていますので、ピッタリの人材を紹介できる可能性があります。