那須のチームに対して、何が羨ましいと思うのか

2016/10/29(土)に行われた「ソフトウェアテスト勉強会～テスターと創る開発現場～」の参加レポートです。

東北デベロッパーズコミュニティ - イベント案内 | 2016-10-29 (土) ソフトウェアテスト勉強会～テスターと創る開発現場～

"テストの妖精"こと@miwa719さんと、"プロの無職"こと@m_sekiさんに彼らの開発現場について語っていただきました。

私たちの開発現場：@miwa719
speakerdeck.com

プロの前座(tohoku again)：@m_seki
speakerdeck.com



JaSST東北2014で初めて彼らにお会いして以来、何度か話を伺っています。彼らの話はいつも刺激的で、彼らのような開発現場をいつも羨ましく思って聞いています。彼らのチームは、私が知る限りにおいて"最高のチーム"を実現したようなチームだと感じています。

ふと、自分は彼らのチームの何を羨ましく思っているのだろうかと考えました。そこで今回は彼らのチームの何が凄いのか、何が羨ましいのかを整理してみました。

彼らのチームの何が凄いのか

2時間という時間がアッという間に過ぎるほど、今回も素晴らしい活動をたくさん話していただきました。

開発とテストが分かれていない

ソフトウェア開発はV字モデルに従って行われることが多いです。そのため、テストは"開発物が仕様通りに動くかどうか"を確認することになりがちです。しかし、彼らのチームは開発時にテストの設計も行います。テストの観点から開発設計に対して指摘をすることもよくあるそうです。また、テスターがあらかじめどのようなことを重点的にテストしたいかを伝えておくことで、開発者がその部分を意識するためバグを減らすことができているそうです。

忍者式テスト

過去のチケットを含めて毎日少量ずつテストを実施するという@m_sekiさん考案のテスト技法。テストを実施するチケットは一定期間ですべてのチケットが回るように工夫してあるとか。忍者式テスト自体は何度かお話伺ったことがありますが、てっきり"若いシステム"に対して有効な手段だと思ってました。今回、対象のシステムが15年以上のシステムだとの話を聞いて、軽く戦慄しています。

テストケースのメンテナンス

仕様が変更になった時、対象となるテストケースは同時期に修正されるのが一般的です。しかし、彼らのチームでは、テストケースの修正は気付いた時に実施するそうです。膨大なテストケースに対して、必要な変更をすべて洗い出すことに膨大な時間がかかることを理解しているからこその対応です。また忍者式テストによって、彼らのチームはすべてのチケットが一定期間で回り続けます。そのため、チケットが仕様変更の対象かどうか気付く機会が多いため、テストケースを適宜修正しても問題が起きないのだと思います。

彼らのチームの何が羨ましいのか

彼らの話を聞くたびに、「彼らは最高のチームである」と感じますし、「彼らのようなチームで働きたい」と感じます。そんな羨望の理由を自分なりに整理してみます。

何が"最高"なのか

彼らのチームは理想的な働き方を体現しています。彼ら以上に理想的な働き方ができているチームは知らないため、"最高のチーム"だと思っていますが、その漠然とした"最高"が何なのかをもう少し明確にしてみます。

  • 技術が"最高"なのか

@m_sekiさんは一流の開発者ですし、@miwa719さんは一流のテスターであることは疑いようがありません。彼らがとても高い技術を持っていることは間違いがありませんが、彼らの技術に対して羨ましいと思っているわけではなさそうです。ことソフトウェアテストの分野で彼らに接する限り、技術を前面に押している印象はありません。もちろん彼らの活動が高い技術によって支えられている部分があるのですが、技術に関して言えばもっと技術を前面に押し出している人がいると考えています。そのため、自分が感じている"最高"は技術ではないのでしょう。

  • 品質が"最高"なのか

彼らの活動から"品質が低いものができるはずがない"と確信しています。全員が良いものを作るために同じ方向を向いている彼らのチームは"最高"の品質を作りこめるレベルだと思います。しかし、彼らの製品は一般消費者向けではないので、自分が彼らの品質を体感できる機会はほぼありません。そのため、自分が感じている"最高"は品質ではないのでしょう。

最高のチームワーク

彼らのチームは、誰かの問題を自分の問題として真剣に向き合ってくれるメンバーで構成されています。トラブルが起きた時でもを全員の問題として捉え、知恵を出し合い、そのチームの中での最善手を選び続けているのだと思います。そんなところを羨ましいと感じています。

