テスト理解、ビジネスマナー研修の振り返り

今回のスピードリンクジャパンの研修の全体像は、「ビジネスマナー」「テスト理解」「コンサルティング理解」の3本柱で構成されていました。

4月では「ビジネスマナー」「テスト理解」についての研修を行い、単にスキルを習得するだけでなく、「価値提供のための準備」という仕事としての意識を持ちながら1ヶ月間取り組みました。

ITの構造とテストの基礎

研修のスタートは、私たちが扱うシステムの裏側を理解することから始まりました。

• Webシステムの三層構造: ユーザーが触れる「プレゼンテーション層（ブラウザ）」、処理を行う「アプリケーション層（サーバー）」、データを保管する「データ層（DB）」の役割とデータの流れを学習しました。
• テストの重要性とV字モデル: 開発の各工程（要件定義、設計など）に対応したテストレベル（システムテスト、単体テストなど）を学び、テストが「品質を評価し、故障リスクを低減する」ための最後の砦であることを叩き込まれました。
• 不具合報告の習得: 実際にバグを探す演習を通じ、エンジニアに正しく伝わる不具合報告書の書き方をどう記載したら伝わるかを学びました。

システムの不具合がどこで起きていて、どのような操作をしたらバグが発生するのを正確に記載するのが難しかったです。

視覚的な設計技法と論理的思考

次は、より複雑な仕様を網羅的にテストするための技法を学びました。

• テスト観点の「型」: 正常系・異常系・境界値といった代表的な観点を用い、仕様の「穴」を見抜く力を養いました。
• 決定表（デシジョンテーブル）: 複雑に絡み合う条件と動作を表で整理し、論理的な矛盾を特定する手法を習得しました。
• 状態遷移図・マトリクス: システムがどの状態にあるか、何の操作で次の状態へ移るのかを可視化し、「起こり得ない遷移」まで網羅する設計を実践しました。

デシジョンテーブル、状態遷移図、マトリクス図など、初めてやる手法で特にデジションテーブルのどこが共通しているのかを把握するのが悩むポイントでした。

実践的な検証と構造の深掘り

後半は、よりエンジニアに近い視点での検証スキルを磨きました。

• ログの解読とシーケンス図: Chrome DevToolsなどを使ってブラウザ・API・DB間の通信（JSON形式のログ）を自力で特定し、技術的根拠のある不具合報告を作成できるようになりました。
• バリデーションの深掘り: 「性悪説」の視点に立ち、フロントエンドが突破された際のリスク（DB破損やセキュリティ脆弱性）を考慮したテスト設計の重要性を学びました。
• QA（質問）の極意: 曖昧な仕様に対して、「背景・懸念・自分の答え」をセットにしてエンジニアに投げ、自律的に設計を進める姿勢を身につけました。

エンジニアとの会話を通して、自分の認識と相手の認識を合わせることはすごく大事なことだと学び、今後何事においても認識合わせを怠らないようにしようと感じました。

最終課題：メルカリ風アプリのテスト設計

研修の集大成として、メルカリ風アプリの決済機能を題材にした最終課題に取り組みました。

• 厳選された20ケース: 膨大な組み合わせの中から、送料無料の境界値やクーポンによる0円決済、パラメータ改ざんなどの「最重要ケース」を、インパクト・頻度・複雑度の観点から厳選しました。
• ILOによる構造化: 文章だけでなく、Input（入力）、Logic（ロジック）、Output（出力）に分解して仕様を捉え直すことで、誰が読んでも迷わない仕様書への昇華を目指しました。

4月の研修を終えて

この1ヶ月で、「画面ベースのテスト」から「システムの構造を想像したテスト」へと視点が大きく変化しました。

また、初めての社会人ということもあり、ビジネスマナーから社会人としての意識、報連相など当たり前にできなければならないことを学びました。

私はテストの中で、攻撃性のある操作からどう守るかといったところが特に印象に残っています。

私自身IT業界が未経験ということもあり、攻撃に対しての知識はなかったのですが、一回でも攻撃から守れないと大きな影響が出てしまうので、そこをどう確実に守るかがテストをする上で大事だと感じました。