ソフトウェアの差分開発のとき、既存システムにはバグが無いもの つまり性善説に基づいて、変更部分のみ試験するが、潜在バグがある場合 小規模の変更でもバグが発現することがある

1. 組込みソフトウェアの品質の小噺
Gou Sawada
2016/2/9

2. 差分開発の構造
潜在バグ
旧ソフト
新規開発時に見つか
らなかったバグ

3. 差分開発の構造
差分開発
潜在バグ 潜在バグ
旧ソフト
開発
既存のまま
新ソフト

4. 差分開発の構造
差分開発
潜在バグ 潜在バグ 潜在バグ
旧ソフト
開発
既存のまま
新ソフト
新ソフト
の試験
試験範囲
回帰試験
（デグレ）
※漏れることがある
潜在バグは残る

5. 既存機能については、バグは無いことを前提として考えている。
性善説
新規開発時に見つからなかったバグは
潜在バグとして残り続ける
何かの拍子にバグが発現する
※工数が限られているため
既存機能まで再試験する
余裕は無い

6. どうするか？

7. 新規開発・大規模開発時に徹底的に
バグを潰す
（観点漏れを防止する）
性善説の強化
どうするか？

8. 新規開発・大規模開発時に徹底的に
バグを潰す
（観点漏れを防止する）
性善説の強化
小規模変更物件でも強化試験を行う
（強化試験をやったことが無い物件について）
性悪説への転換
どうするか？

9. 新規開発・大規模開発時に徹底的に
バグを潰す
（観点漏れを防止する）
性善説の強化
小規模変更物件でも強化試験を行う
（強化試験をやったことが無い物件について）
性悪説への転換
どうするか？
※本当にやろうとすると
試験工数は膨大になる・・・
人も時間も無限ではない

10. 品質対策①：機能一覧表を作る
利用する人の特性 装置の設定 操作中の処理 処理実行
大人 日付（年末年始など） → 停電 → 通常
子供 時刻（深夜0::00など） 長時間の放置 不正終了
年配者 場所 他装置からの通信 取消
性別 時刻補正
障がい者 運用モード
頻繁に利用する 設定の時限切り替え
時々利用する（操作に不慣れ）
故障によるフェールソフト
会員
非会員
１人だけの利用
団体での利用

11. 品質対策①：機能一覧表を作る
利用する人の特性 装置の設定 操作中の処理 処理実行
大人 日付（年末年始など） → 停電 → 通常
子供 時刻（深夜0::00など） 長時間の放置 不正終了
年配者 場所 他装置からの通信 取消
性別 時刻補正
障がい者 運用モード
頻繁に利用する 設定の時限切り替え
時々利用する（操作に不慣れ）
故障によるフェールソフト
会員
非会員
１人だけの利用
団体での利用
ソフト変更・試験項目の作成にあたり
システムが持つ全ての機能や要素を書き出す
これらを、変更しようとしている機能と掛け合わせて
影響があるか検討する

12. 品質対策①：機能一覧表を作る
利用する人の特性 装置の設定 操作中の処理 処理実行
大人 日付（年末年始など） → 停電 → 通常
子供 時刻（深夜0::00など） 長時間の放置 不正終了
年配者 場所 他装置からの通信 取消
性別 時刻補正
障がい者 運用モード
頻繁に利用する 設定の時限切り替え
時々利用する（操作に不慣れ）
故障によるフェールソフト
会員
非会員
１人だけの利用
団体での利用
ソフト変更・試験項目の作成にあたり
システムが持つ全ての機能や要素を書き出す
これらを、変更しようとしている機能と掛け合わせて
影響があるか検討する
※実際、機能一覧表を
作ってみたことで
機能の変更漏れを
発見できたことがあります。

13. 品質対策②：状態遷移を意識してテストする
【観点】各シーケンスにて異常動作を発生させた際、
開始釦を押す 取消 挙動に問題ないことを確認する。
機能別ｷｰを押す 取消
確定を押す 取消
エラー
取消 通信待ち
解除
数量入力
取消 確定を押す エラー
取消
強制実行
正常完了
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
A
B
C
D
E
F
停電
動作
無効キーを押す
通信エラー
日付跨ぎ
業務終了時刻跨ぎ
・・・
1
2
3
4
5
6
7
10
8
9
12
16
13
14
15
11

14. 品質対策②：状態遷移を意識してテストする
【観点】各シーケンスにて異常動作を発生させた際、
開始釦を押す 取消 挙動に問題ないことを確認する。
機能別ｷｰを押す 取消
確定を押す 取消
エラー
取消 通信待ち
解除
数量入力
取消 確定を押す エラー
取消
強制実行
正常完了
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
A
B
C
D
E
F ・・・
動作
停電
無効キーを押す
通信エラー
日付跨ぎ
業務終了時刻跨ぎ
1
2
3
4
5
6
7
10
8
9
12
16
13
14
15
状態×入力の掛け合わせ
で結果が決まる
11

15. 品質対策②：状態遷移を意識してテストする
【観点】各シーケンスにて異常動作を発生させた際、
開始釦を押す 取消 挙動に問題ないことを確認する。
機能別ｷｰを押す 取消
確定を押す 取消
エラー
取消 通信待ち
解除
数量入力
取消 確定を押す エラー
取消
強制実行
正常完了
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
A
B
C
D
E
F ・・・
動作
停電
無効キーを押す
通信エラー
日付跨ぎ
業務終了時刻跨ぎ
1
2
3
4
5
6
7
10
8
9
12
16
13
14
15
状態遷移を意識する
分岐の漏れ＝試験の漏れ
また、各状態における
異常動作が有り得るか検討する
各遷移が成功した場合ばかり試験して、
失敗した場合の試験をしていない事がある
↓
市場で障害発生！
状態×入力の掛け合わせ
で結果が決まる
11

16. 所感：影響度の判断について
単純にソースコードの変更規模が小さければ、影響度も小さいとはいえない！
（変更による潜在バグの発現、処理順序・タイミングが意図せず変わっていた、
もう１か所変更しなければならない部分に気付かなかった・・・etc）

17. 所感：影響度の判断について
単純にソースコードの変更規模が小さければ、影響度も小さいとはいえない！
（変更による潜在バグの発現、処理順序・タイミングが意図せず変わっていた、
もう１か所変更しなければならない部分に気付かなかった・・・etc）
また、小規模の変更であっても、
・担当者が変わった
・前回開発から長期間経過している
などの場合は要注意案件と考える。

18. ありがとうございました