QAエンジニアとしての第一歩 - ブロッコリーさんのテスト講座で学んだこと
movでQAエンジニアをしております宮地と申します。
先日、私はあの著名なQAエンジニア、ブロッコリーさんが主催する「開発を加速するためのテスト講座」を受講しました。
この講座を通じて、自分のQA知識を広げる良いきっかけを得ることができました。本記事では、講座を通じて学んだ内容やその感想をお伝えしたいと思います。
受講したきっかけ
QAエンジニアとして仕事を始めて約1ヶ月が経った頃のことです。当時の私はQAエンジニアとしての基本的な知識も十分ではなく、日々勉強に勤しんでいました。そんなある日、先輩から「シフトレフトアプローチ」(後述)という考え方を、またその考え方を深めることができる講座があることを教えてもらいました。当初は高額な受講料に躊躇していましたが先輩や会社からの後押しもあり受けてみることにしました。
講座の概要
この講座では、QAの基本からテスト活動の詳細に至るまで幅広く学ぶことができるものです。QAエンジニアとして必要な知識を再確認し、実践的なスキルを深めることができる内容でした。
QAとは何か
QAエンジニアのテスト活動（計画、設計、実行、分析）
QAとは？
QA（Quality Assurance）は品質保証を意味します。品質保証の基本的な概念を学ぶことは、QAエンジニアとしての土台を築く重要なステップです。品質については複数の定義があります。
「本来備わっている特性の集まりが要求事項を満たす程度」 (ISO9000)
「品物またはサービスが使用目的を満たしているかどうかを決定するための評価の対象となる固有の性質・性能の全体」 (JIS Z 8101:1981)
これに加えて、品質には以下の要素が含まれます：
利便性（快適に利用できること）
可用性（停止せず、遅延が発生しないこと）
正確性（エラーがないこと）
安全性（安全に利用できること）
QAの定義を学ぶことで、改めて「品質」というものが単なるバグの有無以上に重要な要素を含んでいることを実感しました。
具体例
QAの重要性を理解するために、具体例を通じて考えてみましょう。講座で紹介された例は、実際のプロジェクトでもよく見られるものです。
1つ目の例
新しい機能をサービスに追加した際、その機能が全く使われなければ、品質が低いとみなされます。その機能は存在意義を持たないことになり、開発の目的を果たせません。
この話を聞いたとき、自分がこれまで見逃してきた観点に気づかされました。機能を作るだけでなく、その機能が使われること自体が品質の一部だというのは新しい発見でした。
2つ目の例
機能を実装したものの、ユーザーが意図した挙動をせず、エラーが頻発する場合は、サービスとして機能しているとは言えません。
実際のプロジェクトでもこのような事例に直面したことがあり、この例は非常に共感できました。エラーの多発は、ユーザー体験を損なう大きな要因です。
テストフロー
テストフローは、計画から分析までの一連の流れを指します。各ステップで注意すべきポイントや実践的な方法を学びました。テストフローは主に計画・設計・実行・分析に分けられます。
計画
テスト計画では、まず仕様を想像し、マインドマップを作成します。要件に矛盾がないか、他の機能との兼ね合いで懸念点がないかを確認します。そして、どのようにテストを実行するかを決定します。
設計
設計段階では、以下のテスト技法を学びました。
同値分割法
境界値分析
デシジョンテーブル
状態遷移図
これらは主にブラックボックステストに用いられます。ホワイトボックステストもありますが、講座ではブラックボックステストを中心に学びました。
同値分割法は、同じ結果が得られるケースをまとめることでテストケースを絞り込む技法です。
境界値分析は、動作が変わる境界となる値を中心にテストケースを設定します。境界値とその前後の値を対象にすることで効率的にテストできます。
デシジョンテーブルは、全ての値を表に記入し、論理的にテストケースを絞り込む方法です。同じ結果が得られるケースやあり得ないパターンを削除してテストケースを効率化します。
状態遷移図は、動作の変化を視覚的に整理し、仕様に欠陥や不足がないか確認するために使用します。
これらの情報を作成するだけでテストケースの必要性を示すものになり、実際のプロジェクトでエンジニアに説明する時などにとても活躍しました。
実行
テストの実行は、計画・設計の成果を試す場です。手動と自動、それぞれのテスト方法について理解を深めました。
テストの実行方法は、手動テストと自動テストに分かれます。手動テストはその名の通り、人の手で実行する方法です。一方、自動テストはTDDやE2Eテストで使われる言語を用い、あらかじめ設定されたテストケースを自動で実行します。自動テストの利点は工数の削減や繰り返しの容易さですが、仕様変更や機能追加時にはテストケースを更新する必要があります。
初めてプロジェクトで自動テストを試したとき、その利便性に驚きましたが、一方でメンテナンスの大変さも実感しました。
分析
テスト活動において最も重要なのが分析です。テスト結果を基に修正が必要か、仕様として正しいかを判断します。また、テスト結果を集計し、欠陥が多い箇所を把握することで、重点的にテストケースを作成する部分を決定できます。
シフトレフトアプローチについて
シフトレフトアプローチは、開発初期からテストを取り入れることで欠陥の早期発見を図り、開発全体の効率を向上させる考え方です。講座では、この概念を実感するためにジェンガを使用したワークが行われました。
実際のワーク内容
講座のワークでは、「どの段階でテスト内容がわかっていればスムーズにジェンガを積むことができるか」をテーマに進められました。要件として、ジェンガを3階建以上に積み上げることが求められました。
まず、ジェンガには番号が振られていましたが、最初の段階では番号の理由の説明はなく、我々は、特に計画を立てずに3階建の構造を組み立てました。すると、いくつかの番号のジェンガを抜き取るように指示が出され、その場で該当する番号のジェンガを探し、崩れないように慎重に抜き取らなければなりませんでした。結果的に、一度積み上げた構造を崩し、再度組み直すという二度手間が発生したグループもありました。
次に、抜き取る番号が事前にわかっている状態でジェンガを組み立てるワークが行われました。要件は同じく3階建以上の構造にすること。我々の班では、抜き取る番号を考慮してその番号のジェンガを使用せずに積み上げ、安定した構造を作ることができました。その結果、要件を瞬時に達成することができ、組み直しも不要でした。
シフトレフトアプローチの有用性
このワークを通じて、初めから抜き取る番号がわかっていれば、積み上げる段階で適切な準備ができ、効率的に要件をクリアできることが実感できました。一方で、事前情報がない状態では、構造を崩して再度組み直す必要が生じ、無駄な時間がかかることが明らかになりました。アジャイル開発ではスピードが重要視されるため、二度手間は大きな問題となります。このような問題を防ぐためにも、シフトレフトアプローチを導入し、早期にテスト活動を開始することが大切です。
実際の開発においては、全ての不具合を事前に把握することは難しいかもしれません。どれだけテスト活動を前倒しにしても、抜け漏れや不具合は必ず発生します。すべての欠陥を発見することは不可能ですが、シフトレフトアプローチを活用することで欠陥の早期発見ができ、開発スピードの向上に貢献できることは間違いありません。
シフトレフトアプローチは、開発の初期段階からテストを意識することで、欠陥の早期発見や効率的な開発を目指す手法です。講座の中で行われたワークを通じて、この考え方の重要性を体感しました。
まとめ
講座を通じて、QAエンジニアとしてのテスト活動や品質保証の重要性を再確認しました。欠陥を完全に防ぐことは難しいですが、できるだけ多くの欠陥を早期に発見し、開発の効率を高めることが求められます。
講座内容は他にもたくさんありましたが、ここでは基本的なQAエンジニアの知識とシフトレフトアプローチについて書かせていただきました！
今回の講座に参加することでQAエンジニアの在り方や重要性を認識し、自分の知識を広げる良いきっかけとなりました！今後もQAエンジニアとして成長できるよう日々精進したいと思います！
今回の講座を開いてくださったブロッコリーさんのブログ
https://nihonbuson.hatenadiary.jp/