コドモンのカレンダー | Advent Calendar 2023 - Qiitaの8日目の記事です。
こんにちは。QAエンジニアのこやまです。
社内で実施している負荷試験を改めて考えてみた足跡 🐾 について、ご紹介します
前提
- 弊社の開発プロセスでは、テスト工程は必ずQAエンジニアが実施するわけではありません
- つまり「テスト」の対応が初めての開発エンジニアが負荷試験に挑むことがあります
弊社の負荷試験
- 社内で利用する負荷試験ツールはいくつかありますが、主によく使われるのは「k6」です
- いざ負荷試験を実施しようとチームで決めたとき、まずは負荷試験の設計・実施手順のガイドラインを確認します
- ガイドラインに則って負荷試験環境でシナリオを作成し測定していきます
課題
1.ガイドラインを見てもどのように負荷試験を行うかわかりにくい
- わからないために、負荷試験環境を作成した当時の担当者(現在マネージャ職のメンバー)に聞きにいく
- 忙しいマネージャに聞きに行く…それじゃガイドラインの意味をなしていませんよね？
- 迷える子羊は何に迷うか
- ガイドラインに沿ったフローとしては以下のとおりですが、★マークで迷います
1.テストしたいシナリオを作成する 2.テストの目的を考える ★ 3.検証観点(テスト観点)を整理する ★ 4.テスト種別を選択する(どれくらい負荷をかけるかの設計も含む) ★ 5.どこの検証環境でテストするかを整理する 6.検証ツールを選定する 7.テストを実行する ★
なぜ迷うのか
- 「テスト目的」から考えて「検証観点」をどういうメトリクスで取るべきかわからない
- 「テスト目的」と「検証観点」から選択すべきテスト種別がわからない
- 想定する「テスト種別」でどのように負荷を実際にかけたらいいのかわからない
テスト実行してみたけれど、どこを見たらいいのか、実施した内容がこれで正しいのかわからない
特に「負荷のかけ方」がうまく設計できないために、想定通りの結果が得られずに再テストをすることが多い
テスト目的が達成されていれば負荷試験としては一旦問題ないはずですが、イマイチ自信がないのは確認すべき目的を見誤っている可能性があるということ
どうしたらいいか迷うし、やり方が難しそうで不安だから、負荷試験が全然わからない！
課題を解決しにいく
1.ガイドラインをリニューアル
- 「テスト目的」に記載する例を増やし、イメージしやすくした
「こういうことをしたい場合はどうしたらいい？」の疑問を自己解決できるようにすることで、誰かに聞かずに済む
- 「テスト目的」「検証観点」「テスト種別」が一目でわかる表を準備した
知りたい目的によって、どの方法(テスト種別)でどのように負荷をかけるか、テスト実施時にどこ(テスト観点)を確認して、負荷試験としてPassしていると言えるかを見やすくしたことで、誤ったテスト種別を選択しなくなる
- テスト種別ごとにテストスクリプトのサンプルを用意した
負荷のかけ方がイメージできるようになる
- テスト種別ごとにどんなグラフを描くのかイメージ図を用意した
イメージ図からグラフィカルに負荷を理解できる
2.負荷試験用のテスト仕様書を新規作成
- 負荷試験用のテスト仕様書テンプレートを準備した
テストプランをテスト仕様書内で完結できる また、テスト観点のテンプレートを準備することで、負荷試験時に何を何処で確認すべきかのか迷いが生じなくなる
さらによくするには
JSTQBのシラバス定義と合わせて、テスト種別を充足させる
k6では、6種類のテスト種別(Smokeテスト、Loadテスト、Stressテスト、Soakテスト、Spikeテスト、BreakPointテスト)のみ解説されている
JSTQBにおける性能テストの定義と照らし合わせると、表現されていないテストも存在する
例)コンカレンシーテスト、拡張性テストなど
k6以外の負荷試験ツールついても解説していく
- どんなツールを利用しても、正しい種別で負荷試験が実施できる世界を目指す
あとがき
今回改善した内容は一部のチームで試運転を実施し、現在ブラッシュアップ中です
また、多くのチームにフィットするドキュメントにできるよう、改良を続けていく予定です
負荷試験がわからないという闇を、ちょっとだけ明るく照らしてみました
開発エンジニアからすると普段慣れない「テスト」という分野には色んな種類、手法があって混乱することがあります
しかし、目の前が少し明るくなると、実はそんなに怖くないことがわかると思います
これからもQAエンジニアから、テストは怖くないと発信していきます
