バグのすみか: 色々なめんどうくさいの上

こんにちは。ダイの大冒険エンジョイ勢のbun913と申します。

私は国内では珍しい SDET（Software Development Engineer in Test）という職種で働いており、小さな日々のアウトプットを意識しています。

テスト技術やQAなどの記事を書こうとすると（私にとっては）重くなりそうな記事が多いので、以下のようなZenn Book に日々の小さなアウトプットをまとめていくことで、私の頭の中だけではなく人の目に触れるようにアウトプットを気軽にできることを目指しています。

今回は初めての投稿となりますが、カテゴリーとしては「バグのすみか」シリーズということで、SDETでありながらも手動テストの効果もひしひしと感じている私が思う「こんなところでよくバグが見つかるよなぁ」ということを言語化していくシリーズとなります。

https://zenn.dev/bun913/books/sdet-how-to-walk/viewer/bug-find

./
└── sdet-how-to-walk
    ├── この本の概要
    ├── SDETのマインド・働き方
    ├── バグのすみか # 今回はここ！バグがよく見つかる場所について書くカテゴリーです
    ├── 自動テストの基盤を作る
    ├── 自動テストの知見
    ├── テストの一連のフロー（アクティビティ）
    ├── 英語を学ぶ

今回は「めんどうくさいの上」ですが、「うわぁ・・・テストがめんどうくさいからQAに任せよ」という怠惰という意味合いとは異なります。

調整がめんどうくさい

わかりやすいものだと、関係部署や開発部門以外の人たちとの調整が挙げられます。例えば以下のような例を考えてみましょう。

• アプリの強制アップデート機能のテスト
  • 例えばこれらをテストするうちに、特定のテスト環境で配信するアプリが利用できなくなる時間がある。その場合、それらの環境に携わっている部署に事前に連絡を入れて許可を得る必要があります
• システム全体をメンテナンスモードに切り替える機能のテスト
  • アプリケーションサーバー側でこの機能を持っている場合や、ロードバランサーの機能でソーリーページを表示するなどさまざまな仕組みが考えられると思います
  • いずれにせよ、メンテナンスモードを実行するにあたり上の例と同様に関係者の数だけ許可を得ておかないと、「突然テスト環境が壊れた」となってしまいます

これらの調整を仕組み化したり、「この時間帯はメンテナンス中です」というお約束を結んでおくことで都度の調整の手間を省いているパターンもあるかと思います。

セットアップがめんどうくさい

例えばテスト環境を準備するのに複数のPull Request を挙げた上で、特定の順番でデプロイをするケースなどです。他にも、テストデータを用意するのに特殊なデータを特殊な経路で（UIがない・直接的なアクセス権限がないなど）流し込まなければならないケースもありますね。

• テスト環境のセットアップが面倒
  • 環境セットアップの主導権は開発部門でもっているものの、他の部門にも合わせてPull Request を提出しなければならない。環境設定をするのにインフラの知識や特定のクラウドベンダのサービスの知識が必要になる
• テストデータのセットアップが面倒
  • こちらでは完璧にコントロールできないデータソース、例えば他の部署の方も利用する分析用DB、セキュリティや認証認可の権限の都合で一部の人しか利用が難しいDBなど。それらにデータを流し込んだ上で、1回しかテストできない機能のテストなどですね
    • 不可逆な機能のテスト、1ユーザーにつき1回しか実行できない操作など

シンプルにめんどうくさいし、確かもう確認したはずだから

手順がシンプルにめんどうくさい上に、「確かこれはもう確認したはず」ということありませんか？

• その機能を実行するためのステップに（待ち時間を含めて）1時間以上かかる
• はるか昔に実装していた機能で、その時に手動でテストをした上で変更していない。ユニットテストや自動結合テストではバッチリ動いている

単にめんどうくさいだけでなく、これはもうテストしているから大丈夫だと考えてしまうことに罪はありませんよね。だって私もよくやってしまいます。後で述べますが、それらを拾ってあげたり、気にする必要のない遠くに放り投げてしまえる仕組みを作れることが理想的です。

SDETとしての心得・対処法

さて、これらの場所から出てきたバグを見てきた上で、SDETとしていくつかの学びや大事にすると決めた心得がありました。

（最低でも）拾えるめんどうくさい部分は拾う

リソースやパーミッションなど許容できる範囲で、拾える手間は拾うのが大事です。別の機会にも記事を書きますが、日々の信用貯金にもつながります。

一回自分で面倒なセットアップをすることで、手順書が書けるようになります。面倒さを体中に浴びることで、「これはなんとしても自動化してやる」という決心を固めることができるようになりますしね。

テスト技術者やQAEの方はテストを実行するまでに、「何をテストするか」を決めて「どのようにテストするか」を明確にしていきます。

• （What）メンテナンスモードをテストする
  • （How）メンテナンスモードを有効にすると、ユーザーはソーリーページに遷移する
  • （How）メンテナンスモードを無効にすると、ユーザーは通常アプリページに遷移する

その時に、「うわぁめんどくさそう」と感じたらバグを発見するチャンスだと考えるようにしています。（やっている間はめんどうくさいと何度も思うのですが）

（できれば）めんどうくさいを軽減する

SDETという言葉の中には、Software Development Engineerがいます。みんなが喜ぶ自動化ツールや環境づくりをするのもソフトウェアエンジニアの仕事でしょう。

例えばデータを作成する手間がかかるケースでは、CI/CDパイプラインで少しでも手動作業を自動化できないか考える余地がないか探してみます。

テスト自動化エンジニアは単にいまある手動テストを自動化するだけでなく、自動化にふさわしいアーキテクチャを日々考えたり、時には基盤を作るのも仕事だと私は考えています。心の底からめんどくさがりな私ですが、だからこそ面倒を減らしていきたいです（自戒）。

（心得）技術やモデルを学ぶ

「めんどうくさい」を分解、軽減するためにはそいつの正体を知る必要があります。

例えば「メンテナンスモードをテストする」の何がそんなに面倒なのでしょうか？

• AWSのALBでメンテナンスモードを制御しているらしい
  • ではALBの設定をどのように変えるべきなのか？
  • その設定はどこで制御しているのか？
  • IaC（インフラのコード化）で実装している場合、どのように書けば良いのか？

と分解していくことで、どのような手順が必要なのかなんとなく整理できそうです。

全てを自分一人でやる必要はありませんが、テスト環境基盤づくり、開発者の書いたコードのレビュー、CI/CDの改良など色々な分野に（やろうと思えば）関わることのできるSDETとして、それら技術の基本概念やモデルを理解しておきたいと思っています。

自分で手を動かせるのが理想的ですが、「あ、この人同じ用語（言葉）が話せる人だ」と思われるだけでも、色々な職能の方との橋渡しができそうでとても素敵なことだと思います。

まとめ

• 今回はバグのすみかシリーズの1本目を書いてみました
• 「めんどうくさい」も色々な種類がありますが、SDETとしてそれを
  • 最低でも拾う
  • できれば軽減する
  • ということをしていきたいと常に思っています

以上、最後まで読んでいただきありがとうございました。