2012年11月4日日曜日

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

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

テストプレイでバグが発見された場合、一般的に下記の手順で修正が行われます。
  1. テストプレイでバグが発見される
  2. バグ票に再現手順が記入され開発者に届けられる
  3. バグ票を元に開発者がバグを再現する
  4. 開発者がバグの修正を行う
  5. バグを修正した事がバグ票に記入され発見者に届けられる
  6. 発見者はバグが修正された事を確認する
順調に行った場合は、これだけの手順で済みますが、時々下記のような状況が発生します。
  • バグ票の再現手順では再現しない。
  • バグ票には修正された事として帰ってきたが、実際には修正されていない。
実際に開発者がソースコードやデータを確認するのではなく、テストプレイを実行する人が目で見たものを、ドキュメントに書いて報告するのには多くのコストがかかります。
また、報告されたバグ票を読んで、再現して、修正して、報告するのにもコストがかかります。
それに比べ、開発者が自分で見つけたり、同僚が問題のソースコードやデータを発見した場合は、自分で修正を行って報告を行えば良いだけです。
余計なコミュニケーションのロスは発生しません。

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

2012年10月21日日曜日

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

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

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

2012年10月14日日曜日

バグが発生する仕組み

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

2012年9月10日月曜日

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

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

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

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


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

2012年4月18日水曜日

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

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