彼らのチームは、完璧なものなどないことを理解した上で、それでも理想に向かうために改善策を出し続けています。人はミスをしますし、完璧な成果物を作成することは不可能です。そのうえで、ミスを減らすにはどうすればいいのか、ミスが起きたことにどうやって早く気付くか、に注力しているように思います。そんなところが羨ましいと感じています。

そんな彼らのチームの「誰かの問題を全員の問題として捉え、知恵を出し合える」「人はミスをするという当たり前のことを当たり前のように受け入れ、その上で理想に向かうために変化し続ける」チームが羨ましいです。彼らのチームは私にとって"最高"に理想的な、最高のチームワークを持っているのだと思います。

どうすれば彼らのチームを超えられるのか

彼らのチームのどのようなところが羨ましいかが分かれば、それに対して自分たちにどのような改善が必要かが見えてきます。千里の道も一歩から。彼らのチームと自分のチームの差が千里あるとして、その一歩先を行くために、今の一歩を踏み出さないといけません。

  • チームで問題を出し合える環境を作る

「言うは易し、行うは難し」の最たる例です。チーム内で問題を言い合おうとしても中々出てきません。出てきた問題を他人事に捉えられたり、問題を出したことで責められたり、そもそも自分の時間が惜しくて他人の話を聞くことに消極的になったり。話す側も聞く側も問題を出し合うことにメリットを感じにくいです。実際は良いものを作るうえでは必要でメリットが多いのだけど。
具体策はまだありませんが、ポイントは「心理的安全性」と「チームがどこを向いているか」あたりでしょうか。

  • 現実に対して素直になる

完璧な環境で仕事をする。理想的かもしれませんが、現実にはそんな環境はありません。問題は「自分がうまくいかないのは、理想的な環境ではないから」だと責任を転嫁してしまい動けなくなってしまうことです。自分も他人も含め誰だってミスはしますし、出てきた成果に完璧なものなんてありません。それらから目を逸らさずに、その現実を踏まえた上で改善する方法を考え続けないといけません。

今回の考えを整理していて、最高のチームを作るうえで(IT的)技術そのものが重要ではないように感じました。求めるべきはチーム全員が一つの問題に向き合える環境であって、技術の高さではないかなと思います。では、技術が不要なのかというとそうではなく、チームの問題を解決するために技術が必要になる場面は必ず出てきます。チームの問題に昇華できていない個人の問題を技術で解決しようとすると、認識違いが起きてしまい、チームに良くない影響があるかもしれません。程度によると思いますが。
解決したい問題があったら、まずチームの問題として昇華してから解決する。その方針が良さそうかな、と思います。

まとめ

@miwa719さんと@m_sekiさんの開発現場は本当に魅力的で、話を聞くたび一緒に働かせてもらいたいと思います。そんな理想的な彼らのチームが何を大事にしているのかを理解して、自分でも同じところを大事にできると彼らのような理想的な開発現場が築けるのかな、と思います。

2016/7/23(土)「VSTeP勉強会(仮)」：テストフレーム設計

JaSST東北実行委員による、VSTePの勉強会を実施しました。
VSTePをテーマとした、JaSST'16東北は2016/5/20に完了しています。しかし、「まだ俺たちはVSTePを十分に理解していない」という考えのもと、実行委員で集まって勉強会を開催しました。

今回のテーマは「テストフレーム」です。JaSST東北のワークショップでは、チーム内の考えを揃える「テスト観点図」、テストの戦略を検討する「テストコンテナ」を扱いました。しかし、具体的なテストケースを生成するための準備に相当する「テストフレーム」はワークショップでは扱いませんでした。そのため、テストフレーム設計まで実施して、テストケースまで生成できるようになることが今回の目的でした。

テストフレーム設計を実践してみて理解したことをまとめます。実行委員のみで検討した内容になりますので、実際のVSTePの意図とは異なるかもしれませんが参考まで。

  • テストフレームの構成要素により、抽象的なテストケースが生成できる
  • テストケースにおけるテスト条件、テスト対象、振る舞い
  • 同じテストフレームでも異なるテストが作成できる
  • テストフレームはテスト観点をまとめたもの

参考資料：
http://qualab.jp/materials/VSTeP.130510.color.pdf

