---

こんにちは〜

【読書】知識ゼロから学ぶソフトウェアテスト を読みました📖

知識ゼロから学ぶソフトウェアテスト 【改訂版】

知識ゼロから学ぶソフトウェアテスト 【改訂版】

読みました。

こちらのスライドを見て、ソフトウェアテストに興味が出たので読みました。
ソフトウェアテストを勉強して設計やマネジメントが上手になった話 #iijlab_seminar

大分前に読んだので、曖昧になっている部分がありますが、
気になった点をまとめていきたいと思います💨

目次

  • 1章 はじめに
  • 2章 ソフトウェアテストの基本―ホワイトボックステスト
  • 3章 エンジニアがもっともよく使う手法―ブラックボックステスト
  • 4章 探索的テスト
  • 5章 機能あらざるもののテスト、最難関のテストに挑む―非機能要求のテスト
  • 6章 ソフトウェアテスト運用の基本―テスト成功の方程式
  • 7章 ソフトウェア品質管理の基本―ソフトウェア品質のメトリックス
  • 8章 テストの自動化という悪魔―なぜ自動化は失敗するのか
  • 9章 それでもテストがうまくいかない人へ

テストでチェックすることは?

  • 4つの振る舞いをテストすればいい
    • 入力を処理する
    • 出力を処理する
    • 計算を行う
    • データを保存する

TDDについて

  • 基本は赤・緑・リファクター
    • 赤: 小さい失敗するテストを書く
    • 緑: テストが通るコードを書く
    • リファクター: 重複したコードの削除

数学的知識の有無

ソフトウェア開発者とは逆に、ソフトウェアテスト担当者は数学的知識の有無がその優秀の度合いに大きく左右する

テストケースの書き方

  • いつ、誰がやっても同じような結果が得られるように書くべき
  • テスト管理ツール導入すると、テストマネージャの仕事量は激減する
  • テストは重要な機能からテストする方がいい

納品前日にバグが発見された時の対処法

  • 「出荷基準」を設ける
    • 残存バグ件数が総件数の0.5%以内
    • テストケースの成功率99%
    • 長時間使用テスト(48時間使用)でハングアップが一度もない
  • 明らかに問題のあるバグ以外は、前日・当日に出た場合修正を思いとどまるべき

複雑度のメトリックス

  • 20以上は危険
  • McCabeのサイクロマチック数がおすすめ

テストがうまくいかない人へ

  • 組み合わせテストをやめる
    • 組み合わせテストは、テストケースが多いうえに組み合わせテストでしか見つからないバグは10%以下
  • おすすめテスト法
    • もし入力ダイアログボックスがあれば、境界値テスト
    • もし複数の入力ダイアログがあれば、ディシジョンテーブルテスト
    • もしダイアログボックスの遷移があれば、状態遷移テスト
  • 組み合わせテストで見つかるバグは、二つ以上のデータがあり、そのデータが離れた機能で使われている場合
  • Googleのバグ予測システム
    • 近々にたくさん編集されているかをファイルごとにカウント
    • 編集されている方がバグを生みやすい

感想とまとめ

基本的な内容がまとまっていて勉強になりました。

複雑度のメトリックスについては、RubyだとRubyCriticがあるようです。
参考: RubyCritic で Ruby のコードの品質を静的解析する

ちなみに、関わっているプロジェクトで実行してみたところ、ひどい結果でした。。
(バグを量産するはずだわ。。)