第21回Ques 参加レポート
こんにちは、QAエンジニアのとよしーです。
少し間が空いてしまいましたが11/17（金）に開催された第21回Quesにオフラインで参加してきました！
今回のテーマは「シフトレフト」。
その参加レポートをしたためようと思います。
実は自分はQuesに参加するのははじめてではなく、第17回のQuesにも参加していました。その頃はフロントエンドエンジニアとして働いていたんですが、障害発生率を抑えるためにQAの観点もインプットしようとしていたころだったと思います。
たしかその時はATDD（受け入れテスト駆動開発）について取り扱っていて、自分自身もATDDにチャレンジしようとしていたおぼろげな記憶があります。
その頃の自分からすると、まさかいまQAになるとは思いもしなかったので、
つくづくキャリアというものは予測できないことが多いなぁとしみじみしてます。
余談はさておき、自分にとっては2度目のQuesも勉強になることが多い回でした！
レポートと自分自身の感想をまとめてみたので読んでいただけると嬉しいです。
Honda RoadSync QAとして最初の一年での取り組み
発表者：ぱいんさん
スライドは公開されていなかったので概要をまとめます
きっかけ
リリースを高頻度にしたい
とはいえ、テストフェーズでの差し戻しが多い
という課題があった
なにをやったか
①レビューを工夫する
よくないレビュー事例
問題を指摘するためのレビュー会議
ドキュメントの体裁や形式の不備ばかり
問題の指摘そっちのけで技術談義をはじめてしまう
理想のレビュー
なぜレビューをするのかの目的設定
レビュアーとレビュイーに互いにメリットがある状態
レビューが開発の妨げにならない
課題
Devの人がテストコードを書いているけど品質が担保できているか自信がない状況だった
やったこと
改修内容を聞く会を開催した
そこでQA観点をヒアリングした
気にしたこと
何を直したか、何が不安か聞く
②テストを工夫する
アジャイル開発でのテストの難しいところ
リリースまで短期間
要件定義〜テスト結果報告までやる必要がある
ポイント
100%の網羅性を考えるのは限界がある
リリースの基準にあわせてテストの計画をする
課題
リリースサイクルが長くなると完璧さが求められること
やったこと
リグレッションテスト自体を減らす
リグレッションテストとはなにかを定義して必要なテストを定義
確認すること
必要最低限のユースケースシナリオ
法規、個人情報に直結する正常系の確認
確認しないこと
機能改修の内容
条件の組み合わせ確認
準正常系、異常系の確認
効果
テスト実行工数が半分になった
時間ができた分、個人の裁量でランダムテストをした
③不具合情報を活用する
目的
不具合ノウハウを活用したいため
やったこと
定例で今週のバグコーナーを開催（週に1個バグを紹介する）
その場にいる人が感想や質問、コメントをする
効果
他のメンバーのテスト設計/実行で気にしていることを学べた
④テスト戦略検討
課題
テスト条件の因子が定まっていない
いざテストするときに参考になると思ったため
今後、自分でテスト観点に気づけると思ったため
やったこと
検証端末の条件の整理
テスト観点表作成
作っている時は役に立った
でも活用されなかった…
QAの体幹強化
コアとなる技術
テスト設計
品質保証
コミュニケーション = 人から課題を引き出す能力
メンタリティ = めげない心
理由：アジャイルQAは品質、テストに関する依頼、相談に対応が求められるため
感想
レビューに関して「なぜ行うのか」は時々忘れがちになるので反省した
「リグレッションテストとはなんなのか？」「あなたの会社ではどういう位置付けなのか」という質問が来たら自信をもって答えられないことに気づいた。改めてリグレッションテストについて再定義してもいいかもと思った。
定例での今週のバグコーナーはいいなぁと思った。弊社でも最近、月1でバグ分析コーナーをDevの人に発表する場を設けたが、週一くらいのほうがフィードバックサイクルが早いというメリットがありそう。
QAの体幹強化で「コミュニケーション」について取り上げられていたが、やはり重要視されるスキルなんだなと思った。コミュニケーションというと「話す」スキルをイメージしてしまうが、どちらかというと「聞く」スキルのほうが求められるのではないかと思った。
シフトレフトにおけるシナリオテストの適用事例
発表者：Sammyさん
スライド
感想
シナリオテスト・シナリオベースドレビューについてよく知らなかったので勉強になったのと同時に、新卒で入った会社で一瞬だけQAをやっていたときに「シナリオテスト」を作らされていた記憶がよみがえった。そのときは特定のとてもでかめの企業の業務シナリオをもとにテストを作りつつも「なんでこんなことやらなあかんねん」と愚痴をこぼしていたが、いまになってQAの手法のひとつとしてはアリだなと思った。
スプリントレビューをシナリオベースでデモを行うのはとても良い方法に思えた。なるべくユーザーが使っているデータに近い形でデモをしたほうがいいといったことをどこかで聞いたことがあるので、それを満たせる形になりそう。
受け入れ基準が不明瞭な状態になってしまう課題は共感した。いかに振る舞いベースで記述すべきかと考えたりするが、そんなときにシナリオベースで考えるとより明瞭な受け入れ基準を定めるのに役立ちそうだと思った。
採用情報
株式会社iCAREのQAEチームは絶賛メンバーを募集しております！
ちなみに弊社のシフトレフトの取り組みとしては、機能を実装する前に仕様分析会をQAでファシリテートして、QA観点をPdMとエンジニアと一緒に出し合ったり、実装フェーズに入ってもエンジニアと密に連携をとりつつ早期からQA活動を進めております。
カジュアル面談も大歓迎なので、もし気になる方がいましたらぜひお話しましょう！
この記事が気に入ったらサポートをしてみませんか？