6
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

estieAdvent Calendar 2021

Day 16

アジャイルテストについて学んでみた話

Last updated at Posted at 2021-12-15

こちらはestie Advent Calendar 2021の16日目の記事です。

はじめに

こんにちは!estieでQAエンジニアをしている粕谷 @machoです。
筋トレが大好きなことから社内では「まちょ」と呼ばれています。
(社内での筋肉キャラを死守すべく週5でジムに通っています)
前職では不動産業界を約6年ほど経験し、2021年6月よりestieにジョインしました。
エンジニア界隈では定番となっているAdvent Calendarですが、私自身今回が初めての参加となります!

今回のテーマ

今回は私の職種でもあるQAに関わりの強い「テスト」について書いていきたいと思います。
私がestieに入社し、未経験からQAエンジニアとして活動し始めもうすぐ半年が経ちます。
おかげさまで環境にも恵まれ、日々学びの多い時間を過ごしています。
この半年を振り返ってみると、QA経験のある方にアドバイザーになっていただきつつも、業務を通しての実践的学習が多めで、QAの体系的知識はまだまだインプット不足に感じます。
estieではアジャイル開発を取り入れているため、アジャイルテスト関連の書籍を読んでみようと思い探していたところ、以下の書籍に辿り着きました。

今回はこちらの書籍を読んで私なりの感想と、開発チームにどう活かせるかを考えていきたいと思います。

Agile Testing Condensed Japanese Editionの概要

本書は、Janet GregoryとLisa Crispin(テスト界隈で著名なお二方)による2019年9月発行の書籍『Agile Testing Condensed』の日本語翻訳版です。
(私は英語が苦手で絶賛克服中のためこれは大変ありがたい…)
@nihonbuson様、翻訳いただきありがとうございます!!!
タイトルにある通り、アジャイル開発においてどのような考えでテストを行うべきなのかが著者達の20年に渡る経験をもとに濃縮された1冊です。

読んでみての感想

冒頭に

この本は入門的なテスト用の本ではありません。
テスト、テスト自動化、DevOps、およびその他のトピックの基礎を学ぶために、多くの優れたリソースを利用できます。

とある通り、この一冊で体系立てて広い領域の基礎に触れることができました。
本自体のボリュームはそこまで多くないのですがとても読み応えがあります。
随所に参考となるURLリンクが配置されているため、更に詳細を学びたい場合はそこから飛ぶこともできます。
1周読んで身につけるというよりは、今の自分(チームや会社)に必要な情報を都度取り入れていくような使い方がよさそうと感じました。

読んでみて印象的だったのは以下の2つです。

  1. テストはQA業務の1つであるが、品質はチームの一員であれば誰もが担保することができるものだということ

  2. QAはチームの品質の接着剤となり、さまざまなタスクを受け持つということ

1つ目はまさしくで、テストというとリリース前の受け入れテストをイメージしがちですが、
本書に掲載されてるテストマニフェストの図にもあるように最後にテストするよりもずっとテストし続けること、
バグの発見よりもバグの防止が大切になります。
品質を保つことはチームメンバーであればどの職種でもどの開発フェーズでも常に意識し続けるべきです。
私自身、発見より防止とわかっているつもりでも潜在的に最後の受け入れテストに重きを置いてしまっているなぁと再認識しました。

image.png
引用元: Agile Testing Condensed Japanese Edition

2つ目は、品質の接着剤というフレーズがとても気に入りました。
アジャイルチームは、多様で職域を超えたものである必要があります。
つまり、どこかでサイロやボトルネックになることなくスピーディーに開発を回していかなければなりません。
そんなスピーディーな開発を行いながら品質を担保するためにメンバーと品質を接着するのがQAの役割となります。
年々、QAのタスクは多様化しており

  • UIテストの自動化、手動テストの実施
  • リリースマネジメント
  • プロダクトオーナーと協力し仕様検討、要件定義
  • 開発者と協力しユニットレベルのテスト戦略策定
  • SREと協力し非機能要件等、インフラレベルでのQA
  • チーム内での品質、テストに関する専門知識の共有
  • 場合によっては自らバグ修正、フィーチャーの実装
  • etc.

様々なユニットメンバーと関わりを持ちながら業務を行う必要があります。
こちらも私自身、今よりも更に横断的に動ける体制と知識を身につけていきたいと再認識させられました。

アロンアルファの様に強力で頼もしいQAになっていきたいと思います!

今後の開発に活かしたいこと

この書籍を読んでたくさんの学びがありました。
早速今後のチーム開発に取り入れ、いくつかアクションを起こしたいと考えました。

新たにチームに参加するメンバーと一緒に探索的テストを行う

新たなメンバーはプロダクトがどう振る舞うべきかについての先入観があまりなく、確証バイアスも強くありません。
JSTQBのシラバスにも似たようなことが書いてありますが、新鮮な目でプロダクトを触ってもらうことで
毎日プロダクトに触っているメンバーではバイアスが掛かり気付きづらいバグやUI/UXの課題が見えてくるのでは?と感じました。

モブプログラミングならぬモブテストorペアテストを行う

弊社ではリリース判定テストはスケジュールの都合がつけば基本QAがやることが多いです。
固定メンバーがテストを行うことでテストレベルが安定する一方、着眼点に偏りが出てきてしまいます。
せっかくチーム開発をしていて、そのチームメンバーはそれぞれの経験、癖、職種などからテストの着眼点が違うはずです。
その違いを活かしてこの課題を解消するのが本書で紹介されているモブテストorペアテストです。
チームメンバーとペアを組み、一人がドライバーをしながらもう一人が質問や提案を行うことで複数の観点でサービスを見ることができ、より効果的な探索テストができるのでは?と感じました。

テスト自動化ピラミッドに倣ったテストの自動化戦略

テストを自動化する際、多くのチームは主にUIテストから取り掛かり逆ピラミッド状態になってしまうと本書にあります。
まさしく私自身も上部のUIテストの自動化にばかり目が行ってしまっていました。
土台となるユニットテスト、統合テスト等を疎かにしていては細部の品質を保つことは難しいでしょう。
この辺りをソフトウェアエンジニアに任せっきりにするのではなく、協力して最善の戦略を考えて盤石な基盤を作っていきたいと思いました。

image.png
引用元: Agile Testing Condensed Japanese Edition

一人で読むのではなくチームで輪読、共有する

感想として書いた通り、品質は関与しているチームメンバーなら誰もが担保することのできるものです。
であれば、アジャイルテストへの理解はチームメンバーみんなが共通認識として持っているに越したことはありません。
この書籍を1から読み込むとなると時間がかかり過ぎるかもしれませんが、ミニマムで私が本書で学んだことの共有から始めていければと思います。

最後に

今回、改めてアジャイルテストについての書籍を読んでみて新しい学びもあり、実際の開発に対しての新しいアクションも見つけることができ、とてもいい機会となりました。
言わずもがなですがアジャイルテストの全てを一朝一夕に習得することは難しいため、定期的に本書に立ち戻りつつ、今後拡大していくサービスの品質を担保していきたいです。

現在estieではそんな急拡大していくサービスを品質保証してくQAエンジニアを大募集しております!
まだまだ改善余地のあるサービスの品質基盤を一緒に作り上げていきましょう!!
QAエンジニアに限らず全職種でメンバーを募集しておりますので、まずはカジュアルにお話ししましょう。お気軽にお問い合わせください!

明日はソフトウェアエンジニアの えりりんによる「RubyKaigi Takeout 2021 参加レポート」の予定です。お楽しみに!

6
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?