Webサービスの歩き方

こんにちは。freeeでQAのマネージャをやってるuemuです。これは、freee QA Advent Calendar2024 24日目の記事になります。

はじめに

今年は、どんな一年でしたか？

私は、大好きだった「ブラタモリ」の放送が終了してしまい、ショックを受けていましたが、この記事を書いている最中に「ブラタモリ復活！」のニュースが飛び込んできて、一気にテンションが上がっています！

www.nhk.jp

さて、、、昨年は「ブラタモリ」に倣い、ぶらぶら歩きながらWebサービスの「へり」を探してきました。今年もその続きをお届けします。よろしければ、昨年の記事もぜひ合わせてご覧ください！ developers.freee.co.jp

前回のおさらいになりますが、Webサービスの開発では、普段気づきにくい境界（以下、「へり」）が多数存在します。そういった「へり」を認識した上できちんとリスク分析しないと、思いもよらない不具合や障害に遭遇したりします。今回は、前回書ききれなかった「へり」について、見ていきたいと思います。

データサイズのへり

任天堂の「スーパーマリオブラザーズ」（以下、スーパーマリオ）は、知らない人はいないと思いますが、スーパーマリオには「無限1UP」という裏技があります。この裏技は、カメやノコノコを連続して踏むことで1UPする仕様を利用し、階段などの狭い場所でタイミングよく踏み続けることで、残数を無限に増やすことができるものです。

ところが、この裏技には大きな落とし穴があります。マリオを一定数以上増やしすぎると、マリオの残数がゼロになり、ゲームオーバーになってしまうのです。

ここにデータサイズの「へり」が存在します。

スーパーマリオブラザースがリリースされたのは1985年で、ほとんどのゲームは8bitで作られています。8bitというのは、1byteなので、データとして扱える最大は、符号なしで255、符号ありで127までとなり、マリオを128まで増やした時点でマイナスになってしまい、ゲームオーバーとなってしまうのです。ちなみに初代パックマンも255画面をクリアした後に、画面が崩れるというバグがありました。

符号ありは -128 から 127、符号なしは 0 から 255 の範囲を持つ — 符号あり (signed) と符号なし (unsigned) の数値範囲

以下は、各データサイズに対応するデータの取り得る範囲です。

データサイズ	データの範囲（符号なし）	データの範囲（符号あり）
1バイト	0 ～ 255	−128 ～ +127
2バイト	0 ～ 65,535	−32,768 ～ +32,767
4バイト	0 ～ 4,294,967,295	−2,147,483,648 ～ +2,147,483,647
8バイト	0 ～ 18,446,744,073,709,551,615	−9,223,372,036,854,775,808 ～ +9,223,372,036,854,775,807

現代のシステムでは、日々扱うデータ量が爆発的に増加しています。データベースも例外ではなく、初期設計時に想定していたデータ量を超えてしまうことが珍しくありません。このような場合、データベースの型を正しく設定していないと、オーバーフローが発生し、深刻な問題を引き起こす可能性があります。

システムのトランザクション情報をinteger（4バイト）の整数型で管理していたが、データ数が21億を超えてしまいシステム障害が発生した
毎日数100万件のログデータを保存していたが、ある日を境にログデータが保存されなくなった
大量のデータを登録しようとすると、MySQLのplaceholder上限（65,535）を超えて、エラーが発生した
利用事業所数が増加した結果、取引金額の合計を計算する際に、合計値がオーバーフローしてしまった

これらの問題は、初期設計の段階で適切なデータ型を選ばなかったり、取りうる最大値を考慮していなかったことが主な原因です。以下のポイントを押さえることで、リスクを最小化できます。

将来的なデータ量や演算結果を見越して適切なデータ型を選定する
データが取りうる最大値を把握しておく
不要なログデータを削除する、またはアーカイブするためのポリシーを設定する
監視システムを導入し、異常時にアラートが出るように設定する

テスト環境のへり

普段は、テスト環境やステージング環境を利用してQAを行うことがほとんどだと思います。しかし、本番環境でしか発生しない問題に遭遇することがあります。本番環境とテスト環境をまったく同じ環境にすることは難しく、ここに環境による「へり」が存在します。

LP（Landing Page）へ遷移してもページが表示されない
モバイル環境からアクセスできない
VPNを繋いだ環境だとアクセスできるが、VPNをOFFにするとアクセスできない
テスト環境では、外部サービスとの連携にモックやスタブを利用しているが、本番環境では予期しない動作をする
本番環境で登録したデータが、テスト環境のデータベースに反映される（または、その逆）
テスト環境でテストしているつもりだったが、実は本番環境でテストしていた
Feature/Release Flagの設定が、テスト環境と本番環境とで差分があり、意図しない挙動になる