テストフレームの構成要素により、抽象的なテストケースが生成できる

テストフレームとは「テストケースの構造（スケルトン）をテスト観点の組み合わせで示す」もの。
例えば、解凍ソフトというテーマがあったとして、以下のようなテスト観点から構築されるテストフレームがあったとする。

  • 環境(OS)
  • ファイル(ファイル名、ファイル数)
  • トリガ(ドラッグ＆ドロップ、GUIからの指定)
  • 解凍(圧縮前と解凍後のファイルが一致)

このテストフレームからは「<環境>において、<ファイル>を<トリガ>によって<解凍>することを確認する」という抽象的なテストケースを作成することができる。
具体的なテストケースでは、このテスト観点に当たるところに具体的な値を入れればよい。

テストケースにおけるテスト条件、テスト対象、振る舞い

テストフレームにおけるテスト観点は大きく3つに分類される。テストフレームに現れたテスト観点は必ずしも全ての項目を組み合わせでテストしなければならないわけではない。

  • テスト条件

テストケースにおけるインプットに当たる。そのテストにおいて、網羅されるもの。あるテストフレームからテストを生成する際に、パターンを試したいものを示す。

  • テスト対象

テストケースにおけるインプットに当たる。そのテストにおいて、テストしたいもの。あるテストフレームからテストを生成する際に、変化しないものを示す。

  • 振る舞い

テストケースにおけるアウトプットに当たる。そのテストにおいて、期待される結果。あるテストフレームからテストを生成する際に、確認したいものを示す。

同じテストフレームでも異なるテストが作成できる

何をテストしたいかによって、同じテストフレームでも異なるテストケースを作ることができる。テストフレームにおいて、各テスト観点をテスト条件、テスト対象、振る舞いのいずれかに割り当てることによって、生成できるテストが異なる。

  • どんな解凍方法でも適切に解凍できることをテストしたい

テスト条件：トリガ
テスト対象：環境、ファイル
振る舞い：解凍

  • どんな環境でも適切に解凍できることをテストしたい

テスト条件：環境
テスト対象：ファイル、トリガ
振る舞い：解凍


上記は一例。「GUIの挙動はOSに依存するから、環境とトリガをテスト条件にして、組み合わせテストしたい」というものも可能です。設定の仕方はテストエンジニアのうで次第。

テストフレームはテスト観点をまとめたもの

テスト観点図からテストコンテナを生成する。テストコンテナでどんなテストを実施したいかを定めた後に、詳細なテストフレームを設計する。テストコンテナで大まかにテスト観点をまとめるが、ここで集まったテスト観点は粗い粒度でのテストフレーム構築に相当する。粗い粒度のテストフレームから、テストしたいことに合わせて詳細なテストフレームを生成する。
例えば、「環境はOSの他にCPUやメモリ搭載量などもあるが、OSに限定してテストフレームを生成する」などが挙げられる。


感想

テストフレームの考え方を理解することにより、テストコンテナの重要性を理解することができた。詳細なテストフレームの作成には、何をテストしたいを明確にする必要がある。テストしたいことが定まっていないと詳細なテストフレームを生成することができず、意味のあるテストケースが生成できない。

組み込み開発にMVCは使えるか？

WACATE名物と言っても過言ではない「夜の分科会」の二次会で、モデリングの話し合いをしてきました。その中で、「組み込み開発にMVCは使えるか」という話が出たのでまとめます。基本的に自分の主観を語っています。異論は認めます。
toshimana.hatenablog.com

はじめに

MVCについて勘違いをしていました。正しい理解は以下のリンクなどを参考にしてください。
at-grandpa.hatenablog.jp

私の理解では、MVCのMはシステムロジックという理解は正しかったのですが、View-Controllerについて勘違いしていました。Viewをシステム外部とのやり取り全般、ControllerはViewとModelの橋渡しだと勘違いしていました。正しくはViewは表示(システム外部への出力)、Controllerは(システム外部からの入力)になります。WACATEでは自分が誤った理解で話をしていたので、ここで修正しておきます。

組み込み開発にMVCは使えるか

