[例題]分析する - マインドマップ版

例題を作って、テスト設計をしてみる。

  • [例題]テニスのスコアボード

  • [例題]分析する - 3色ボールペン版
  • ==

    Tennisscoreboardmm_2

    マインドマップから始めるソフトウェアテストでは、仕様分析~テスト計画~テスト設計~といった流れで、マインドマップをツールとして利用している。ここでは仕様分析+アプローチといったニュアンスでマインドマップを使ってみた。各メインブランチにふれてみると、

  • 単機能テスト
  • ここでは、ボタンを押すと仕様どおり(電源が切り替わったり、ポイントが増えたり)動作することを確認すること。スモークテスト的なテストでもいいかも。

  • 同値・境界値テスト
  • ポイント数、ゲーム数、セット数。ゲームが終わるとき、セットが終わるとき、試合が終わるとき。表示の桁数などなど。

  • 状態遷移テスト
  • 業務シナリオテストに近いイメージ。実際の試合を想定した利用。効果的、効率的なテストを目指す。

  • 組み合わせテスト
  • この状況でこのボタンを押したら、こうなる。

  • テストしない
  • ソフトウェアテストの例題なので、外部環境はできないですね。あと、数字がちゃんと表示されるか。とか。

  • テニスのルール
  • スコアのつけかたって、意外に複雑なのだよ。15ずつ増えたり、増えなかったり。タイブレークがあったり、なかったり。

    こういうのって数をこなしていくことも重要なのかな。ここ何日かは通勤バスの中でテキストを読んで復習してます。


    | | コメント (2) | トラックバック (0)

    [例題]分析する - 3色ボールペン版

    [例題]テニスのスコアボードのテストをしてみるのだが、まずテスト対象の分析をしてみる。分析をしてどんなテスト設計をするのか、テスト技法を使うのか、などなどを検討する。今回は、ソフトウェアテストPRESS Vol.2 「3色ボールペンで読む仕様書」にならってやってみようかな。

    1. 赤 - 客観的に見て、最も重要な箇所
    2. 今回は、同値分割や境界値などに使えそうな箇所もあげてみた。
    3. 青 - 客観的に見て、まあ重要な箇所
    4. 実は微妙に青色って難しい。。。
    5. 緑 - 主観的に見て、おかしいと感じた箇所
    6. おかしいというか仕様があいまいであったり、矛盾がある箇所としてみた。

    32


    次回はマインドマップを分析ツールとして使ってみる。予定。


    | | コメント (0) | トラックバック (0)