本番環境とテスト環境の違いにより、パフォーマンスの問題やデータの不整合、設定の不一致、外部サービスとの動作の違いが本番環境で顕在化することがあります。これらは新規サービスをリリースする際に起こりがちですので、必ず本番環境で確認することをお勧めします。

本番環境とテスト環境が分かれている場合、または複数のテスト環境が存在する場合は、自分がどの環境で作業しているのかを正確に把握する必要があります。freeeでは、利用している環境をブラウザ上に表示するプラグインを用意しており、自分がどの環境を利用しているのかを視覚的に確認できる仕組みを提供しています。

利用している環境をブラウザ上にラベルで表示している — 利用している環境をブラウザ上に表示

テストタイプのへり

QAを効率的に行うためには、テストタイプをバランス良く組み合わせることが重要です。すべてのテストタイプを網羅的に実施するのではなく、コストや実行速度、対象範囲を考慮しながら、最適なテスト戦略を構築する必要があります。テストピラミッドやテストダイアモンドの考え方が提唱されることも多いですが、ここにも「へり」が存在します。

Unitテストで確認できている項目を、Manualテストでも確認している
E2Eテストで確認できているはずなので、手動テストケースからは除外していたが、特定のパターンでしか確認できてなくて、本番環境でバグが見つかった
Integrationテストがなかったので、大量のE2Eテストを実装したが、テスト実行およびメンテナンスに多大な時間がかかる

これらの問題を解決するためには、各テストタイプの役割とカバー範囲を明確にし、重複による無駄を削減する必要があります。特にUnitテストは、コード単位の確認を効率的に行う手段ですが、QAエンジニアがその内容を把握するのは、開発経験が少ない場合にはハードルが高いかもしれません。

そのため、開発エンジニアとのコミュニケーションが重要になります。例えば、「どのようなテストを書いていますか？」「この条件のテストは存在しますか？」といった具体的な質問を通じて、テスト内容を確認するようにしましょう。

ただし注意すべきなのは、「その部分はテストがあるから大丈夫です」と言われても、簡単に鵜呑みにしないことです。テストが存在していても、分岐条件が網羅されていない、特定の条件でしか確認されていない、といったケースはよくあります。QAエンジニアとしては、網羅性や条件の確認を意識し、「このパターンのテストはありますか？」「この条件での動作は確認していますか？」など、具体的に確認・依頼することが大切です。これにより、テストの漏れや重複を防ぎ、効率的かつ確実な品質向上につなげることができるでしょう。

最近は、copilotなどのAI技術を利用して、テストケースのレビューもできるようになってきているので、試してみるといいと思います。

テストアーキテクチャーについては、QAエンジニアのrenさんが詳しく説明してくれているので、こちらもご覧ください。 developers.freee.co.jp

地域のへり

グローバルでサービスを展開する場合、文化や習慣、地政学的な違いにより、さまざまな課題が発生することがあります。ここにも、その地域ならではの「へり」が存在します。

現地通貨での入力ができない
日付フォーマットが異なる
Googleアカウントによるログインが利用できない
ネットワーク環境が不十分でサービスが正常に動作しない
データの保存日時がずれる

グローバル展開では単なるローカライズにとどまらず、文化や顧客ニーズ、各国の法規制を深く理解することが不可欠です。さらに、Googleサービスの利用が制限されている国もあるため、それを考慮した設計が求められます。また、インフラの違いを考慮した開発とQAを徹底することも成功の鍵となります。

終わりに

昨年に続いて、Webサービスをぶらぶらと歩き回り、その中で「へり」を探してきましたが、いかがだったでしょうか？

Webサービスにはさまざまな「へり」があり、それらの「へり」には多くのリスクが存在しています。これらのリスクに気づくためには、QAとしての知識を深め、サービスの特性やドメインに関する理解を深めることが必要です。また、Webサービスがどのように作られているかを理解することで、リスクを的確に捉えることができるようになります。

良いQAになるためには、QA技術を磨くことが不可欠ですが、プログラミング言語やインフラ関連の技術は日々進化しているため、それに対応するためのアップデートも必要です。また、AIなどの新しい技術を取り入れることで、より効果的で効率的なQAを実現できるようになると思います。