テストデザインファーストについて

テストデザインファーストという言葉を聞いたことがあるでしょうか。


私の会社ではこの言葉を

◆要件定義の時にシステムテストケースを
◆外部設計の時に結合テストケースを
◆内部設計の時に単体テストケースを
(外部設計→基本設計、内部設計→詳細設計)


つくること、を意味しています




検証のレベルに合わせて、適当な設計段階でテストケースの作成を実施すると、より詳細な設計や実装に移る前に、設計上の不備や、考慮漏れが検出しやすくなります。


また、テストケースを作成することで、想定結果(システムの想定上の振る舞い)をあらかじめ検証できます。

つまり、手戻りが非常に少なくなるということです。

これは見積り上の問題(より上流の工程に多くの要員、作業量を投入する必要がある)のため、簡単にはできないと思います。


が、私の担当プロジェクトでは、幸いなことにそのすすめ方が定着しています。


なぜ「テストデザインファースト」の話を出したかと言うと、いま進行中の案件でこれがうまくできていないものがあるからです。


この案件ではテストでの確認観点や想定結果を記載した「テストケース」と、そのテストケースを実現するためにどのようなデータを投入するかを記載した「データ設定表」を設計段階で作成しています。


しかし、データ設定表が空っぽのまま先に進んでいたのです。


曰く、「どのようにデータを設定するか実際のデータ作成をしないとわからない」とのこと。

で、実際にテストをする段階になって、データ設定表を作成してもらったところ、

そのデータ設定表がめちゃくちゃ。

原因を聞いてみたところ、仕様の理解が不十分とのこと。

結局、どういうことかというと、データの流れなどをまったく理解してないまま、

設計～製造まで実施していたということです。

つまり、どのようにデータが導出されるか分からないため、データ設定表を

つくることができなかったということです

このような設計はとても信頼することができません。

（新規開発でなく、保守開発で他の設計を真似をできるから

　なんとかそれなりの設計ができていた）

仕様を理解できていないため、テストデータ設定表の棚上げして、

結局、仕様を理解していない設計を続けてしまった。

「テストデザインファースト」について、もう一度考え直した瞬間でした。

それでは本日のコケコッコはこれまでです。おやすみなさい。

仕事のなかで困難なこと

仕事をしていると、困難を感じることは多々あります。

例えば、パートナーの進捗報告の危なそうな部分を見抜くこと。

例えば、効率よく業務をすすめられるような、手順を確立すること。

このブログに目を通している方は誰でも少なからず

毎日色々な「困難」に立ち向かっていると思います。



私にとって、今立ち向かっていて苦しいと感じる「困難」は、

初めて対面する課題に解決策をひねり出すことです。


今まではこのような課題はスマートにひらめきのようなもので

解決策が生み出されるものと考えていました。

だから、課題の解決は「困難」なものではなく、最適なフレームワークを

使用したロジカルシンキングによってきれいに生み出されるものだと

考えていました。

しかし、違いました。

もちろん解決策にたどり着くためにはロジカルシンキングで

出てくるようなフレームワーク(フェルミ推定だとか、MECEだとか)は

役に立つと思います。


ただ根本的に必要なものは、知的なタフさ、わからないものを

わかるようにしていくための強力な集中力だと思うようになりました。


答えの決まっていない課題に立ち向かっていると、

投げ出したくなってきます。

考える前よりかは問題や行動プランが明確になってるし、

このくらいでなんとかなるだろうと、思ってしまいます。


ただ、本当に問題が解決されているということができるのは、

解決策が鮮明にイメージできて、その解決策で行けると確信が

もてたときだけです。

(未来は不確定なことが多いので必ずしもここまでたどり

着けるかはわかりません。ただ少なくともどのようなことが

理解されていないか＝なにがはっきりすれば確実な解に

たどりつけるかはわかっている必要があると思います）


課題の難易度にもよりますが、ここまでたどりつくにはかなり

大きな精神的負荷がかかると思います

じりじりするような思考の積み重ねと、それを積み木のように

崩れないよう積み上げていく集中力が必要だからです。



成功を積み重ねる人は、この精神的負荷に耐えられる

人、知的なタフさを持つ人だと思います。

考え抜いて、解決までの道筋が見えているからこそ

成功できると思います。

（そういう意味で、考え抜けない人は日々

バクチを打ちながら仕事をしていることになります）

あきらめず考え抜くこと、言うは易し、行なうは難しですが

これを続けていくことで少しずつ知的タフさを身につけて

行きたいと思います。

それでは今日のコケコッコはこれまでです。

終わらない内部設計

今日は、はっきりとした方針とかを出せない回かも知れません。

先日ブログに載せましたが、いま私のチームでは、何個かの案件を並行して回しています。その中の一つに業務的に少し難しく、規模も大きめの案件があります。


今はプログラミングを終えつつあり、テストをはじめる段階。プログラミングの結果を見ながらテストケースなどに見直しをかけているところです。


でるわ出るわ。内部設計の指摘が。


この段階で内部設計レベルの指摘がぽんぽん出るとスケジュールに影響が結構出てきます。


ここで思うのは手戻りがいかに大きなインパクトをもつかということです。


内部設計レベルの誤りがあっただけでも、内部設計の見直し、プログラミング修正、テスト計画(ケース)見直しと、品質を保つためにたくさんの作業が発生してしまいます。


手戻りの悪いところは単に前の工程をもう一度検討しなければならないだけではなく、管理すべき成果物を増やすというところにもあります。


では、どうすればよいか？
何らかの結論があるわけではありません。上流からしっかり押さえていきましょうというのは簡単ですが、それが簡単にできるならシステム開発はこんなに難しくありません。


一つだけ言えるとすれば、以下のことです。(これは私のチームができていないだけで、みなさん当然としてやっていることかもしれません)


少なくとも設計の段階で保留事項をなくし、その設計で問題ないと確信がもてるまで設計をつめること。


詰め切れないことがあれば、後ろの工程を見ていつまでに詰めるか決めておくことです。


スケジュールを守ることに躍起になって、いまいち自信のもてない成果物を作ることは、一番いけないことです。


それを詰めるために掛かる時間と、あとあと手戻りとして掛かる時間は後者のほうが圧倒的に大きいからです。


いまは後者を選んだ結果に苦しまされています。



それでは、本日はいまいち具体的な結論がでないコケコッコでした。おやすみなさい。