WACATE 2022 冬 参加レポート (1/2)

1年前に存在を知り、ずっと気になっていた WACATE にようやく参加してきました。
このブログは、研修中にやったことや学んだことを、自分が思い出せるようにするためのレポートになります。1日目と2日目でレポートを分けます。これは1日目のレポートです。

 

当日のスケジュール
WACATE2022 冬プログラム - WACATE

 

セクション:オープニング <20分>

  • 感想
    • WACATE のコンセプトを丁寧に教えていただいた。コンセプトが明確になった状態で活動に参加できたので、集中して課題に取り組むことができた気がする。人を巻き込んで何かするときは、自分もこれくらい丁寧に説明しないとダメだよなぁと感じながらお話を聞いていた。
  • memo
    • 若手が積極的に活躍できる場がないという課題感から WACATE は始まった
    • 毎年、夏と冬に開催され、夏は一つのテーマを掘り下げるスタイル。冬は広いテーマを扱うスタイル

 

セクション:ポジションペーパーセッション<70分>

  • 感想
    • 背景や現状、目指したいことが文章化されたポジションペーパーは、コミュニケーションをする上ですごく便利だった。自分以外にもこんなことを考えている人がいるんだとか、そんな課題もあるのかなど知ることができて面白かった。誰かの自己紹介で"旗振り役"というワードが出てきたが、リーダーという表現よりも良いなと思い、今後自己紹介の時に使おうかなと思った。自分は2回目の自己紹介に躓きやすいという"パターン"を見つけ今後気を付けようと思った。
  • memo
    • テストをしない QA の方が数名おられた。テストは開発者が行い、QA はテストが行われているか、良いテストができているのか(観点の評価)、といったところに関与するスタイルらしい。どんな感じの業務になるのかもっと知りたい。
    • 感情の扱いに関心を持っておられる参加者をよく見かけた

セクション:BPPセッション<30分>

  • 感想
    • WACATE で学んだことをちゃんと実際の現場で活かすよう動かれていて素晴らしいと思った。どのように活かそうとしてどのように活きたのかをレポートにされていて、ちゃんとされているなと思った。見習う。

 

セクション:セッション1 (テストプロセスを用いて、テストケース作成の思考を整理しよう)<90分>

  • 感想
    • テストケースをリバースして評価する手法を知ることができてよかった。各テストフェーズで何をしないといけないかも改めて学ぶことができて良かった。悪い例(?)として提示されたテストケースの問題点として、テストする観点が暗黙的かつ、観点に対して適したテスト技法を適用できていなかった(境界値やパターンの洗い出しができていなかった)がありそうだと思った。テストケースの整理も大事だが、機能の整理も大事かもと思った。
  •  memo
    • 例えば 8*7-32/4 の計算をした時など、人によってプロセス(過程・工程)が異なる。
    • プロセスが細かいとレビューがしやすい。
    • デシジョンテーブルは仕様漏れに気づきやすい。テストケースはどんなテストをすればいいか分かりやすい。
    • 各テストフェーズでやること
      • テスト分析
        • 「何をテストするか」を考える
        • 箇条書きやマインドマップなどを活用する
        • 分析結果(テスト対象)に適用するアプローチ(テスト手法)を考える
      • テスト設計
      • テスト実装
        • テストの実行に必要なすべてを準備する
        • テスト自動化などもこのタイミングで行う
    • 「どれだけテストするか」はテスト計画で考える
    • テストの粒度を考える時はテストレベルを参考にする。テストレベルに対応した機能は現場によって異なる

 

セクション:セッション2(状態遷移テスト) <90分>

  • 感想
    • 状態遷移図や状態遷移表の書き方をシンプルに教えていただき、わかりやすかった。実際に作るワークも良かった。例えば A という状態と、B という状態と、A と B の状態が重なっている C という状態がある時、状態遷移図をどのように書くと良いか分からなかった。とりあえず、状態遷移図を分けて書いたが、正しいアプローチだったかは不明。nスイッチカバレッジというワードを知ることができてよかった。
  • memo
    • 状態遷移テストはシステムが複数の状態を持ち、イベント発生時の状態によって遷移先が異なる場合に有効
    • どのような状態があるのか、どのようなトリガーで遷移するのかを見ることができる
    • 考慮が漏れているパターンなどを洗い出すことができる
    • 状態遷移テストのやり方
      • ①仕様から状態とイベントを抜き出す
      • ②図(状態遷移図)を書いてみる
        • システム全体を俯瞰するのに有効
        • できるだけシンプルにまとめるとよい(複雑な場合は粒度を上げてみる)
      • ③マトリクス図(状態遷移表)を作る
        • 動作を網羅的に確認するのに有効
        • イベントが発生しても何も起きない場合と、そもそもイベントが発生しない場合とでは、結果は似ているが異なる状態なので、区別してテストした方がいい
    • nスイッチカバレッジは、画面遷移のカバレッジを測る指標
    • テストは0スイッチカバレッジが基本
    •  nスイッチカバレッジのカウント方法
      • 画面遷移後、画面遷移が発生したら1スイッチ

 

セクション:夜の分科会 <120分>

  • 感想
    • ディスカッションのフォーマットが無かったので、どう話をしたらいいかなとドキドキしたが、誰かに話してみたいことは大体話せたので満足。話したことに対して、別の現場で品質に関する取り組みをしている人からリアクションやアドバイスをいただけて良かった。ありがとうございます。
  • memo
    • エンジニアが自分でテストすると偏りが出る
    • JSTQBシラバスには結構良いこと書いてある
    • バグをたくさん見つけるのではなくシステムの品質を向上させることを目的にテストする(開発者に嫌がられないバグ報告のノウハウ。「消防ホース」の話)
    • ASTER標準テキスト に書いてあることも良い
    • シフトレフトの施策でテストをしない QA というのもある
      • テストの代わりにすること 
        • 仕様のレビュー
        • 不具合発生原因の分析
        • など
    • テストの漏れや内容が心配な場合は、開発者とお互いに取り組んでいるテストの情報交換するとよい
    • プログラマーは QA にコードを書くことは求めていないかも
      • 求めていること
        • 価値提供に必要な品質を知っている
        • 事業に支障が出るような問題を知っている
        • プログラマーの)認知の外のことに気づいてもらう動き
        • プロダクトをどう良くするといいか知っている
        • プロダクトの仕様を詳しく知っている
        • ドメイン知識
        • プロダクトの運用フロー
        • など

 

1日目のレポートは以上です。