テスト設計のドキュメントを残していますか
高品質な企業情報システムを開発するために，ソフトウエア・テストはとても重要である。だが，ソフトウエア・テストに詳しいベリサーブの佐々木方規氏（管理本部 検証品質保証統括部 統括部長）は，現在のソフトウエア・テストには一つ大きな問題がある，と指摘する。それは，「テスト設計」のドキュメントを残していないケースが多い，ということだ。 ドキュメントが残っていないために，「ソフトウエア・テストをさらに良いものにする改善活動になかなかつながらない」という弊害があるという。さらに，テストの再利用も難しくなる。「テストを再利用できないと，ソフトウエア・テストのコストは下げられない。再利用するためにはテスト設計のドキュメントは必須だ」（佐々木氏）。 ソフトウエア・テストは，要件定義書や設計仕様書，製品マニュアルなど，なんらかの「仕様書」に基づいて実施される。通常は，まずテスト対象となる機能から，確認する必要
【連載】実践ソフトウェアテスト考現学 (5) 開発プロジェクでの勝つための決め手となる「テスト戦略」とは? | エンタープライズ | マイコミジャーナル
テストには、「どこまでやれば全部テストしたことになるのかわからない」とか「納品間近になってもバグが出続けるけど、テストを終わりにしていいのか」という問題が付きまといます。これらを乗り越えて製品をリリースするために、誰しもが何らかのテスト戦略を立てていますが、テストだけの個別戦略になってしまっているケースも往々にして見受けられます。さらに一歩進んでテストから開発全体を最適化させるためには、戦略立案のパラダイムシフトが必要となります。今回は、テスト戦略の基本的な考え方について説明します。 「戦略」とは、strategyの日本語訳であり、漢字からもわかる通り、元々軍事用語です。戦いの局面では、兵力的に圧倒的に劣る場合でも、戦略次第で勝負に勝てる場合が出てきます。 例えば、以下のようなアプローチで戦いに挑むと良いと言われています(※)。 ・接近戦を選択する ・一騎打ちの場面を作る ・兵力を集約
第4回 こんなテスト担当者はイヤだ！ | gihyo.jp
永い間テストに従事していると、日常生活の中でもある種の「職業病」とも思える行動をとっていることがあります。 たとえば 目の前に「ボタン」があると押したくなる。特に2つ以上あると、同時押しをしたくなる。 製品を買っても、常にエラーケースを考えたり、エラー操作をしたくなる。 いつでも再現確認できるように、操作手順を覚えている。 カタログのスペック表をずーっと見ていられる。 ……等々。 今回は、そんな「ソフトウェアテストな人」をご紹介しながら、「人間力」を考えてみます。 “真（円）”を追求する いつも通りに筆者が同僚のM氏とテストを実施中、ふとM氏を見ると何やらごそごそと。よく観察すると、トレーシングペーパーを取り出してディスプレイにあてて書き込んでいる様子です。 筆者： 「何しているの？」 M氏 ： 「今日は、Circleコマンド（円表示）のテストだから、表示の確認だよ」 筆者： 「（筆
【連載】実践ソフトウェアテスト考現学 (4) 「テストの最適化」はシステム開発成功への近道 | エンタープライズ | マイコミジャーナル
開発のもどかしさを解消するカギはテストフェーズにあり 前回、開発上で、開発者と受注者が感じる「もどかしさ(リスクや課題)」は、開発工程の各フェーズに存在すると説明しました。筆者が関わった数多くの現場とコンサルの経験から言わせていただくと、数々のもどかしさの中でも、品質を最終的に評価する段階であるテストフェーズでのもどかしさは、開発ライフサイクル全般に起因しているため、特に悩ましいと言えます。 こう考えると、システム開発における「もどかしさ」の大半を何とかしたいと思うのであれば、「テストフェーズを何とかするために何ができるか」を考えるのが、アプローチとしては悪くないとの考えに至った訳です。 もちろん、テストだけですべてが解決するわけではないのですが、スムーズにプロジェクトを進めるためには、まずテストをベースに問題をとらえることが必要だと思います。つまり、プロジェクトにおける問題が顕在化したら
【連載】実践ソフトウェアテスト考現学 (3) 調査だけではわからないシステム開発の実態 | エンタープライズ | マイコミジャーナル
調査データからは見えないもの と、ここまで書いて筆者は、「本当にこんなに不具合を抑え込めているのだろうか?」と考えました。いろいろな所で筆者が見聞きする現場の状況を踏まえると、どうしても違和感を感じざるを得ないからです。 調査結果が示しているデータはあくまで「表面上、明らかとなった不具合数」にとどまっているように筆者には思われました。 例えば、開発側が「保守」という形で、一見すると不具合とはわからないように対応することは多々あるはずです。また、ユーザー側からすれば不具合だと思われるような場合でも、発注時や要求定義時に曖昧に開発側へ依頼した場合は発注側の問題となり、受注側の立場からすると不具合として扱えないことも少なくはないはずです。 このようなケースはおそらく、公式な調査データに載らないであろうことを考慮に入れれば、実感とは少々かけ離れているように感じたとしても不思議はない、と筆者自身は納
Eclipse 3.4を使ったデバッグとテスト～Eclipse 3.4 入門～
はじめに 第4回「Eclipse 3.4でのアプリケーション開発方法（swing／JSP／サーブレット）」までで、Eclipseのインストールと設定からEclipseを用いてアプリケーションを開発するまでの一般的な流れなどを説明しました。 今回は、複雑なアプリケーションを開発するために必要な「デバッグやテストを支援する機能」の基本を紹介します。 事前準備 第4回のJSP開発の章で紹介した「Tomcat Launcherプラグイン」を用いるので、あらかじめ導入しておいてください。また「JStyle」も導入しておくと便利でしょう。今回の画面画像は「JStyle」導入済みの場合になっています。 今までの記事 第1回「Eclipse 3.4のインストールと日本語化」 第2回「Eclipse 3.4の各種設定と利用方法」 第3回「Eclipse 3.4プラグインのインストール／設定方法」 第4回「E
【連載】実践ソフトウェアテスト考現学 (1) 調査データから見た日本人が作るシステムの質 | エンタープライズ | マイコミジャーナル
立場によって異なる「もどかしさ」 システム開発を発注するユーザー側でも、受注する側でも、ほとんどの方は業務の中で日常的に、何かしらのもどかしさを感じていることでしょう。 とはいえ「〜がもどかしい」の「〜」の部分に込められる悩みは人それぞれで、当然ながら立場によっても異なるはずです。 例えば、同じ悩みでも発注者と受注者との間で、相手に対するもどかしさの表現は、上のように変わってくると思います。 発注者側のもどかしさ受注者側のもどかしさ はなからサービスインに間に合わせようという意気込みが伝わってこない システム開発のプロであるはずなのに、「欲しいシステム」を提案してくれない 機能として十分な実装ができてないのに、修正を要求すると機能追加や変更扱いにしたがる いつまでたっても仕様を確定させないから、サービスインに間に合わなくなる システムに何が必要なのか、ユーザー自身が整理しきれていない 「あ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
あなたのテスト、単なる動作確認になっていませんか？