2017/12/16, 17の二日間で、若手エンジニア向けワークショップ:WACATE （ソフトウェアテストワークショップ）に参加してきました。

２日めのワークショップの各セッションでとったメモと、内容・感想をお伝えします。

コミュニケーションで大切なことは「伝わったこと」（越中谷郁美さん）

内容・感想

コミュニケーションについてのワークを行いました。

ふたりペアになって、お題となる絵を相手に見せないようにして、口頭だけで伝えるというワーク。これが想像通り難しい。□や◯などの図形を書いたりするのですが、紙の上での位置や大きさなど、なかなか伝わらない。

やってみて思ったのは、やはり説明の起点として「お互いが共通して知っているもの」を用意してそこからスタートすることが大事だということ。

そして「相手に伝えるにはどうしたらいいでしょうか」の問いかけにたいして、同じ班だったyoshitakeさんの「絵を見せちゃうのが一番はやいよね」が結構的確だなと勝手に納得。

機能テストで不具合が起こっている様子を説明するときなど、アレコレ文章に起こすよりもむしろスクショ１枚貼ったほうがはやいことってありますよね。コミュニケーションで相手に的確に伝えるためには、文章をどうするかに加えて、視覚情報に頼っちゃうというのも正解の１つだよなと。深い。

メモ

  • コミュニケーションでの困り事
    • たとえば
      • お願いしたものと違うものが出来上がってきた
      • 全く意見がかみ合わずに会話が平行線
      • 質問内容と全く違うことが返ってきた
  • 今回は、ワークを通じて聞き手の立場に立ってみる
    • 交互に、絵をみながら相手におなじものを書いてもらう
    • 思ったこと
      • 共通の尺度が要る
        • 紙の上の軸なり、身近にある物理的なモノだったり
        • お互い普段使っているツール
    • 伝えたいことが伝わる＝同じ絵がかける
      • 伝えたらおわりではなく、伝わったかどうかまでがコミュニケーションで大切なこと
    • yoshitakeさん
      • 絵を見せちゃうのが一番早い
        • →いとう：スクショ貼って報告するとか大事ですしね

みんなのメトリクス（中村仰志さん）

内容・感想

みんなだいすきメトリクスのセッション。

乱暴に一言でまとめてしまうと、目的が大事だよねという理解でした。

自分も経験があるのですごくわかるのですが、メトリクス取り始めると「あれも、これも」となって、Excelのシートに毎日退勤前にアレとコレとを入力して・・・とかやっちゃったりするんですよね。

で、入れるのサボったり忘れたりする人がいると「データの推移がわからないじゃないか！」と怒る、と。

でもそれって本当にしあわせですか？と言われるとそんなこと無いんですよね。

まず知りたいことがあって、それを知るために何のデータを集めればいいかを決めて、あとは集める。

このとき、人間はなるべく手間をかけたくない生き物なので、出来る限り自動で収集されるほうがいいですね。（ただし、工数は自動が難しい）

先日参加した[さらに増枠!] SRE-SET Automation Night – connpassでもトピックとして挙がっていた記憶があるのですが、理想的にはデータが自動で集まってレポーティングされて、人間は自分が知りたいときにそれを見に行く。もしくはしきい値を超えたときにメールなりSlackなりで通知が飛んでくる。このくらいの運用になると、チームとしていい形で進められるだろうなーと思いました。

そしてそういった仕事してみたい。

メモ

  • セッションの目的
    • データ収集のお悩みに対するヒントを見つけてもらう
  • 情報ニーズ
    • どうしてわざわざデータを集めるのか
    • 集めたデータは何に使われているのか
  • こんなことはないか
    • 使いみち分からないけどルールなので集める
    • なんとなく測れそうだから測る
    • 今は使わないけど将来使えるかもしれないから
  • 情報ニーズを考えよう
    • 誰が、いつ、何をしりたいのか
    • どの程度正確性が必要か
    • どの程度タイムリーであるべきか
    • 集めた情報はどのような方法で受け取りたいのか
  • GQM
    • Goal
      • まずゴールありき。何が知りたいのか。
    • Question
      • ゴールを達成するためには何が分かればいいのか。
    • Metrics
      • 質問に対する答えを手にいれるために必要なものを測る
  • 先程挙がったデータに対して
    • 誰がどのようなニーズを持っているか
    • 正確さ、タイミング、提供方法はニーズにあっているか
  • 測定対象の性格
    • 尺度の類型
      • 名義尺度
      • 順序尺度
      • 間隔尺度
      • 比尺度
    • 性格をしっておくことが大事
  • 分析できるようなまともなデータが集まらない
    • なぜ？→情報ニーズを持っている立場ではなく、測定する立場で考えてみる
    • たくさんの、意味不明な項目を取れと言われると
      • みんなルールだから一応入れるんだけれども
      • いい加減にやるのでまともなデータがあつまらない
      • 時間の無駄
  • 分析結果は測定した人に直接的な恩恵をもたらさない
    • 測定が現場仕事の邪魔になったら駄目
  • 人に測ってもらうのをやめる
  • 成果物から機械的に測定する
  • 測定する人にポジティブフィードバックを与える
    • 測定結果がタイムリーに自分たちの役に立つ、と思ってもらう
  • ノルマや評価だけでなく、見える化による安心感をあたえる
    • 工数とかも、見える化によって自分で入れるようになったりする

