Upgrade to Pro — share decks privately, control downloads, hide ads and more …

納得できるテストをつくるアプローチ

 納得できるテストをつくるアプローチ

JaSST17 関西での発表内容
納得できるテストケースを設計するためのアプローチを紹介します。

みずのり

June 21, 2024
Tweet

More Decks by みずのり

Other Decks in Technology

Transcript

  1. 5 2017/06/23公開用 JaSST’17 Kansai 不安 不安 不安 ありそうなシチュエーション 例えば、何らかのシステムをリリースするとします。 ※主にBtoBの場合

    テスト設計 開発担当 顧客 マネージャ 期待 責任 責任 リリースか 延期の判断 コスト 記載しているものだけでは 当然ありませんが… 不具合 テスト 工数 残業… 大丈夫 なの? 大丈夫 かなぁ? ちゃんと わかる 資料つくれ 1.納得できるテストを考えてみよう
  2. 6 2017/06/23公開用 JaSST’17 Kansai 不安 不安 不安 ありそうなシチュエーション 例えば、何らかのシステムをリリースするとします。 ※主にBtoBの場合

    テスト設計 開発担当 顧客 マネージャ 期待 責任 責任 リリースか 延期の判断 コスト 記載しているものだけでは 当然ありませんが… 不具合 テスト 工数 残業… 大丈夫 なの? ちゃんと わかる 資料つくれ 1.納得できるテストを考えてみよう 大丈夫 かなぁ? 「説明できること」 (相手の納得) 「自信が持てること」 (自分の納得)
  3. 7 2017/06/23公開用 JaSST’17 Kansai ワーク①:テストでの説明を考えてみましょう 「自信が持てる」「説明できる」 (納得できる) テストは大事そうですが、どうすればよいかを 一度、考えてみましょう。 <ワーク内容>

    次ページに「お題」のテスト対象があります。 1.テストケースをつくってみましょう(5分) 2.近くの人に説明してみましょう(5分) ※ひと段落したら誰かに聞いてみようと思います。 1.納得できるテストを考えてみよう
  4. 8 2017/06/23公開用 JaSST’17 Kansai ワーク①:テスト対象とワーク内容 お題:遊園地的な場所への入場システム、券売機です。 「購入計算画面」(左側)のテストが対象となります。 現在時間:17:00:15 購入種別(選択式) おとな

    こども 計算 料金表 おとな(15才以上)1000円 こども(14才以下)500円 10:00-17:59入場 通常料金 18:00-19:59入場 +300円 ※上記時間以外は購入不可 計算結果: 時間: 17:00:16 おとな: 1枚 支払いは 1000円です 購入計算画面 購入画面 ・通常料金チケットは18:05まで使用(入場)可能です ・計算ボタンを押したタイミングで時間が決定します ・購入者の妥当性チェックはシステム上はありません ・ユーザビリティは(あえて)考慮してませんので テストからも外していただいてOKです ・妥当性はあまり気にせず+深読みしなくてよいです 1.納得できるテストを考えてみよう
  5. 10 2017/06/23公開用 JaSST’17 Kansai 不安 不安 不安 ありそうなシチュエーション・リターンズ 例えば、何らかのシステムをリリースするとします。 ※主にBtoBの場合

    テスト設計 開発担当 顧客 マネージャ 期待 責任 責任 リリースか 延期の判断 コスト 記載しているものだけでは 当然ありませんが… 不具合 テスト 工数 残業… 大丈夫 なの? ちゃんと わかる 資料つくれ 1.納得できるテストを考えてみよう 大丈夫 かなぁ?
  6. 11 2017/06/23公開用 JaSST’17 Kansai ありそうなシチュエーション:実際の説明 各ステークホルダとの説明の場があるとして… 1.納得できるテストを考えてみよう 不安 テスト設計 開発担当

    10万件 やります! テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース 不安 顧客 仕様どおり 確認 してます! 全部テスト しろよ! テストケース×10万件 テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース×10万件 テスト設計 開発担当 不安 マネージャ 時間ないので、 少なくしても いいですか? 不具合でたら 誰が責任 とるんだ!
  7. 12 2017/06/23公開用 JaSST’17 Kansai 1.納得できるテストを考えてみよう イマイチな後は… 不安 テスト設計 開発担当 10万件

    やります! テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース 不安 顧客 仕様どおり 確認 します! 全部テスト しろよ! テストケース×10万件 不安 マネージャ 不具合でたら 誰が責任 とるんだ! 全部は キツイ… その後… 不具合で 多方面から 怒られて 意味不明の テストだらけ おわらない テスト _人人人人人人_ > 突然の死 <  ̄Y^Y^Y^Y^Y ̄
  8. 14 2017/06/23公開用 JaSST’17 Kansai 納得できる説明とは? 説得力のある説明(納得できる説明)とは? ・反論の余地が生まれるような抜けや漏れ、見落としが無い ・裏付ける根拠が整理して示されている ・聞き手が知りたいことにダイレクトに答え、明快 納得できる説明を専門の技術から引用します。

    ※複数の書籍が同じ表現をしています。 1.納得できるテストを考えてみよう 納得できる説明(論理的な説明): 主張が明確、筋道がわかること。 ※MBAクリティカルシンキングなどより引用。章末の書籍を参考のこと。 ※MBAクリティカルシンキング より引用
  9. 15 2017/06/23公開用 JaSST’17 Kansai 納得できる説明とは?:テクニック 1.納得できるテストを考えてみよう 説得力のある説明(納得できる説明)とは? ・反論の余地が生まれるような抜けや漏れ、見落としが無い ・裏付ける根拠が整理して示されている ・聞き手が知りたいことにダイレクトに答え、明快

    XX事業から撤退 すべきである ※主張ー論拠の ツリー構造の例 極めて市場の 見通しが暗い ※MBAクリティカルシンキングより引用 小さい市場規模 競合が強く 収益率が低くなる わが社の強みを 活かせない 今後の低成長 シビアな顧客 競合とコスト差⇒大 差別化が困難 ・・・ 構造的に考える 全体的に考えて 抜けがなく見える 根拠が明確 繋がり(筋道)が明確
  10. 16 2017/06/23公開用 JaSST’17 Kansai 納得できる説明とは?:構造で考える 1.納得できるテストを考えてみよう 構造的に考える 根拠が明確 繋がり(筋道)が明確 全体的に考えて

    抜けがなく見える (相手に直接伝わる) XX事業から撤退 すべきである ※主張ー論拠の ツリー構造の例 極めて市場の 見通しが暗い 小さい市場規模 競合が強く 収益率が低くなる わが社の強みを 活かせない 今後の低成長 シビアな顧客 競合とコスト差⇒大 差別化が困難 ・・・ 構造的(ツリー的)にまずは考えてみましょう。
  11. 17 2017/06/23公開用 JaSST’17 Kansai 納得できる説明とは?:目的-手段構造 構造をツリーで表現する際には、いくつかの形式があります。 これは「目的-手段」の構造。 1.納得できるテストを考えてみよう 新商品の売上 を向上させる

    ターゲットとして XXXに売り込む XXXへのTVCMを実施 商品のコンセプト をXXXとする 価格帯を XXXに設定する XXXを中心に広告 ・・・ ・・・ 理由 ・・・ ・・・ 販売チャネルとし てXXXと連携する ・・・ 理由 手段 / 目的 目的 手段
  12. 18 2017/06/23公開用 JaSST’17 Kansai 納得できるテストでの説明:重要な定義 構造を考える際に1つ重要な定義をしてみます。 それぞれのテストケース (グループ) は なんらかの「目的」を持つ

    テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース×10万件 テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース目的 ※「テストケース目的」という用語はJSTQBにはありません。現在は仮名称です。 テストケース目的 テストケース目的 1.納得できるテストを考えてみよう
  13. 19 2017/06/23公開用 JaSST’17 Kansai 納得できるテストでの説明:重要な定義 構造を考える際に1つ重要な定義をしてみます。 それぞれのテストケース (グループ) は なんらかの「目的」を持つ

    JSTQB AL TA シラバスにも テストケースが 目的を持つという 記述があります。 引用:ISTQBテスト技術者資格制度 Advanced Level シラバス 日本語版 テストアナリスト Version2012.J01 P13 1.納得できるテストを考えてみよう
  14. 20 2017/06/23公開用 JaSST’17 Kansai 納得できるテストの構造:テスト目的と構造 1.納得できるテストを考えてみよう テストケース テストケース テストケース テストケース

    テストケース目的 テストケース目的 テストケース目的 Target (仮) ・・・ ・・・ テストケース が目的を持つ 複数のテストケースで何らかの目的 もしくは対象範囲がカバーされる 目的-手段と同じような構造で考えてみましょう。
  15. 21 2017/06/23公開用 JaSST’17 Kansai 納得できるテストの構造:一般的な構造の例 一般的には目的-手段の構造として次のような紹介があります。 1.納得できるテストを考えてみよう 手段 戦略目的 戦略目的

    戦略目的 上位 目的 ・・・ ・・・ 戦略目的を達成するための 「具体的な手段」を考える 上位目的を達成するために 戦略目的が存在する ※引用:世界一やさしい「思考法」の本 手段
  16. 22 2017/06/23公開用 JaSST’17 Kansai 納得できるテストの構造:使い方(例) ワーク①を例に作り方の流れを紹介してみます。 1.納得できるテストを考えてみよう テストケース テストケース目的 Target(仮)

    「おとな」設定時 購入種別パラメータ を確認する 購入計算 機能 入場時間パラメータ を確認する パラメータの組合せ を確認する ・・・の時 理由 テストケース テストケース テストケース テストケース 他にも あるかも? 理由 ・・・
  17. 23 2017/06/23公開用 JaSST’17 Kansai テストベースに記述追加 お題:遊園地的な場所への入場システム、券売機です。 現在時間:17:00:15 購入種別 おとな こども

    計算 料金表 おとな(15才以上)1000円 こども(14才以下)500円 10:00-17:59入場 通常料金 18:00-19:59入場 +300円 ※上記時間以外は購入不可 計算結果: 時間: 17:00:16 おとな: 1枚 支払いは 1000円です 購入計算画面 購入画面 ・購入客を計算で待たせないこと ・通常料金チケットは18:05まで使用(入場)可能です ・計算ボタンを押したタイミングで時間が決定します ・購入者の妥当性チェックはシステム上はありません ・ユーザビリティは(あえて)考慮してませんので テストからも外していただいてOKです 1.納得できるテストを考えてみよう 追加
  18. 24 2017/06/23公開用 JaSST’17 Kansai 納得できるテストの構造:使い方(例) ワーク①を例に作り方の流れを紹介してみます。 1.納得できるテストを考えてみよう テストケース テストケース目的 Target(仮)

    「おとな」設定時 購入種別パラメータ を確認する 購入計算 機能 入場時間パラメータ を確認する パラメータの組合せ を確認する ・・・の時 理由 テストケース テストケース テストケース テストケース 理由 1秒以内に計算が 完了することを確認 理由 ・0.1秒までなら応答が瞬時に 返ってきたという印象を与える。 ・1秒までならユーザーの思考は 途切れなく流れる。 ・10秒までならユーザーの注意力は続く。 ・10秒遅延してしまうと、ユーザーが即、 サイトから離れてしまうことも多くなる。 (Webサイトの応答時間 – U-Site, 2010/06/21)ニールセン氏 https://note.mu/tsukamoto/n/nde7fe5e21216 ・・・
  19. 25 2017/06/23公開用 JaSST’17 Kansai 納得できるテストの構造:使い方(例) これらの構造を用いて説明する場合。 1.納得できるテストを考えてみよう テストケース テストケース目的 Target(仮)

    「おとな」設定時 購入種別パラメータ を確認する 購入計算 機能 入場時間パラメータ を確認する パラメータの組合せ を確認する ・・・の時 理由 テストケース テストケース テストケース テストケース 理由 1秒以内に計算が 完了することを確認 理由 1000人連続で 計算できること 理由 ・・・ ・・・
  20. 26 2017/06/23公開用 JaSST’17 Kansai 納得できるテストの構造:説明(例) これらの構造を用いて説明する場合。 1.納得できるテストを考えてみよう テストケース テストケース目的 Target(仮)

    「おとな」設定時 購入種別パラメータ を確認する 購入計算 機能 入場時間パラメータ を確認する パラメータの組合せ を確認する ・・・の時 理由 テストケース テストケース テストケース テストケース 理由 1秒以内に計算が 完了することを確認 理由 1000人連続で 計算出来ること 理由 ・・・ テストケース 目的を使用して 説明する ・・・
  21. 27 2017/06/23公開用 JaSST’17 Kansai ワーク①:こうなっていた? 下記で紹介した例を同じ構造で表してみると…? テストベース? テストケース テストケース テストケース

    テストケース テストケース 何か テストベース テストケース テストケース テストケース テストケース テストケース テストベース テストケース テストケース テストケース テストケース テストケース テスト 技法 仕様から 引用(コピー) 1.納得できるテストを考えてみよう
  22. 28 2017/06/23公開用 JaSST’17 Kansai ワーク①:こうなっていた? 下記で紹介した例を同じ構造で表してみると…? ※縦横が変わっておりますがご了承ください。 1.納得できるテストを考えてみよう テストケース テストケース目的

    Target(仮) 「全部」 確認する? 購入計算 機能 テストケース テストケース テストケース テストケース テスト技法 を使う? 購入計算 機能 テストケース テストケース テストケース テストケース 仕様どおりである ことを確認する? 購入計算 機能 テストケース テストケース テストケース テストケース
  23. 30 2017/06/23公開用 JaSST’17 Kansai テストの(納得への)構造:各構造説明 とある対象範囲(上位目的)に対して テストケース目的で確認を行う。 1.納得できるテストを考えてみよう Target (仮)

    テストケース テストケース テストケース 目的 理由 テストケース 理由 ・・・ 理由 ・・・ テストケース 目的 テストケース 目的 理由 テストケース 目的 「テストケース目的」はここでは手段。 他の呼び方 ・確認すること、気がかり事項、リスク ・テストカテゴリ、テスト方針、テスト観点? 目的に対して テストケースが存在する。
  24. 31 2017/06/23公開用 JaSST’17 Kansai テストの(納得への)構造:上位から検討 上位から検討する場合の考え方です。 1.納得できるテストを考えてみよう テストケース テストケース テストケース目的

    テストケース目的 テストケース目的 Target (仮) ・・・ ・・・ 理由 理由 ・・・ これらの手順は 当然ですが 往復もあります ①何らかの対象や 上位目的を設定 理由 ②テストケース 目的を設定 ③目的に対応する テストケース作成 ②´必要に応じて 理由を明確化 ③´必要に応じて 理由を明確化
  25. 33 2017/06/23公開用 JaSST’17 Kansai テストの(納得への)構造:使い方と利点① 「説明」時における使い方です。これは説明済み。 ※Javaly Parkの例 1.納得できるテストを考えてみよう 「おとな」設定時

    購入種別パラメータ を確認する 購入計算 機能 入場時間パラメータ を確認する パラメータの組合せ を確認する ・・・の時 理由 テストケース テストケース テストケース テストケース 理由 1秒以内に計算が 完了することを確認 理由 1000人連続で 計算できること 理由 ・・・ ・・・
  26. 34 2017/06/23公開用 JaSST’17 Kansai テストの(納得への)構造:使い方と利点② 一連のテストケース目的に対する議論や知識の蓄積にて 「成長」ができます。※Javaly Parkの例 1.納得できるテストを考えてみよう 購入種別パラメータ

    を確認する 購入計算 機能 入場時間パラメータ を確認する パラメータの組合せ を確認する 1秒以内に計算が 完了することを確認 理由 1000人連続で 計算できること 理由 ハイスキルの エンジニアの経験 想定されるリスク 分からない部分を聞く 知見ある人に意見貰う PDCAと 知識の蓄積へ
  27. 35 2017/06/23公開用 JaSST’17 Kansai テストの(納得への)構造:使い方と利点③ 構造の1つ1つを取り出して丁寧に「確認」ができます。 1.納得できるテストを考えてみよう Target (仮) テストケース

    テストケース テストケース 目的 理由 テストケース 理由 ・・・ 理由 テストケース 目的 テストケース 目的 理由 テストケース 目的 <チェック方法の例> テストケース目的XX達成には、 XXのテストケースが必要である。 (なぜならば理由である) 確認 <チェック方法の例> ・テストケース目的XXとXXにて Targetを確認・達成ができる。 ・Targetにテストケース目的が必要だ。
  28. 36 2017/06/23公開用 JaSST’17 Kansai テストの(納得への)構造:まとめ 利点・使い方 1.説明、2.成長、3.確認 1.納得できるテストを考えてみよう テストケース テストケース

    テストケース目的 テストケース目的 テストケース目的 Target (仮) ・・・ ・・・ 理由 理由 理由 ・・・ 1.テストケース 目的を説明に使う 2.テストケース 目的を議論や知識 の蓄積で成長へ 3.構造の1つ1つ を取り出して確認
  29. 37 2017/06/23公開用 JaSST’17 Kansai ワーク②:テスト対象とワーク内容 お題:伊丹の仮想的な遊園地「いたみパーク(通称いたパー)」 いたパーWebシステムの「Webチケット購入画面」が対象です。 1.納得できるテストを考えてみよう 「いたみパーク(通称いたパー)」 Webシステム

    入園予定日 購入種別 チケット購入 早期割引ルール 料金案内 購入人数 団体料金案内 Webチケット購入画面 ※休園日は選択 できません。 06月23日(金) 入園のみ 入園+フリーパス おとな 名 こども 名 02 01 チケット購入画面
  30. 38 2017/06/23公開用 JaSST’17 Kansai ワーク②:テスト対象とワーク内容 「Webチケット購入画面」の各種情報。 1.納得できるテストを考えてみよう 入園予定日 購入種別 チケット購入

    早期割引ルール 料金案内 購入人数 団体料金案内 Webチケット購入画面 入園 入園+フリーパス おとな (中学生以上) 1400円 4400円 こども (2歳~小学生) 800円 2600円 団体料金 (入園のみ) おとな (中学生以上) こども (2歳~小学生) 25人以上 1260円 720円 50人以上 1120円 640円 入園予定日の14日以上前に購入の場合に 料金を200円割引します。 ※休園日は選択 できません。 06月23日(金) 入園のみ 入園+フリーパス 団体料金 (入園+フリーパス) おとな (中学生以上) こども (2歳~小学生) 25人以上 3960円 2520円 50人以上 3820円 2440円 おとな 名 こども 名 01 01 ↓の情報は、「料金画面」で記述します。 カレンダーから 選択可能
  31. 40 2017/06/23公開用 JaSST’17 Kansai ワーク②:回答例 ワーク②の回答例(他にもあるかも) 1.納得できるテストを考えてみよう カレンダー表示月期間 入園予定カレンダーの 表示期間、選択確認

    Webチケット 購入画面 カレンダー設定の 料金反映の確認 選択結果の反映(日、曜日) 購入種別設定の 料金反映の確認 購入人数設定の 料金反映の確認 パラメータ 組合せの確認 理由 当日よりも前は選択不可能 休園日は選択不可能 14日以上前に早期割引あり 14日未満前は早期割引なし キャンセル時に元の 設定が残っていること 入園のみ、入園+フリーパス 画面遷移のレスポンス 時間(1秒)確認 理由 おとな人数の反映 こども人数の反映 ・・・ 金額計算の結果を確認。 チケット購入可、不可 のケースを確認する。 ※合計0人は購入不可など 入力間違いで購入者が次の購入確認画面 から「戻る」場合がある。 この場合を考慮して、キャンセル時には 元の設定に戻るべき。 入園予定日 購入種別 チケット購入 早期割引ルール 料金案内 購入人数 団体料金案内 Webチケット購入画面 ※休園日は選択 できません。 06月23日(金) 入園のみ 入園+フリーパス おとな 名 こども 名 02 01
  32. 42 2017/06/23公開用 JaSST’17 Kansai むずかしい理由 1.納得できるテストを考えてみよう いくつかむずかしい理由が存在します。 ・なれるまで時間がかかる ・知識ギャップ①:テストケース目的の知識 ・知識ギャップ②:テスト技法(作り方)の知識

    ・目的-手段の思考方法(考えることが少ない) テストケース テストケース テストケース目的 テストケース目的 テストケース目的 Target (仮) ・・・ ・・・ 理由 理由 理由 ・・・ 知識ギャップ① 知識ギャップ②
  33. 43 2017/06/23公開用 JaSST’17 Kansai むずかしい理由⇒解決策 1.納得できるテストを考えてみよう 解決策の例となります。 ・なれるまで時間がかかる ⇒ 使ってみてなれましょう!

    ・知識ギャップ①:テストケース目的の知識 ⇒ パターンや知見を集めることが有効 「VSTeP」の知見も役立ちます ・知識ギャップ②:テスト技法(作り方)の知識 ⇒ テスト技法を勉強してみよう WACATE、WARAI、技法ドリル ・目的-手段の思考方法(考えることが少ない)
  34. 44 2017/06/23公開用 JaSST’17 Kansai むずかしい理由⇒解決策 1.納得できるテストを考えてみよう テストケース目的の知見を集める、整理する方法の例 「テストタイプ」や品質モデル(ISO250XX等)を知り、 そこから整理する。 「テストタイプ」

    からの整理の例 「品質モデル」 からの整理の例 ネットワーク負荷時の確認 連続使用人数の確認 同時複数人使用の確認 連続使用時間の確認 パラメータ組合せ確認 パラメータ単体確認 テスト タイプ ストレステスト 信頼性テスト 機能テスト 機能適合性 - 性能評価 性能効率性 ボリューム - 結果網羅 ふるまい - 結果網羅 機能排他 レスポンス
  35. 45 2017/06/23公開用 JaSST’17 Kansai 目的-手段の思考方法の重要性 テストケース目的セットを用意することでも対処はできますが… テストケース 目的セット テストケース 目的

    手段 テストケース XXXパラメータ を確認する パラメータ 組合せを確認する レスポンス を確認 最大アクセス 数で確認 テストケース テストケース テストケース テストケース テストケース目的 ない? (新しい) テストケース目的 テストケース テストケース テストケース テストケース 引用 レビューで チェック 新たに 追加 1.納得できるテストを考えてみよう
  36. 46 2017/06/23公開用 JaSST’17 Kansai 目的-手段の思考方法の重要性 テストケース目的セットを用意することでも対処はできますが… テストケース 目的セット テストケース 目的

    手段 テストケース XXXパラメータ を確認する パラメータ 組合せを確認する レスポンス を確認 最大アクセス 数で確認 テストケース テストケース テストケース テストケース テストケース目的 ない? (新しい) テストケース目的 テストケース テストケース テストケース テストケース 引用 レビューで チェック 新たに 追加 「自分のアタマで考える」 必要は必ず発生します この場合に、目的-手段の 思考方法が役に立ちます 1.納得できるテストを考えてみよう
  37. 47 2017/06/23公開用 JaSST’17 Kansai 目的-手段の基本構造 1.納得できるテストを考えてみよう Target (仮) テストケース テストケース

    テストケース 目的 理由 テストケース 理由 ・・・ 理由 テストケース 目的 テストケース 目的 理由 テストケース 目的 手段 目的 理由 基本の構造は「目的-手段(+理由)」 ←の考え方を トレーニングしよう!
  38. 48 2017/06/23公開用 JaSST’17 Kansai 目的-手段の重要性:例 1.納得できるテストを考えてみよう 手段 目的 理由 基本の構造は

    「目的-手段(+理由)」 目覚ましを セットして寝る JaSSTに 朝から参加して 情報を得る <目的> <手段> 早めに おふとん.in 前日の お酒を控える
  39. 49 2017/06/23公開用 JaSST’17 Kansai 目的-手段の重要性:例 1.納得できるテストを考えてみよう 手段 目的 理由 基本の構造は

    「目的-手段(+理由)」 目覚ましを セットして寝る JaSSTに 朝から参加して 情報を得る <目的> <手段> 早めに おふとん.in 前日の お酒を控える 目覚ましを セットして寝る 午後の講演を 最大限に 良いモノにする <目的> <手段> ?
  40. 50 2017/06/23公開用 JaSST’17 Kansai 目的-手段の重要性:いろいろ役立つ 1.納得できるテストを考えてみよう 手段 目的 理由 基本の構造は

    「目的-手段(+理由)」 目覚ましを セットして寝る JaSSTに 朝から参加して 情報を得る <目的> <手段> 早めに おふとん.in 前日の お酒を控える 目覚ましを セットして寝る 午後の講演を 最大限に 良いモノにする <目的> <手段> 遅刻してでも 十分な睡眠を とる 理由: 睡眠時間が 確保できないと キレが悪い 目的がわかると 他の手段を見つける こともできる 目的が異なると 手段も変わる 目的から手段を チェックできる
  41. 51 2017/06/23公開用 JaSST’17 Kansai 目的-手段の重要性:例題 目的-手段は普段から考えることもできます。 以下のような例題を簡単に考えてみましょう。 <例題> 目的を考えてみましょう! ・直近に実施したレビューの目的はなんでしょう?

    ・開発やテストで実施している 現在実施中のプロセスの目的はなんでしょう? ・本セッションに参加する目的はなんでしょう? ・勉強する目的はなんでしょう?(子供のケースでもOK) ・思考フレームワーク(目的-手段など)を 使う目的はなんでしょう? 1.納得できるテストを考えてみよう
  42. 52 2017/06/23公開用 JaSST’17 Kansai 目的-手段の重要性:トレーニングが必要 目的-手段を普段から考えている人 うまく考えることができる人は少ないです。 <失敗例> ・循環論理(単なる読み替え、立場を代えただけ) 「知識をつけたいために学ぶ」

    ・目的-手段の逆転 「TOEIC800点取るため、英語を話せるようになる」 ・手段が目的となる(逆転と近い) 「チェックリスト項目を完璧にクリアする」 1.納得できるテストを考えてみよう
  43. 53 2017/06/23公開用 JaSST’17 Kansai 目的-手段の重要性:いったんまとめ ・テストケース目的セットからの引用以外を 行いたい場合、テストケース目的のチェックには必要 ・普段の生活、活動にも役に立つ ・普段の意識でトレーニングできる 1.納得できるテストを考えてみよう

    XXXパラメータ を確認する パラメータ 組合せを確認する レスポンス を確認 最大アクセス 数で確認 テストケース テストケース テストケース テストケース テストケース目的 (新しい) テストケース目的 テストケース テストケース テストケース テストケース 引用 引用以上のことを やる場合に必要
  44. 54 2017/06/23公開用 JaSST’17 Kansai 目的-手段の重要性:テストでは? 目的-手段を考えることでテストケースを整理する力と 説明・納得を高める力がつくかもしれません。 1.納得できるテストを考えてみよう テストケース テストケース

    テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース 大量のテストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース目的 テストケース目的 テストケース目的 手段 目的 理由 目的-手段を考える
  45. 55 2017/06/23公開用 JaSST’17 Kansai ワーク③:テストケースから目的を取り出す ワーク①「Javaly Park」購入計算機能に対して、 テストケースだけを用意してみました。 1.納得できるテストを考えてみよう テストケース

    テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース目的 テストケース目的 テストケース目的 <ワーク内容> 1.テストケースを目的で整理しましょう 2.不足の追加や整理をしてみましょう
  46. 56 2017/06/23公開用 JaSST’17 Kansai ワーク③:テスト対象とワーク内容 お題:遊園地的な場所への入場システム、券売機です。 「購入計算画面」(左側)のテストが対象となります。 現在時間:17:00:15 おとな こども

    計算 料金表 おとな(15才以上)1000円 こども(14才以下)500円 10:00-17:59入場 通常料金 18:00-19:59入場 +300円 ※上記時間以外は購入不可 計算結果: 時間: 17:00:16 おとな: 1枚 支払いは 1000円です 購入計算画面 購入画面 ・通常料金チケットは18:05まで使用(入場)可能です ・計算ボタンを押したタイミングで時間が決定します ・購入者の妥当性チェックはシステム上はありません ・ユーザビリティは(あえて)考慮してませんので テストからも外していただいてOKです 1.納得できるテストを考えてみよう 購入種別(選択式)
  47. 57 2017/06/23公開用 JaSST’17 Kansai ワーク③:テスト対象とワーク内容 テストケース一覧はこちら。※何となくグルーピングは実施済み 「おとな」設定の反映 入場時間「00:00:00」の時 入場時間「00:01:00」の時 入場時間「05:00:30」の時

    入場時間「09:00:00」の時 入場時間「09:59:59」の時 入場時間「10:00:00」の時 入場時間「12:00:00」の時 入場時間「15:30:30」の時 入場時間「17:00:00」の時 入場時間「19:59:59」の時 入場時間「20:00:00」の時 入場時間「23:59:59」の時 購入種別:おとな、入場時間:09:00:00(購入不可) 購入種別:こども、入場時間:09:00:00(購入不可) 購入種別:おとな、入場時間:09:59:00(購入不可) 購入種別:こども、入場時間:09:59:00(購入不可) 購入種別:おとな、入場時間:10:00:00(1000円) 購入種別:こども、入場時間:10:00:00(500円) 購入種別:おとな、入場時間:19:00:00(1300円) 購入種別:こども、入場時間:19:00:00(800円) 購入種別:おとな、入場時間:10:00:00で 計算処理の時間が1秒以内であること。 同時に10人で購入計算を行い、 計算処理が1秒以内であること。 計算を500回繰り返した後、計算処理が1秒以内であること。 電源が切れて再起動後の表示が変わらないこと。 1.納得できるテストを考えてみよう
  48. 58 2017/06/23公開用 JaSST’17 Kansai ワーク③:回答例 1.納得できるテストを考えてみよう 回答例。先ほど紹介していたテストケース目的を使用します。 テストケース テストケース目的 Target(仮)

    購入計算 機能 購入種別パラメータ を確認する 入場時間パラメータ を確認する パラメータの組合せ を確認する 1秒以内に計算が 完了することを確認 理由 1000人連続で 計算できること
  49. 59 2017/06/23公開用 JaSST’17 Kansai ワーク③:回答例 1.納得できるテストを考えてみよう 回答例。先ほど紹介していたテストケース目的を使用します。 テストケース テストケース目的 Target(仮)

    購入計算 機能 購入種別パラメータ を確認する 入場時間パラメータ を確認する パラメータの組合せ を確認する 1秒以内に計算が 完了することを確認 理由 1000人連続で 計算できること 「おとな」設定の反映
  50. 60 2017/06/23公開用 JaSST’17 Kansai ワーク③:回答例 1.納得できるテストを考えてみよう 回答例。先ほど紹介していたテストケース目的を使用します。 テストケース テストケース目的 Target(仮)

    購入計算 機能 購入種別パラメータ を確認する 入場時間パラメータ を確認する パラメータの組合せ を確認する 1秒以内に計算が 完了することを確認 理由 1000人連続で 計算できること 「おとな」設定の反映 「こども」設定の反映 「設定なし」時の確認 不足部分を追加
  51. 61 2017/06/23公開用 JaSST’17 Kansai ワーク③:回答例 回答例。入場時間はたくさんありますが… テストケース テストケース目的 Target(仮) 購入計算

    機能 購入種別パラメータ を確認する 入場時間パラメータ を確認する パラメータの組合せ を確認する 1秒以内に計算が 完了することを確認 理由 1000人連続で 計算できること 入場時間「00:00:00」の時 入場時間「00:01:00」の時 入場時間「05:00:30」の時 入場時間「09:00:00」の時 入場時間「09:59:59」の時 入場時間「10:00:00」の時 入場時間「12:00:00」の時 入場時間「15:30:30」の時 入場時間「17:00:00」の時 入場時間「19:59:59」の時 入場時間「20:00:00」の時 入場時間「23:59:59」の時 ?
  52. 62 2017/06/23公開用 JaSST’17 Kansai ワーク③:回答例 目的を達成するテストを集めてみました。 一部余ります⇒これら、どうしますか? 入場時間パラメータ を確認する 入場時間「00:00:00」の時

    入場時間「00:01:00」の時 入場時間「05:00:30」の時 入場時間「09:00:00」の時 入場時間「09:59:59」の時 入場時間「10:00:00」の時 入場時間「12:00:00」の時 入場時間「15:30:30」の時 入場時間「17:00:00」の時 入場時間「19:59:59」の時 入場時間「20:00:00」の時 同一結果となる それぞれ範囲を確認 範囲設定(境界)の ずれがないことを確認 理由 購入不可 通常料金 夜間料金(+300) 購入不可 09:59:59 10:00:00 17:59:59 18:00:00 19:59:59 20:00:00 境界の値は、プログラムで 間違いが多い(>≧) 23:59:59 00:00:00 理由 すべての「結果」となる パターン確認(網羅)する 入場時間「23:59:59」の時 入場時間「17:59:59」の時 入場時間「18:00:00」の時
  53. 63 2017/06/23公開用 JaSST’17 Kansai ワーク③:回答例 回答例。先ほど紹介していたテストケース目的を使用します。 テストケース テストケース目的 Target(仮) 購入計算

    機能 購入種別パラメータ を確認する 入場時間パラメータ を確認する パラメータの組合せ を確認する 1秒以内に計算が 完了することを確認 理由 1000人連続で 計算できること 「おとな」設定の反映 「こども」設定の反映 「設定なし」時の確認 入場時間「00:00:00」の時 入場時間「09:59:59」の時 入場時間「10:00:00」の時 入場時間「19:59:59」の時 入場時間「20:00:00」の時 入場時間「23:59:59」の時 入場時間「17:59:59」の時 入場時間「18:00:00」の時 1.納得できるテストを考えてみよう
  54. 66 2017/06/23公開用 JaSST’17 Kansai 目的と手段の重要性:まとめ 簡単にまとめてみます。 テストケースは「目的」を持つ 1.納得できるテストを考えてみよう 「目的」のないテストケースは 意味がない

    「目的」を考えることで、重複したテストケースや 優先しないケースも見えてきます。 ※普段の活動も同様で「目的」を考えることで、 不要なものが見えてくるかもしれません。
  55. 67 2017/06/23公開用 JaSST’17 Kansai 現場でためしてみるには 比較的やりやすいことは… 1.小さい範囲(改修など)で構造を使ってみる 2.過去の流用でテストをつくる際にリバースしてみる 1.納得できるテストを考えてみよう テストケース

    テストケース テストケース目的 テストケース目的 テストケース目的 Target (仮) ・・・ ・・・ 理由 理由 理由 ・・・ テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース 大量のテストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース テストケース目的 テストケース目的 テストケース目的 すぐに「試す」ことはできます。 使い続けることで上手く、速くなっていきます。 1.構造を使ってみる 2.リバースしてみる
  56. 68 2017/06/23公開用 JaSST’17 Kansai 現場でためしてみるには:注意事項 現場のテストケースは単純に整理できる「表現」では ない場合がありますので注意してください。 1.納得できるテストを考えてみよう 例1:混ざったテストケース⇒分解を推奨 例2:抽象的・曖昧すぎるテストケース

    ⇒テストケース目的かも。内容を明確に決めずに「逃げて」いる場合も。 同時に10人で購入計算を行い、 計算処理が1秒以内であること。 同時に10人で購入計算を行う。 計算処理が1秒以内であること。 パラメータを 確認する。 多人数で同時に使用 できること。 計算処理が手早く 終わること。 購入種別を 確認する。
  57. 69 2017/06/23公開用 JaSST’17 Kansai 現場でためしてみるには:推奨 テストケースは目的から辿る方が効果的と考えます。 ケースのレビュー、保守、管理がやりやすいためです。 手順作成(テスト実装)や実行時にまとめることを推奨します。 1.納得できるテストを考えてみよう テストケースB

    テストケースA テストケース 目的 ・・・ テストケースY テストケースX テストケース 目的 テスト手順書 もしくは実行時の手順 1.XXを準備する 2.(テストケースA) XXを押し、XXを確認 3.(テストケースB&Y) XXを入力してXXを確認 ・・・ ・・・
  58. 72 2017/06/23公開用 JaSST’17 Kansai 注意事項:②信頼と論理 1.納得できるテストを考えてみよう 今回紹介した構造的な「論理」をつくったとしても、 納得、信頼は得られない場合もあります。 ※不具合が多発している状況で顧客に「問題ないです!」と説明しても… “アリストテレスは説得の三要素として、語り手の信頼性(エトス)と、

    聞き手の感情に訴えること(パトス)、及び言論(ロゴス)を 用いることを挙げています。” 参考文献:ロジカル・シンキング入門(茂木秀昭氏)日経文庫 言論(ロゴス) ※論理のこと 感情に訴える (パトス) 信頼性 (エトス) 「論理」が良くても 納得して貰えない ことも当然あります。
  59. 73 2017/06/23公開用 JaSST’17 Kansai おさらい ※会社に報告する人は、ここだけ押さえておきましょうw 1.納得できるテストを考えてみよう ・納得できるテストはステークホルダにも テスト設計担当、開発者にも大事 ・構造化して、全体的に抜けがなく、

    根拠が示されることで納得につながる ・テストケースは何らかの「目的」を持つ ・テストケース目的を用いて構造化して、 1つ1つ確認できるようにすることが大事 ・構造を知っても使うことは難しいので、 目的-手段のトレーニングで鍛えよう
  60. 75 2017/06/23公開用 JaSST’17 Kansai 参考シリーズ:テストの目的 各種書籍、資料からの「テストの目的」をとりあげました。 1.納得できるテストを考えてみよう JSTQB FLシラバス(P14)より ISTQBテスト技術者資格制度

    Foundation Level シラバス 日本語版 Version 2011.J02 テストには以下のような目的がある。 欠陥を摘出する。 対象ソフトウェアの品質レベルが十分であることを確認する。 意志決定のための情報を示す。 欠陥の作りこみを防ぐ。 ソフトウェア・テストの技法(G.J.マイヤーズ)より ソフトウェア・テストとは、コンピュータ・コードが意図されたよう に動作し意図されないことはすべて実行しないように設計されている ことを検証するように設計されたプロセスである。 マインドマップからはじめるソフトウェアテストより ソフトウェアテストを行うと、ソフトウェアが作られていく過程で入り込んで しまうバグを発見することができ、そのバグを開発者が修正することによって、 ソフトウェアを利用者が安心して使用することができるようになる。
  61. 76 2017/06/23公開用 JaSST’17 Kansai 参考シリーズ:テストの目的 各種書籍、資料からの「テストの目的」をとりあげました。 1.納得できるテストを考えてみよう ソフトウェアテスト293の鉄則より テストの目的、<中略>を明らかにするため、 以下の項目を読んで自分に期待されていることを考えてほしい。

    ・重要なバグを速く見つける ・製品の品質を総合的に評価する ・製品が規格や標準に合致することを証明する ・製品の品質やテスト用威勢を顧客が改善できるよう支援する ・実際のテストのプロセスが、決められた責任や基準を満たすことを保証する ・テストの進め方や、テスト担当者と作業する際の注意点をプログラマに教育する ・ある決められた方法や規則に従う ・製品保守のコストを予測したり管理できるように支援する ・顧客が自分の業務プロセスを改善できるように支援する ・コストや工数、リスクが最小限になるように自分の仕事を実行する ・顧客を満足させるため、ありとあらゆることを実行する 基本から学ぶソフトウェアテストより バグを検出したテストが成功で、不具合を見つけられないテストは時間の無駄だ。
  62. 77 2017/06/23公開用 JaSST’17 Kansai 参考シリーズ:参考書籍と関連情報 こちらの資料は、「ソフトウェアテスト」と「論理思考」に 関連する書籍を参考としております。 1.納得できるテストを考えてみよう ▪ソフトウェアテスト関連書籍(一部です) ・ソフトウェアテストの基礎:ISTQBシラバス準拠

    ・ソフトウェアテスト293の鉄則 ・ソフトウェアテスト技法ドリル ▪論理思考関連書籍(一部です) ・グロービスMBAクリティカル・シンキング ・考える技術・書く技術―問題解決力を伸ばすピラミッド原則 ・世界一やさしい「思考法」の本
  63. 78 2017/06/23公開用 JaSST’17 Kansai 参考シリーズ:世の中のツール(D-Case) 今回の考えに近い記法・ツールとしてD-Caseを紹介してみます。 D-Case参考:http://www.dcase.jp/ 1.納得できるテストを考えてみよう D-Caseの記法(概要のみ) ゴール

    戦略 前提 エビデ ンス 対象システムに対して 議論すべき命題 (目的と捉えてもよい) ゴール達成を分割して 詳細化する時の方法 (分割理由と捉えてもよい) ゴールや戦略議論の 前提となる情報 (理由と捉えてもよい) 詳細化されたゴールを 最終的に保証するもの D-Caseの例 購入計算機能で 問題がない 画面の各構成と 品質面を確認 画面構成それぞれ で問題がない 品質面で 問題がない 各パラメータ と組合せ確認 品質特性から 必要項目確認 XXパラメータで… パラメータの 組合せで… レスポンスが1秒 … 1000人連続での 信頼性を…
  64. 80 2017/06/23公開用 JaSST’17 Kansai 参考シリーズ:テストカタマリー 今回の構造を保守する場合において、UMLツールを使用できる 「記法」を用いることで、作成・管理がやりやすくなります。 1.納得できるテストを考えてみよう + XX確認()

    : パラメータ組合せ確認 + 入場時間XX確認() : 単体パラメータ確認 + 購入種別パラメータXX確認() : 単体パラメータ確認 - 1000人連続で計算 : 信頼性 - 1秒以内に計算が完了 : 性能効率性 - パラメータ組合せ確認 : 機能適合性 - 単体パラメータ確認 : 機能適合性 購入計算機能 「おとな」設定時 購入種別パラメータ を確認する 購入計算 機能 入場時間パラメータ を確認する 「こども」設定時 パラメータの組合せ を確認する ・・・の時 テストケース テストケース テストケース テストケース 1秒以内に計算が 完了することを確認 理由 1000人連続で 計算出来ること ・・・ テストケース目的を属性に配置 テストケースをメソッドに配置 参考リンク テストカタマリーの紹介:まとめ http://blog.amateur-factory.jp/?eid=1444276 テストカタマリーを活用したテスト設計プロセス案:まとめ http://blog.amateur-factory.jp/?eid=1444278 Test Conglomeration - Proposal for Test Design Notation Like Class Diagram http://ieeexplore.ieee.org/document/7899074/
  65. 82 2017/06/23公開用 JaSST’17 Kansai 今までの内容は氷山の一角 2.納得できるテストを考えてみよう(全体編) 「おとな」設定時 購入種別パラメータ を確認する 購入計算

    機能 入場時間パラメータ を確認する 「こども」設定時 パラメータの組合せ を確認する ・・・の時 理由 テストケース テストケース テストケース テストケース 理由 ・・・ 今まで紹介した内容… 当然ですが(機能1つではなく) 「全体のテスト」を 考える必要が発生します。
  66. 83 2017/06/23公開用 JaSST’17 Kansai テスト全体を考えるには テスト全体を考えるにはどうしましょうか 2.納得できるテストを考えてみよう(全体編) 「おとな」設定時 購入種別パラメータ を確認する

    購入計算 機能 入場時間パラメータ を確認する 「こども」設定時 パラメータの組合せ を確認する ・・・の時 理由 テストケース テストケース テストケース テストケース 理由 ・・・ 購入計算機能 なんらかの ハコで表す 統計機能 ログ機能 リコメンド 機能 ・・・ 購入計算機能
  67. 86 2017/06/23公開用 JaSST’17 Kansai 仕様ベース テスト全体を考えるには 個々のパッケージは同じような構造化ができます。 2.納得できるテストを考えてみよう(全体編) 購入計算機能 統計機能

    リコメンド機能 ログ機能 ・・・ その他品質特性 ユースケース・シナリオ ひとつのパッケージは 「構造」にて表現できる 仕様 ベース 購入計算 機能 統計機能 ログ機能 理由 理由 ・・・ Target (仮) ↓の呼び方も 上位から考える と変わる
  68. 87 2017/06/23公開用 JaSST’17 Kansai どう分けるか:分け方も「理由」がある 例えば、全体を表すテストベースに「仕様一覧」と DFDの2つが存在しているかもしれません。 2.納得できるテストを考えてみよう(全体編) 仕様一覧 XXX

    YY PP AA OO DDD DDDD DFD一覧 仕様 ベース 購入計算 機能 統計機能 ログ機能 理由 理由 ・・・ DFD ベース 計算処理 購入処理 ・・・ 理由 理由 理由 理由 仕様一覧の分類 をもとに分ける ※なぜなら… DFDのプロセス と対応して分ける ※なぜなら…
  69. 89 2017/06/23公開用 JaSST’17 Kansai 構造:目的と手段の階層構造 階層構造を考えながら整理していきましょう。 2.納得できるテストを考えてみよう(全体編) 仕様ベース 購入計算機能 統計機能

    リコメンド機能 ログ機能 ・・・ 「おとな」設定時 購入種別パラメータ を確認する 購入計算 機能 入場時間パラメータ を確認する 「こども」設定時 パラメータの組合せ を確認する ・・・の時 理由 テストケース テストケース テストケース テストケース 理由 ・・・ 対象機能の1つに対する「構造」 パッケージに 対する「構造」 仕様 ベース 購入計算 機能 統計機能 ログ機能 理由 理由 ・・・
  70. 90 2017/06/23公開用 JaSST’17 Kansai 構造:目的と手段の階層構造 さらに全体に対しても同じようになっていきます。 ※最上位の目的になると「あたりまえ」に近づきます。 2.納得できるテストを考えてみよう(全体編) 品質を 確保する

    仕様 ベース ユース ケース 品質特性 理由 理由 仕様ベース 購入計算機能 統計機能 リコメンド機能 ログ機能 ・・・ その他品質特性 ユースケース・シナリオ 分割 理由
  71. 91 2017/06/23公開用 JaSST’17 Kansai テストにおける構造の一例とまとめ Target (仮) テストケース テストケース テストケース

    目的 理由 テストケース 理由 ・・・ 理由 テストケース 目的 テストケース 目的 理由 テストケース 目的 パッケー ジ分類 Target (仮) 理由 理由 Target (仮) Target (仮) 手段 目的 理由 手段 分割 理由 テストケース目的-テストケース Target-テストケース目的 パッケージ-Target 分割 理由 基本的な構造は 目的-手段-理由の カタチになります。 ※左に行くほど 抽象的・より全体的 になります。 2.納得できるテストを考えてみよう(全体編)
  72. 92 2017/06/23公開用 JaSST’17 Kansai テストケース目的の構造 パッケージ内の各ハコはテストケース目的を複数持っております。 これらは、同じものを使うことも多いでしょう。 2.納得できるテストを考えてみよう(全体編) 仕様ベース 購入計算機能

    統計機能 リコメンド機能 ログ機能 ・・・ 購入計算 機能の テスト ケース目的 購入種別パラメータ を確認する 購入計算 機能 入場時間パラメータ を確認する パラメータの組合せ を確認する ・・・ 理由 リコメンド 機能の テスト ケース目的 XXXパラメータを 確認する リコメンド 機能 パラメータの組合せ を確認する ・・・ 理由
  73. 93 2017/06/23公開用 JaSST’17 Kansai テストケース目的の構造:構造の整理 これらも、何らかの目的や基準とつながる構造として 表現することもできます。 2.納得できるテストを考えてみよう(全体編) 購入計算 機能の

    テスト ケース目的 購入種別パラメータ を確認する 購入計算 機能 入場時間パラメータ を確認する パラメータの組合せ を確認する ・・・ 理由 リコメンド 機能の テスト ケース目的 XXXパラメータを 確認する リコメンド 機能 パラメータの組合せ を確認する ・・・ 理由 テスト目的の構造(例) 機能適合性 単体パラメータを確認する パラメータ組合せを確認する 性能効率性 レスポンス 1秒以内に計算完了 信頼性 1000人連続で使用 「VSTeP」での「テスト観点」 構造に近くなる
  74. 94 2017/06/23公開用 JaSST’17 Kansai 2.納得できるテストを考えてみよう(全体編) テスト全体を考えるには:まとめ テストは全体を表現するために順次抽象化できます。 ※逆にすると段階的に詳細化出来ます。 それぞれの構造は「目的-手段の階層構造」でも考えられます。 「おとな」設定時

    購入種別パラメータ を確認する 購入計算 機能 入場時間パラメータ を確認する 「こども」設定時 パラメータの組合せ を確認する ・・・の時 理由 テストケース テストケース テストケース テストケース 理由 ・・・ 仕様ベース 購入計算機能 統計機能 リコメンド機能 ログ機能 ・・・ その他品質特性 ユースケース・シナリオ 抽象化 詳細化 テストケース目的は同じものを 何度も使う場合もあります。 それ自体を構造化ができます。 機能適合性 単体パラメータを確認する パラメータ組合せを確認する 性能効率性 レスポンス 1秒以内に計算完了 信頼性 1000人連続で使用
  75. 97 2017/06/23公開用 JaSST’17 Kansai 参考シリーズ:VSTePと関連情報 こちらの資料も、「ソフトウェアテスト」と「論理思考」に 関連する情報および文献を参考としております。 ▪ソフトウェアテスト関連 ・VSTeP(Viewpoint-based Software

    Test Engineering Process)が 「質の高いテストを行うためのテスト開発方法論」として 提案されております。本資料でも多数参考にしております。 参考リンク Qualab:http://qualab.jp/vstep/ ※テスト観点に基づくテスト開発方法論VSTePの概要 を参照 ▪論理思考書籍 ・世界一やさしい「思考法」の本 ※目的-手段の階層化構造での説明があります 2.納得できるテストを考えてみよう(全体編)
  76. 103 2017/06/23公開用 JaSST’17 Kansai お題:伊丹の仮想的な遊園地「いたみパーク(通称いたパー)」 いたパーWebシステムの「ログ機能」が対象です。 3.妥当性へ向けた問題発見へ むずかしい問題:ワーク対象 済 No.

    済 番号 ・顧客のWebチケット購入処理 ・企画によるイベント登録時、イベント削除・編集時 ・企画による統計グラフ作成時 1週間以上のログを残すこと。 ログ機能は、JaSST関西ワー クショップ「いたパーWebシ ステム概要」P7-P9も参照の こと。 次のタイミングで操作実施の時間、ログを残す。 ▪ 2 ログ領域を使い切ることがないよう、ローテーションでデータの削除を実施する。 ▪ 1 使用番号 PARKSPEC-03 タイトル ログ機能 説明 保守向けとして、ユーザの操作を記録にとり、不具合発生時における関連性を調査可能にする。 ▪ 1 タイトル ログ作成機能 説明 顧客のWebチケット購入時、企画によるイベント登録時、イベント削除・編集時、統計グラフ作 成時における操作ログを残す。 QRコードによる入場カウン ト、アトラクション使用カウ ントは対象外。 仕様詳細
  77. 105 2017/06/23公開用 JaSST’17 Kansai 途中までをできる限り構造化してみましょう。 3.妥当性へ向けた問題発見へ むずかしい問題:途中まで検討 ログ書出し条件の 入出力を確認する ログ

    機能 同時書き込みでの 動作を確認する 削除しつつ1週間 以上ログを残す 理由 複数機能より同時に ログが書き込まれる 可能性があるため
  78. 106 2017/06/23公開用 JaSST’17 Kansai 記載以外は「??」となる部分が出てきます。 3.妥当性へ向けた問題発見へ むずかしい問題:途中まで検討 複数機能より同時に ログが書き込まれる 可能性があるため

    現状の動き ログ書出し条件の 入出力を確認する ログ 機能 同時書き込みでの 動作を確認する 削除しつつ1週間 以上ログを残す 理由 ?? ?? ??
  79. 107 2017/06/23公開用 JaSST’17 Kansai 4つの「困難」な理由を挙げてみます。 3.妥当性へ向けた問題発見へ むずかしい問題:4つの困難 ログ書出し条件の 入出力を確認する ログ

    機能 同時書き込みでの 動作を確認する 削除しつつ1週間 以上ログを残す 理由 問題を特定できない (知識ギャップ) 問題が曖昧・抽象的 ?? 現状の動き 現状を把握できない (知識ギャップ) 4つの困難 1.現状を把握できない 2.問題を特定できない (問題≒解決すべきもの) 3.問題が曖昧・抽象的 4.実現への懸念 「知識ギャップ」 も存在している。
  80. 108 2017/06/23公開用 JaSST’17 Kansai 情報を追加してみます。 3.妥当性へ向けた問題発見へ むずかしい問題:現状の把握 ログ書出し条件の 入出力を確認する ログ

    機能 同時書き込みでの 動作を確認する 1週間以上 ログを残す 理由 問題を特定できない (知識ギャップ) 問題が曖昧・抽象的 ?? 現状の動き 現状を把握できない (知識ギャップ) 4つの困難 1.現状を把握できない 2.問題を特定できない (問題≒解決すべきもの) 3.問題が曖昧・抽象的 4.実現への懸念 「知識ギャップ」 も存在している。 <想定動作・設計時の見込み> ログ書込み方法:購入、統計のトリガ発生時に書込み。 「発生時間,種別ID,イベント内容(ASCII),引数1,引数2,…」 削除方法:毎日23:59:00に8日以上前のデータ削除 1回の書き込みデータ量:最大1024Byte 書き込み頻度: チケット購入機能・・・1日2,000回が最大 統計機能・・・1日5回が最大 ログ容量:1GByteを用意
  81. 109 2017/06/23公開用 JaSST’17 Kansai ログ書込み方法:購入、統計のトリガ発生時に書込み 時間,種別ID,イベント内容(ASCII),引数1,引数2,… 削除方法:毎日23:59:00に8日以上前のデータ削除 1回の書き込みデータ量:最大1024Byte 書き込み頻度: チケット購入機能・・・1日2,000回が最大

    統計機能・・・1日5回が最大 ログ容量:1GByteを用意 3.妥当性へ向けた問題発見へ 情報を追加してみます。 むずかしい問題:テストケースまで ログ書出し条件の 入出力を確認する ログ 機能 同時書き込みでの 動作を確認する 削除しつつ1週間 以上ログを残す 理由 でき そう 4つの困難 1.現状を把握できない 2.問題を特定できない (問題≒解決すべきもの) 3.問題が曖昧・抽象的 4.実現への懸念 容量超過しない 削除されすぎない 1週間連続で確認 1データサイズ 現状の動き(設計想定) テストケース テストケース テストケース テストケース 実書込み頻度 (使用状況にて) テストケース テストケース テストケース テストケース こうかな?
  82. 110 2017/06/23公開用 JaSST’17 Kansai ログ書込み方法:購入、統計のトリガ発生時に書込み 時間,種別ID,イベント内容(ASCII),引数1,引数2,… 削除方法:毎日23:59:00に8日以上前のデータ削除 1回の書き込みデータ量:最大1024Byte 書き込み頻度: チケット購入機能・・・1日2,000回が最大

    統計機能・・・1日5回が最大 ログ容量:1GByteを用意 3.妥当性へ向けた問題発見へ むずかしい問題:解決ポイントマッピング ログ書出し条件の 入出力を確認する ログ 機能 同時書き込みでの 動作を確認する 削除しつつ1週間 以上ログを残す 理由 でき そう 4つの困難⇒解決ポイント 1.現状を把握 2.問題を定義 (問題≒解決すべきもの) 3.問題を分割・整理 4.解決策を決める 容量超過しない 削除されすぎない 1週間連続で確認 1データサイズ 現状の動き(設計想定) テストケース テストケース テストケース テストケース 実書込み頻度 (使用状況にて) テストケース テストケース テストケース テストケース 問題を定義、問題を分割・整理 問題を定義 現状の把握 解決策を決める 問題を分割・整理 ※実験的 に考える 場合も さらに上位の検討 から発見へ 仕様ベース 購入計算機能 統計機能 リコメンド機能 ログ機能 ・・・ その他品質特性 ユースケース・シナリオ
  83. 111 2017/06/23公開用 JaSST’17 Kansai 途中段階で「知らない」ことが、わかることが重要です。 3.妥当性へ向けた問題発見へ むずかしい問題:「知らない」がわかる 現状の動き ログ書出し条件の 入出力を確認する

    ログ 機能 同時書き込みでの 動作を確認する 削除しつつ1週間 以上ログを残す 理由 ?? ?? ?? 4つの困難⇒解決ポイント 1.現状を把握 2.問題を定義 (問題≒解決すべきもの) 3.問題を分割・整理 4.解決策を決める この範囲、 「知らない」ことが わかることが大事
  84. 112 2017/06/23公開用 JaSST’17 Kansai 「知らないこと」「知らない部分がある」ことをわかること、 知っている部分と知らない部分を分けることが大事 3.妥当性へ向けた問題発見へ 「知ってる/知らない」と「わかる/わからない」 知識がある (知っている)

    知識がない (知らない) 自分の知識状況を 理解している (わかる) 知っていることを わかっている 知らないことを わかる (知識ギャップ) 自分の知識状況を 理解していない (わからない) 知っていることを わからない (暗黙知) 知らないことが わからない (愚者の天国)
  85. 113 2017/06/23公開用 JaSST’17 Kansai 科学的なアプローチ わからないことに対しては、論理構造を明確にしながら、 一つずつ根拠を明確にしながら仮説検証を繰り返していきます。 3.妥当性へ向けた問題発見へ XXX ??

    仮説 仮説 XXX OK 仮説 仮説 仮説 検証済 仮説構築 ⇒実際には手さぐりで進めることも多いですが、「構造」を活用しつつ 実験や観察といった活動で1つ1つ検証しながら進めます。 ”基本的に,さまざまな科学的学問は, 証拠への依存,仮説と理論の使用,用いられる 論理の種類等において共通している。” *引用:SFAA(すべてのアメリカ人のための科学)より 検証& 仮説構築
  86. 114 2017/06/23公開用 JaSST’17 Kansai 科学的なアプローチ:わからない部分へ ワーク①での考え方の例を紹介してみます。 3.妥当性へ向けた問題発見へ 購入計算 機能 1秒以内に計算が

    完了することを確認 理由 ・0.1秒までなら応答が瞬時に 返ってきたという印象を与える。 ・1秒までならユーザーの思考は 途切れなく流れる。 ・10秒までならユーザーの注意力は続く。 ・10秒遅延してしまうと、ユーザーが即、 サイトから離れてしまうことも多くなる。 (Webサイトの応答時間 – U-Site, 2010/06/21)ニールセン氏 https://note.mu/tsukamoto/n/nde7fe5e21216 明確な情報がなかった 場合にはどうするか?
  87. 115 2017/06/23公開用 JaSST’17 Kansai 科学的なアプローチ:わからない部分へ ワーク①での考え方の例を紹介してみます。 3.妥当性へ向けた問題発見へ 購入計算 機能 ??秒以内に計算が

    完了することを確認 理由 1秒の応答で10人から 意見を獲得する 3秒の応答で10人から 意見を獲得する 例えば、1秒と3秒のどちらかにする、 という判断までをして検証を行ってみる… といったこともできます。
  88. 116 2017/06/23公開用 JaSST’17 Kansai 科学的なアプローチ:わからない部分へ ワーク①での考え方の例を紹介してみます。 3.妥当性へ向けた問題発見へ 購入計算 機能 理由

    実際の人数を確認する (必要に応じて強化) 1000人連続で 計算出来ること オープン前で予測だが、 1000人が損益分岐のため この人数で設定する
  89. 117 2017/06/23公開用 JaSST’17 Kansai 科学的なアプローチ:わからない部分へ ワーク①での考え方の例を紹介してみます。 3.妥当性へ向けた問題発見へ 購入計算 機能 理由

    実際の人数を確認する (必要に応じて強化) 1000人連続で 計算出来ること オープン前で予測だが、 1000人が損益分岐のため この人数で設定する 実際の人数が 5000人超過 ひらパーで年間100万人。 年250日開業で1日平均4000人
  90. 118 2017/06/23公開用 JaSST’17 Kansai 科学的なアプローチ:仮説検証の繰り返し 小惑星への接触を考えるような場合には 「シミュレーション」と「実験」を繰り返して納得感を高めます。 3.妥当性へ向けた問題発見へ 小惑星への接近時で 問題ないことを確認

    小惑星への 接触が上手く 行くことを 確認する 接触における地面の 形状に対して・・・ ・・・ 実験データ 実験データ 実験データ ・・・ 実験 シミュレーション 論理構築 シミュレーション シミュレーション シミュレーション
  91. 122 2017/06/23公開用 JaSST’17 Kansai 参考シリーズ:問題解決と科学の活動 こちらの資料は、「問題解決」と「科学の活動」に 関連する文献を参考としております。 ▪問題解決関連書籍(一部です) ・世界一やさしい問題解決の授業 ・仮説思考

    BCG流 問題発見・解決の発想法 ・問題発見プロフェッショナル―「構想力と分析力」 ▪科学的なアプローチ ・すべてのアメリカ人のための科学 - Project 2061 http://www.project2061.org/publications/sfaa/SFAA_Japanese.pdf ・Wikipedia「科学的方法」 3.妥当性へ向けた問題発見へ
  92. 123 2017/06/23公開用 JaSST’17 Kansai おさらい(全体編) ※会社に報告する人は、ここだけ押さえておきましょうw ・納得できるテストをつくるため、 「構造」を意識して全体、つながりを考えよう ・テストケースには目的が存在する ・目的を用いて構造化することで、

    「説明」「検討(ケース作成)」ができる ・「目的-手段」の階層化でトレーニングしよう ・構造化でむずかしい問題に取り組むことも可能 次の4点で考えてみる⇒「現状を把握」、「問題を定義」、 「問題を分割・整理」、「解決策を決める」 ・仮説-検証アプローチが困難な問題に役立つ