MVCはWeb業界で広まった印象があるため、「MVCはGUIがあるシステム向けのデザインパターン」というイメージがあると思っています。Viewが表示、Controllerが操作であれば、GUIがない組み込み開発であれば、使い道がない印象を受けます。
私のイメージではViewはシステム外部への出力、Controllerはシステム外部からの入力となります。そのように解釈すると組み込みデバイスへの出力はViewで、組み込みデバイスからの入力はControllerで表現できます。ViewとConntrollerは強く依存していることが多いため、分離しない方がいいことが多そうですが。
ViewやControllerという言葉のイメージだと組み込み開発には使いにくいイメージがありますが、デバイスとの入出力をViewやControllerで表現する事でMVCを組み込みに活かすことができます。

MVCは1システム1つでなくても良い。

組み込みMVCで考えた場合、各デバイスに関する操作をサブシステムとしてMVCを用意した方が分かりやすい、という話をしました。例えばエアコンシステムの場合、エアコン本体をMVCで設計し、リモコンを別のMVCとして設計します。その2つのやり取りは統合したModelとして扱うと良いのではないか、と考えました。@dproject21さんの話では、統合したModelをサービス層と表現していました。

デバイス処理の抽象化

ControllerからModelに操作を渡す場合、処理の抽象度を変えた方が良いと思います。リモコンを例にすると、Controllerでは「電源ボタンを押す」操作を扱い、Modelでは「電源ON/OFF」という抽象化したイベントとして扱う方が良いと考えています。

MVCでデータベースはどれに該当するのか

Web開発では欠かせないデータベースですが、MVCではどれに該当するか、という話が出ました。
データベースはViewもしくはControllerに該当すると考えています。システムで管理できる状態はModelで、管理できない状態はViewもしくはControllerで扱うべき、と考えています。データベースはその中に格納されているデータをシステムでは保持しません。必要に応じて、システムがデータベースに問い合わせるため、その問い合わせはViewもしくはControllerで表現されるべきだと考えています。

まとめ

組み込みでMVCは使える。ETロボコンとかで証明できるといいな。
お話しの発端はWACATEだけど、こういう開発よりの話は大好物なので、楽しかったです。

2016/6/18(土),19(日) 「WACATE2016夏　～走りきるテスト設計～」に参加しました。

「Workshop for Accelerating CApable Testing Engineers」、通称WACATEに参加してきました。神奈川県・三浦海岸にテストバカが集まって夜通しテストの話をする勉強会です。
WACATE2016 夏 ～走りきるテスト設計～ 開催概要 - WACATE （ソフトウェアテストワークショップ）

以下、前回の参加レポートです。
toshimana.hatenablog.com
…2015夏も参加しているはずなのですが、レポート書いていなかったですね。

概要

タイトルに"走りきる"と書いてある通り、「テスト分析」から「テスト設計」、「テストケース実装」までの一連を行うことが今回のメインテーマとなっています。

「テスト分析」「テスト設計」「テストケース実装」を全て行うワークショップは、JaSST'16東北の企画当初に想定し、最終的に断念したテーマでもあります。
ワークそのものにも興味がありますが、どんな運営、ワークをするのかに凄く興味を持って参加しました。

BPPセッション 近美さん

ASTER-テスト設計コンテスト'14の優勝チームの一員である近美さんの発表は、まさに今回のテーマにうってつけだと言えます。「テストエンジニアはどうあるべきか」の話だったり「テスト技術があると何が嬉しい」といった話があり、上流から下流までの様々な話題の詰まった満足度の高い発表でした。特に印象に残ったものを書き出します。

「始めるのは危機感、続けるのは楽しさ」

普段は意識しないけど、言われると納得する一言。「炎上駆動改善」のように、普段動かない人を動かすには危機感を煽るのが有効。だけど、それではどこかでガス欠になってしまう。なので、楽しさを体感できる仕組みも必要。ゲーミフィケーションがフィットする？この一言は自分の成長サイクルを見直す一環にもなる。

テスト活動も「段階的」戦略で構造設計が必要

良い(と自分が信じている)ものでも、周りは正しく(=自分が期待する通りに)理解してくれない。他人に伝えるためにはどう伝えるかを考える必要があるし、伝える言葉によって、伝わり方が変わることもある。他人を変えることはできなくて、自分が変わる事しかできない。なので、他人を最適化するためには、自分がどう振る舞えば良いかは良く考える必要がある。

ゲストセッション 秋山さん

www.slideshare.net

