こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
以下、Connpassのイベントページから引用です。
ソフトウェアテストの「つぎの一歩が見つかる、気づきと学びの場」 TEST Study シリーズ。 Forkwell はこれまで「つくり手と、未来を拓く。」というビジョンのもと、第一線を走るエンジニアから統合的な学びを得る勉強会を継続開催してまいりました。
インフラ、フロントエンド、機械学習と技術領域にフォーカスした題材を多く取り扱う一方で、ソフトウェアテストの様な普遍的なテーマについてはこれまであまり取り扱ってきませんでした。
そこで Forkwell はソフトウェアテスト自動化プラットフォームの「Autify」を提供するオーティファイ株式会社と共同でソフトウェアテストに関する勉強会を開催します。
Test Automation Specialist の末村 拓也氏にモデレーターを依頼し、テストに関する思想や向き合い方、具体的な技術論までソフトウェアテストに関する幅広い学びを提供する場としていく予定です。
全3回をかけて行い、各回のテーマに沿った第一線を走るエキスパートの方々にお話を伺っていきます。
会で印象的だったこと
LayerXの考える「開発速度」と「品質」、その中でQAチームの目指す姿
機能開発速度を上げるために
LayerXは、プロダクトの機能を作るスピードがめちゃくちゃ早いと言われることが多いそうですが、その理由として以下のようなものが挙がっていました。
- 全員がドメイン知識を貪欲に吸収している
- デザイナーがコードを自律的に書く
- とにかく動くものを作る
- チームに程よい緊張感がある
- 徹底的に設計する
フェーズごとの品質体制
探索フェーズでは激しい改修が続くため、ものを全部捨てて作り直すことも積極的にされているということです。その後のPMFフェーズでは、Autifyで自動テストを重要機能を中心に進め、運用フェーズに載ったところでは、全面的にE2EテストをAutifyで自動化し、ユニットテストも充実させているというお話でした。*1
PMFフェーズ以降では、Autifyをはじめとした自動化テストを導入することで、自動化に対する知識が少なくても効率的に品質を担保できるというお話がありました。
顧客への価値提供までのスピードを最大化する
どんなに上手に設計しても、機能を作った時点である程度負債になるので、本当に顧客にとって価値がある機能に絞って作るということでした。
抽象化を駆使しながら言われたものをそのまま作らないことを意識することで、めちゃくちゃシンプルな機能になることも結果として多いという話が面白かったです。
機能開発速度は、動くものが提供できるまでの速度ではなく、顧客が価値を感じるものを提供できるまでの速度だ、という話は非常に面白かったです。
QAチームの仕事
狭義の品質保証(バグ発見)に固執するのではなく、ドメイン知識を誰よりも持ち、顧客への価値提供を如何にして図るのか？ということを考えるのがQAチームだと思っているという力強いお話がありました。
パネルトーク+Q&A
以下、パネルトークやQ&Aで話されていた内容を箇条書きで書いていきます。
テスト自動化導入のコツは？
- マニュアルテストの削減がどれくらいできるのかを検証することが重要。
- 大きな目標を立てすぎない。継続性を大事にする。
- 費用対効果をすぐに出さない。最初は導入コストが大きくかかるので、なかなか費用対効果がすぐに出ることはない。
- ユーザーストーリーマッピングをまず書いてみる。
品質の定義
- 顧客が違和感を感じたら品質が低い、という理解はチーム内でできている
UXについてどのように考えるか？上流工程でFIXする？
- 実際に作ってみて使ってもらってみて、フィードバックループを素早く回すことを意識している。なので、上流工程でFIXすることはない。
- エンジニア、デザイナー、QAマネージャー、カスタマーサクセスチームといった風に、様々な役割の人たちがフィードバックを掛けてFIXする。
Android/iOS両方や古いOSバージョンのカバレッジを担保することって重要か？
- やりたくなる気持ちはわかるが、どれくらいシェア率があるのか？で優先度を下げたり、テスト対象から落とすことは必要。古いバージョンのOSに対してというよりは、Android/iOS両方でテストする方が重要な気はしている。
- スモークテストで壊れやすい機能だけ網羅する、という戦略はある
アジャイル開発ではテストコードはいつ書くのか？
- テストするのがしんどいところは早いタイミングからどんどんテストコードを書いていく
- 薄く広くでもいいから、最初からテストコードを書いていく
- 実際に変更の必要性が出てきたタイミングで、振る舞いの保護をするためにテストコードを書く
- 人数が増えたタイミングでコードを書く
E2Eがこれだけ充実しているのであればユニットテストは不要だと思わないか？
- こけた時のトレースがユニットテストの方が早いので、ユニットテストでできるならユニットテストを書いた方がいい
- 分岐が複雑なところはユニットテストの方が効率がいい
- 手元で素早く実行できるのでユニットテストが必要
- E2Eテストは粒度が粗いけど重要な部分に絞って行う
自動検証時間の長時間化を避けるためには？
- リグレッションテスト自体を定期的に見直してどんどん間引いていく
- リリースされた機能であまり利用されていないようなものは、リグレッションテストから間引くようにする
- ロジックの共通化をして間引いていく
- 小さい目標を積み立てていくことで、長時間化する速度を遅める
手動テストを自動テストに置き換えるコツは？
- シナリオテストよりに手動テストの手順を変える
- 仕様を把握している人が自動テストを作る
- 人間だからわかるニュアンスをなくす(ログインするんだったらメールアドレス入力必須だよね、みたいなのはなくす)
会全体を通した感想
基調講演もパネルトークもとっても面白かったです。
現場で実践されているからこそ出てくるよな、現実解的なアイデアが多く出ていたのは特に印象的でした。
