テストで欠陥を見逃す、たった三つの要因
「e発送サービスは受付を一時休止しています」。 ほぼ毎日のようにローソンを訪れる筆者にとって、この注意書きはおなじみになってきた。レジ横で目にする注意書きは、心なしか紙にしわが寄りはじめている。2017年6月28日にシステム障害で停止したこのサービスは、1カ月を経過しても復旧できていない。 デジタル化が進むほど、システムはビジネスと直結するようになる。システムが止まったり、間違った結果を返したりするバグがあると、ビジネスに直接ダメージを与えてしまう。こうした欠陥を見つけ出し、品質を確保する関門となるのがテストだ。ただ、十分なテストを実施できているかどうか、実のところ心許ないのではないだろうか。 さまざまなプロジェクトのテスト工程を経験したSHIFTの小林元也ソフトウェアテスト事業本部本部長は、大きく三つの要因が欠陥の見逃しにつながると指摘する。「後工程に責任を放り投げる」「パターンの整理を
鈴村さんが指南する業務フロー図の上手な書き方
まずは，業務フローの例を見てみよう。UMLのアクティビティ図で書いたのが（図1）である。スイムレーンに役割を書き，上から下（または左から右）に向かって業務の進行を書いていく。かどの丸い四角形で示したアクティビティが業務プロセスに対応し，矢印で示したフローが業務の流れになる。「誰が何をするか」が明確になる。 よほど定型化されたものでない限り，業務とは複雑なものである。厳密に書こうとすると，業務フローも複雑になりがちである。しかし，分かりやすさを重視するなら，一つの業務フローに登場するアクティビティはせいぜい10～15程度にとどめるべきだ。 複雑なフローを表現したければ，一部の業務フローを別に切り出して，サブ業務フローとして記述すればよい。親の業務フローのある業務プロセスの内部が，サブ業務フローとなっているというように階層化する。 スイムレーンには顧客や営業担当など役割を設定する。「松山さん」
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