テスト分析手法「HAYST法」考案者である秋山さんの講義。テスト要求分析で基本となる「分解」について、どのように考えればよいかを説明いただいた。十分に洗い出せているかを確認するための分解フレームワークの紹介や、どのように分解できていると良いのかの例示など。60分という時間ながら、濃厚かつ分かりやすい内容。テスト分析のチートシートとしてスライドを持ち歩きたい内容でした。

ワーク「走りきるテスト設計」

1チーム6人で、二日間を使ってテスト分析ーテスト設計ーテストケース実装を体験する大ボリュームのメインワーク。WACATE実行委員から「WACATEへの参加登録システムのテストケースを用意してほしい」という依頼に応える体のお題でした。お題の説明資料が来た時は、「こんな大ボリュームが二日間で終わるのか！(いや、無理だろう)」と思ったのですが、チームメンバーが上手く協力できてなんとか走りきることができました。

テスト分析

顧客要求や対象のシステムから何をテストしなければならないかを分析する。

  • テスト要求分析：システムの目的の洗い出し
    • 誰が何の目的でこのシステムを使うのか
  • テスト対象分析：画面項目や入力項目の洗い出し
    • 画面A、画面Bなどの画面の種類の洗い出し
    • 氏名、メールアドレスなど入力項目の洗い出し

雑な言い方をすると、テスト要求分析はトップダウン、テスト対象分析はボトムアップな洗い出しになりやすい。理想としては、ボトムアップとトップダウンが繋がるのだけれど、時間の都合で今回はそこまではいかなかった。

感想

仕様書に引っ張られた印象がある。テストエンジニアは仕様書に書かれていない所を含めて不具合を見つけることが求められるが、仕様書以外のテストすべきことについては十分な議論ができなかったことが反省点として挙げられる。

テスト設計

テスト分析で出てきた項目に対して、テスト設計技法を用いてテストケースを作る準備をする。何をテストするかをモデルを書いて整理することで、テストケースが十分であることを担保する。今回はテスト設計技法として、以下のモノを利用しました。

感想

技法ありきのモデリングとなった印象がある。テスト設計技法を使うことが網羅を担保することにはならないはず。何を保証したいのかを整理した上で、それぞれの保証したい内容をテスト設計技法で整理する方が望ましい。技法を使えることに満足してはいけない。

テストケース実装

テスト設計で作成したモデルに基づき、テストケースを生成する。テスト分析のワークショップではテストケース導出までやることはほとんどないので、テスト分析、テスト設計したものでテストケースを出してみるのは楽しかった。最後の報告で、モデルとテストケースを照らし合わせて「我々はこれでテストの網羅性を担保しています」とドヤ顔でいうのも楽しかった。

感想

チームではユースケーステストを担当した。ユースケーステストはまともに作成したことがなかったが、シナリオテストとして作成してみた。シナリオテストでは、シナリオを実行することで「シナリオ通りにシステムが動作するか」を確認するテストだと思っていた。しかし、シナリオを作成する過程で「このシナリオは現実に即しているか」をレビューして、実利用時の挙動から新しいテストすべきことを見つける役割もあるかと感じた。

まとめ

運営側の目線でワークショップの内容についても考えていました。本ワークショップオリジナルのテスト対象なのに、仕様書が良く作り込まれており、運営側の力の入り具合が感じられました。ワークショップとしてとても楽しい二日間でした。欲を言えばJaSST東北実行委員として、WACATE実行委員と運営やワークの内容について色々意見交換したいと感じました。*1

*1:だから、WACATE実行委員は7/2(土)のJaSST'16東北おかわり会に来ればいいと思う。 tohoku-dev.jp

2016/4/23(土) 「とちぎテストの会議04」に参加してきました。

那須野が原ハーモニーホールで行われた「とちぎテストの会議04」に参加してきました。
d.hatena.ne.jp

今回で2回目の参加になります。
前回参加した時の記事はこちら。
toshimana.hatenablog.com

今回の昼食はご当地大盛中華料理店「阿Q」で揚げ焼きそば、肉丼、餃子をいただきました。仙台テストクラスタのマスコット様と一緒に食べたんですが完食ならず…
余りは持ち帰りパック(お店で販売してる)に詰めて持ち帰りました。
f:id:toshimana:20160424093431j:plain


「つくるいとなむ」をテーマにしており、
テストの話だけではなく、教育、成長に関する話が多かったです。
とても刺激的な話を沢山聞くことができました。那須、楽しい。

招待講演

