納得できるテストをつくるアプローチ（JaSST'17 Kansai向け）
•
17 gostaram•6,182 visualizações
自信をもってプロダクトを送り届けるために、また、心配なステークホルダに説明するために、自分も相手も「納得できる」溜めのテストを考える、整理する方法を紹介してみます。
Recomendados
Recomendados
Mais conteúdo relacionado
Mais de Noriyuki Mizuno
Mais de Noriyuki Mizuno (16)
Último
Último (10)
納得できるテストをつくるアプローチ（JaSST'17 Kansai向け）
- 7. 72017/06/23公開用 JaSST’17 Kansai ワーク①：テストでの説明を考えてみましょう 「自信が持てる」「説明できる」 （納得できる） テストは大事そうですが、どうすればよいかを 一度、考えてみましょう。 ＜ワーク内容＞ 次ページに「お題」のテスト対象があります。 １．テストケースをつくってみましょう（５分） ２．近くの人に説明してみましょう（５分） ※ひと段落したら誰かに聞いてみようと思います。 1．納得できるテストを考えてみよう
- 8. 82017/06/23公開用 JaSST’17 Kansai ワーク①：テスト対象とワーク内容 お題：遊園地的な場所への入場システム、券売機です。 「購入計算画面」（左側）のテストが対象となります。 現在時間：１７:００:１５ 購入種別（選択式） おとな こども 計算 料金表 おとな（15才以上）1000円 こども（14才以下）500円 10:00-17:59入場 通常料金 18:00-19:59入場 +300円 ※上記時間以外は購入不可 計算結果： 時間： １７：００：１６ おとな： １枚 支払いは １０００円です 購入計算画面 購入画面 ・通常料金チケットは18:05まで使用（入場）可能です ・計算ボタンを押したタイミングで時間が決定します ・購入者の妥当性チェックはシステム上はありません ・ユーザビリティは（あえて）考慮してませんので テストからも外していただいてOKです ・妥当性はあまり気にせず＋深読みしなくてよいです 1．納得できるテストを考えてみよう
- 9. 92017/06/23公開用 JaSST’17 Kansai ワーク①：完了 他の人の説明で 納得できましたか？ 自分で考えた説明は 納得のいく内容でしたか？ 1．納得できるテストを考えてみよう
- 19. 192017/06/23公開用 JaSST’17 Kansai 納得できるテストでの説明：重要な定義 構造を考える際に１つ重要な定義をしてみます。 それぞれのテストケース（グループ）は なんらかの「目的」を持つ JSTQB AL TA シラバスにも テストケースが 目的を持つという 記述があります。 引用：ISTQBテスト技術者資格制度 Advanced Level シラバス 日本語版 テストアナリスト Version2012.J01 P13 1．納得できるテストを考えてみよう
- 23. 232017/06/23公開用 JaSST’17 Kansai テストベースに記述追加 お題：遊園地的な場所への入場システム、券売機です。 現在時間：１７:００:１５ 購入種別 おとな こども 計算 料金表 おとな（15才以上）1000円 こども（14才以下）500円 10:00-17:59入場 通常料金 18:00-19:59入場 +300円 ※上記時間以外は購入不可 計算結果： 時間： １７：００：１６ おとな： １枚 支払いは １０００円です 購入計算画面 購入画面 ・購入客を計算で待たせないこと ・通常料金チケットは18:05まで使用（入場）可能です ・計算ボタンを押したタイミングで時間が決定します ・購入者の妥当性チェックはシステム上はありません ・ユーザビリティは（あえて）考慮してませんので テストからも外していただいてOKです 1．納得できるテストを考えてみよう 追加
- 24. 242017/06/23公開用 JaSST’17 Kansai 納得できるテストの構造：使い方（例） ワーク①を例に作り方の流れを紹介してみます。 1．納得できるテストを考えてみよう テストケーステストケース目的Target（仮） 「おとな」設定時 購入種別パラメータ を確認する 購入計算 機能 入場時間パラメータ を確認する パラメータの組合せ を確認する ・・・の時 理由 テストケーステストケーステストケーステストケース 理由１秒以内に計算が 完了することを確認 理由 ・0.1秒までなら応答が瞬時に 返ってきたという印象を与える。 ・1秒までならユーザーの思考は 途切れなく流れる。 ・10秒までならユーザーの注意力は続く。 ・10秒遅延してしまうと、ユーザーが即、 サイトから離れてしまうことも多くなる。 （Webサイトの応答時間 – U-Site, 2010/06/21）ニールセン氏 https://note.mu/tsukamoto/n/nde7fe5e21216 ・・・
- 33. 332017/06/23公開用 JaSST’17 Kansai テストの（納得への）構造：使い方と利点① 「説明」時における使い方です。これは説明済み。 ※Javaly Parkの例 1．納得できるテストを考えてみよう 「おとな」設定時 購入種別パラメータ を確認する 購入計算 機能 入場時間パラメータ を確認する パラメータの組合せ を確認する ・・・の時 理由 テストケーステストケーステストケーステストケース 理由 １秒以内に計算が 完了することを確認 理由１０００人連続で 計算できること 理由 ・・・ ・・・
- 34. 342017/06/23公開用 JaSST’17 Kansai テストの（納得への）構造：使い方と利点② 一連のテストケース目的に対する議論や知識の蓄積にて 「成長」ができます。※Javaly Parkの例 1．納得できるテストを考えてみよう 購入種別パラメータ を確認する 購入計算 機能 入場時間パラメータ を確認する パラメータの組合せ を確認する １秒以内に計算が 完了することを確認 理由１０００人連続で 計算できること 理由 ハイスキルの エンジニアの経験 想定されるリスク 分からない部分を聞く 知見ある人に意見貰う PDCAと 知識の蓄積へ
- 36. 362017/06/23公開用 JaSST’17 Kansai テストの（納得への）構造：まとめ 利点・使い方 １．説明、２．成長、３．確認 1．納得できるテストを考えてみよう テストケース テストケーステストケース目的 テストケース目的 テストケース目的 Target （仮） ・・・ ・・・ 理由 理由 理由 ・・・１．テストケース 目的を説明に使う ２．テストケース 目的を議論や知識 の蓄積で成長へ ３．構造の１つ１つ を取り出して確認
- 38. 382017/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 ↓の情報は、「料金画面」で記述します。カレンダーから 選択可能
- 39. 392017/06/23公開用 JaSST’17 Kansai ワーク②：テスト対象とワーク内容 「Webチケット購入画面」のテストを考えてみましょう。 テストケース テストケーステストケース目的 テストケース目的 テストケース目的 Webチケット 購入画面 ・・・ ・・・ 理由 理由 理由 ・・・ ★次の構造で考えてみましょう！★
- 42. 422017/06/23公開用 JaSST’17 Kansai むずかしい理由 1．納得できるテストを考えてみよう いくつかむずかしい理由が存在します。 ・なれるまで時間がかかる ・知識ギャップ①：テストケース目的の知識 ・知識ギャップ②：テスト技法（作り方）の知識 ・目的－手段の思考方法（考えることが少ない） テストケース テストケーステストケース目的 テストケース目的 テストケース目的 Target （仮） ・・・ ・・・ 理由 理由 理由 ・・・ 知識ギャップ① 知識ギャップ②
- 43. 432017/06/23公開用 JaSST’17 Kansai むずかしい理由⇒解決策 1．納得できるテストを考えてみよう 解決策の例となります。 ・なれるまで時間がかかる ⇒ 使ってみてなれましょう！ ・知識ギャップ①：テストケース目的の知識 ⇒ パターンや知見を集めることが有効 「VSTeP」の知見も役立ちます ・知識ギャップ②：テスト技法（作り方）の知識 ⇒ テスト技法を勉強してみよう WACATE、WARAI、技法ドリル ・目的－手段の思考方法（考えることが少ない）
- 44. 442017/06/23公開用 JaSST’17 Kansai むずかしい理由⇒解決策 1．納得できるテストを考えてみよう テストケース目的の知見を集める、整理する方法の例 「テストタイプ」や品質モデル（ISO250XX等）を知り、 そこから整理する。 「テストタイプ」 からの整理の例 「品質モデル」 からの整理の例 ネットワーク負荷時の確認 連続使用人数の確認 同時複数人使用の確認 連続使用時間の確認 パラメータ組合せ確認 パラメータ単体確認 テスト タイプ ストレステスト 信頼性テスト 機能テスト 機能適合性 - 性能評価 性能効率性 ボリューム - 結果網羅 ふるまい - 結果網羅 機能排他 レスポンス
- 45. 452017/06/23公開用 JaSST’17 Kansai 目的－手段の思考方法の重要性 テストケース目的セットを用意することでも対処はできますが… テストケース 目的セット テストケース 目的 手段 テストケース XXXパラメータ を確認する パラメータ 組合せを確認する レスポンス を確認 最大アクセス 数で確認 テストケーステストケーステストケーステストケース テストケース目的 ない？ （新しい） テストケース目的 テストケーステストケーステストケーステストケース 引用 レビューで チェック 新たに 追加 1．納得できるテストを考えてみよう
- 46. 462017/06/23公開用 JaSST’17 Kansai 目的－手段の思考方法の重要性 テストケース目的セットを用意することでも対処はできますが… テストケース 目的セット テストケース 目的 手段 テストケース XXXパラメータ を確認する パラメータ 組合せを確認する レスポンス を確認 最大アクセス 数で確認 テストケーステストケーステストケーステストケース テストケース目的 ない？ （新しい） テストケース目的 テストケーステストケーステストケーステストケース 引用 レビューで チェック 新たに 追加 「自分のアタマで考える」 必要は必ず発生します この場合に、目的－手段の 思考方法が役に立ちます 1．納得できるテストを考えてみよう
- 48. 482017/06/23公開用 JaSST’17 Kansai 目的－手段の重要性：例 1．納得できるテストを考えてみよう 手段目的 理由 基本の構造は 「目的－手段（＋理由）」 目覚ましを セットして寝る JaSSTに 朝から参加して 情報を得る ＜目的＞ ＜手段＞ 早めに おふとん.in 前日の お酒を控える
- 49. 492017/06/23公開用 JaSST’17 Kansai 目的－手段の重要性：例 1．納得できるテストを考えてみよう 手段目的 理由 基本の構造は 「目的－手段（＋理由）」 目覚ましを セットして寝る JaSSTに 朝から参加して 情報を得る ＜目的＞ ＜手段＞ 早めに おふとん.in 前日の お酒を控える 目覚ましを セットして寝る 午後の講演を 最大限に 良いモノにする ＜目的＞ ＜手段＞ ？
- 50. 502017/06/23公開用 JaSST’17 Kansai 目的－手段の重要性：いろいろ役立つ 1．納得できるテストを考えてみよう 手段目的 理由 基本の構造は 「目的－手段（＋理由）」 目覚ましを セットして寝る JaSSTに 朝から参加して 情報を得る ＜目的＞ ＜手段＞ 早めに おふとん.in 前日の お酒を控える 目覚ましを セットして寝る 午後の講演を 最大限に 良いモノにする ＜目的＞ ＜手段＞ 遅刻してでも 十分な睡眠を とる 理由： 睡眠時間が 確保できないと キレが悪い 目的がわかると 他の手段を見つける こともできる 目的が異なると 手段も変わる 目的から手段を チェックできる
- 51. 512017/06/23公開用 JaSST’17 Kansai 目的－手段の重要性：例題 目的－手段は普段から考えることもできます。 以下のような例題を簡単に考えてみましょう。 ＜例題＞ 目的を考えてみましょう！ ・直近に実施したレビューの目的はなんでしょう？ ・開発やテストで実施している 現在実施中のプロセスの目的はなんでしょう？ ・本セッションに参加する目的はなんでしょう？ ・勉強する目的はなんでしょう？（子供のケースでもOK） ・思考フレームワーク（目的-手段など）を 使う目的はなんでしょう？ 1．納得できるテストを考えてみよう
- 55. 552017/06/23公開用 JaSST’17 Kansai ワーク③：テストケースから目的を取り出す ワーク①「Javaly Park」購入計算機能に対して、 テストケースだけを用意してみました。 1．納得できるテストを考えてみよう テストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケース テストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケース テストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケース テストケース テストケーステストケーステストケーステストケース テストケーステストケーステストケーステストケース テストケーステストケーステストケーステストケース テストケース目的 テストケース目的 テストケース目的 ＜ワーク内容＞ １．テストケースを目的で整理しましょう ２．不足の追加や整理をしてみましょう
- 56. 562017/06/23公開用 JaSST’17 Kansai ワーク③：テスト対象とワーク内容 お題：遊園地的な場所への入場システム、券売機です。 「購入計算画面」（左側）のテストが対象となります。 現在時間：１７:００:１５ おとな こども 計算 料金表 おとな（15才以上）1000円 こども（14才以下）500円 10:00-17:59入場 通常料金 18:00-19:59入場 +300円 ※上記時間以外は購入不可 計算結果： 時間： １７：００：１６ おとな： １枚 支払いは １０００円です 購入計算画面 購入画面 ・通常料金チケットは18:05まで使用（入場）可能です ・計算ボタンを押したタイミングで時間が決定します ・購入者の妥当性チェックはシステム上はありません ・ユーザビリティは（あえて）考慮してませんので テストからも外していただいてOKです 1．納得できるテストを考えてみよう 購入種別（選択式）
- 62. 622017/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」の時
- 67. 672017/06/23公開用 JaSST’17 Kansai 現場でためしてみるには 比較的やりやすいことは… １．小さい範囲（改修など）で構造を使ってみる ２．過去の流用でテストをつくる際にリバースしてみる 1．納得できるテストを考えてみよう テストケース テストケーステストケース目的 テストケース目的 テストケース目的 Target （仮） ・・・ ・・・ 理由 理由 理由 ・・・ テストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケース テストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケース テストケーステストケーステストケーステストケーステストケーステストケーステストケーステストケース 大量のテストケース テストケーステストケーステストケーステストケース テストケーステストケーステストケーステストケース テストケーステストケーステストケーステストケース テストケース目的 テストケース目的 テストケース目的 すぐに「試す」ことはできます。 使い続けることで上手く、速くなっていきます。 １．構造を使ってみる ２．リバースしてみる
- 71. 712017/06/23公開用 JaSST’17 Kansai 注意事項：①「完璧な」テストではない ・作成結果は、「実力どおり」の内容となります。 ・ただし、構造が明確になるので成長はできます。 ・関連する人たちの知見を集めることで 「その時点でのベスト」は可能かと思われます。 1．納得できるテストを考えてみよう 納得できるテスト ≠ 完璧な、よくできたテスト （不具合の出ないテスト？） ここだけは勘違いしないようにしてください。
- 74. 742017/06/23公開用 JaSST’17 Kansai メインコンテンツ・完！ 以上でメインコンテンツが完了となります。 1．納得できるテストを考えてみよう １．納得できるテストを考えてみよう
- 75. 752017/06/23公開用 JaSST’17 Kansai 参考シリーズ：テストの目的 各種書籍、資料からの「テストの目的」をとりあげました。 1．納得できるテストを考えてみよう JSTQB FLシラバス（P14）より ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2011.J02 テストには以下のような目的がある。 欠陥を摘出する。 対象ソフトウェアの品質レベルが十分であることを確認する。 意志決定のための情報を示す。 欠陥の作りこみを防ぐ。 ソフトウェア・テストの技法（G.J.マイヤーズ）より ソフトウェア・テストとは、コンピュータ・コードが意図されたよう に動作し意図されないことはすべて実行しないように設計されている ことを検証するように設計されたプロセスである。 マインドマップからはじめるソフトウェアテストより ソフトウェアテストを行うと、ソフトウェアが作られていく過程で入り込んで しまうバグを発見することができ、そのバグを開発者が修正することによって、 ソフトウェアを利用者が安心して使用することができるようになる。
- 79. 792017/06/23公開用 JaSST’17 Kansai 参考シリーズ：世の中のツール（USDM） 要求仕様を記述するための「USDM」において、 今回の内容と近い構造が示されております。 参考文献：要求を仕様化する技術・表現する技術 -仕様が書けていますか? 1．納得できるテストを考えてみよう ※USDMでは「要求」と「仕様」の 階層構造を持つ 仕様 仕様（手段）要求 （目的） 理由 仕様 ツリー構造で示すと 今回の構造と近い形になる
- 80. 802017/06/23公開用 JaSST’17 Kansai 参考シリーズ：テストカタマリー 今回の構造を保守する場合において、UMLツールを使用できる 「記法」を用いることで、作成・管理がやりやすくなります。 1．納得できるテストを考えてみよう + XX確認() : パラメータ組合せ確認 + 入場時間XX確認() : 単体パラメータ確認 + 購入種別パラメータXX確認() : 単体パラメータ確認 - 1000人連続で計算 : 信頼性 - 1秒以内に計算が完了 : 性能効率性 - パラメータ組合せ確認 : 機能適合性 - 単体パラメータ確認 : 機能適合性 購入計算機能 「おとな」設定時 購入種別パラメータ を確認する 購入計算 機能 入場時間パラメータ を確認する 「こども」設定時 パラメータの組合せ を確認する ・・・の時 テストケーステストケーステストケーステストケース １秒以内に計算が 完了することを確認 理由１０００人連続で 計算出来ること ・・・ テストケース目的を属性に配置 テストケースをメソッドに配置参考リンク テストカタマリーの紹介：まとめ 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/
- 83. 832017/06/23公開用 JaSST’17 Kansai テスト全体を考えるには テスト全体を考えるにはどうしましょうか ２．納得できるテストを考えてみよう（全体編） 「おとな」設定時 購入種別パラメータ を確認する 購入計算 機能 入場時間パラメータ を確認する 「こども」設定時 パラメータの組合せ を確認する ・・・の時 理由 テストケーステストケーステストケーステストケース 理由・・・ 購入計算機能 なんらかの ハコで表す 統計機能 ログ機能 リコメンド 機能 ・・・ 購入計算機能
- 85. 852017/06/23公開用 JaSST’17 Kansai 仕様ベース テスト全体を考えるには テスト全体を考えるにはどうしましょうか ２．納得できるテストを考えてみよう（全体編） パッケージは他の ものも定義できる 購入計算機能統計機能 リコメンド機能 ログ機能 ・・・ その他品質特性 ユースケース・シナリオ
- 86. 862017/06/23公開用 JaSST’17 Kansai 仕様ベース テスト全体を考えるには 個々のパッケージは同じような構造化ができます。 ２．納得できるテストを考えてみよう（全体編） 購入計算機能統計機能 リコメンド機能 ログ機能 ・・・ その他品質特性 ユースケース・シナリオ ひとつのパッケージは 「構造」にて表現できる 仕様 ベース 購入計算 機能 統計機能 ログ機能 理由 理由 ・・・Target （仮） ↓の呼び方も 上位から考える と変わる
- 87. 872017/06/23公開用 JaSST’17 Kansai どう分けるか：分け方も「理由」がある 例えば、全体を表すテストベースに「仕様一覧」と DFDの２つが存在しているかもしれません。 ２．納得できるテストを考えてみよう（全体編） 仕様一覧 XXX YY PP AA OODDD DDDD DFD一覧 仕様 ベース 購入計算 機能 統計機能 ログ機能 理由 理由 ・・・ DFD ベース 計算処理 購入処理 ・・・ 理由 理由 理由 理由 仕様一覧の分類 をもとに分ける ※なぜなら… DFDのプロセス と対応して分ける ※なぜなら…
- 89. 892017/06/23公開用 JaSST’17 Kansai 構造：目的と手段の階層構造 階層構造を考えながら整理していきましょう。 ２．納得できるテストを考えてみよう（全体編） 仕様ベース 購入計算機能統計機能 リコメンド機能 ログ機能 ・・・ 「おとな」設定時 購入種別パラメータ を確認する 購入計算 機能 入場時間パラメータ を確認する 「こども」設定時 パラメータの組合せ を確認する ・・・の時 理由 テストケーステストケーステストケーステストケース 理由・・・ 対象機能の１つに対する「構造」 パッケージに 対する「構造」 仕様 ベース 購入計算 機能 統計機能 ログ機能 理由 理由 ・・・
- 90. 902017/06/23公開用 JaSST’17 Kansai 構造：目的と手段の階層構造 さらに全体に対しても同じようになっていきます。 ※最上位の目的になると「あたりまえ」に近づきます。 ２．納得できるテストを考えてみよう（全体編） 品質を 確保する 仕様 ベース ユース ケース 品質特性 理由 理由 仕様ベース 購入計算機能統計機能 リコメンド機能 ログ機能 ・・・ その他品質特性 ユースケース・シナリオ 分割 理由
- 92. 922017/06/23公開用 JaSST’17 Kansai テストケース目的の構造 パッケージ内の各ハコはテストケース目的を複数持っております。 これらは、同じものを使うことも多いでしょう。 ２．納得できるテストを考えてみよう（全体編） 仕様ベース 購入計算機能統計機能 リコメンド機能 ログ機能 ・・・ 購入計算 機能の テスト ケース目的 購入種別パラメータ を確認する 購入計算 機能 入場時間パラメータ を確認する パラメータの組合せ を確認する ・・・ 理由 リコメンド 機能の テスト ケース目的 XXXパラメータを 確認する リコメンド 機能 パラメータの組合せ を確認する ・・・ 理由
- 93. 932017/06/23公開用 JaSST’17 Kansai テストケース目的の構造：構造の整理 これらも、何らかの目的や基準とつながる構造として 表現することもできます。 ２．納得できるテストを考えてみよう（全体編） 購入計算 機能の テスト ケース目的 購入種別パラメータ を確認する 購入計算 機能 入場時間パラメータ を確認する パラメータの組合せ を確認する ・・・ 理由 リコメンド 機能の テスト ケース目的 XXXパラメータを 確認する リコメンド 機能 パラメータの組合せ を確認する ・・・ 理由 テスト目的の構造（例） 機能適合性 単体パラメータを確認する パラメータ組合せを確認する 性能効率性 レスポンス １秒以内に計算完了 信頼性 １０００人連続で使用 「VSTeP」での「テスト観点」 構造に近くなる
- 94. 942017/06/23公開用 JaSST’17 Kansai２．納得できるテストを考えてみよう（全体編） テスト全体を考えるには：まとめ テストは全体を表現するために順次抽象化できます。 ※逆にすると段階的に詳細化出来ます。 それぞれの構造は「目的－手段の階層構造」でも考えられます。 「おとな」設定時 購入種別パラメータ を確認する 購入計算 機能 入場時間パラメータ を確認する 「こども」設定時 パラメータの組合せ を確認する ・・・の時 理由 テストケーステストケーステストケーステストケース 理由・・・ 仕様ベース 購入計算機能統計機能 リコメンド機能 ログ機能 ・・・ その他品質特性 ユースケース・シナリオ 抽象化 詳細化 テストケース目的は同じものを 何度も使う場合もあります。 それ自体を構造化ができます。 機能適合性 単体パラメータを確認する パラメータ組合せを確認する 性能効率性 レスポンス １秒以内に計算完了 信頼性 １０００人連続で使用
- 97. 972017/06/23公開用 JaSST’17 Kansai 参考シリーズ：VSTePと関連情報 こちらの資料も、「ソフトウェアテスト」と「論理思考」に 関連する情報および文献を参考としております。 ■ソフトウェアテスト関連 ・VSTeP（Viewpoint-based Software Test Engineering Process）が 「質の高いテストを行うためのテスト開発方法論」として 提案されております。本資料でも多数参考にしております。 参考リンク Qualab：http://qualab.jp/vstep/ ※テスト観点に基づくテスト開発方法論VSTePの概要 を参照 ■論理思考書籍 ・世界一やさしい「思考法」の本 ※目的－手段の階層化構造での説明があります ２．納得できるテストを考えてみよう（全体編）
- 98. 982017/06/23公開用 JaSST’17 Kansai 参考シリーズ：テストカタマリー 今回の構造を用いて、全体やテストケース目的の整理が可能です。 参考リンク テストカタマリーの紹介：まとめ 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/ ２．納得できるテストを考えてみよう（全体編）
- 103. 1032017/06/23公開用 JaSST’17 Kansai お題：伊丹の仮想的な遊園地「いたみパーク（通称いたパー）」 いたパーWebシステムの「ログ機能」が対象です。 ３．妥当性へ向けた問題発見へ むずかしい問題：ワーク対象 済 No. 済 番号 ・顧客のWebチケット購入処理 ・企画によるイベント登録時、イベント削除・編集時 ・企画による統計グラフ作成時 1週間以上のログを残すこと。 ログ機能は、JaSST関西ワー クショップ「いたパーWebシ ステム概要」P7-P9も参照の こと。 次のタイミングで操作実施の時間、ログを残す。 ■ 2 ログ領域を使い切ることがないよう、ローテーションでデータの削除を実施する。 ■ 1 使用番号 PARKSPEC-03 タイトル ログ機能 説明 保守向けとして、ユーザの操作を記録にとり、不具合発生時における関連性を調査可能にする。 ■ 1 タイトル ログ作成機能 説明 顧客のWebチケット購入時、企画によるイベント登録時、イベント削除・編集時、統計グラフ作 成時における操作ログを残す。 QRコードによる入場カウン ト、アトラクション使用カウ ントは対象外。 仕様詳細
- 109. 1092017/06/23公開用 JaSST’17 Kansai ログ書込み方法：購入、統計のトリガ発生時に書込み 時間,種別ID,イベント内容（ASCII）,引数1,引数2,… 削除方法：毎日23:59:00に8日以上前のデータ削除 １回の書き込みデータ量：最大1024Byte 書き込み頻度： チケット購入機能・・・1日2,000回が最大 統計機能・・・1日5回が最大 ログ容量：1GByteを用意 ３．妥当性へ向けた問題発見へ 情報を追加してみます。 むずかしい問題：テストケースまで ログ書出し条件の 入出力を確認する ログ 機能 同時書き込みでの 動作を確認する 削除しつつ１週間 以上ログを残す 理由 でき そう ４つの困難 １．現状を把握できない ２．問題を特定できない （問題≒解決すべきもの） ３．問題が曖昧・抽象的 ４．実現への懸念 容量超過しない 削除されすぎない １週間連続で確認 １データサイズ 現状の動き（設計想定） テストケーステストケーステストケーステストケース 実書込み頻度 （使用状況にて） テストケーステストケーステストケーステストケース こうかな？
- 110. 1102017/06/23公開用 JaSST’17 Kansai ログ書込み方法：購入、統計のトリガ発生時に書込み 時間,種別ID,イベント内容（ASCII）,引数1,引数2,… 削除方法：毎日23:59:00に8日以上前のデータ削除 １回の書き込みデータ量：最大1024Byte 書き込み頻度： チケット購入機能・・・1日2,000回が最大 統計機能・・・1日5回が最大 ログ容量：1GByteを用意 ３．妥当性へ向けた問題発見へ むずかしい問題：解決ポイントマッピング ログ書出し条件の 入出力を確認する ログ 機能 同時書き込みでの 動作を確認する 削除しつつ１週間 以上ログを残す 理由 でき そう ４つの困難⇒解決ポイント １．現状を把握 ２．問題を定義 （問題≒解決すべきもの） ３．問題を分割・整理 ４．解決策を決める 容量超過しない 削除されすぎない １週間連続で確認 １データサイズ 現状の動き（設計想定） テストケーステストケーステストケーステストケース 実書込み頻度 （使用状況にて） テストケーステストケーステストケーステストケース 問題を定義、問題を分割・整理 問題を定義 現状の把握 解決策を決める 問題を分割・整理 ※実験的 に考える 場合も さらに上位の検討 から発見へ 仕様ベース 購入計算機能統計機能 リコメンド機能 ログ機能 ・・・ その他品質特性 ユースケース・シナリオ
- 113. 1132017/06/23公開用 JaSST’17 Kansai 科学的なアプローチ わからないことに対しては、論理構造を明確にしながら、 一つずつ根拠を明確にしながら仮説検証を繰り返していきます。 ３．妥当性へ向けた問題発見へ XXX ？？ 仮説 仮説 XXX OK 仮説 仮説 仮説 検証済 仮説構築 ⇒実際には手さぐりで進めることも多いですが、「構造」を活用しつつ 実験や観察といった活動で１つ１つ検証しながら進めます。 ”基本的に，さまざまな科学的学問は， 証拠への依存，仮説と理論の使用，用いられる 論理の種類等において共通している。” *引用：SFAA（すべてのアメリカ人のための科学）より 検証＆ 仮説構築
- 114. 1142017/06/23公開用 JaSST’17 Kansai 科学的なアプローチ：わからない部分へ ワーク①での考え方の例を紹介してみます。 ３．妥当性へ向けた問題発見へ 購入計算 機能 １秒以内に計算が 完了することを確認 理由 ・0.1秒までなら応答が瞬時に 返ってきたという印象を与える。 ・1秒までならユーザーの思考は 途切れなく流れる。 ・10秒までならユーザーの注意力は続く。 ・10秒遅延してしまうと、ユーザーが即、 サイトから離れてしまうことも多くなる。 （Webサイトの応答時間 – U-Site, 2010/06/21）ニールセン氏 https://note.mu/tsukamoto/n/nde7fe5e21216 明確な情報がなかった 場合にはどうするか？
- 122. 1222017/06/23公開用 JaSST’17 Kansai 参考シリーズ：問題解決と科学の活動 こちらの資料は、「問題解決」と「科学の活動」に 関連する文献を参考としております。 ■問題解決関連書籍（一部です） ・世界一やさしい問題解決の授業 ・仮説思考 BCG流 問題発見・解決の発想法 ・問題発見プロフェッショナル―「構想力と分析力」 ■科学的なアプローチ ・すべてのアメリカ人のための科学 - Project 2061 http://www.project2061.org/publications/sfaa/SFAA_Japanese.pdf ・Wikipedia「科学的方法」 ３．妥当性へ向けた問題発見へ