直交表に触れてみよう（並木正典さん）

内容・感想

みんなだいすき直交表。だけど実際の業務で使ったことがないという方も意外と居た様子。

私もたまーに、PICTMasterを使ってテストつくったりしていました。今回は手を動かしてみて、「当たり前だけど面倒だよね。もちろん自分で考えるのも大事だけど、ツールの力を借りてみてもいいよね！」ということでした。

初めて聞いたのが「直交表下敷き」というものがあるそうです。。

あと有則無則は不勉強だったので勉強しなおします。

内容には関係ないですが、並木さんのトークペースというか節がすきでした

メモ

  • 目的
    • 直交表を知り、実際に使ってみる
      • 知る
      • 触れる
      • もっと学ぶ
  • 組み合わせテストとは
    • 組み合わせを全網羅すると死ぬ
    • JSTQBで組み合わせテストが定義されている
  • なぜ組み合わせを考えるのか
    • 確認するポイントを抑えて、テストケース数を削減しましょう
    • 何を網羅するか
    • 安易にケース減らすと危険では
    • 減らし方を工夫して、大きな効果を得たい
  • 直交表を使うと
    • 1024通り→16通りに激減
  • メリット・デメリットがある
    • 目的を考えて、特徴を知り使おう
  • 直交表下敷き
  • 直交表をもっと学ぶには

インシデントレポート:Reboot（藤原洋平さん）

内容・感想

インシデントレポート、バグ票、不具合票・・・などなどいろんな呼び方があるアレについてのセッション。

JSTQBではインシデントレポートといいます。その割に、会場で普段みんながどう呼んでいるのかアンケートをとったところ、インシデントレポート派はゼロという結果に。

このインシデントレポート、いちおう検証の会社に勤めている身として、「どうやって書いたらより伝わるか」は普段から考えているポイントではありました。

どんな項目を書いたらいいだろうかというのをこのセッション中にも考えたりしたのですが、最終的には

開発者との往復がなるべく少なく、一発で伝わるような必要十分項目を目指す

なのかなというのが自分のかんがえです。

メモ

  • インシデントレポートとは
    • JSTQB参照
  • インシデントとは
    • ISTQB：発生した事象の中で、調査が必要なもの
    • 調査が必要ってどういうこと？
      • 期待していた結果と違う場合など。
    • 調査が必要なものはすべてインシデントとして扱われるので、コードだけでなくドキュメントなどにもインシデントは発生する
    • バグとインシデントは違う
  • インシデントレポートの呼び名がいろいろある
    • バグレポート
    • インシデントレポート
    • バグ票
    • 不具合報告書
    • 障害管理
    • などなどなど・・・
      • 会場アンケートとったら、[JSTQB]に書いてあるにもかかわらず、インシデントレポートと呼んでいる人はゼロ
  • インシデントレポートを伝える相手
    • 開発
    • テストリーダー
    • プロジェクトリーダー
  • まずはワークで体験
    • チーム内では、入力する具体値を書くか、それとも無関係と思われる項目については「その他は任意」で済ますかが分かれた
  • どんな項目があるといいか
  • 考えるのも大事だけど、先人の知恵（規格）を拝借するのもイイ
    • ISO/IEC/IEEE 29119-3
      • Scope
      • References
      • Glossary
      • Incident details
      • Timing information
      • Originator
      • Context
      • などなど・・・
    • IEEE829（ご参考）
  • 次のワーク：こんな項目が要るのではないか
  • 情報源としてのレポート
    • インシデントレポートは情報の宝の山
    • 適切な項目を書いてもらうことで、あらゆるものが可視化される
    • しかしやりすぎには注意
    • 項目が多いほど、入力に工数がかかる
      • 本当に必要なの？
      • 誰のために
      • 何のために
    • 面倒くさいと思われたら負け
  • まとめ
    • インシデントレポートは様々なひととコミュニケーションとる手段のひとつ
    • ふじわらさんの考える「良い」レポート
      • 他人に影響を与えられるレポート

