【連載】実践ソフトウェアテスト考現学 (5) 開発プロジェクでの勝つための決め手となる「テスト戦略」とは? | エンタープライズ | マイコミジャーナル
テストには、「どこまでやれば全部テストしたことになるのかわからない」とか「納品間近になってもバグが出続けるけど、テストを終わりにしていいのか」という問題が付きまといます。これらを乗り越えて製品をリリースするために、誰しもが何らかのテスト戦略を立てていますが、テストだけの個別戦略になってしまっているケースも往々にして見受けられます。さらに一歩進んでテストから開発全体を最適化させるためには、戦略立案のパラダイムシフトが必要となります。今回は、テスト戦略の基本的な考え方について説明します。 「戦略」とは、strategyの日本語訳であり、漢字からもわかる通り、元々軍事用語です。戦いの局面では、兵力的に圧倒的に劣る場合でも、戦略次第で勝負に勝てる場合が出てきます。 例えば、以下のようなアプローチで戦いに挑むと良いと言われています(※)。 ・接近戦を選択する ・一騎打ちの場面を作る ・兵力を集約
【連載】実践ソフトウェアテスト考現学 (4) 「テストの最適化」はシステム開発成功への近道 | エンタープライズ | マイコミジャーナル
開発のもどかしさを解消するカギはテストフェーズにあり 前回、開発上で、開発者と受注者が感じる「もどかしさ(リスクや課題)」は、開発工程の各フェーズに存在すると説明しました。筆者が関わった数多くの現場とコンサルの経験から言わせていただくと、数々のもどかしさの中でも、品質を最終的に評価する段階であるテストフェーズでのもどかしさは、開発ライフサイクル全般に起因しているため、特に悩ましいと言えます。 こう考えると、システム開発における「もどかしさ」の大半を何とかしたいと思うのであれば、「テストフェーズを何とかするために何ができるか」を考えるのが、アプローチとしては悪くないとの考えに至った訳です。 もちろん、テストだけですべてが解決するわけではないのですが、スムーズにプロジェクトを進めるためには、まずテストをベースに問題をとらえることが必要だと思います。つまり、プロジェクトにおける問題が顕在化したら
【連載】実践ソフトウェアテスト考現学 (3) 調査だけではわからないシステム開発の実態 | エンタープライズ | マイコミジャーナル
調査データからは見えないもの と、ここまで書いて筆者は、「本当にこんなに不具合を抑え込めているのだろうか?」と考えました。いろいろな所で筆者が見聞きする現場の状況を踏まえると、どうしても違和感を感じざるを得ないからです。 調査結果が示しているデータはあくまで「表面上、明らかとなった不具合数」にとどまっているように筆者には思われました。 例えば、開発側が「保守」という形で、一見すると不具合とはわからないように対応することは多々あるはずです。また、ユーザー側からすれば不具合だと思われるような場合でも、発注時や要求定義時に曖昧に開発側へ依頼した場合は発注側の問題となり、受注側の立場からすると不具合として扱えないことも少なくはないはずです。 このようなケースはおそらく、公式な調査データに載らないであろうことを考慮に入れれば、実感とは少々かけ離れているように感じたとしても不思議はない、と筆者自身は納
【連載】実践ソフトウェアテスト考現学 (1) 調査データから見た日本人が作るシステムの質 | エンタープライズ | マイコミジャーナル
立場によって異なる「もどかしさ」 システム開発を発注するユーザー側でも、受注する側でも、ほとんどの方は業務の中で日常的に、何かしらのもどかしさを感じていることでしょう。 とはいえ「〜がもどかしい」の「〜」の部分に込められる悩みは人それぞれで、当然ながら立場によっても異なるはずです。 例えば、同じ悩みでも発注者と受注者との間で、相手に対するもどかしさの表現は、上のように変わってくると思います。 発注者側のもどかしさ受注者側のもどかしさ はなからサービスインに間に合わせようという意気込みが伝わってこない システム開発のプロであるはずなのに、「欲しいシステム」を提案してくれない 機能として十分な実装ができてないのに、修正を要求すると機能追加や変更扱いにしたがる いつまでたっても仕様を確定させないから、サービスインに間に合わなくなる システムに何が必要なのか、ユーザー自身が整理しきれていない 「あ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
