システムテスト自動化標準ガイド５章発表資料

1. 「システムテスト自動化標準ガイド」第5章伊藤雅俊（ @masatoshiitoh ） 2015/7/4

2.  日本メディカルネットコミュニケーションズ(株)勤務  本発表は、所属する企業・団t（ry  サーバー側メインのおおむね何でも屋  JS/PHP/Obj-C/Java  ここ3ヶ月では、Wordpressカスタマイズ職人、Androidアプリ改修職人、iOSアプリ改修職人などなど。  プライベートでErlang/OTP、Unity(C#)など  UnityからRabbitMQ(AMQP)やMQTTを使うライブラリなどを公開。  https://github.com/masatoshiitoh/unity_mqlib  https://m2mqtt.codeplex.com/SourceControl/network/forks/masatoshiitoh/M2mqtt4Unity

3.  1990年代  クライアントサーバー系システム ▪ テスト方法は、手動操作による確認。 ▪ テスト項目は、画面とシナリオから作成。お客様側から指定あり。 ▪ GUIテストツールのMicrosoft Testの採用を検討するも、社がクライアント部分の開発を担当しなかったので推進できず。 ▪ 内部ライブラリはソースコード目視チェック ▪ テストコードは特に作らず、実行ファイルごとに結果を目視確認。

4.  2000年代前半  回線速度測定サービスの企画・開発 ▪ コアプロトコル発案・設計、v1.0クライアントの開発を担当。 ▪ テスト方法は、手動操作による確認。 ▪ テスト項目は特に定めず。 ▪ 回線種別ごとに、このぐらいの速度が出るだろう、という想定で、そこを大きく逸脱した値が出ると「不具合」として修正を実施。 →びっくりするほどアドホック ▪ http://www.itmedia.co.jp/broadband/0307/09/lp17.ht ml

5.  2000年代後半  ネットリサーチとポイントサービスの連携システムの開発 ▪ テスト方法は、手動操作による確認。 ▪ テスト実施数、エラー件数、修正件数などのカウントが入った、統一書式の報告Excelが提供された。 ▪ テスト項目のリストアップや、手順書作成はExcel方眼紙。  2010年代前半  ウェブアプリのポイント管理システムの開発 ▪ テスト方法は、テストスクリプトによる一括テスト。 ▪ モックとテストコードを作成。実行は手動。 ▪ スクリプトにはパラメータをハードコード。 ▪ 結合後のテストは手動操作による確認。  小規模チームによるゲームアプリの開発 ▪ テスト方法は、手動操作による確認。 ▪ テスト項目は、画面遷移とディレクター指示。 ▪ 開発拠点が遠隔のため、バグ報告はGoogle spreadsheet でした。 ▪ 新バージョンがビルドされるたび、手作業でチェック。

6.  業務でのシステムテストの自動化経験は「基本的にありません」。  自動化を推進している方の実践情報をお聞きしたい！  というわけで、のちほど「お客様とやりとりするテスト関連の資料はどのように整理していますか？」というお題でポストイットアンケートやります。

7.  ５章テストウェアアーキテクチャ  5.1 テストウェアアーキテクチャとは何か  5.2 カギとなる4つの課題 ▪ 規模 ▪ 再利用性 ▪ 複数のバージョン ▪ プラットフォームと環境からの独立  5.3 取り組み方 ▪ 序文 ▪ 基本概念 ▪ テストウェアセット ▪ テストスイート ▪ テストウェアライブラリ ▪ 構成管理 ▪ テスト結果 ▪ 物理的構造 ▪ テストツールとのインターフェース  5.4 これはやりすぎだろうか？  5.5 まとめ

8.  ご紹介したい2つのスライドが。  http://www.slideshare.net/k_su zuki/aaa2015-49898261  http://www.slideshare.net/k_su zuki/1sta-stac2014  ギア本翻訳の鈴木一裕さん！

9. Kazuhiro SUZUKI/ギアと開発とわたし p.24

10. Kazuhiro SUZUKI/ 60 minutes STA (p.39)

13.  ギア本の全体像をつかむのに、とてもいいスライド。「システムテスト自動化標準ガイド」の途中で迷ったときは、ぜひ俯瞰図として参照されるといいでしょう   http://www.slideshare.net/k_suzuki/aaa2015-49898261  http://www.slideshare.net/k_suzuki/1sta-stac2014

14.  ここからは質疑応答の時間です。

15.  ここからは質疑応答の時間です。・・・？

16.  ・・・というわけには。

17.  テストに関連するファイルには何があるか？  あなたはテストに関連するファイルをどう管理しているか？  なぜ管理する必要があるのか？ディレクトリにまとめておけばいいのでは？  あなたのプロジェクトで古いバージョンのテストは必要か？  あなたの既存のテストはすぐに拡張・再利用できる状態になっているか？  何かやるとしたら、いつ始めるべきなのか？

18.  テストウェアアーキテクチャで管理される「テストウェア作成物」は、以下のものがある。  テスト資料  「入力」「スクリプト」「データ」「ドキュメント」「期待結果」  テスト結果  生成物 ▪ 「実際の出力」  二次生成物 ▪ 「ログ」「ステータス」「比較レポート」

19.  テストに関連するファイルには何があるか？  あなたはテストに関連するファイルをどう管理しているか？  なぜ管理する必要があるのか？ディレクトリにまとめておけばいいのでは？  あなたのプロジェクトで古いバージョンのテストは必要か？  あなたの既存のテストはすぐに拡張・再利用できる状態になっているか？  何かやるとしたら、いつ始めるべきなのか？テストで使用される入力、スクリプト、データ、ドキュメント。テスト実行で生成される成果物（出力結果）、二次成果物（レポート類） (5.1.1) ↓ 1つのテストケースだけでも 6種類のファイルが必要！

20.  「カギとなる4つの課題」  規模  再利用性  複数のバージョン  プラットフォームと環境からの独立  →ここは5.3節の前振りです 

21.  テストに関連するファイルには何があるか？  あなたはテストに関連するファイルをどう管理しているか？  なぜ管理する必要があるのか？ディレクトリにまとめておけばいいのでは？  あなたのプロジェクトで古いバージョンのテストは必要か？  あなたの既存のテストはすぐに拡張・再利用できる状態になっているか？  何かやるとしたら、いつ始めるべきなのか？自動化されたテストケースがほんの十数個であり、そのテストケースを扱う人が1～2名である間は、構造化されていようと、その場しのぎに作ったものであろうと、どのようなテストウェアアーキテクチャでも問題は無い(5.2.1) ↓ 逆に言えば、本格的にチームで自動テストを利用し始めると、テストに関連するファイルの管理法が重要になる、ということ。

22.  あなたはテストに関連するファイルをどう管理しているか？  なぜ管理する必要があるのか？ディレクトリにまとめておけばいいのでは？  あなたのプロジェクトで古いバージョンのテストは必要か？  あなたの既存のテストはすぐに拡張・再利用できる状態になっているか？  何かやるとしたら、いつ始めるべきなのか？テストケースが10倍に増加したり、自動テストのメンテナンス担当が変わったりすると、すぐにミスが多発するようになり、自動テスティングを役に立たないものにしてしまう。(5.2.1)

23.  あなたはテストに関連するファイルをどう管理しているか？  なぜ管理する必要があるのか？ディレクトリにまとめておけばいいのでは？  あなたのプロジェクトで古いバージョンのテストは必要か？  あなたの既存のテストはすぐに拡張・再利用できる状態になっているか？  何かやるとしたら、いつ始めるべきなのか？再利用可能なスクリプトや、データの開発には多くの努力が必要だが、この努力はスクリプトやデータが実際に再利用された場合にだけ報われる。（5.2.2） ↓ テストの自動化をし続けるためには管理が大事。

24.  なぜ管理する必要があるのか？ディレクトリにまとめておけばいいのでは？  あなたのプロジェクトで古いバージョンのテストは必要か？  あなたの既存のテストはすぐに拡張・再利用できる状態になっているか？  何かやるとしたら、いつ始めるべきなのか？あるソフトウェアの旧バージョンで緊急の欠陥が見つかった（中略）持っていると思っていた適切なバージョンのテストスクリプトは、以前テストをアップデートしたときに保存されておらず、一部が失われていることが分かったのだ(5.2.3経験談コラム) ↓ 旧バージョンを完全に放棄できる環境でなければ、古いバージョンのテストが保存される仕組みが必要だ。

25.  あなたのプロジェクトで古いバージョンのテストは必要か？  あなたの既存のテストはすぐに拡張・再利用できる状態になっているか？  何かやるとしたら、いつ始めるべきなのか？自動テスト全体に一貫性がなければ、難解で間違いが発生しやすくなる（中略）どのテスト技術者がどのライブラリのスクリプトを探すにしても2分以上かかるようではいけない。スクリプトが見つかったら、テスト技術者がその使用方法を妥当な時間内で正確に判断できなければならない。(5.2.2) ↓ 拡張・再利用のためには、内容をつかみやすいライブラリが必要だ。

26.  5.3 取り組み方 ▪ 序文 ▪ 基本概念 ▪ テストウェアセット ▪ テストスイート ▪ テストウェアライブラリ ▪ 構成管理 ▪ テスト結果 ▪ 物理的構造 ▪ テストツールとのインターフェース

27.  「テストスイート」は、テストが実行可能な状態のファイル群。  「テストスイート」は、テストの目的ごとに下記のものを任意でピックアップした詰め合わせである。 ▪ テストセット（テスト固有のスクリプト、データ、ユーティリティ、ドキュメント） ▪ スクリプトセット（共用） ▪ データセット（共用） ▪ ユーティリティセット（共用） ▪ ※上記4種の「セット」の総称がテストウェアセット。  テストウェアライブラリは、全てのテストウェアセットのマスターバージョンを格納しているリポジトリであり、テスト実行時はここからコピーしてきて実行する。  バージョン管理は適宜行う。

28.  「テストスイート」は、テストが実行可能な状態のファイル群。  「テストスイート」は、テストの目的ごとに下記のものを任意でピックアップした詰め合わせである。 ▪ テストセット（テスト固有のスクリプト、データ、ユーティリティ、ドキュメント） ▪ スクリプトセット（共用） ▪ データセット（共用） ▪ ユーティリティセット（共用） ▪ ※上記４種の「セット」の総称がテストウェアセット。  テストウェアライブラリは、全てのテストウェアセットのマスターバージョンを格納しているリポジトリであり、テスト実行時はここからコピーしてきて実行する。  バージョン管理は適宜行う。 5.3節は長く、しかも8.3形式（MS-DOS時代のスタイル）のファイル名をサンプルで多用するという、今となっては非常に分かりにくい構成になっています。そのまま読み進めるのは大変なので、ここではざっくり掴んでいくことにします。

29. テストウェアライブラリ (リポジトリ) テストスイート (実行環境) テストセットスクリプトセットデータセットユーティリティセットテストセットt1 スクリプトセットs1 データセットd1 ユーティリティセットu1 ユーティリティセットu1 データセットd2 スクリプトセットs1 テストセットt2 テストセットt1 コピー

30.  「これから示す方法は、テストウェアアーキテクチャで成功を収めるために、多くの組織にとっての出発点として使用されてきた。」  「読者は、自分の状況にこの取り組み方を適応させるか、魅力的と思えるアイデアだけでも取り上げることをお勧めする。」

31.  「これから示す方法は、テストウェアアーキテクチャで成功を収めるために、多くの組織にとっての出発点として使用されてきた。」  「読者は、自分の状況にこの取り組み方を適応させるか、魅力的と思えるアイデアだけでも取り上げることをお勧めする。」

32.  「これから示す方法は、テストウェアアーキテクチャで成功を収めるために、多くの組織にとっての出発点として使用されてきた。」  「読者は、自分の状況にこの取り組み方を適応させるか、魅力的と思えるアイデアだけでも取り上げることをお勧めする。」ものすごくお勧めされてます！

33.  テストウェアには、テストで仕様および生成される全ての作成物が含まれる。（5.1.1）  テスト資料とテスト結果に大別される。  テスト資料は「入力、スクリプト、データ、仕様書などの各ドキュメント、および期待結果」。  テスト結果は「成果物と二次成果物」。

34.  テスト資料は複数のテストセットの集合。  テストセットには1つ以上のテストケースが含まれる。  テストセットには、テストケースに関連づけられたスクリプト、データ、期待出力、ドキュメント類を含む。

35.  2つ以上のテストセットを目的によって等まとめたものが「テストスイート」。  テストスイートは、テストケースの集合体。

36.  しかし、「テストセット」「テストスイート」だけでは5.2節で提示された4つの課題に対応できない。  4つの課題とは？  規模  再利用性  複数のバージョン  プラットフォームと環境からの独立

37.  解決するために→  スクリプトセット（スクリプトを共有する）  データセット（データを共有する）  ユーティリティセット（ユーティリティを共有する）  そしてテストセット  これをまとめたのが「テストウェアセット」。

38.  テストウェアセットは、テストウェアアーキテクチャを構成する要素である。  テストウェアセットは、以下の種類がある。  テストセット  スクリプトセット  データセット  ユーティリティセット  テストウェアセットとは、テストウェア作成物を、テストスクリプトやデータファイルといった種類で分けた論理的な集合（セット）である。

39.  テストセットは1つ以上のテストケースを定義する。  テストセットはテストケース固有のテストウェア作成物を全て含む。内容は、  テストスクリプト  期待結果  テストデータ  テスト入力  文書ファイル（テスト仕様書など）  ユーティリティのソースファイル（テスト用ドライバや独自のコンバーターなど）  ユーティリティの実行ファイル（上述のソースファイルからビルドされたもの）  テストセット内のテストウェア作成物はそのテストケースでしか使用されない  異なるテストセットに含まれるスクリプトを再利用したいときは、スクリプトをテストセットからスクリプトセットに移動する。

40.  スクリプトセットはテストスクリプトと、それに対するドキュメンテーションのみを含んでいる。  スクリプトセットに含まれる全てのスクリプトは、再利用される。  複数のテストケースによってそのスクリプトが使われる。  ドキュメントは必須ではないが、作成することを強く推奨。  アプリケーションの開始・終了等のナビゲーション、ロギングなどのスクリプトが例に挙げられている。

41.  データセットは、データファイルとそれに対するドキュメンテーションのみを含んでいる。  データセット内のファイルは、2つ以上のテストセットの異なるテストケースで利用される。  複数のテストケースで再利用される。

42.  ユーティリティセットは、2つ以上のテストセットのテストケースで利用されるユーティリティ（スタブ、ドライバ、コンバータ、比較ツールなど）を含む。  また、ソースコードと実行ファイル、関連文書も含む。  例として、日付フォーマット変換ユーティリティ、比較ツールへの簡単なインターフェースを提供するコマンドファイル等が挙げられている。

43.  テストスイートは、テストの実行に必要なものが全て揃った環境をいう。  選択したテストケースは全て、テストスイートから実行される。  例で挙げられているテストスイートは、修正したScribbleアプリケーションの特定のバージョンに対して実行したいテストケースを含むもの、として、  Scribbleの全機能をカバーする幅広いテストを含むテストセット  ログを取る共有スクリプト  比較ツールの共有ユーティリティ  文書管理の共有スクリプト  Scribbleをナビゲートする共有スクリプト  修正した箇所をテストするためのデータセット  修正した箇所をテストするためのスクリプトセットセット  という構成が示されている。

44.  テストウェアライブラリとは、すべてのテストウェアセットのマスターバージョンを格納しているリポジトリ。  リポジトリの管理・利用についての説明。

45.  テストウェアライブラリは、全てのテストウェアセットのマスターバージョンを格納しているリポジトリ。  これらの資料を使うには、コピーを行う必要がある。  ※我々感としては、チェックアウト、でいいいか？  テストスイートを構築するときは、テストウェアライブラリから、必要なテストセットをコピーしてくる。

46.  テストウェアライブラリからテストウェアセットをコピーする作業は、できるだけ簡単であることが重要。  短時間でおこなえる。  失敗の余地がない（不完全なコピーが起きないように）。  コピー失敗でテストが失敗したりしないように。

47.  テストウェアの構成を管理する方法。  難しく書いてあるが、  テストを更新したら、テストウェアセットの新版として登録するのが1 つめ。  テストウェア作成物を修正したら、個々のテストウェア作成物の新版を登録するのが2つめ。  ※我々感としては、バージョン管理システムを使うイメージでいいか？

48.  複数人での作業に耐えるようにしよう。  古いバージョンのテストケースのサブセットを2つの異なる環境で実行するようなことが簡単に行えるならおおむね良好。  ※テストウェアアーキテクチャの内、テスト実行用ファイル（テスト資料）については、ここまで。

49.  テスト結果には、  実際の出力  比較レポート  テストツールのログを含むもので、テスト実行のたびに生成される。

50.  テストの出力は直接的な成果物。  テスト比較レポートや、テストツールログなどは、日付や環境情報を含むオペレーションログを含み、こちらも重要。

51.  テスト実行の証拠として必要なら保存する必要がある。  そうでなければ全てのテスト結果は削除可能。

52.  テストスイートに含まれるテスト結果一式は、テストセットごとにグループ化できる。

53.  テストウェアセットと、テストスイートの構造を実装する場合は、ファイルシステムの階層構造を利用すると良い。

54.  テストウェアセットのディレクトリ構造は厳密に守らなくてはならない。

55.  テストスイートもまたディレクトリ階層。  全てのテストウェアセットディレクトリが、テストスイート内の1 つのディレクトリに配置される。

56.  テストスイートからテスト結果を分離し、独自のディレクトリ階層に格納する。  トップレベルのディレクトリには、対応するテストスイートとの関連が分かるような名前を付けるのがベスト。

57.  もしランダムな名前(Mark, Barbara, Franky, Bobbyなど)をファイルに付けていたら、個々のスクリプトやデータファイルを探し出すことはかなり困難になるだろう。  本書では、テストウェアセットは  スクリプトセット：ｓ  データセット：ｄ  テストセット：ｔ  ユーティリティセット：ｕで始まり、アンダースコア、アプリケーション名と続き、テストケースが実行する、もしくはテストウェアがサポートする機能やアクションを記す。  たとえば「s_ScribbleDocument」であれば、Scribbleに関する、何らかドキュメントに関連するスクリプトセットが含まれている。

58.  期待結果がＯＳなど環境に依存する場合がある。  環境固有のファイルは分けて管理。「前処理」で環境固有バージョンのファイルにスクリプトが正常にアクセスできるようにコピーするのもいい。  テスト結果は環境によって分けて出力されるように。

59.  テストセットの中に、テストケースが多数になると管理しづらくなる。  テストケースを分割する方法がある。

60.  キーワード駆動テストケースでは、テストケースとスクリプトが一意には結びつかない。期待結果をスクリプトが含んでいる場合、期待結果が独立したファイルで存在しない。  →構造が一定しない。  実装を知らなければ、たとえばデータ駆動アプローチが使われると分かっていても、分離されたデータファイルを見つけるのは容易ではない。  →探す場所どころか、探すもの（スクリプト、データファイルなど）すら分かっていないかも知れない！！  テストウェアアーキテクチャが十分に構造化され、一貫性を備えているとしても、テストケース自体が簡単で一貫した方法で識別できない場合には欠陥がある。  →テストケース定義ファイルによって、どのようなテストケースがあるのか、どのテストウェアが使用されるのかといったことを識別できるようになる。

61.  実行したいテストケースを全て含んだテストスイートを持っているとして、どんなテストケースがあり、どう実行すればよいか、テストツールが理解出来る必要がある。  実現する方法はテストツールによる。  テストツールに情報を与える部分については、自動化し、「前処理」タスクで実行するようにしよう。  ※5.3章はここまで。

62.  「テストスイート」は、テストが実行可能な状態のファイル群。  「テストスイート」は、テストの目的ごとに下記のものを任意でピックアップした詰め合わせである。 ▪ テストセット（テスト固有のスクリプト、データ、ユーティリティ、ドキュメント） ▪ スクリプトセット（共用） ▪ データセット（共用） ▪ ユーティリティセット（共用） ▪ ※上記4種の「セット」の総称がテストウェアセット。  テストウェアライブラリは、全てのテストウェアセットのマスターバージョンを格納しているリポジトリであり、テスト実行時はここからコピーしてきて実行する。  バージョン管理は適宜行う。

63.  これはやりすぎだろうか？

64.  筆者の主張：「いや、やりすぎではない！」  「テスト自動化の取り組みがうまくいっているならそのテストは拡大していき、コントロールしなければならないファイルの数も急増する。」  「テストウェアのサブセットが簡単に分離できるということには、過小評価できないメリットがある。」  正直、今読むと「やりすぎ」感はさほど無い印象。しかし、原著刊行当時、支援ツールなしでこれを自前で構築しろと言われたら、「やりすぎ」と言ったかもしれません。

65.  あなたのプロジェクトで古いバージョンのテストは必要か？  あなたの既存のテストはすぐに拡張・再利用できる状態になっているか？  何かやるとしたら、いつ始めるべきなのか？テスト自動化の取り組みの開始時に、適切なアーキテクチャを導入しておかなければ、あとから適切なアーキテクチャでやり直すのには、ずっと手間がかかるだろう。手に負えない状態になってしまってからではなおさらだ。(5.4) ↓ テスト自動化の取り組みの開始時から！

66.  1999年刊行の本なので、そのちょっと前から見てみましょう。  スペック等はコンシューマーPCのものです。  1995年  Pentium Pro (150MHz ~  メイン4MB ~ 8MB時代  1GB HDD  10BASE2/-T時代  Windows95  MacOS 7.5  Linux 1.0カーネル (Redhat/Suse)

67.  1999年刊行の本なので、そのちょっと前から見てみましょう。  スペック等はコンシューマーPCのものです。  1995年  Pentium Pro (150MHz ~  メイン4MB ~ 8MB時代  1GB HDD  10BASE2/-T時代  Windows95  MacOS 7.5  Linux 1.0カーネル (Redhat/Suse) メモリは1/1000 HDDも1/1000 ネットワークは1/100 CPUクロックは1/20

68.  1997年  Pentium II (233MHz ~  8MB ~ 32MB時代  4GB HDD  100BASE-TX時代  Windows NT4.0 (1996~  MacOS 8  Linux 2.0 カーネル(1996~

69.  1997年  Pentium II (233MHz ~  8MB ~ 32MB時代  4GB HDD  100BASE-TX時代  Windows NT4.0 (1996~  MacOS 8  Linux 2.0 カーネル(1996~ メモリは1/1000 HDDも1/1000 ネットワークは1/10 CPUクロックは1/10

70.  1999年  Pentium III (450MHz~  16MB~64MB時代  10GB HDD  100BASE-TX時代  Windows 98SE  MacOS 9  Linux 2.2  Samba 2.0

71.  1999年  Pentium III (450MHz~  16MB~64MB時代  10GB HDD  100BASE-TX時代  Windows 98SE  MacOS 9  Linux 2.2  Samba 2.0 メモリは1/1000 HDDも1/1000 ネットワークは1/10 CPUクロックは1/5

72.  発刊後  日本国内のADSLサービスは2000年前後から。 ▪ USはむしろブロードバンドの普及は遅かった。  Windows 2000は2000年。  Windows XPは2001年。  一般向け1000BASE製品が出回り始めたのは2003年。  Mercurial、 Gitは2005年。  原著がこうした状況で1999年に刊行された、ということを意識してあらためて5章（特に3節）を読むと、著者の危機感が共有できるのではないかと思います。

73.  テストに関連するファイルには何があるか？  テストで使用される入力、スクリプト、データ、ドキュメント。テスト実行で生成される成果物（出力結果）、二次成果物（レポート類）。  あなたはテストに関連するファイルをどう管理しているか？  本格的にチームで自動テストを利用し始めると、テストに関連するファイルの管理法が重要になる。  なぜ管理する必要があるのか？  テストの自動化をし続けるためには管理が大事。

74.  あなたのプロジェクトで古いバージョンのテストは必要か？  旧バージョンを完全に放棄できる環境でなければ、古いバージョンのテストが保存される仕組みが必要だ。  あなたの既存のテストはすぐに拡張・再利用できる状態になっているか？  拡張・再利用のためには、内容をつかみやすいライブラリが必要になる。  何かやるとしたら、いつ始めるべきなのか？  用意をするなら、テスト自動化の取り組みの開始時点から！

75.  ・・・

76.  ・・・と思ったら。  ギア本の日本語版第14章として「CI（継続的インテグレーション）」が書き下ろされていました！  ※「ギアと開発とわたし_AAA2015」p.23  TravisCIの利用について紹介されています。 Kazuhiro SUZUKI/ギアと開発とわたし p.23

77.  おもに、お客様ありの開発をしている方への質問となりますが・・・  テスト計画書やテスト項目、手順書、バグ報告書など、テスト前後でお客様とやりとりするファイルが多数あり、しかもバージョン管理が困難な運用スタイル（日付付きファイル名のExcelシート等）なことが多いのではないでしょうか？  テスト項目の管理はExcel？ Google spreadsheet？  バグ管理はExcel？ BTS？  テストの進捗を、オンラインでBTS等でお客様に見てもらうかたちにできてる方、いますか？  テスト管理ツールの出力でいいよ、とお客様を納得させてるかた、いますか？  Excel職人としての工数が大きくて苦労している方、いますか？  アンケート：  テストの管理（お客様とのテスト項目の共有、進捗、レポート等）のツールは？  そのツールで満足している点、不満な点は？

78.  そして、アンケートへのご協力、ありがとうございました。

システムテスト自動化標準ガイド５章発表資料

You are reading a preview.

Check these out next

システムテスト自動化標準ガイド５章発表資料

More Related Content

Slideshows for you (20)

Similar to システムテスト自動化標準ガイド５章発表資料 (20)

More from Masatoshi Itoh (7)

Recently uploaded (20)