現場でも最近テスト設計という言葉は当たり前に使われるようになり、テスト設計を推進しているところですが・・・
よく耳にするのは、「仕様書が無いとテストは考えられない」という一言。(従って仕様書がある程度完成しないとテスト設計ができない。と。)
よっぽど未知の世界の商品でないかぎり、ある程度は考えられるでしょう？？？と私は思っているので、このギャップはなんだろう？と考えてみることにしました。
きっと彼等はそもそもテスト対象の分析がうまくできないのではないか？全体像をつかむ訓練ができていないのではないか？という仮説をたてました。
事あるごとに、まずは全体像を絵に描いてごらん、登場物を出してごらん、という話はするのですが、なかなか描こうとしません。これは私にも当てはまるのですが、絵にすると絵をがんばって描こうとしてしまうんですよね・・・・・
でもUMLとか全く勉強していないとやはりハードルは高い・・・(そもそも私もぜんぜん描けない・・・)
そんな折、TEF道で開かれた勉強会の資料を拝見して「ドメインモデリング」というキーワードを得ました。
・・・これなら簡単に描けるんじゃね？？
ネットを調べるうちに、エンティティと線だけでとりあえず描いてみるというのはどうだろう？と思いました。
現場で適用するために、モデルに対して以下の要件を持っています。
・ラフに、こういうモノが登場してこんな処理をするよね、を示したい。(だいたいの認識を共有するのに使いたい)
・UMLの知識が無いと全くわからないのは嫌(簡単な説明でだいたい分かるくらいがよい)
・自由に描きたい
・既存のモデルのお作法に引っ張られたくない(ガチガチに守るということはしたくない)
・だけどゆくゆくはクラス図や他の図に発展するとよいと思っている
・エンティティと関係線と関係の記述は必要
・既存のフリーツールを使いたい。パッと描けるのがよい
ということで、astah communityを使ってクラス図を利用して描いてみよう！という試みが始まりました。まずは世の中にありふれたログイン機能に対して描いてみました。
当たり前にベースドキュメントは無いです。単に世の中にあるログイン機能とはだいたいこんな感じだよね？を示したものです。
こねこねしてできた作品がコチラ(ドメインモデル・・・？？)
クラスを描くと難しく考えてしまうので、エンティティと線で描いてみました。
矢印は流れがあるところに矢印を使っています。
集約と汎化の記号は使ったほうが便利だと思ったので使っています。だけど1:多とかいう数についてはまだ意識して書いていません。単に「このエンティティはこういうものを持っている」「このエンティティを具象化するとこんなものになる」程度の意味で使っています。
この程度なら、あまりモデルに慣れていない人でも、インプットとなる情報から、気になるワードを出すだけ出して、関係線で結んでみることができるかな、と思いました。
ログイン機能の図を職場のメンバーに見せてみたところ、そこそこ納得してもらえました。
で、こちらの図に対してプライベートなSNSに投稿したところ、なんと久保秋さんから「ロバストネス図にしちゃったほうが良い気が・・・」というアドバイスがやってきました！
ろ、ロバストネス図かぁ・・・あ、でも、描けそう。
ネットで画像検索するといろんな図が掲載されていて、いろんな図を見ながら描いてみたのがコレ
再び久保秋さんからアドバイス。
コントローラーはシステム内に収めるのがよく、バウンダリーはシステム間のインタフェースとして扱うとよいということで、インタフェースとシステム内の処理シナリオを意識して再度描き直し！
確かにそれぞれシナリオが見えるようになりました。
処理がより明確になりました。おぉぉ！
そして、これならUIに馴染んでいるブラックボックスなテスト担当者に、UI操作の裏でこんなことが起こっているんだよーというのを理解してもらうのに役立ちそう！
あ、でも、これ、ちょっと描きすぎているかも・・・メンバーに説明するのはこれくらいで良いかもしれないけれど・・・これは臨機応変にズームイン・ズームアウトさせるのがよさそう、と感じました。
ちょっとすっきりさせるためにまとめて、最終的にこうなった！
なお、図の左下にコメントを入れている件について、この図ではエンティティにどんなものがあるかというのは描かないほうがよいと思うのですが、思いついたらまずは描いておくということを止めないようにしようと思っています。最終的に邪魔なら別の図に分ければよいかな、と。
そして、この図をもとに開発側と認識合わせを行なって、そこからテスト要件を載せていくとよさそうだな、と思っています。その工夫はこれから考えるところです♪
私はユースケース図は描いていないのですが、ドメインモデルとユースケース図を描いてからロバストネス図にいくほうがよいようですね。たぶん私は最初のモデルを描いている時点でユースケースが思いついているのだろうな、と思っています。
ログインだけでなくいろんなシステムや機能のドメインモデルを描いていくつもりです。
