いちばんやさしいソフトウェアテストの本 の商品レビュー
この本でどこまでソフトウェアテストについて知ることができるかというと、一般的なソフトウェアテスト実施に必要な知識、資料、進行手順を大まかに把握できる内容になっています。著者自身がソフトウェアテスト専門会社であるため、経験した具体的な事例を1つ2つ用いながら、順を追って説明してい...
この本でどこまでソフトウェアテストについて知ることができるかというと、一般的なソフトウェアテスト実施に必要な知識、資料、進行手順を大まかに把握できる内容になっています。著者自身がソフトウェアテスト専門会社であるため、経験した具体的な事例を1つ2つ用いながら、順を追って説明しているため、イメージは非常につきやすいと感じました。 主な構成は以下のようになっています。 1.ソフトウェアテストとは 2.開発の流れとテスト 3.テストの流れとドキュメント 4.ソフトウェア開発における2種類のテスト ーホワイトボックステストとブラックボックステスト 5.ブラックボックステスト技法 6.先輩たちの勘所 タイトルにもあるとおり”いちばんやさしい”をうたっておりますので、各工程や作業について細かく踏み込むことはなく、テスト設計資料やテストケースの作り方やソフトウェアテスト技法の実践方法などまでは書かれていません。あくまでソフトウェアテストがどういったもので構成されているかまでの説明で、さらに興味を持たれた方は他の専門書を読むことを推奨しています。 巻末には、以下のお勧め参考文献一覧が記載してあります。 『ソフトウェアテスト入門』 『ステップアップのためのソフトウェア実践ガイド』 『知識ゼロから学ぶソフトウェアテスト』 『はじめて学ぶソフトウェアテストの技法』 『体系的ソフトウェアテスト入門』 ソフトウェアテストの入門者や開発マネージャーやプロデューサーとして知識としてソフトウェアテストがなんたるか知っておく必要のある方にとっては、非常にとっつきやすくライトな一冊だと思います。
Posted by
•あっという間に読める。薄くて小さいのに、エッセンスはしっかり書いてある。 •前提は、ウォーターフォールのドキュメント主義。 •状態遷移図、状態遷移表の説明は分かりやすい。前者はできること、後者はできないことにフォーカスできる。組み合わせテストの考え方も参考になった。
Posted by
バルテスというソフトウェアテスト専門会社が生まれたのは、2004年4月19日のこと。技術と人を大切にしていて成長を続けている会社です。 そんなバルテスさんの、セミナー教材を基にした本が新書で生まれました。 とても読みやすく、それゆえにソフトウェアテストは、≪バルテスさんに...
バルテスというソフトウェアテスト専門会社が生まれたのは、2004年4月19日のこと。技術と人を大切にしていて成長を続けている会社です。 そんなバルテスさんの、セミナー教材を基にした本が新書で生まれました。 とても読みやすく、それゆえにソフトウェアテストは、≪バルテスさんに任せれば≫十分知識のある人が計画・実施すれば、大丈夫という感覚になりがちなところがちょっと心配ですが、まー、いいでしょう。 あと、ちょっとしたことだけど、96ページのデシジョンテーブルの例と、97ページの状態遷移図の例は変えた方がいいと思うなー。最初に出会う例って大切と思うから。
Posted by
ソフトウェアテストの初学者向けであるかと思いますが、初学者にオススメしたいかと言われると躊躇します。 簡単に説明しようとした弊害かもしれませんが、説明として適切出ないと感じる箇所や、誤りと見受けられる箇所が多く感じます。 確かに「、MyersやBeizerを初学者にいきなり勧...
ソフトウェアテストの初学者向けであるかと思いますが、初学者にオススメしたいかと言われると躊躇します。 簡単に説明しようとした弊害かもしれませんが、説明として適切出ないと感じる箇所や、誤りと見受けられる箇所が多く感じます。 確かに「、MyersやBeizerを初学者にいきなり勧めるのは躊躇しますし、新書でさくっと よめて概要を知るというコンセプトは非常にすばらしいと思うのですが、最初に触れる情報というのは非常に大事だと思いますので、易しいのだけれどもポイントをしっかりと押さえた適切な情報を求めたいです(非常に難しい要求ですが...)。
Posted by
テストエンジニアに必要な2つの視点 ?正しく製品を作っているか。verification。検証。仕様通りか。 ?正しい製品を作っているか。validation。妥当性評価。ユーザの立場から見て正しいか。 当たり前品質 基本要求・・・これだけは絶対満たしてほしい。 魅力的品質 ...
テストエンジニアに必要な2つの視点 ?正しく製品を作っているか。verification。検証。仕様通りか。 ?正しい製品を作っているか。validation。妥当性評価。ユーザの立場から見て正しいか。 当たり前品質 基本要求・・・これだけは絶対満たしてほしい。 魅力的品質 変動要求・・・満たせれば評価が上がり、満たせられなければ下がる。 潜在要求・・・あったらいいな。まだ実現されていない。 開発の流れ 要求定義 基本設計 詳細設計 実装 テスト 運用 保守 V字モデル ↓要求定義 ↑システムテスト ↓基本設計 ↑結合・機能テスト ↓詳細設計 ↑単体テスト レ実装 W字モデル ↓要求定義↓テスト計画 ↑修正↑システムテスト ↓基本設計↓テスト設計 ↑修正↑結合・機能テスト ↓詳細設計↓テストケース ↑修正↑単体テスト レ実装 テストの観点から、開発の初期段階から参加する。 テストの種類 回帰テスト(regression) 機能Aをテスト→機能Aにバグ発見→機能Aの修正完了→再び機能Aをテスト、この2回目のテストのこと。 デグレードチェック(degrade:あるバグ修正の際に別のバグを混入させてしまうこと) 当該箇所以外の品質が落ちていないかチェック。 アドホックチェック(ad hoc:場当たりの、特定の問題・目的について) 勘と経験を頼りに狙い打ち。ゴッドハンド、デビルハンド。 ドキュメント テスト計画・・・・・・・・・テスト計画書 テスト対象 テスト設計の目的および概要 テスト対象範囲・非対称範囲 アプローチ 成果物 工程 テスト設計体制 リスクとその対応 テスト設計・・・・・・・・・テスト設計仕様書 アプローチ概要 アプローチ詳細 設定値一覧 禁則回避方法 テストケース作成・・・テストケース群 テスト実施・・・・・・・・・不具合報告書・テスト進捗報告書 テスト報告・・・・・・・・・テストサマリレポート ブラックボックステストの技法 状態遷移図・状態遷移表 同地クラス分割・境界値分析 組み合わせ技法(直交表・All Pairs) ディシジョンテーブル 組み合わせテスト 大原則 ★100%残らず全てテストすることは不可能。 ★バグの多くは、2つまでの条件の組み合わせによって起こる。 全条件の組み合わせではパターンが非常に多くなってしまうので、2つの条件の組み合わせを 全てカバーするパターンに絞る。
Posted by
- 1