HOME > 開発者向けBLOG > Bryntum >  JavaScriptの品質保証 Part I

Technology Note 開発者向けBLOG

Bryntum

JavaScriptの品質保証 Part I

こんにちは、ゼノフィnakamuraです。

この記事は、Bryntum社ブログ JavaScript Quality Assurance pt.1 を翻訳したものです。

これは弊社のJavaScript製品に対する品質保証プロセスの内容についてのブログシリーズの最初の記事となります。我々が思うには、品質保証というものには、バグの扱い、チケットの扱い、テストケースの作成が含まれています。この記事の内容はどのソフトウェア開発にも関係ありますが、失敗しやすいJS/CSS開発に特につながります。失敗しやすい点を復習しましょう:

  1. 余分なカンマを入れてしまうとIEは落ちます。これを解決するウェブサイト http://trailingcomma.com/ まであります。
  2. varステートメントを忘れると、グローバル変数になる。
  3. CSSファイル内で4096以上のCSSセレクターを利用する。 詳しくはこちら

バグが広がる方法

大局的に見て、製品の開発プロセスで異なる段階でバグを発見する結果を検討しましょう。 最初は開発者の段階で細かく見て、その後は開発者の回りに引いて見ましょう。 例えばあなたの会社は他の企業に販売するソフトウェア製品を生成していて、その製品の中に最終的にエンドユーザーに売られるあなたが開発したソフトウェアが入っていることにしましょう。 この環境では、バグは次の段階で発見できます:

  1. あなたの開発コンピュータ
  2. あなたのチーム
  3. あなたの組織
  4. あなたのクライアント(あなたのような開発者)
  5. あなたのお客様のお客様:エンドユーザー

Tier 1. あなたの開発コンピュータ

これはあなたが中心となるローカルの世界、あなたの世界です。 ここではバグを発見するのは安価で、スピーディーです。 バグはあなたの世界の中に現れ、そのバグは気づかれないようにこっそり逃げ出そうとします。 手動、またはテストスイートを利用してコミットをテストしていると、あなたの世界の外側には安全な網がかかっています(下記の通り)。ただ、この時点でバグを100%止めることは不可能ですから、網には穴があいています。

ソースリポジトリにコミットする前に、ここでバグを発見するのがベストです。 もしここで見つけたら、正しいコンテキストに入っていますので、時間の無駄になる「タスク切り替え」の操作は不要となります。

バグ発見された場合のコスト:ゼロ。発見されました。これはあなただけの秘密です。

Tier 2. あなたのチーム

例えば、あなたの組織では複数のチームが最後の製品に関わる作業をするような体制をとっている場合には、次の段階はあなたのチームとなります。

もしあなたが作ったバグが自分の世界からチームの世界に逃げ出した場合、次のような出来事になる可能性があります:

  1. あなたの自動化しているCIテストスイートがバグを発見する
  2. あなたの同僚がバグに影響されて、チケットを作ってデバッグします:時間がかかります
  3. バグが未検出のまま発見されないこともあります

バグ発見された場合のコスト:低い。チームメンバーがデバッグにかけた時間のみ。

Tier 3. あなたの組織

ここでは、バグがあなたの世界とあなたのチームの世界から逃げ出したので、たぶん会社内のQAまたはステージングサーバーでリラックスしています。他のチームがあなたの(バグ付きの)チーム成果物からソースコードの最新版を引っ張って、統合したかもしれません。 もし運が良かったら、あなたの会社に最後の防衛線となるQAチームが存在しています。 ただ彼らがバグを発見すると、あなた自信の世界で発見するよりより高いコストがかかります。 ありえるシナリオは次のとおり。

  1. あなたの会社のQAテスターが発見します。チケットを開いて、テストケースを作成する:時間の無駄です。致命的な場合、ビルドは無効になります。公開も遅れる可能性があります。
  2. バグが未検出のまま発見されないこともあります

バグが発見された場合のコスト:高い。もしかしたら複数の事業部が関わる可能性がある。管理作業が行う必要があります。

Tier 4. あなたのクライアント

もしこの段階までにバグが発見されてなかったら、バグは公開バージョンの一部となっていますので、最終的にクライアントに納品されます。あなたのクライアントは自社でテストをするかもしれないし、しないかもしれません。 通常は複数のクライアントがいるので、クライアントが多いほど低い品質のビルドが公開されるとクレームが多くなります。もしクライアントがバグを発見しなかったら…はい、そうです:本当のエンドユーザーです。

バグ発見された場合のコスト:とても高い。もしかしたらあなたの会社がイメージダウン。

Tier 5. エンドユーザー

もしバグがクライアントの段階で発見されずに通った場合は、バグはホームランを打ったように喜ぶでしょう。 この段階でベストな結果はあなたのエンドユーザーがバグを全然体験しないことです。しかし、よりありえそうなシナリオは:

  1. ユーザーはバグを発見するけど、ただ我慢する。
  2. ユーザーは少しイライラして、あなたのクライアントにクレームする(そのクレームはクライアントからあなたの会社に転送されます)
  3. ユーザーがすごく怒って、その製品を使用するのを止める。

バグ発見された場合のコスト:最も高い。エンドユーザーがパッチを貰えるまで長く待つ可能性がある。あなたの会社とあなたのクライアントがイメージダウン。

まとめ

この例で明確になることは、バグが早く発見されるほど、それを解決するためにかかる費用、資源、時間、を削減できます。その上、怒っているユーザーからの電話やメール連絡の恥ずかしさも減ります。このシリーズのパート2では、Bryntum社では、どのように早くバグを発見して対策しているかを説明します。

PAGETOP