品質管理部の仙波です。

自動テストツールShirates開発後記の2回目です。前回はShiratesがどういった経緯でオープンソースソフトウェアとして公開されたのかについて語りました。今回は当社がスマホアプリのテストの自動化に取り組んだ背景について語ります。

なぜテストの自動化に取り組むのか

最初に結論を言うと、弊社がスマホアプリのテストの自動化に取り組む理由は、

システムを変更した際に行うリグレッションテストという、重要ながら、とても退屈な作業の苦痛からテストエンジニアを解放し、より付加価値が高く、よりクリエイティブなテストに要員リソースを当てるため

です。

なお、ここでいうリグレッションテストは結合テスト/システムテストにおける打鍵によるテストをスコープとします。

リグレッションテストの苦痛

リグレッションテストで実施する作業は

すでに一度はテストが実施されOKとなったテスト項目を再実施し、再びOKになることを確認する作業。つまり、システムの挙動が変化しないことを確認する作業

です。

ソフトウェアやシステムの一部に変更を実施した際に、意図しない範囲に埋め込まれた不具合（デグレ）が存在しないかを確認することが目的です。

リグレッションテストは繰り返すことで練度が上がるのでベテランほど作業が早くなります。

一方、人間は同じ作業を繰り返し行うと退屈を感じ、次第にそれは苦痛に変わっていきます。モチベーションが下がり、注意力が低下し、どうせ同じ結果だろうという先入観が入り込むため、不具合があっても気付きにくくなります。

テストエンジニアとしてのスキルアップにつながる作業でもありません。

なので、長期間にわたって同じメンバーにリグレッションテストを任せるのは、品質確認の面でも、人材育成の面でも、問題があります。

リグレッションテストが必要になるタイミングには以下のようなものがあります。

これはケースバイケースで考える必要がありますが、基本的な指針は以下のようになります。

アプリケーションを改修しリリースする前
- ソースコードを改修した内容から影響範囲を推測し、範囲を絞って実施します
- 範囲が絞れない場合や万全を期す場合は各機能が正常に実行できることを確認するため正常系のテストシナリオを全て実施します（場合によってはイレギュラーのシナリオも実施）
ソフトウェア開発キット（SDK）をアップデートする時／OSの新しいバージョンが提供された時
- リリースノートに記載された内容から影響範囲を推測し、範囲を絞れる場合は絞って実施します
- 範囲が絞れない場合や万全を期す場合は各機能が正常に実行できることを確認するため正常系のテストシナリオを全て実施します（場合によってはイレギュラーのシナリオも実施）

リグレッションテストにおいて毎回全てのテストを再実施することは費用対効果を考えると現実的ではないので、可能ならば範囲を絞って実施します。ただし、推測が外れて不具合を見落とすリスクがあります。

リグレッションテストが自動化されている場合は範囲を絞らずに全て実施すればよいかもしれません。しかし、自動テストの実行時間が長時間になる場合は、やはり実施範囲を絞る必要が出てきます。これについては、それなりに投資が必要であるものの、テストの実行を並列化することで問題を緩和することが可能です。