タグ

2013年4月12日のブックマーク (5件)

  • 結合テストと総合テスト

    ソフトウェアの開発におけるテスト作業は、「テスト計画」「テスト設計」「テスト実施」「テスト管理」という4つのプロセスで構成されます(図1)。 テスト計画プロセスでは、テスト全体の指針や概要をまとめます。テストの目的、対象範囲、実施方法、テスト体制、テスト環境、スケジュール、合格基準など、テスト全般に関わる方針を「テスト計画書」にまとめ、ユーザを含むプロジェクトメンバー全員で方向性を共有します。 テスト設計プロセスでは、策定されたテスト計画に基づいて、実際のテスト作業内容を設計します。テストのシナリオやテスト内容、確認すべき項目などを「テスト仕様書」に具体的に定義します。 テスト実施者は、このテスト仕様書に基づいてテストを実施します。障害を発見した際は、障害番号を採番し、障害管理票に記載して残管理します。これらの障害が片づいて、テストが正常に行われた場合は「テスト報告書」で報告します。 弊社

  • 結合テスト仕様書兼報告書のテンプレート

    シナリオとケースの作り方 筆者が初めて結合テストの仕様書を作成する際、何から作成してよいかさっぱりわからなかった記憶があります。そうこうしているうちに時間ばかりが過ぎ、焦りが募っていきました。今思えば、それは「シナリオ」と「ケース」をどう作ったらよいかピンときていなかったからでしょう。そこで、結合テストに出てくる「シナリオ」と「ケース」について整理してみたいと思います。 シナリオとは「受注業務」「発注業務」「請求業務」「支払業務」といった業務の単位と考えるとわかりやすいでしょう。その単位をシナリオとし、これが結合テスト仕様書の単位にもなります。またこれには通常、上流工程で作成した業務フロー図が対応します。したがってシナリオ=業務の単位=結合テスト仕様書の単位=業務フロー図の単位となるのが基です。 また、ケースとはシナリオ内での場合分けと考えるとよいでしょう。例えば、支払業務を1シナリオと

  • 終わるSIerの底辺を見てきた - ミッションたぶんPossible

    ご挨拶 今月の第二日曜日は3月11日でした。言わずと知れた、あの「3.11 東日大震災」から丸一年が経過した日です。改めまして、当時亡くなられた方々のご冥福をお祈り申し上げます。また、被災され現在も不便な暮らしを強いられている大勢の方々にお見舞い申し上げます。一日も早く元通りの日常が送れるようになることを願って止みません。 3.11の14:46、オレは代休で自宅にいるところにあの大地震がやってきました。自身が立つこともままならないような衝撃の中、不安定なテレビ台とPC棚をなんとか抑えて揺れが収まるのを必死で耐えたのは、今でも鮮明に思い出すことができます。それもあって我が家の被害は全くなく、妹も職場の方の好意で車で送って貰え、日付が変わった頃に無事帰宅できました。都内では翌日昼を過ぎても帰宅できなかった人が多かった中、我々は非常に運が良かったと思います。 はじめに さて、オレにとって、この

    終わるSIerの底辺を見てきた - ミッションたぶんPossible
  • ユーザ受け入れテストでレガシーコードと戦っていく

    レガシーコードとは、レガシーコード改善ガイドを参考にすると、テストのないコードを指しています。コードだけでなくレガシーなシステムも存在し、レガシーじゃないシステムよりレガシーシステムのほうが多いので、新しい要求への対応と、レガシーコードの改善をうまくやっていくスキルが求められるのではないかと思います。今日は、うまく戦っていく手段について考えてみました。 レガシーシステムでの問題 自動化されたテストのない現場にいたときに、以下の問題に直面しました。 レグレッションテストに時間がかかる 何をもって「ちゃんとテストした」のかがわからない 結果的に、リリース作業時間が長くなり、リリースにかけるコストが大きく膨れたり、テストを網羅しきれず、トラブルが継続的に発生してしまうというダメージを受けてしまいます。 1については、新しく追加した機能のテストはできても、追加した影響範囲まで特定できず、別の所で問

    ユーザ受け入れテストでレガシーコードと戦っていく
  • Windowsアプリの受け入れテストを自動化しよう

    単体テストの次は、エンド・ユーザーへの納品時の受け入れテストも自動化したい? それを実現する手法を紹介する。 連載目次 受け入れテスト(=受け入れ検査)の自動化は、ユニット・テスト(=単体検査)の自動化より難易度が高い。 一般的にはこのようにいわれている。 なお受け入れテストとは、エンド・ユーザーが使うのと同じシチュエーションでアプリやシステムをテストすること、つまりシステムの検収のことである。ユニット・テストがメソッドなどの最小の実装単位でその内容をテストするのに対し、受け入れテストではユーザー操作単位でテストするという違いがある。特にアジャイル開発では、小さく機能を追加しながら頻繁にリリースするので、検収の回数も増えてしまい、エンド・ユーザーの負担になってしまうことがある。 このような課題に対処する1つの案として、受け入れテストの自動化の手法が考えられているわけだが、その手法を現実に実

    Windowsアプリの受け入れテストを自動化しよう