mokky14's IT diary

IT関係の仕事メモ、勉強会の感想など書いてます。

仙台ソフトウェアテスト勉強会〜エンジニアのためのQA研修〜 のレポート

f:id:mokky14:20170129072503p:plain

GaiaxでWebシステムのQA(Quality Assurance)をやってる@sakaimoさんによるQAレクチャーのレポート。

講演内容(抜粋)

「あたりまえ品質」を担保するためにやること。

テストでやること

  1. 仕様を理解しながらどんなテストが必要かイメージする
  2. テストケースの作成
  3. テストを実施
  4. バグトラッキング

開発者の視点として

  • 作るものを正しくQAに伝えることは大切
  • ドキュメント化が基本だが、全ては表現できない
    • 密なコミュニケーションが必要
    • 意図や熱意の共有
  • 開発者からの情報が全て、の場合も多い
    • 整理して説明してもらわないとテスト漏れする
    • あなたの当たり前は私の当たり前じゃない、の精神

実際の業務では
「仕様(書)の不明点や抜け漏れをどれだけ 実装前に 指摘できるか」が大事。
後工程で見つかったバグほど、修正コストは高くなる。 リリース後の不具合修正コストは、リリース前とは比較にならない。

CRUD(Create/Read/Update/Delete)のD

仕様を考える人も、コードを書く人もDが抜けることが多い。(経験上)
言われなくても、作るときに発想して下さい。

  • SNSでアカウント削除したら、投稿、他人へのコメント、友だち関係はどうするの?
  • 投稿がシェアされてたら? イベントの主催者だったら?
  • 削除後、同じアカウントで再登録できるの?

ソフトウェアテスト7原則

  • 原則1:欠陥があることしか示せない
    欠陥がないことは証明できない
    「バグのないシステムを作って下さい」と言われても、「バグがない」事は証明できない
  • 原則2:全数テストは不可能
    組み合わせは膨大。テストの焦点を絞る
  • 原則3:初期にテストすべし
    開発サイクルのなるべく早いうちにテストすべし
  • 原則4:欠陥の偏在
    バグの大部分は特定の少数モジュールに集中する
  • 原則5:殺虫剤のパラドックス
    同じテストを繰り返していると、そのテストではバグが出なくなる
    バグが出なくなったから品質が良くなったとは限らない
  • 原則6:テストは条件次第
    ECサイトとゲームではテスト方法が異なる
  • 原則7:バグゼロの落とし穴
    バグを修正してもシステムが「使えない(使い物にからない)」のでは役に立たない

品質観点からのテスト分類

  • 機能要件
    • 機能テスト
  • 非機能要件

機能ばかりに目が行って、非機能観点の要件は忘れがちなので注意。

実行方法によるテスト分類

  • 動的テスト
    • テスト対象を動作させてみて結果を確認する
  • 静的テスト
    • ドキュメント、ソースコードを「見る」「読む」ことで確認する(レビューも含む)
      • コーディング規約
      • 静的解析ツール
      • ソースコードインスペクション

テスト手法による分類

  • ホワイトボックステスト
    • 制御・パステスト
      • 理経路をどれだけ網羅したか(カバレッジ)
        • 命令網羅(C0) 全ての命令文(statement)が少なくとも1度は実行されるように設計
        • 判定条件網羅(C1) 全ての判定条件において、真と偽が少なくとも1回は通るように設計
          このあたりが現実的に出来るところ
        • 条件網羅(C2) 全ての条件について結果(真・偽双方)が少なくとも1回を確認するように設計
  • ブラックボックステスト
    • 同値分割
      • 同じ結果になる値を同値グループとして扱い、試験パターンを減らす
    • 境界値分析
      • 同値グループの端の値について試験を行う
    • ディシジョンテーブル
      • 複数の条件の真・偽の組み合わせを表にする
      • それぞれの場合に対応する結果(行動)を示す

QAチームでやってるのはほぼブラックボックステスト

「なぜそのテストで充分なのか」説明できるか?

品質特性(ISO9126)として以下のものがある。

  • 機能性(正確さ、セキュリティ等)
  • 信頼性
  • 使用性(使いやすさ)
  • 効率(性能)
  • 保守性
  • 可用性

このうち、どこの品質特性を満たすか、的を絞る。
品質特性は、モノを作り始める前に使い、「このプロダクトで求める品質は何か?」を検討する。

どの品質を確認したいのかで内容は変わる。 使用性を担保するためのテストと、信頼性を担保するためのテストは中身が違う。
プロダクトとしての確保が必要な品質特性に応じ、テストを実施する。

往々にして「動けばOK=機能テスト」に目が行きがち。でも動くのは「当たり前」。

Q&A

  • 「使用性」のテストは属人化する事が多いが、何か良いやり方はあるか?
    • 「使いづらい」については、とりあえず意見を出してもらって、みんなで判断する
    • 周りのWebサービスを触ってみて「世の中の当たり前」を確認、自分の作ったサービスと比較してどうかを判断する
  • アジャイル開発を行ったとき、仕様書の作成に力を入れなか結果として、テスト担当から「仕様書がないので何をテストすればよいのか分からなかった」と言われた事があった。開発チームに求める仕様書とか作成基準はあったら教えて欲しい
    • 仕様書について、条件は特にない
    • アジャイル開発では、チケットに完了条件を書いて、この「完了条件」を満たせばチケットクローズになる
    • 完了条件を書くのはチケット担当になった 人。他の人が完了条件を追記することは可能

感想とか

人への指導や説明に使える枠組み(公的なもの)の情報が欲しかったので、今回の「なぜそのテストで充分なのか」の話が聞けたのは良かった。
最近関わった開発で「どこまでテストすればいいか」について各自の意識がバラバラだった事があり、どうやって意識合わせすれば良かったのかと思っていたが、そもそもプロダクトに求められる品質を明確化していなかったので、意識合わせをする元がなかった事が原因だった事に思い至った。

仕様書でバグを見つける事は同意。仕様書を見れば検討不足とかは良く分かる。非機能要件は特に漏れがち。
ひどいPJだと仕様書見ただけで炎上する事が分かったりする。テスト目的に限らず仕様書の確認は重要。
JaSST'2015東北でレビューの話聞いてたので、後で見返しておく。

メモ