1. パッケージソフトのテスト戦略
開発者から見たテストの現場
rev.2
2010/01/29
SATO Tomoyuki
Ariel Networks, Inc.

2. 自己紹介

3. 佐藤 寛之 (SATO Tomoyuki)
✔ アリエル・ネットワーク株式会社
開発部 ソリューショングループ 所属
✔ プログラマ 時々 プロジェクトマネージャ
✔ 2008年6月より現職

4. ふだんの仕事

5. IBMに喧嘩を売るだけの
簡単なお仕事です

6. ・・・というのを
ニコ生で流しても
いいんでしょうか

7. 多くの企業が抱えている
Lotus Notesという負の遺産を
弊社のグループウェアに移行する
お手伝いをしています

8. 弊社のグループウェア上で動く
特定顧客向けのアドインの
受託開発もやってます

9. 会社はパッケージベンダですが
私の仕事はSIに近いです

10. 自分語りは
このくらいにして

11. 本日のお題
テスト過剰にどう対処するか

12. ソフトウェアテストPRESSの
記事では、テストに対する
取り組みの変遷と
トラブル事例を紹介しました

13. が

14. そこで取り上げた内容のうち
プログラマ兼PMの立場から
最大の課題と考えているのは

15. 品質を犠牲にせず
いかにテスト工数を
削減するか

16. ・・・という部分です

17. そんなわけで
今日はこの部分について
掘り下げる形でお話しします

18. あらすじ
✔ テスト不足と過剰の事例
✔ テスト過剰への対処法(案)
➢ 完璧なソフトウェアを目指さない
➢ テストの自動化

19. 極端な事例1
1年ちょっと前のアリエル

20. 客先にいる
コンサルタントから電話

21. コンサルタント「このアドインの
ここの動きをこう変えて、ここの
文言もこうしてほしいんだけど」

22. 佐藤「すぐ直します」

23. 電話をつないだまま
おもむろにコードを修正

24. ビルド

25. メールで送る

26. 佐藤「今送ったファイルで
差し替えてください」

27. 所要時間
約15分

28. とはいえ

29. 第三者による
テストを通さないのは
ものすごく怖いし危険です

30. よい子は真似しないでね♪

31. 極端な事例2
前職

32. アリエル入社前は
某メーカー系SIerで
SEをやってました

33. 担当していたパッケージで
JavaScriptを1行修正する
プロジェクト

34. プロジェクト期間
約1ヶ月

35. 内訳

36. プロジェクト開始に関わる
事務手続き
2日

37. 品質計画の策定と
レビューと承認
2日

38. テスト計画の策定と
レビューと承認
2日

39. 設計ドキュメントの作成と
レビューと承認
3日

40. テストケースの作成と
レビューと承認
2日

41. 実装
10秒

42. テストと品質分析/評価
4日

43. マニュアル修正
1日

44. 検査
3日

45. 企業認証絡みの
エビデンス整備
2日

46. 爆発しろ

47. 物事には
程度というものがあります

48. 教訓
プロジェクト内容を見極めて
プロセステーラリングを
ちゃんとやりましょう

49. 用語のおさらい： テーラリング
組織・企業が業務の基本として定めた
標準プロセスや開発標準などを手直しして、個別の
プロジェクトや顧客の要求に合わせて実用的な
標準（手順・成果物・指標など）を作成・実行すること
出典：@IT情報マネジメント用語辞典

50. ご紹介した事例2つは
プロジェクト全体にわたって
色々問題がありますが

51. 今日はテストの話なので
テストの不足や過剰という
切り口で考えてみる

52. テスト不足への対処
✔ 障害事例の分析
✔ ツールや方法論の研究・開発
・・・etc.
様々な場で活発に議論されてきた

53. 一方でテスト過剰については
取り上げられる機会が
少ないように思える
※ 私はテストの専門家ではないので
気のせいかもしれません

54. テスト過剰の弊害
✔ スケジュール・予算超過
✔ 価格競争力の低下
✔ 重大なバグの埋没・見逃し

55. テスト過剰への対処法(案)
✔ 完璧なソフトウェアを目指さない
✔ テストの自動化

56. 1. 完璧なソフトウェアを
目指さない

57. “Good enough software”
十分に良いソフトウェア
出典:
Andrew Hunt & David Thomas
“The Pragmatic Programmer”

58. 残存バグ0件や
テストカバレージ100%は
本当に求められているか？

59. eXtreme Programmingの哲学
失敗するかもしれない
すべてのことをテストしよう
出典：
Ron Jeffries, Ann Anderson & Chet Hendrickson
“eXtreme Programming Installed”

60. 逆に捉えると

61. 「失敗しそうにないこと」は
テストしてはいけない
出典：
Ron Jeffries, Ann Anderson & Chet Hendrickson
“eXtreme Programming Installed”

62. 常に品質最優先ではなく
スケジュールやコストとの
トレードオフを
ちゃんと考えるべき

63. 事例
複雑なワークフローと
多数の帳票を用いる
旅費精算アドイン

64. リリース予定日1ヶ月前の状況
✔ テストで検出されるバグが多く
修正に時間を要して作業が遅延
✔ リリース予定日までに全ての
テストを完了するのは絶望的

65. では、残された時間を
何に注力すべきか？

66. 顧客要件の整理
✔ 旅費の金額計算に誤りがないこと
➔ 既にテスト完了しておりクリア
✔ 年度初めに予定通り稼働すること
➔ 作業を削らないと間に合わない！

67. この段階で
スケジュールに合わせて
品質/機能を落とすという
決断をしている

68. 残っているテスト内容の分析
ワークフローのテストが未実施
(申請経路：約150パターン)
分析・整理
担当者や担当組織が異なるだけで
論理的な経路は同じものが多数存在する
ことが判明

69. テスト内容の絞り込み
論理的に同じ経路をグルーピングし
各グループから1パターンずつ選択
テスト対象の申請経路
150パターン ⇒ 19パターン

70. バグのトリアージ
✔ 申請書を閲覧できないはずのユーザーが
申請書を閲覧できる
➔ 顧客の業務ルールに反するため対処必須
✔ 帳票の印刷時に一部の罫線が消える
➔ 業務への影響が軽微ため対処しない

71. 結果
当初の予定通りに本番稼働
大きな不具合報告は無し
対処しなかったバグについては
保守フェーズ内で順次対応

72. 2.テストの自動化

73. テストケースが過剰でも
それが自動化されている限り
工数へのインパクトは少ない

74. アリエルのアドイン開発における
テスト自動化への取り組み

75. アドインのユニットテストの自動化
アドインの実装形態
XMLによるデータ構造の定義と
JavaScript on Mozilla Rhinoによる
ロジックの記述
こういう特殊な環境下で
テストの自動化は可能か？

76. 言語はJavaScriptだけど
実行環境がJavaだから
JsUnitによるテストは難しい

77. 実行環境はJavaだけど
言語はJavaScriptだから
JUnitによるテストは難しい

78. 苦節1年
JUnit
DbUnit
ねこ ねこ
JsUnit Selenium

79. ※以下の内容は後ほど詳しく説明します
JUnitのTestCaseクラスを
JavaScriptで継承して実装することで
JUnitを用いてスクリプトをテストできそう！

80. まとめ

81. No Silver Bullets
技法・方法論・ツールを盲信せず
テストのやり方は自分たちの手で
きちんとテーラリングしよう！

82. 徹底した作業の自動化
コンピュータにできることは
コンピュータに任せよう！
人間にしかできないことに集中しよう！

83. 前半終了