JaSST Review'18 S0,S1 (memo)

memo テスト

目次

このページの概要

一気に書き上げようと思ったら書ききれなかったので、S1,S2 と S3,S4 を分けることにしました。
今回は S1 (と S0 もちょこっと)。

参考リンク

JaSSTソフトウェアテストシンポジウム-JaSST Review'18 togetter.com

S0) オープニングセッション (ブロッコリーさん)

遅れて参加したので色々聞き損ねました。。
ブロッコリーさんから色々質問がありました。

  • レビューの技法 (チェックリスト / 固有の欠陥タイプに集中 / 視点(設計者、実装者)を決めてレビュー / アドホック) は普段どれを使ってる？
  • タイミング (適宜行う / 工程完了 / 開発者主体のレビュー)
  • どういう立場で普段レビューに参加しているか

S0) 私見

自分としては、それに答えることでいったいどういう立場で話を聞くのかを改めて認識できたのでよかったです。
あとは、自分が普段しているレビュー以外にも色々あるということが分かりました。

予稿集は読んでいたとはいえ、パネリストの方の紹介や、セッションの依頼内容について話があったのでこちらも聞くときに心構えができました。

S1) 講演 「設計レビューで問題を叩き出せ！～QAの役割～」

設計レビューのポイント：人事と人智を尽くす
よいレビューとは「できることをしっかりやること」

  • 現在の状況

    • 環境が変化して、スピード開発が求められるようになってきた(短納期といえども2，3 か月などの短さなので Agile とは違う)
    • 重い開発ルール、短納期、など悩みは尽きない

  • レビューは机上テスト

    • テストは書いてあることを動くことを確認
    • レビューは書いてないことを見つける
      • 書かれてないことがある、ことを見つけるのは難しい。(悪魔の証明)

  • 書かれていないことに、問題は潜む...

    • 社外発生(流出)不具合の割合 : 86% (仕様から見つけられない者の割合)
    • 検査検出不具合の 58% が記載なし

  • 開発者は気付いてないから書けない…

  • レビューの良しあしは「人」から「暗黙知」を引き出せるかどうか

  • 「設計」「テスト」＋「品質」の三つの枠組みでの検証レビューで品質確保

    • 計画要件ー実装まで：機能・テスト十分性検証レビューフェーズ
    • テストー検査(受入テスト)の間：品質十分性検証レビューフェーズ

  • 網羅する、より深く、より広く。視点を変えて設計をする

  • 開発部門とは異なる視点でテストする

  • ※全体的にテスト＝開発チームがやるテスト、検査＝QA部門がやるテスト

  • 品質特性的な点でもテストやレビューをする

    • テスト＝verification
    • 検査＝varidation
      • QA部門独自の観点
      • 障害時の復旧機能、原因調査資料の十分性

  • 探針？？日立独自のもの

    • 開発工程のテスト終盤で、QAが検査項目の「一部」を先行評価し、その品質状況分析結果から、以降の品質向上計画を決めるために行う
    • 作りこみ、見直し原因の二面に対し、動機的原因まで踏み込んで分析する
      • 要は、バグの偏在個所の推定？検討を行う
      • 見直しもする

  • 設計レビューのポイント：人事と人智を尽くす

  • よいレビューとは「できることをしっかりやること」

  • レビューアは自ら気付くべし！

  • レビューアは作成者とは違う視点で、思考を巡らせよう
    • 俯瞰する
    • 先見する
    • 想像する
  • 長い文章、あいまい語などなど注意している
  • レビューアは日和らない。発言し、気付かせるべし！
    ※勝手な解釈で指摘しないことのないように

  • チェックリストを過信しない

    • チェックリストはあくまでも過去起きたことがある問題などを形式知化したもの。
    • ないものは載ってない
    • 文章解釈は十人十色
    • 数が増えると思考停止する
    • チェックリストのウイークポイントを認識した運用が必要
    • 減らしたいが「将来同じ過ちをしないとは限らないので消したくない」という意図がある

  • 開発スタイルに合わせた、レビュー・テストの連携が重要

S1) 私見

自分が現在担当しているサービスとはちょっと重さも規模も段違いだったので即業務に反映できるなとはちょっと思えませんでした...
ただ、基本的な考えみたいなものはとても感慨深かったので、個人的にキニナルワードをピックアップしました。

  1. レビューは机上テスト
    • レビューは書いてないことを見つける
      • 多分誰もが心がけていることだし、普段テストを専門にしている人ならレビューに限らず、仕様を読み解く際も心がけていることと思います
      • この文脈でのレビューは、対開発者レビューだと思うのですが、私はこれをテストケースのレビュア側の心構えとしても受け取りました
      • 書いてあることが正しいことの確認だけでなく、出された項目に対して抜けがないかを見つけるのは結構シンドイですし、大変です
      • 意図を読み解く際に、見えない部分に気を配れるようになるといいなあと思いました
  2. レビューアは日和らない。発言し、気付かせるべし！
    • ここはきっとこういう意図だろうなあ、という想像で解釈するのは NG！という話
      • 現場でのレビューで、発言が少ない！という問題がありましたが、この日和が一つの原因じゃないかなあと感じました
  3. いわゆる市場不具合について、自分で確認・検査する
    • 見逃せば社外事故 : 責任感が高まる
    • 障害時の惨状を知る
      • 自分で顧客対応をしてもうやだ！行きたくないと思うことで、更に慎重になる
      • 顧客意見や考え方、想定していなかった使い方を知る : 視野が広く変わる
    • このあたりの話は恐らく我々テスト専門会社としてお客様先にいると立場的には難しいのかなあと思います。特に QA 部門にいたりすると。
      ただ、可能ならば同行させてもらったり、開発チームから詳細な情報を受け取ることで次へつなげることはできるのかなと思います。