見出し画像

QAEに移籍して1ヶ月のふりかえり

iCARE QAEチーム

はじめまして。iCAREのQAEチームのとよしーです。
7月末までOpsチームとSREを兼任していたのですが、8月からQAEチームに移籍しました。
この記事では、自分がQAEチームに移籍してからの

  • やったこと

  • 工夫した点

  • 学んだこと

  • 今後のアクション

のセクションで1ヶ月をふりかえろうと思います。

ちなみに自分は
フロントエンドエンジニア
↓
スクラムマスター
↓
Ops/SRE
↓
QAE
というキャリアの変遷を辿っています。
あとプライベートでは作曲家でもありDJでもあります。
このままでは器用貧乏なってしまう...（もうなってる）という心配はありつつも、立派なジェネラリストとして邁進していこうと思います。


● 1ヶ月でやったこと

とあるPJのテストプロセス

この1ヶ月で担当していたPJの
テスト分析→テスト設計→テストケース作成→テスト実行（with エンジニア）
のプロセスを実施しました

テスト分析では目的/ユースケース/リスク/複雑なところ/バリデーションになりそうな点についてマインドマップで表現したり、UIデザインや振る舞いの懸念点を洗い出しました。

マインドマップの例

テスト設計では、分析したものをテスト対象としてどこまでテストしていくかを掘り下げていきました。
もう一度不明瞭なところはマインドマップを書いたり、デシジョンテーブルを使ってパターンごとに洗い出したりします。
またこのフェーズでテスト実行の工数の見積もりも行いました。

テストケース作成では、設計したものを元に具体的なテストケースを実装していきました。
実装しているときに考慮漏れに気づく点も多くあり、このフェーズが一番大変なポイントでした。

テスト実行では、QAEだけでは非効率なのでエンジニアと協力して500~600個のテストケースを実施しました。


他PJのテスト設計・テストケースレビュー

QAEのメンバーの数が限られている状況のため、現在稼働しているすべてのPJのテストプロセスにがっつり携われないのが現状です。
そのため、他PJのQA担当のエンジニアがテスト設計やテストケース作成を実施し、QAEチームはそのレビューを行うという関わり方を実施しました。


ふりかえりの実施

QAEチームとして隔週でふりかえりを実施するようにしました。
チームとしての活動を徐々に改善していくために、まずは
やったこと/Keep/Problem/Try/Action
で良い点や問題点を可視化することを継続的に行いました。
「やったこと」を書いている理由は、Keep/Problem/Tryを書きやすくするための補助的な意味で可視化しています。
またTryとActionを分けている理由としては、Tryはアイデアベースのやってみたいことで、Actionでより具体的なアクションに落とし込むというプロセスを採用しています。

Figjamでのふりかえり

● 工夫した点

テスト実行時にエラーが出た場合、エラーログまで情報を提供した

テスト実行でエラーになったときに、エラーになった事象を明記するのは最低限必要だと思います。
ただ自分は元々エンジニアでもあったので、エンジニアが解決までのリードタイムを短くできればという思いでエラーログも情報として提供するようにアクションしました。


テスト設計/テストケースレビューをチェックリストベースで実施した

  • 自分のテストレビューがまだ不慣れなため観点に抜け漏れがある可能性があったこと

  • レビュー観点がメンバー間で大きくずれているとレビュワーとしての信頼性が損なわれる可能性があること

上記のような理由から、最低限ここはレビューとして見る観点としてチェックリストを作成しました。
チェックリストを満たしていること + 他に気になった点があればコメントをしていく方針に変えることで、最低限のレビュー品質を担保できるようになったと思います。


● 学んだこと

テスト分析・テスト設計のやり方

そもそもテスト分析やテスト設計自体のプロセスがはじめてだったので学ぶことはたくさんあったのですが、とくにマインドマップの観点について学びが深まりました。

実は前職でフロントエンドエンジニアをやっていたときも、自分たちでマインドマップを使用してテスト分析（っぽいこと）をしていました。その時やっていたことは、要件を洗い出すためのマインドマップなので、今回やった「目的」「ユースケース」「リスク」「複雑なところ」のような項目はやっていませんでした。
とくにリスクや複雑なところをマインドマップで可視化することで、インシデントのリスクを事前に認知できたり、複雑な仕様を会話による空中戦ではなくわかりやすく表現することで理解を促進できたので今後もKeepでいこうと思います。


バグは開発着手後に生まれるのではなく着手前にも生みだされていること

コミュニケーションによるチームメンバー間の仕様の認識の齟齬や、開発物、修正するものの受け入れ条件が不明瞭だと、成果物が「おもてたんとちがう！」となるケースがありました。
なので、いかにコミュニケーションの交通整理をするか、各タスクの受け入れ条件を書いて成果物の認識をそろえるかもバグ予防のためには大事だと思いました。


● 今後のアクション

受け入れ条件を書くプロセスを浸透させたい

学んだことにも書きましたが、受け入れ条件を書くことでゴールの認識がそろうメリットもあるのですが、QAEとしても各タスクの期待値がわかるので、テスト設計〜テストケース作成のときにもメリットがあるのではと思っています。開発者もQAEもWin-winな取り組みだと考えているのでアクションしようと思います。


Unitテスト・コンポーネントテストと手動テストの棲み分けの透明化

現在、Unitテスト・コンポーネントテストがどれくらい実装されているのか/いないのかが把握できていない部分があり、ここが把握できることで手動テストでやっていたものをUnitテストなどの自動テストで担保できるようになると考えています。
例えば、受け入れ条件で
・〇〇をクリックしたとき■■が表示されること | Unitテスト
・〇〇をスクロールしたとき△△が表示されること | 手動テスト
のように明文化できると、実装前にテスト手法の棲み分けができるのではと思い描いています。


● 採用についてのお知らせ

以上、1ヶ月のふりかえりでした。ここまで読んでくださりありがとうございました！

株式会社iCAREのQAEチームは絶賛メンバーを募集しております！
カジュアル面談もOKなので、もし気になる方がいましたらぜひお話しましょう！


またiCAREのQAEチームについてはメンバーのじゃっきーさんが執筆していますので是非読んでみてください！


この記事が気に入ったらサポートをしてみませんか？