読者です 読者をやめる 読者になる 読者になる

QA勉強会に行ってきた #QAアーキ

12/20にQA勉強会に参加してきたので、印象に残ったことや思ったことなどを残しておく。
品質評価に焦点を当てた勉強会に参加したのは初めてだったかも。

connpass.com

テスト観点は意図を明らかにする

  • 仕様をなぞるのではなく、意図を明らかにするのがテスト観点
  • そのテストでは何を気にしているのか、意図を明らかにする
    • ✕: 1M以上のファイル、ファイルサイズによる挙動(仕様書のコピーにしかなっていない)
    • ◯: ディスクをいっぱいにして動かなくしたい(意図を明らかにする)
  • その意図は開発者が気にすることになる
  • 観点が正に開発者が気にすることにつながるので、開発・QAのコラボレーションがすごく期待できそう
  • 開発者が気になるけども、気付いていない観点をQAが出せるようになったらさらに素晴らしい
  • 観点洗い出しができるようになると、設計やレビューでQAが可能になる

品質保証を選択する

  • どのQA観点をどう作り込みどう検証するかまとめる→アシュアランスフロー
  • どこで何をするか整理すると品質保証が取捨選択できるようになる
    • 品質保証は選択ができないといけない
    • どこで何を保証するかが整理されていないといけない
  • 工程の責務が明らかになれば、自動化の注力先も分かる
  • 捨てる選択ができるようにするアプローチはイイネ!!

スピード感が求められる中でのアプローチ

時間があったので質問してみました。

質問
  • QA観点を洗い出して、アシュアランスフローに落とし込むのはとても有用だと思う
  • Webサービス開発のようにスピードが求められる場合、QA観点の段階から取捨選択が必要になるのではないか
  • そのあたりに何かアドバイスあれば
回答
  • 大切にしたいものによって、やり方は色々ある
  • 品質に網羅性を求めるのか、機動性を上げたいのか、開発能力を上げたいのかで異なる
  • 特にスピードが求められる現場であれば、「これはやらなくていいよね、大丈夫だよね」の納得感が得られるようなアプローチ
  • 妖精型
    • 気になるところや気にしているところを集めて整理していく
    • ティータイムを設けて、最近自分が出したバグを共有する会を設けているところもある
    • 決してプロセスを整理したりハンコを増やしたりするものではない

感想

とても有意義で面白かった。
QAと開発のコラボレートが具体的にイメージできるようになったのが一番の収穫かもしれない。

その他メモ

  • チェックを増やすと精度は下がる
  • (主に上層部批判の)組織論的な話が出るのはどこでもだなぁ
  • バグを出したら怒られる、っていうのが無駄なプロセスを増やす根源な気がした

資料

www.slideshare.net