JaSST’23 Kyushu 実行委員会主催の「JaSST’23 Kyushu」に参加してきました | 2部: 招待講演
去る2023年11月2日、JaSST’23 Kyushu 実行委員会及び特定非営利活動法人（NPO法人）ソフトウェアテスト技術振興協会（ASTER）主催の「JaSSTソフトウェアテストシンポジウム-JaSST’23 Kyushu」が開催されました。
本ブログは、福岡で現地参加してきたレポートになります。
そして、2部作で本ブログの範囲は、「2部: 招待講演」になります。
- 1部: 基調講演
- 2部: 招待講演
※ 本ブログで使用している画像は著者が作成したものになります。
招待講演: 「テスト自動化から、開発と品質を支える継続的テストへ」/ 末村 拓也 氏（オーティファイ）
講演の流れ
講演は上記の対策: ①から④の流れで進んでいきました。
- モノゴトを進めると
- 【課題】が生まれて
- 課題への【対策】を実施して
- 対策の【効果】が見えた
- けど、また別の【課題】が生まれて…、
と、自動テストを導入するときの壁が分かる講演でした。
なので、これから自動テストを導入するチームには、とても良い指針になると思います。
では、次より講演のふりかえりをしていきます。
前提: チーム体制
前提です。
チーム体制で、それぞれの役割は以下になります。
- PO: <要件>をなぜ必要かを説明する
- Dev: <要件>を<プログラムコード>に変換して実現する
- QA: <プログラムコード>が<要件>を満たしているか<検証>する
対策①: テスト自動化
【課題】クライマックステストでは、欠陥の修正に時間が必要です。それが、テストの時間がかかる要因です
クライマックステストでは、リリースする機能群を一気にテストします。
クライマックステストは、講演者である末村さんがChatGPTから提案された用語なので検索しても出てきません。
その場合、欠陥（不具合）が発生した時の原因の特定が困難になります。
なぜかというと、以下になります。
Devは機能群をA→B→Cの順に実装します。
そして、Aに欠陥が発生した時には時間の経過により、以下が発生します。
・ Aは昔すぎて覚えてないな…
・今は違うリリースのDを実装していて、頭切り替わらないな…
その結果、Devの思い出しの時間が必要なります。
それは、テストに時間がかかることに繋がります。
【対策】テストの時間を短縮するために、人の手で行なっていた手動テストを自動化します
テストの時間がかかるのであれば、人の手で行っていたことを、機械に行わせれば良いのです。
テスト自動化ですね。
【効果】テストを実行する時間が、1/2になりました
テスト自動化を導入することで、クライマックステストの時間が1/2になりました。
すごい効果ですね。
対策②: シフトレフト
【課題】手動テストの自動化により、テストの実行時間は減りました。しかし、テストコードのメンテナンスでQA自体の負荷は変わりませんでした
テスト自動化を導入した当初は、テストの時間は1/2になりました。
しかし、リリースを繰り返していくと、テストの時間が導入する前と変わらなくなりました。
それは、テストコードのメンテナンスの時間が発生するからです。
その結果、どんどんQAによるテストの時間が伸びて、QAの作業がボトルネックになるようになりました。
【対策】QAのテストコードのメンテナンスの負荷を減らすために、Devが実装中にメンテナンスするようにします
QAの作業がボトルネックになるのであれば、作業分担をすれば良いです。
Devの実装プロセスで同時にテストコードをメンテナンスしてもらうようにします。
【効果】欠陥の発見が実装中、つまり早期にできて、原因の特定が簡単になりました
Devに作業分担されることにより、QAの負荷は下がりました。
ただし、テストコードをメンテナンスをDevに頼むということは、あまり良い顔はされません。
Devの作業負荷が上がりますからね。
しかし、Devにもメリットがあります。
それは、欠陥を修正時に思い出す時間が短くなることで、原因の特定が簡単になります。
クライマックステストでの課題がここでも解消されましたね。
対策③: テストリアーキティング
【課題】実装中に、テストコードも実装するので実装する時間が長くなり、Dev内テストとの重複も出てきました
テストコードのメンテナンスもDevで担当することになりました。
ここで、Devはモヤモヤし始めます。
それは、作業負荷が増えたことではありません。
実装のプロセスには「コーディング」と「Dev内テスト」が含まれます。
その「Dev内テスト」でテストしていること「テストコード」でテストしていることが重複していることが分かりました。
これが、モヤモヤの原因です。
【対策】テストの重複をなくすために、実装時のテストとDevのテストの役割を明確にします
テストが重複しているのであれば、それぞれのテストの役割を明確にすれば良いです。
そのための基準として、The Test PyramidやTest Sizesがありますが、ここでの説明は省きます。
末村さんはTest PyramidのTestLevelのお話をされていた時に、例を多く出して、とても丁寧に説明されていたのが印象的でした。
TestLevelは本当に現場によるので、一概に定義できないです。
【効果】自動テスト実行時間と、自動テストを実装する時間が削減できました
重複したテストがなくなったので、Devのモヤモヤは解消されました。
また、テストの実装と実行の時間、両方を削減することができます。
対策④: 継続的テスト
【課題】少しの修正であれば、QAへの相談をなく、テストが必要ないとDevが判断して、障害が発生しました
ここより”クライマックステスト”から”テスト”にプロセス名を変えています。この段階に来るとクライマックス感はないからです。
自分で早期に欠陥を発見して修正したり、テストの役割を明確する経験を積んでいくと、Devでのテストが成熟していきます。
そして、Devはテストに対して自信がつきます。
自信がつくと自走できると判断して、相談なくモノゴトを進めます。
その結果、テストプロセスを通さずリリースしてしまい、インシデントを発生させてしまいました。
インシデントが発生した後には、再発防止策がとられます。
良く挙げられる対策は、以下になります。
- 「テストフェーズは必須だよね」
- 「もっとテストをしなきゃ！」
しかし、これでは、対策②: シフトレフトで解消したはずのQAがボトルネックを再発させます。
さらに、せっかく成熟したDevについたテストに対する自信がなくなります。
【対策】実装の前にQA、さらにはPOを含めた会話をして、必要なテストを発見するようにします
ここが講演で、一番重要と感じた部分です。
課題は2つです。
- テストを増やすことで、QAがボトルネックになる
- QAが増やしたテストを見て、Devが自信を無くす
私は、QAがボトルネックになることより、Devが自信を無くすことがチームの損失だと思います。
なぜなら、自信が無いと恐怖と戦うことになり、開発スピードを落とさざるをえないからです。
では、どうするか？
DevはQAに相談するタイミングを実装前にすれば良いのです。
さらに、そこにはPOも登場します。
PO、Dev、QAでこの機能ではどのようなテストが必要か？（受け入れ基準 / AC）を会話して発見します。
基調講演でも登場しました、コラボレーションベースのテストアプローチですね。
ここで、基調講演の伏線回収した！と勝手にテンションが上がっていました。
【効果】QAによるテストの範囲が明確になり、QAへ相談すべきか？の判断がDevできるようになった
課題が対策によって、効果が出たのか？確認します。
- テストを増やすことで、QAがボトルネックになる
↓
チームで会話して考えたテストがあることで、不要なテストをしなくなった。さらにチームの合意があるので、自信が持てる（自信が無いと、「とりあえずやっておこうテスト」を増やす） - QAが増やしたテストを見て、Devが自信を無くす
↓
チームで会話して考えたテストには、QAの観点も入っているので、Devでのテストに自信が持てる
共通した効果は、自信が持てたことですね。
自信が持てると、恐怖と戦う必要がないので、開発スピードも上がります。
まとめ: 目指すチーム体制には会話が必要
テストプロセスを無くしてリリースして大丈夫なの？と疑問は出ると思います。
ただ、テストプロセスを無くすというより、テストを開発プロセスに点在させることが重要とお伝えしたいです。
次の最終的な開発プロセスを見ると、多くでテストが登場するのがわかります。
この開発プロセスを目指すチーム体制には、要件を満たしているか？を確認するテストをチームで考える会話が大事です。
起点のプロセスでもありますしね。
Foundation Level シラバスにも、コラボレーションベースのテストアプローチが追加された理由も納得できました。
では、会話ってどうやってやるの？ですが、講演では実例マッピング（実例による仕様）を例にお話しされていました。
ぜひ、講演資料を参考にしてください。
最後に:
本当は4部作の予定でしたが、1–2部で気合い入れすぎて、気力がなくなってしまいました…。
なので、「JaSST’23 Kyushu」の参加レポートは以上です！
