TEF道イベントの勝ちIBURIの会 ーテスト設計コンテスト優勝記念ー

イベント報告 ソフトウェアテスト

TEF道イベントの勝ちIBURIの会 ーテスト設計コンテスト優勝記念ーに参加しました。

テスト設計コンテストというテストエンジニアの最高峰を決める戦いがあります。 http://aster.or.jp/business/contest/finals.html

そこで優勝した北海道のチームSTUDIO IBURIを招いて、優勝の秘訣を聞きました！ 結論を言っちゃうと、「すごい良かったので他の地域でも是非どうぞ！！」って話です。 3人組みなので、交通費*3くらい。都合10万くらいでいけると思います。

せっかくなのでなかなかなかなか明らかにならない3人の話も書いておきます。

  • みずのり：現職は花屋さん。前職はマネジメント、テスト、モデリング、TOCが得意。
  • MAQ ：現職は薫製屋さん。空いた時間でエンジニア。テスト、コード両方いけるがテスト好き。
  • せーの ：モデリング、コードが好きだが、テストに足を踏み入れた。冷静に見えて熱い男。

いつものように自分がグッときた事を書いておきます。

グッときた事１

品質特性とか既存のフレームワークではなく、顧客の仕様書から言葉を拾い出して丁寧にモデリングしている。 顧客ドメインのモデリング、テスト設計が導出されていた。 ここらへんはDDD（ドメイン駆動設計）の思想が見えた。

グッときた事２

色々な図（ビューといっている）を出しているが、リポジトリは一つであり、見せ方が違うだけというアプローチ。 達成ビューは顧客向け、などこの図は誰のためというのがしっかり考えられている。 変更も考慮していて、astah*というUMLのツールを使って各ビューを作成している。 ここらへんはRDRA（らどら）の思想が見えた。

グッときた事３

クラス図を上手く使ってテストカタマリーを作っている。 is-aとhas-aの関係や、テストの目的、どんなテストをするのかが、一目で分かるようになっている。 ここらへんはクラス図の特性をうまくアレンジしていると感じた。

グッときた事４

プロセス自体もウォーターフォールのように一つずつ完全に決まってから次の工程に行くのではなく、スパイラル的に回して完成度を高めていくやり方。 ここらへんはRDRAやDDDやVSTePと一緒のアプローチ。色々な見方を回すことで足りない箇所を補完していく。

グッときた事５

チームメンバーがそれぞれの役割をこなしている。 特にテストにどっぷり使っていないせーのさんに分かるように説明してもらうことで、花屋と薫製屋の考えも整理されていったとのこと。 そしてそれぞれをリスペクトしているがイイネ！！

最後にせーのさんにモデリングとは何ですか？と聞いてみました。 せーのさん「モデルとは要約力である！」 DDDの増田さんのワークで聞いたフレーズだと思ったけど、今回の経験に裏打ちされた重い言葉でした！！ ※せーのさん的には増田さんからパクったわけではないと主張しているが、ただのツンデレだと思われｗ

まとめると「変なコンサルにお願いするくらいなら、この３人を呼んでみて」って話です。

最後に優勝おめでとう！！北海道から優勝チームが出てくれたってことは意義あることだと思います。

ついでにこの話をより理解するためのトピックは･･･