やっとこさ、提案したものが受け入れられる（かも？）
今まで何度か触れてきたABAP Unitを（試験的にですが）実プロジェクトで試すことができそうです。
経緯
ABAP UnitとはxUnitの一種で、SAP/ABAP用のユニットテストフレームワークです。以前、プロジェクト内勉強会でデモを含めて紹介したことはあったのですが、そのときは「うまく使いこなせると便利そうだけど、導入する手間が大き過ぎる…」という評価でした*1。
そういう流れの中、今回仕様変更対応によるデグレードが発生しました。しかも、帳票出力項目の追加対応で、片方は対応したけど別の箇所は対応していなかったためという、結構恥ずかしいバグ…。これには、開発リーダーも思うところがあったみたいで、どうしたら防げるかということを開発メンバーに相談に来ました。
で、ここぞとばかりに「以前紹介したテストツールがあったじゃないですか？あれを導入してたら、今回のようなデグレは防げたかもしれませんよ。」と発言。更に続けて「今は作業量的に若干余裕があるので、この機会に実プロジェクト上でそのツールを試してみませんか？」と持ちかけました。
そしたら、「じゃあ次新規開発するようなものがあったら、そこで試してみようか。」って。やほーい！ｖ
考えなければいけないこと
ただ、ABAP Unitを導入するにあたって、結構考えなければいけないことがありますよね。導入することによって、テストのプロセスも多少なりとも変更があるでしょう。今ある開発プロセスを改善するわけだから、以前と同じ程度の効果しか発揮できないものは意味がない。かといって、今まで開発チームとして培ってきたノウハウもあるわけで、そこをまったく無視したプロセスを提案することも避けなければならない。
ということで、ぱっと思いついたことをとりあえず箇条書き程度ですがあげてみました。
- 誰がテストを作成するの？
- 開発者
- 第三者
- どのレベルのテストを作成するの？
- 正常処理が検証できるレベル
- 異常処理まで含めて検証できるレベル
- テストの網羅性はどう判断する？
- ABAP Unitと合わせて、何か知っておいた方がいいことは？
今考えているのは、「プログラム作成者＝テスト作成者」で最初は正常処理のみテストをしていって大枠を組み上げる。大枠が固まってきたら、今度は異常処理のロジックとテストを作成して全体の検証を行う。という感じかな？以前作成した資料があるので、それを元にしてクラスの概念とか例外ハンドルについてノウハウ共有する時間も取れたらいいな。網羅性に関しては、djUnitみたいなものがあれば一番よかったのですが、カバレッジ測定ツールがないので机上で検証するしか。
本当は自分でプログラム作って自分でテストまで作成して…だと色々やりやすかったのですが、「できるだけ新人などにコーディングする機会を与えて欲しい」と言われたらどうしようもありません。できるだけサポートしながら、こっちが望む方向に持っていくようにしないとですね。
まぁ、新規開発するプログラムがなければ、↑で考えたことも絵に描いた餅なのですけどね。提案したものが受け入れられそうな数少ない事例なので、何か検証できそうなものが落ちてくることを願います・・・ｗ