インシデントレポートは書くこと自体が目的ではない。読む人に何か訴えたい、伝えたいことがあるから書くもので、さらに、読んだ人を動かす、何かアクションを起こしてもらうために書くものなんだ

設計品質とアーキテクチャ（小井土亨さん）

内容・感想

タイトルの通り、設計とアーキテクチャのおはなし。

仕様が与えられたときに、そのまま設計をするとそれぞれいろんな設計をして実現しようとする。バラツキがある。これを抑えるにはどうすればいいか。システムアーキテクチャだね。

といった内容を、ガイドとレシピというワードで説明していただきました。

感覚的にはわかりつつあるものの、たぶん他人に説明しようと思うとそこまでは理解できていない、というレベル。。実際、あまりシステム開発とかやったことのない、テストはじめて半年くらいの参加者は結構難しかったようです。

自分も上流から始めてシステム開発をやったことがないので、このへんの感覚は話聞くなり本読むなりで多少補っておきたいところです。

後半には『初めての自動テスト』でも書かれている、テストのピラミッドや自動化のおはなし。テストの自動化をしようと思ったときにUIに偏りすぎてアンバランス・非効率的になるのは避けるべきで、そのためには開発プロセスの上流からどこをどうやってテストしてどこをどう自動化するか考えるのが大事です。大事なのはわかりつつ、自分の身の回りにそｒをどうやって浸透させていくか、というところはまだまだアクションが必要そうです。

メモ

  • 設計とは
    • 要求、分析の結果を実現する方法を決める作業
    • 唯一の正解はなく、あるのは最適解
    • 設計は料理のレシピに似ている
      • レシピは何度も失敗を繰り返してブラッシュアップしていくが、設計の場合は、ふつう作るのは１回だけ。。
      • ガイドとレシピは違う
      • ガイドをレシピ的に作ってしまうと、特定の分量でしか作れないものになってしまう
    • 今回はレシピを作らない。ガイドを作る。
    • 普段ドキュメントを書く際などにも、どちらを書こうとしているのかを意識してやらないと、読み手にとってわかりづらいものになる
  • 設計には良し悪しがある
    • 答えが合っている場合、良し悪しの判定はどうやってやるの？
      • たとえば「部屋の掃除をして欲しい」という場合
        • 効率重視でルンバ使うか
        • 品質重視で掃除機使うか
        • →人によって解が異なる
    • 設計の良し悪しを判断するには
      • ルール
      • 指針
        • 複数のメンバーでルールを共有する
  • みんなが同じようなレシピになるには、どういったガイドを書けばいいのか
  • システムアーキテクチャ
    • 品質特性と対象
    • “設計にはブレが生じるよね、という前提で、それを防止するのがシステムアーキテクチャ”
    • システムとして統一された品質を達成するために、求められる[品質特性]と対象（ステークホルダー）を明確にする
  • ルール
    • 複数メンバー間で統一された品質を達成するために具体的な規則を用意
    • 品質特性を強制する仕組み作り
  • もう一つのゴール
    • アーキテクチャの目的理解
      • すべてのシステムは必ずアーキテクチャがある
      • アーキテクチャにより品質特性が決定する
    • アーキテクチャを理解する理由
      • 間違ったアーキテクチャ選ぶと大惨事
        • アーキテクチャを理解して、無駄な努力をしないように
    • 万能なアーキテクチャ＝役に立たない
      • 営業とかは「なんでもできます」的なことをいいがちだけど、トレードオフは必ずある
  • 作るときの品質特性と、使うときの品質特性は違ってくる
    • 分けて考えよう
  • テスト容易性に注目したらどうか
    • テスト容易性を、他の品質特性を達成するために利用する
    • テスト容易性を羅針盤にして設計を進める
  • システムと自動テスト
    • システムと自動テストは兄弟の関係（写像）
    • システムにあわせて自動テストを設計
    • システムに合った自動テストを行う
    • 開発プロセスごとに異なった自動テストを行う
      • プロセスの目的
      • プロセスの粒度
  • テストを自動化しようと思ったら、できるだけ早い段階からそのシステムの弱いところに対して手当できるように要求しなければいけない
    • ※『初めての自動テスト』と同じような内容と思った
    • テスト自動化を考えるときには、どのテストをどこのプロセスで自動化するのかを考える

まとめ

冬のwacateということで、様々な分野のことに広く触れた２日間でした。３年半ぶり２回めの参加となりましたが、非常に濃くて面白かったです。そして、色々な思考やアイディアのタネがたまりにたまった２日間でもありました。wacateはいいぞ。加速するぞ。

１日めの記事はこちら。