『会社をHackするために未来会議をやったら出版流通をHackすることなったでござるの巻』岩切さん

speakerdeck.com

凄まじかった。

『失敗ばかりの開発チームをいとなむ』椎葉さん(@bufferings)

b.hatena.ne.jp

良いものを作れたら嬉しい、と大体のメンバーが思っている。開発チームで良いものを作る方向に動いていない(と自分が思う)ことが多い。悪いのでは人ではなく「場」。人の動きを阻害する「場」を何とかする。何度も繰り返し伝えたり、自然と気づける仕組みを導入したりした。

感想

環境を変えると人も変わる。椎葉さんは恐らく「文化」を作ったんだと思う。
あと、自分の愛娘を預けたい、と思えるチームを作るというゴールがあることが素晴らしいと思った。自分のためにチームと一緒に成長したいという、理想的なモチベーションが保たれていると感じた。また、自分事だからこそ、現実から目を背けずにいられるのだと感じた。

一般講演

[経験と、ルールと、知識と] 松尾さん(@Kazu_cocoa)

www.slideshare.net

障害の再発防止として、「今は経験ベースだから、ルール(自動化、チェックリスト化)ベースを増やしていこう」というのを実践し、さらに踏み込んだ内容。ルール／知識ベースの障害対策を覚えた人より、経験ベースの人の方が障害が発生した時の事後対応を適切に行える。しかし、失敗への予防は経験だけよりも知識／ルールがある方が役に立つ。重要なのは学ぶこと(対象を理解しようとすること)。知識／ルールも深掘りすることにより「経験」を覗くことができる。それを自身に転化できたら面白い。

感想

ルール／知識を中心に理解した場合、そのルール／知識にしか焦点が向かなくなる「思考が縛られる」状態に陥ることがある。ルール／知識はとても有用だが、思考が狭まるものにならないよう、学び続けることが必要だと感じた。

[チームメンバーを"テスト"する] やっとむさん(@yattom)

www.slideshare.net
新しいチームメンバーには定期的に(毎週)試験を実施する。試験は点数を判断するものではなく、チームが何を大切に感じているかを伝えることに利用する。

[剪定テスト] よねざわさん(@vestige)

www.slideshare.net
剪定（せんてい）とは樹木の枝を切り、形を整えたり、風通しを良くする事。 見た目を美しくするのみでなく、養分を効率よく利用させて生長を促進したり、病害虫の繁殖を予防する効果がある。*1

[0からはじめたUIテスト・ABテスト～スマホアプリ開発の経験をもとに～] @ki_macho

大学生が作ったアプリでUIの改良にABテストをやってみた。大学生のアプリ作成はウェーイになりがちだから、しっかりした方法でやりたかった。

[テスターのドロア（わたしのあたまのなかのひきだし）～プログレスダイアログの巻～]みわさん(@miwa719)

speakerdeck.com

みわさんがプログレスダイアログをテストするときのテスト項目の紹介。「何を考え、何を心配しているのか」を伝える目的。
プログレスダイアログの「しばらくお待ちください」のメッセージがあるとき、時間が長すぎないか、短すぎないかがテスト項目にあるなど、仕様書には出てこないような内容もテストするところは流石だと感じた。

[割とみなさん挫折しているかと思いますが、実践アジャイルテストの第５部は意外とよく出来てると思います。正誤表もででます。] 川口さん(@kawaguti)

speakerdeck.com
タイトルの通り。途中で出てくる第5部の全体像の図は世界一わかりやすい(らしい。川口さん談)

[テストと情報エントロピー] 松山さん(@Dai_HungryWater)

www.slideshare.net
テストの良し悪しを情報エントロピーで表現できるのではないか、という話。情報エントロピーが大きいテストほど良いテストなのではないか。

[かえりみち] (@track8)

speakerdeck.com
雪月花に合わせて季節に沿ったバグを紹介。ログ出力の年月日が日本表記か英国表記かの違いと最新ファイルの指定方法が名前ソート(年月日が日本表記でしか機能しない)が組み合わさったバグ、熱によるクロックダウンによるシステムの速度低下、サマータイム問題など。だいたい、エンジニアは何もしていない。

「チョットデキル人に訊け！」

秋山さん(@akiyama924)、和田さん(@t_wada)、関さん(@m_seki)によるパネルディスカッション。和田さんだけお題を事前に聞いていないというサプライズがありました。秋山さん、関さんが事前に準備した回答であることを強調し続けるおまけ付き。


