FV表とFL表 - プログラマの思索
テスト仕様書を作る一つの方法として、直交表を用いたHAYST法がある。 HAYST法で重要な概念は、FV表とFL表の二つ。 考えたことをラフなメモ書き。 間違っていたら後で直す。 【参考】 ソフトウエアテスト分析の方法 テスト分析 テスト設計 受入テストのテストケースを作る場合、要求に対してテストケースを作る。 そのテストケースのレベルは、プログラムレベルではなく、顧客の観点になる。 だから、いきなりテストケースを作ったとしても、粒度や網羅性が不十分になりやすい。 「ソフトウェアテストHAYST法入門 品質と生産性がアップする直交表の使い方」にも書いてあるように、テスト設計で最も重要な観点は、テスト対象の因子・水準を漏らさず抽出することにある。 因子とは、テスト対象のパラメータ。 水準は、パラメータが取りうる値。 例えば、MSのOffice製品をテストする場合、OSやCPU、HDDなどは因
「ソフトウェアテストとは、ツールではなく、頭で行うもの」 JaSST '11 Tokyoでリー・コープランド氏が基調講演 − ＠IT
「ソフトウェアテストとは、ツールではなく、頭で行うもの」：JaSST '11 Tokyoでリー・コープランド氏が基調講演 ASTER （ソフトウェアテスト技術振興協会）が1月25日、26日に開催しているソフトウェアテストシンポジウム「JaSST '11 Tokyo」（Japan Symposium On Software Testing）で、世界的に有名なソフトウェア技術者、リー・コープランド氏が基調講演を行った。氏は、“イノベーション”と評価すべき、開発やテスト分野における複数の手法・事象を紹介する中で、「テストにベストプラクティスはない」と指摘、「各社が状況に応じて、あらゆる手法を使いながら“自社に最適”な取り組みを行う」ことの重要性を示唆した。 テストとは、ツールではなく、テスターの頭で行うもの コープランド氏はSoftware Quality Engineering社に所属し、幾多
複雑度と単体テストケース数の相関関係 - プログラマの思索
garyoさんから、ソースの複雑度と単体テストケース数について有益なアドバイスを示唆してもらったので、メモしておく。 ◆SourceMonitor Version 2.4 SourceMonitorはフリーで、以下の言語のソースのソフトウェア複雑度（McCabeのサイクロマチック数）を測定できる。 例：C++, C, C#, VB.NET, Java, Delphi, Visual Basic (VB6) or HTML ◆McCabe's cyclomatic complexity SourceMonitorで求められる複雑度（McCabeのサイクロマチック数）は、モジュール内の分岐の数（＋ループの数）で計算される。 複雑度の数値は、下記の意味を持つらしい。 10 以下であればよい構造 30 を越える場合，構造に疑問 50 を越える場合，テストが不可能 75 を越える場合，いかなる変更も
SRATSの使い方 - プログラマの思索
ソフトウェア信頼度評価ツールSRATSの使い方がようやく分かったのでメモ。 【元ネタ】 信頼度成長曲線 - Wikipedia SRATS:Software Reliability Assessment Tool on Spreadsheet Software SRATSダウンロード ソフトウェア信頼性評価 における最近の話題 信頼性評価ソフトウェア ソフトウェア信頼度評価ツール - 脱・下流エンジニア (仮) Mantisのバグ情報から信頼度成長曲線作成ツール - Rubyの魔神 - はてな？Rubyグループ SRATSは、広島大学の岡村さんが作ったソフトウェア信頼度(SRM)を評価するExcelマクロ。 バグ情報をCSV形式で用意さえすれば、信頼度成長曲線(SRM)を自動生成することができる。 garyoさんから、このツールの存在を教えてもらった。 信頼度成長曲線が必要な理由は、システ
テスト自動化について5分で分かるまとめ
みなさんこんにちは。@ryuzeeです。 テスト自動化について簡単に教えてほしいと言われることが多いので、以下にまとめました。 テスト自動化/テスト駆動開発についてXPのプラクティスの中で、最も単体で導入しやすいプラクティスの１つであるこのプラクティスのみで１冊の本が書けるくらい奥が深い基本的な方法失敗するテストを書くできる限り早く、テストがパスするような最小限のコード本体を書くリファクタリングをする適用範囲通常では、独立性の高いクラスやファンクションへの適用が良いGUIや分散オブジェクト、自動生成されたコード、DBのスキーマに関するテストは導入が難しい既存システムにおいて、テストが準備されていない場合に、部分的に導入するのは難易度が高い。したがって新規プロジェクトの初期から導入することが望ましい問題点開発者が仕様を誤解していた場合、誤解に基づくテストコードが作成されるため、誤解の検知は保
知るだけで天地の差が出る、テスト仕様書の必須項目＆表現方法
テスト仕様書で絶対に必要な項目リスト テスト仕様書に記述すべきものとして、以下の事項があります。 テストを実施した環境 実施するテストの内容 テストを実施するためのシステムの操作手順 テストの実行結果 個々のテスト項目を識別するための番号や記号（通し番号など） テストを実施した年月日 テストを実行した担当者 障害報告票番号（発生した障害の詳細を開発グループに報告する帳票の識別番号） まずはテスト環境について明記する テスト仕様書の先頭には、「テストを実施した環境」を記述します。ここでは、ハードウェア環境やソフトウェア環境、ネットワーク環境など、「どのような環境でテストを行ったか」を説明します。 ただし、テストを実施した環境を記述するだけでは十分ではありません。「顧客にとって必要な情報は何か」を考えるのです。ここで必要なのは、「要件定義書で規定した環境」との関係が分かることです。 なぜなら、
TestLinkのアンチパターン - プログラマの思索
TestLinkでテスト管理をしてみた経験、他の人から聞いた話から、TestLinkを運用したけど使いこなせない症状にパターンがあるような気がした。 それらをアンチパターンとしてまとめてみた。 【元ネタ】 TestLinkがExcelのテスト仕様書よりも素晴らしい点 TestLinkを運用して気付いたことpart4～TestLinkの概念を再考 TestLinkを運用して気付いたことpart5～TestLinkのテストケースの概念 TestLinkを運用して気付いたことpart6～テスト工程のプロジェクト管理 TestLinkを運用して気付いたことpart7～要件カバレッジは難しい TestLinkを運用して気付いたことpart8～みなしバグ、ブロッキングバグ、周辺テスト、そしてクリティカルパス TestLinkを運用して気付いたことpart9～後追いテスト 【公開】脱Excel！ Tes
TestLinkのベストプラクティス集 - プログラマの思索
TestLinkでテスト管理を運用してみて、ベストプラクティスを自分なりにまとめてみた。 あくまでも下記は僕が経験したこと、理解できたことに過ぎないので、間違っていたらコメント下さい。 【元ネタ】 脱Excel！ TestLinkでアジャイルにテストをする － ＠IT自分戦略研究所 TestLinkのFAQ: プログラマの思索 テスト手法の概念をTestLinkで説明する: プログラマの思索 TestLinkを運用して気付いたことpart8～みなしバグ、ブロッキングバグ、周辺テスト、そしてクリティカルパス: プログラマの思索 TestLinkを運用して気付いたことpart9～後追いテスト: プログラマの思索 TestLinkを受入テストで運用する方法: プログラマの思索 【1】ブロック テストケースの事前条件が、失敗したテストケースに依存しているためにテスト不能になった状態を指す。 ブロッ
CSV実践講座 その6 テスト計画書の書き方
＜連載 全12回＞ CSV実践講座（第6回） CSV実践について研究するページです。 ＊万が一文中に解釈の間違い等がありましても、当社では責任をとりかねます。 本文書の改訂は予告なく行われることがあります。 1. はじめに CSVを実施するにあたって、テストはもっとも重要なアクティビティである。必要な文書を一通り揃えるだけの形骸化されたCSV実施では、本来のシステムの信頼性を保証するという目的は達成されない。 ソフトウェアの特徴は、欠陥が長期間潜んでしまうことにある。ハードウェアの場合、欠陥は比較的容易に検査することができる。またハードウェアの異常は音や振動、動作状況により事前に察知できることが多い。これに対してソフトウェアの欠陥は、初期のテストでは発見されず、数年使用している中で突然発生することがあり得るのである。これは時間やリソースの制限から、あらゆる動作環境や入力条件をあらかじめ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
