QAで発見されたバグは修正コストが高い

テストプレイで発見されたバグは、開発者に発見されたバグより修正コストが多くかかります。

テストプレイでバグが発見された場合、一般的に下記の手順で修正が行われます。

1. テストプレイでバグが発見される
2. バグ票に再現手順が記入され開発者に届けられる
3. バグ票を元に開発者がバグを再現する
4. 開発者がバグの修正を行う
5. バグを修正した事がバグ票に記入され発見者に届けられる
6. 発見者はバグが修正された事を確認する

順調に行った場合は、これだけの手順で済みますが、時々下記のような状況が発生します。

• バグ票の再現手順では再現しない。
• バグ票には修正された事として帰ってきたが、実際には修正されていない。

実際に開発者がソースコードやデータを確認するのではなく、テストプレイを実行する人が目で見たものを、ドキュメントに書いて報告するのには多くのコストがかかります。
また、報告されたバグ票を読んで、再現して、修正して、報告するのにもコストがかかります。
それに比べ、開発者が自分で見つけたり、同僚が問題のソースコードやデータを発見した場合は、自分で修正を行って報告を行えば良いだけです。
余計なコミュニケーションのロスは発生しません。

もしテストプレイにアプリケーションを渡す前に、ひとつでも多くのバグを修正できたら、テストプレイの作業を効率化する事が出来たなら、別の事に多くの時間を使う事が出来るかも知れません。

キャラクタープログラムのテスト

ゲームプログラムでのソフトウェアテストは難しいものとして認識されています。

画面上に表示された2Dキャラクターが、ゲームパッドのスティックを左右に入れる事により移動して、ボタンを押す事によりジャンプをする。
今回はキャラクタープログラムのテストを考えてみます。

バグが発生する仕組み

プログラマは毎回慎重にプログラムを作成していますが、如何しても一定数のバグが発生してしまいます。
そこで今回はバグが発生する仕組みについて考えて見ます。

規模の拡大に強い開発体制とは

今年のCEDECでは開発プロセスやプロジェクトマネージメントに関するセッションが多くありました。本当に多かった為に自分は全てのセッションを見れていません。

近年プロジェクトマネージメントが注目されて来た事もあり、安定したスケジュールでリリースを行うノウハウは共有されてきましたが、どうしても特定人物に負担が集まる傾向が何処でもあり、その解決の糸口になるセッションを探していた所、注目のセッションがありました。

「CEDEC2012」スケールアウトできる開発体制構築の取り組み
http://jcgs.co.jp/presentation/CEDEC2012-C12_P0206_public.pdf


とても、ためになる話が多かったのですが、規模の拡大を行う為に標準化で対応しようとしていた事が少し気にかかりました。

パフォーマンスエンジニアリング

コンピュータソフトウェアを作る上で、パフォーマンスが重要な分野はまだまだあります。
しかしパフォーマンス向上には、少なからずコストがかかります。
コストがかかると言う事は、かかるコストに対する効果を示せなければ、実際に実行に移す事が難くなります。
経験と感ではなく、統計と理論によりパフォーマンス向上させる事を、パフォーマンスエンジニアリングと呼びます。

マルチスレッドによるマルチコア

前回ではプログラマが並列処理をコントロールする事により、大きな処理性能の向上が図れる事を説明しましたが、マルチコアCPUを利用する時にも同様の事が言えます。

マルチコアCPUとは、CPUの機能を一つのチップ上に複数持っているCPUの事です。
マルチコアCPUは搭載されているコアの分だけ並列にプログラムを実行させる事が可能で、搭載されているコアを休み無く動作させる事により性能の向上が可能です。

現在は組み込み機器にもLinuxを初めとしたマルチスレッドに対応したOSが採用されており、マルチスレッドの機能を利用する事により、マルチコアCPUの性能を引き出す事が可能です。

よりコントロールされた並列処理のSIMD

今までの説明の中で、プログラマが意識しない場所で、並列化による高速化が行われてきた事を、説明しましたが、プログラマが書いたソースコードが並列化に向かない書かれ方がされている状況では、CPUが勝手に高速化するのにも限界があります。

その中でプログラマがコントロール可能な並列処理として登場したのが、SIMD(Single Instruction Multiple Data)です。