凄い人の話を聞いたときどうするか

秋：凄い話は理想に近い。理想と現実のギャップを理解すること。
和：成功した人がする成功した話は一番きれいな話。そこから成功のパターンを掴むことが大事。あと、前に出てきていない話(苦労話など)を聞く。

ちゃんとテストしているか

秋：リスクの高い項目(健康・財産・環境)は特にテストが必要
和：開発と品質保証のテストが異なる。開発は自身が近くした範囲でしかテストできない。開発者が自信を持てるテストと製品として十分な品質を担保するテストは異なる。品質保証のテストを行うには、自分が見ている枠の外に視野を広げる必要がある。他人の考えをテストに取り入れられているかが重要。

テスト上手くなりたいか？

関：テスト上手くなりたい、とは思わない。興味のあることをやっているだけ。

感想

「興味があることだけをやっている」という関さんにとって、テストを含む多くのモノはその興味を満たすために必要だからやっている、という感覚なのかと思った。ぶれないビジョンがあるからこそ、良いものを作るために淡々と前に進めるのだと感じた。

その他

フリートーク

ガチなスライドを用意して、2分発表しました。

www.slideshare.net

テストの地図

みわさんから「テストの地図」についてお話しいただきました。良い価値を届けるための開発に使えるテスト技法としては「テストの地図」はこれまで触れた中では最も理想に近いと感じた。
miwa719.hatenablog.com


感想

感想をまとめるの大変なくらい盛り沢山の内容でした。また来たいです。

*1:引用：wikipedia https://ja.wikipedia.org/wiki/%E5%89%AA%E5%AE%9A

2016/4/9(土)「JaSST東北2016準備会(仮)」：VSTePのやり方を変えてみたら失敗した話

仙台は今、VSTePが一番熱い街らしいです。

JaSST東北実行委員が集まって、一日かけてVSTeP勉強会を開催しました。仙台在住組は何度か集まってやっていましたが、今回は福島組や北海道からも人が集まって「かんばんりすと」を対象にしてVSTeP演習を実施しました。慣れていないメンバーがいたり、本会はテスト分析に慣れていない人がたくさん来ることもあって、より効率的にVSTePでテスト観点図作成ができないかの試みをしてみました。以下のようなことをやって大失敗したので、それらの話をまとめてみました。

  • テスト観点図作成時にあらかじめ大枠を用意してみた
  • テスト観点図作成時に因子水準表を作ってみた

今回のVSTePでのテスト分析手順は以下のように実施しています。

  1. 仕様書確認
  2. 仕様についての認識合わせ(フリートーク)
  3. テスト観点洗い出し
  4. テスト観点グルーピング
  5. テスト観点図作成
  6. テストコンテナ作成
  7. テストコンテナ依存関係整理

テスト観点図作成時にあらかじめ大枠を用意してみた

やろうと思った理由

テスト分析に慣れていない人がVSTePをやると、恐らくテスト観点洗い出しまでは何とかなるが、テスト観点図作成はとても苦労すると予想した。そのため、あらかじめ最終形が見える大枠を用意することで、慣れていない人でも大きな失敗なくテスト観点図が作成できるのではないか、と考えた。

やったこと

テスト観点グルーピングをしたあとに、テスト観点図のトップレベルにあらかじめ、「入力」「テスト対象」「出力」の大枠を置いてみた。大枠に基づいてテスト観点のグループごとにテスト観点図を作成してみた。

やってみた結果

大失敗した。全く納得のいく形にならなかった。
始めは上手くいく予想があったし、分かりやすいテスト観点は大枠の下にぶら下がる形になった。しかし、分類が難しいテスト観点が出てきたとたんに手が止まってしまった。さらに、しばらく考えてもどのように整理すればよいかのアイディアが出てこなかった。

面白かった事

「入力」「テスト対象」「出力」の大枠を外して、通常のVSTePの手順でやってみた。メンバーが慣れていることもあって、テスト観点図はスラスラと組み上がっていったのだけど、最終的に「入力」「テスト対象」「出力」の形になっていた。

分析

共通認識がない状態で、枠に当てはめようとすると、周りと意見が合わない、納得のいくモデルにならない。
決められた枠を用意すると、思考が「枠の中にどうすれば収まるか」に変わってしまう。

感想

