インフラプロジェクトでテストファーストに試験仕様を先に書くことで得られた副次効果

on


兎角、インフラの設計と構築は

要件を実現するパラメータの特定
　↓
パラメータ値の設計
　↓
構築時のデフォルト値の変更
　↓
結合試験で設計したパラメータ値での動作試験


こんな風ですよね。
で、トラブルが起きる、というかアプリと結合してみたら想定外の動きをしてパラメータを修正することになる、と。


「なぜそうなってしまうのか。」と言えば、結合試験と言う名の単体試験をやっているからであり、インフラの中で機能を連携した結合試験の観点で試験をやっていないから、です。あと、変更前後のパラメータの振る舞いを知らずにパラメータを設計しているから、というのもあります。


よく訓練された、いや、過去に痛い目にあったインフラエンジニアは、将又、品質で詰められことのあるエンジニアは、パラメータとして取りうる値の中ではパッケージを適用する限りその製品ベンダが動作保証してくれるけれど、実際にどう動くかは様々なパラメータの組み合わせの結果が一つのシステムとしての振る舞いになることをわかっていて、そうした振る舞いは机上で裏を取り、実際の検証で動作を確認しないと後で痛い目に合うのでやっておかないと「いけないコト」を知っているんですけどね。


要件からパラメータを設計したんだから……
割と「要件どおりパラメータを設計したんだからパラメータを確認したら終わりでいいじゃん？」と言うインフラエンジニアが多いです。「あとでトラブルが起きたときに作業品質を担保するエビデンスが無くてどうやって説明するの？」と聞けば黙っちゃうし、「作業品質のエビデンスと品質保証のエビデンスは意味が違うよ。」と言うと、今度は「作業が煩雑で大変だから取るの止めたい。」という始末で。


自分達の作業が確実に行われていることの客観的な証明や要件が実装されていることの証拠を残しておかないとあとあとトラブルになって疑われたときにただ「やってます。」と言っても誰も信じないし「エビデンスを出して。」と言われるが落ちだし。そのことまで想像がつないみたいなんだけどなんでだろう。やっぱり、一担当としてのエンジニアの責しか感じていないからなんだろうなぁ、と思うのは仕方がないのかそうでもないのか。


「あのさ、作業品質の保証が今と同じレベルで取れるやり方なら変えてもいいよ。作業品質のエビデンス取り方を教えて。」というと、対案が無くいっているのだから我儘や甘えと思われても仕方がないよね。


「何度も同じことを言わせてもらうんだけど、自分達が設計したパラメータがそのパラメータだけ変更したこと、変更したパラメータとデフォルトのパラメータを組み合わせたシステムとして要件を実装していることを証明するエビデンスが欲しいんです。やり方は、今と変えてもいい。だけど、要求は下げたりはしないよ。」と。ここはしっかりと詰めておかないといけないと思うんですよ、品質に対する考え方は、後々になって確保しようとしても無理だもの。


要件の整理のタイミングで結合試験の中項目の仕様を決める
割と大きな機能追加をするタイミングがあったとき、コレをそのままやっては前述の該当するパラメータの特定から手を付けてしまって、担当するシステムとしての全体の振る舞いの観点での設計が漏れてしまうと危惧をしたのです。いくらパラメータを特定してパラメータ値を設定しても担当している既存システムとして出来上がっている全体の動きをイメージできなければ設計が漏れるし、影響範囲を見誤ってしまうから。



で、どうしようかと思って、少し逡巡して機能追加を進めるうえでの構築プロセスの見直しの必要性の有無の検討後に結合試験んの中項目の仕様を決めて、試験で確認するシステムとしての振る舞いを決めてしまおう、と。


これって、実装しなければならない要件、満たしていなければならない機能仕様を試験項目から意図的に設計させているということになるのでは？と。Aという追加機能を実装していることを試験で確認する。一方、Aの機能を実装したことで既存の機能は影響しない、又は、Xという機能は振る舞いが変わる、それを試験で確認する仕様とする、ということにしてしまえば、設計時点でパラメータの設定に机上で試験済みのパラメータの設計をしていることになり、危惧している抜け漏れは防止できるのでは？と。


これって正統なTDDじゃないかもしれないけど、意図的な開発行為をさせるわけでテストファーストと言ってもいいのではないかな。どうなんでしょう。


試験仕様を先に書くことでの副次効果
先に結合試験の中項目の仕様を決めるのですから、メンバは試験実施に必要な環境を考えるようになります。既存への機能追加ですから、一から構築するときよりは制約が多いのです。それを考える必要が出てきます。それを理解しようと担当するシステムを中心としてシステムの概要図を描くことになり、機能追加するときのインタフェースや環境の状態からの制約を下敷きにした作業の順番まで考えないといけないことに気付くんですね。


これは一担当で考えていたことを担当するシステムをホールで考える機会を与えることになるんです。こうした観点で考えるのはリーダのロールのエンジニアばかりになってしまうのでそれが全員で考えさせたことが良かったな、と。