(某ウルルン滞在記風に)

マイクロサービスのスクラムチームと聞いて、みなさんはどんなイメージを浮かべるでしょうか？
アーキテクチャが難しそう？ 全体像がイメージしにくそう？ そもそもスクラムじゃなくてもいいんじゃない？

昨年、私は立ち上げから間もないスクラムチームが開発しているマイクロサービスの品質保証について相談を受け、そのままQA担当者として3ヶ月ほど一緒に過ごしました。
マイクロサービスを “利用する側” のプロダクトしか経験したことがなく、そもそもAPIテスト自体ほどんどやったことがない。そんな自分が悩みながら駆け抜けた日々についてお話します。

「QAさんからバグを指摘されたので、このバックログアイテムはDoneにできませんでした」
これはQAエンジニアである私が度々出会う、最もモヤッとする言葉です。

なぜこのような発言が出るのでしょうか？

これはテストによって発生したフィードバックを、開発者が「差し込みで発生した作業」と捉えてしまうからではないかと考えています。自分の手で実装したものなのに、自分ごとにできなくなってしまう瞬間があるのです。

開発者の実装が完了した後、1Sprint遅れでQAエンジニアがテストを行うやり方を採用しているアジャイルチームを時折見かけます。これはあまり推奨できるやり方ではありません。
QAチームがテストを実施している頃、開発チームの心はすでに後続のバックログに向いていて、テスト対象となっているアイテムは「すでに終わったもの」と認識しているからです。

しかし、たとえ1Sprintの中で実装からテストまで行ったところで状況は変わらないでしょう。「QAにテストを任せた瞬間に心が離れてしまう」という点は同じだからです。

また、QAエンジニア自身にも甘えや油断が発生しているのではないでしょうか？
あるバックログに対して要件に不明な点があったとき「これはテストをするときに確認すればいいか」と解決を先延ばしにしてしまうことがあります。やがてそれがSprintの終盤にバグとなって吹き出すのです。

考えられる解決手段は2つあります。

1. 開発者自身でテストを行うこと
2. 実装に着手する前に、要件の解像度を上げること

今回は後者についてお話ししたいと思います。

バグの多くは、要件の認識ずれによって引き起こされます。
そしてその認識ずれは、プロダクトに関わる各ロール (PO、開発者、デザイナー、QA、etc.) が細かく対話を重ねることで解消できるものも多いでしょう。

テストだけが品質保証の手段にあらず。
重厚なテストに頼りすぎず、より早い段階で対話を重ねることで品質を担保するチームにシフトしていきませんか。

2020年4月に『Agile Testing Condensed Japanese Edition (以下、Condensed日本語版)』の初版が公開されてから2年が経ちました。
この本はQAエンジニアやテストエンジニアの当事者に限らず多くのアジャイル実践者に読まれ、年々ポピュラーな1冊となりつつあります。

ところで、原作者2名による最初の著作『実践アジャイルテスト』を読んだことはありますか？

『Condensed日本語版』が発行される数ヶ月前、駆け出しのQAエンジニアだった私は『実践アジャイルテスト』に出会いました。そこに書かれていたのはアジャイル開発の世界に入ったテスターが直面する困惑と抵抗、それを乗り越えて築かれた数々のプラクティスでした。

『Condensed日本語版』にももちろんそのプラクティスは受け継がれていますが、『実践アジャイルテスト』とは異なる目的のもと構成されています。

"この本の目標は、テストを成功させてアジャイルな状況で質の高い文化を作り込む方法について基本的な理解を得るために誰でも手に入れることができる、小さく簡潔で読みやすい本を作成することでした。(中略)
これは、アジャイルを採用しているチームにいる読者、またはテストや品質がアジャイル開発にどのようにフィットし、マネージャーや経営層などのガイダンスを探しているかを知りたい読者向けです。"
(『Condensed日本語版』序文「なぜこの本があるのですか？」より)

この序文からも分かる通り、メインターゲットは品質保証の専門家を迎え入れるアジャイルチームの人たちや、マネジメント・経営層の人たちです。そのためテストエンジニア・QAエンジニアの当事者が身につけておくべきスキルやマインドセットについては、各々の努力で補完していく必要があります。

現在『実践アジャイルテスト』の日本語版は入手困難であり、これから Agile Testing の世界に入っていく日本のQAエンジニアは『Condensed日本語版』を拠り所にしていくことでしょう。それでももちろん問題ありません。ただ、前者に全く触れないでいるのも私はちょっともったいないように思えてならないのです。

本セッションでは『実践アジャイルテスト』で印象的だった内容を紹介することで、『Condensed日本語版』を読了した方の次の学びへと繋げていきます。また、『実践アジャイルテスト』の原著『Agile Testing: A Practical Guide for Testers and Agile Teams』を手にするか迷われている方の参考になれば幸いです。

スクフェスの魅力ってなんでしょう？　それはたぶん、現地・オンラインに集まった人がとにかく楽しくワイワイできることではないでしょうか？

そんなイベントを盛り上げるために、あえてDay 1で行いたいWorkshopとして提案します。しかも "Markin’ Quality 第9回" として。

スクフェス新潟に集まる人は、きっと多種多様だろうと思います。職種こそエンジニアが多い気はしますが、業界も仕事のやり方も性格も千差万別でしょう。そこで相互理解を初日に深めるために、アジャイルテストをテーマに掲げるスクフェス新潟だからこそ「品質」をベースにした懇親会をやってみませんか？

スクフェス新潟というイベントが 通常の3倍楽しく、和気藹々となる こと、まちがいなし！！

分類はアジャイルリーダーシップです。懇親会をワークショップにするという無茶なリーダーシップ（Leader Ship）という、わたしたちにとっても実は初めてのチャレンジです。たぶん、いろいろな対話を通じて、参加者の「スクフェス新潟」に対する解像度がグッとあがると思います。

アジャイル開発において避けては通れないであろうトピックのひとつが、E2Eテストの自動化です。近年ではSaaSモデルのE2Eテストツールもメジャーとなり、それに伴い導入事例の紹介も多く見受けられるようになりました。

しかし発表される事例の多くは運用フェーズに入ったプロダクトのテスト自動化であり、結局のところいつからE2E自動テストを導入すれば良いのかという疑問が残ることでしょう。

「マネーフォワード クラウド確定申告」は2020年にフルリニューアル版をローンチしました。

スクラムチームでインクリメンタルに実装するにあたり、当時のQAリーダーである西條は開発の初期からE2Eテストツール Gauge を導入しました。本セッションの前半では、ツール選定や実装時の困難など導入時のエピソードを紹介します。

後半は、2代目QAリーダーの小林による運用篇です。

400件近くのシナリオが実装された状態で引き継いだ小林は、開発経験者が自分ひとりのみのQAチームでローコードなE2E自動テストを運用するという課題に直面しました。それを乗り越えるための取り組みと、今後の展望についてお話しします。