テスト観点図作成フェーズで作るべきは、洗い出したテスト観点の「納得のいく構造関係」。フェーズ始めはチーム内の納得感がズレているので、それを合わせていくことが重要である。チーム内の納得感がずれている状態で枠を与えてしまうと、チーム内に取り戻しのつかないギャップが発生してしまうように感じた。チームの納得感に合わせて進めていくことが大事であり、大枠を用意してもチーム内の納得感を生み出す働きは起こらない。

テスト観点図作成時に因子水準表を作ってみた

やろうと思った理由

VSTePに慣れていない場合、テスト観点図のイメージが湧きにくい。テスト観点をMECEに洗い出したものが欲しいのであれば、別の手法で洗い出してテスト観点図のツリー構造に落とし込めば上手くいくのではないか。

やったこと

今回は因子水準表を作ってMECEのようにテスト観点を洗い出した。
f:id:toshimana:20160411081212j:plain

やってみた結果

因子を根、水準を葉としたツリーができた。しかし、次のテストコンテナ作成フェーズでは、テストコンテナを適切なまとまりで抽出することが難しかった。因子間の関係性についてチーム内の認識が合わせられていないため、テスト可能なまとまりの抽出に苦労した。

分析

「何をテストしたいのか」が見えないテスト観点図になっていた。因子水準表でまとめたが、MECEに洗い出した感覚はチームで共有できた。しかし、具体的なテストケースが出てこなかっため、テスト観点図が現実と乖離してしまったように感じた。

感想

VSTePを行う上で、現実との乖離が起きていないかはよく確認する必要がある。作ったモデルから、現実がイメージできないのであれば、モデルを見直すことを考える必要がある。

総括

VSTePに限った話ではないのだけれど、モデリングの肝は「納得できること」と「現実に即していること」だと感じた。2つを満たせていれば、例え実際に抜けがあったとしても、自信を持てると思う。自信を持てるからこそ、抜けがあったら真摯に捉えられる。技術は実力を効率良く表現するものであって、実力以上を出すものではない、と感じた。

反省点

「JaSST東北の本会も近いから、モデレータ育成をメインにやろう」という趣旨で始めたはずだけど、ガン無視でVSTePによるテスト分析に夢中になってしまった。

2016/2/21(日)「JaSST東北2016準備会(仮)」：テスト上流設計の嬉しいところ

テスト上流設計を体験したのだけど、人に教えるときには「テスト上流設計はイマドキ皆ヤッテマスヨ」では心には響きません。嬉しいことがあるからテスト上流設計をするのです。そのテスト上流設計の嬉しいところをまとめます。

テスト実行の戦略を立てられ、出戻りの発生を減らせる

テスト上流設計を行うことで、出てきたテストコンテナは不具合が起きた修正コストの見通しが立ちやすい。例えば、パフォーマンステストで失敗した場合、大規模な修正が必要になる場合がある。テストコンテナ間の依存関係を整理した上で、修正コストの大きいパフォーマンステストをできるだけ早く実行するテスト実行計画を立てることで、開発・テストの総工数を小さくすることができる。また、テスト計画が明確になれば、それに合わせて開発計画を最適化できる場合がある。テスト実施タイミングの設計はテストコンテナクラスのような抽象かされた項目が検討しやすい。

仕様変更時のテスト修正コストが低くなる

派生開発による機能追加が起こった場合、すべてのテストケースを洗い出すのにはとても多くの時間がかかる。しかし、テストコンテナのように抽象化されているモデルが存在すれば、テストケースの洗い出しを変更が必要なテストコンテナに限定できる。修正を毎回総当たりで行う必要がなくなり、テストケースの修正が容易になる。

ノウハウが溜まりやすい

テスト観点やテストコンテナでテストは抽象的なため、別案件へ応用しやすい。その別案件の検討で新しい観点が見つかれば、さらに別案件を成長させることに繋がる。例えば、未知のバグが出てきた場合に、そのバグから新しいテスト観点が生まれるかもしれない。それらのテスト観点はそのままテスト設計者のノウハウになる、と考えている。

感想

適切なテスト上流設計は製品の品質向上の道しるべとなる。テスト上流設計を学ぶと、テストと開発は自転車の両輪のような関係であると感じる。良いテスト設計は開発設計と繋がり、品質管理と品質開発が良い循環をすることで素晴らしい製品をつくることに繋がると感じた。