JaSST'21 Tokyoに参加して、テスト技法の必要性を考察してみた

テスト

こんにちは、カトです。
2021年3月15日～16日に開催されたJaSST'21 Tokyoに参加してきました。

私が参加したセッションはこちらです。

セッション番号 タイトル
A0) オープニングセッション ―
A1）基調講演 Being Agile about Architecture
B2）テクノロジーセッション JSTQB AL テスト自動化エンジニア
シラバスの概要＆見どころ！
F3）チュートリアル1 価値につながる要件・仕様からテストを考える
F5）チュートリアル2 JSTQB Advanced Level テストアナリストのシラバスでテストプロセスとテスト技法を学ぼう
F6）基調講演／招待講演者チュートリアル QA2AQ – Being Agile at Quality: Values, Practices, and Patterns
D8）一般公募セッション 仕様整理のためのテスト設計入門
A9）招待講演 パターンQA2AQによるアジャイル品質のマインド、体制、プロセス、技術


F5とD8で、テスト技法に関するセッションを聴講し、テスト技法の必要性を再認識しました。
そこで、「テストケースとセットで、テスト技法を残した場合とテスト技法を残さなかった場合に、どんな差が生まれるのか」をテーマにして、社内でQAエンジニア向けに共有会を実施しました。

共有内容

ワークショップで使われたカレンダーの仕様がわかりやすかったので、「カレンダーの色分け」を例に考えていきます。 f:id:yayoikato:20210329122538p:plain
カレンダーの日付を確認して、表示色が仕様通りかを確認するテストケースを作成していきます。

テストケースを作成する

今回は、テスト技法としてデシジョンテーブルを使います。

テスト技法とテストケースをセットで残した場合

f:id:yayoikato:20210329122643p:plain
これを見た人の反応はどうなるでしょうか？
きっと、テストケースを確認しやすいと感じるはずです。

テスト技法とテストケースをセットで残さなかった場合

f:id:yayoikato:20210329122707p:plain
これを見た人の反応はどうなるでしょうか？
f:id:yayoikato:20210329122732p:plain
「そんなおかしなことをするなんて、ありえない」と思いますか？
この例では、テスト対象が慣れ親しんだカレンダーで仕様も複雑ではないので、そのように思うかもしれません。
しかし、実際に業務で扱う仕様は複雑で入り組んでいるので、予定外なテストケースを追加してしまう可能性もあるのです。

翌年のケースにメンテナンスする

無事に2021年対応のテストが完了したら、2022年対応に向けてメンテナンスをしていきます。

テスト技法とテストケースをセットで残した場合

デシジョンテーブルに変更はありません。
デシジョンテーブルをみながら、テストケースを修正していきます。
f:id:yayoikato:20210329122821p:plain
はい。スムーズです。

テスト技法とテストケースをセットで残さなかった場合

f:id:yayoikato:20210329122847p:plain
混沌としてきました。

仕様追加が発生する

カレンダーの仕様としては違和感があるかもしれませんが、色分けを追加することにします。
製品・サービスの開発現場では、新規開発だけではなく、追加開発することが多いので、例題として対応してみます。
f:id:yayoikato:20210329122904p:plain

テスト技法とテストケースをセットで残した場合

水曜日の確認のため、デシジョンテーブルを更新します。
デシジョンテーブルに合わせて、テストケースも更新します。
f:id:yayoikato:20210329122923p:plain
迷うことなく、追加に対応できました。

テスト技法とテストケースをセットで残さなかった場合

f:id:yayoikato:20210326110255p:plain
翌年に変更した時点で、何をテストしたいのかわからなくなってしまっています。
何をテストしたいのかわからない状態のテストケースに対して、仕様追加に合わせたテストケースを追加することが難しくなってしまいました。

結論：テスト技法とテストケースはセットで残す

レビューイにとってのメリット：
テスト技法を成果物として残すことで、レビューイである初回の作成者の思考整理だけではなく、メンテナンス実施者にとっても迷いがなくなります。

レビューアにとってのメリット：
レビューアは、テストケース1つずつを見なくてもテスト技法を見ることでテストケースの過不足を確認できるようになります。

テスト技法を共有し受け継ぐことは、レビューイにもレビューアにも効果があります。

JaSSTに参加し、さらにJaSSTの学びを社内のQAエンジニアと共有することで、テスト技法の必要性を再認識する機会になりました。
場面にあったテスト技法を使うことは、テスト工程だけではなく、仕様検討や設計の際にも有効になる手段です。

私は、QAエンジニアが製品開発のすべての工程でテスト技法を使いながら関わっていけるチームをつくっていきます。

障害ふりかえりに向き合ってみた話

この記事は、弥生 Advent Calendar 2020　24日目のエントリーになります。

障害のふりかえりについて、私が感じていた課題と取り組んだことを書きます。

はじめに

私はいくつかのサービスについて品質保証の仕事をしています。ちょっと前までプロジェクトマネージャーを担当していました。どのような立ち位置でも、品質やテストに関して計画をし、実行をリードし、評価するということをやってきました。うまくいかないこともあるし、うまくいったこともあります。 その中で、個人的にうまくできないなとおもっていた、障害のふりかえりについて感じていた課題と取り組んだことを書きます。

なぜこれを書くか

障害が発生する、もしくはミスが起きるとふりかえりをして、次に同じことが起きないように対策を立てる、教訓にするという活動を行っているチームは多いと思います。私も、次に生かすためにふりかえりを行うことは大事、と思っています。障害が起きればふりかえりを行い、次に向けた対策を考え、次のプロジェクトでは同じことが起きないように対策を実行するということを行ってきました。

その一方で、私自身はふりかえりという活動がうまくできないなと思っていました。大きく分けると以下の2点に課題を感じていました。

  • 事実の抑えや原因をすっとばして、再発防止策を先に考えてしまう
    • 対策が先にあって都合がいい原因を選んでいるイメージ
    • 事実という土台がしっかりしてないからそこから導き出される再発防止策もふわふわしている
  • わかりやすい原因、対策を思いついたらそれ以外の発想が出ない
    • 誰かに説明をすることが決まっていると、わかりやすいに加えて、説明しやすいも加わる
    • ストーリーとしてこれだ！ってのがあると、それ以外目に入らなくなる、思いつかなくなる

　客観的に考えればできるはずでしょ、という話はありますが、私にとって、思い込み、思惑、心理的抵抗を排除して考えるということはそんなに簡単なことではありません。ましてや当事者の立場であれば、もっと難しいと思います。ということで、私がやってみたことをこれから書きます。

読んでもらいたい人

  • 障害のふりかえりをやってはいるものの、うまくいってないなと思っている人
  • 障害のふりかえりについて深く考えたことがない人

課題を整理

　はじめに、にも記載しましたが、ここで私の感じている課題を整理します。

  • 事実の抑えや原因をすっとばして、再発防止策を先に考えてしまう
    • 順を追って考えられていない
    • 次に向けた教訓を得ることを目的とするあまり、結論を急ぐ
    • 事実⇒原因⇒再発防止策の順で積み上げるべき
  • 事実の把握をおろそかにしている
    • 担当者、レビューをした人の話を聞いて、原因を考えていた
    • 現物を見れてない、記憶ベースの時もあった
  • わかりやすい原因、対策を思いついたらそれ以外の発想が出ない
    • 障害の原因となる欠陥を作りこんだ原因は１つではなく、複数の要素が絡まっていることがほとんど
    • 本来は原因が複数出てくるべきだが、ほかの原因はないか？という問いに対する答えが出てこない

やったこと

やったことは大きく分けて2つです。

  • 障害ふりかえりで考える項目を挙げた。挙げた項目について考える順番も決めた。
    • 経緯を現物で抑える
      • 混入した経緯
      • 検出できなかった経緯
      • チケットや成果物の格納場所のリンクを載せる
    • あるべき姿
    • 今のやり方の課題は？
    • 今度こう変える
  • 上記で挙げた項目をマインドマップの1つ目のノードにした。考えた内容は各ノードにぶら下げて書けるようにした。

f:id:yharuta:20201218110655p:plain
障害ふりかえりのマインドマップ

工夫したポイント

ここでのポイントは以下の3つです。

  • 考えるべき項目を挙げて、順を追って考えるようにした
    • 再発防止を先に考えない
  • 経緯を現物で抑える
    • 関わった人の話を聞く場合でも、現物をみながら経緯を追うようにする
  • 違う切り口の意見を考えやすいように、Excelなどのフォーマットではなく、マインドマップにした
    • マインドマップはExcelなどと比べて、意見をたくさん出す、というときに使いやすいと感じていたため

どうだったか

良かった点、改善が必要な点がそれぞれあります。

良かった点

  • 経緯を現物ベースでやると混入した経緯、検出できなかった経緯が腹落ちする
    • 複数人で行うときには皆が同じ経緯を認識して始めることができたので効果的だった
  • 原因や対策は決めうちにならず、いくつか意見が出た
    • 個人で考えるときにも、複数人で行うときにも、意見が出やすくなったと感じました。マインドマップの良いところが出た

改善が必要な点

  • 事実はおさえられたが、今度こうしよう！を先に考えてしまうのは変わらず
    • あるべき姿、こうすればよかったを軽く考えて、結論をいそいでしまう傾向は変わらずあった
      • 手法だけでカバーではなく、他の工夫も必要。たとえば、複数人で行うときはファシリテーションをうまく行う、一人でやるときは推敲の時間をとるといったこと

最後に

　ここまでで、障害ふりかえりについての取り組みの話は終わりになります。

　最後にもう1つ、取り組みのご紹介をします。障害の再発防止という意味では、ふりかえりして教訓を得るということも大事だけど、その教訓を忘れずに引き継いでいくという取り組みも大事であると考えます。ふりかえりした、というだけでは、次のプロジェクトの対して貢献することができないためです。 これに対する取り組みを最後に紹介します。プロジェクト開始のキックオフで、過去の障害の話をして同じことが起きないようにしようというのを伝えるという取り組みです。弥生の他のチームでは同じ取り組みをしていまして、先日行った自分のチームのキックオフでも取り入れてみました。 このように、障害が起きたらきちんとふりかえりをする、さらに、そこから得られた教訓を折に触れて思い出すこともセットでやっていくとチームに教訓が浸透していくのではないか、と思っています。まだまだ改善できる余地はあるので、今後も取り組んでいきます。

　ということで、障害ふりかえり、というややニッチなテーマではありますが、私が取り組んだことをご紹介しました。誰かの参考になればうれしいです。ここまで読んでいただきましてありがとうございました。

マネージャー視点でリモートワークを語ろう

1on1

弥生株式会社で製品サービスのチーフテクニカルリーダーをしているクロキです。
弥生アドベントカレンダー 2020の22日目の記事を書きますよ。

f:id:ym_AdventC:20201221131749j:plain
クロキのリモートワーク作業環境

はじめに

コロナ禍の影響で、弥生でも2020年4月からリモートワークが始まりました。
すでに中途入社してすぐリモートワークになった記事や、新卒1年目なのにフルリモートで研修になった記事が投稿されていますが、今回はマネージャー視点でリモートワークを語る話となります。

リモートワークの困りごと

リモートワークとは、働く場所がオフィスではなく自宅になるだけです。
とは言っても、実際やってみるとオフィスとは違う困りごとが出てきます。

  • とりあえず腰が痛い。会社の椅子って実はよかったのかも…
  • 通勤がなくなった分、メリハリもなくなってしまった
  • 誰ともしゃべってなくて寂しい
  • 毎日、代り映えしなくて、今日が何曜日か分からない
  • ちょっと相談したいけど、状況がよくわからないから声をかけづらい

世間的にもリモートワークの課題は話題になっているようです。
そこで弥生では、以下の3つのテーマに対して施策をやることにしました。

  1. 生活の乱れ
  2. 孤独
  3. 何が起こっているのか、どうすればいいのか分からない不安

詳細は以下に書きますが、平たく言うと「メンバーの心と身体をケア」が目的です。

①朝会、夕会

朝会では毎日の作業予定、課題を。
夕会では毎日の作業実績、課題を。
それぞれZoomでプロジェクトのチームメンバーに共有します。

②チーム会

月水金の午後イチにチームメンバーがZoomに集まり、会社からの連絡事項や他のプロジェクトで起こっているトラブルなどを共有します。

③個別面談

週に1回、上司と15分以上話す時間を設けます。
チームメンバーが話したいことをなんでも話す場となります。

④カウンセリング

必要に応じてカウンセリングの場を設けます。
弥生にはカウンセラーの資格を持ったマネージャーがいます。また契約している産業医との面談も可能です。

うちのチームの結果

チームメンバーからは個別面談を通じて施策のフィードバックを受ましたが、「リモートワークのほうがむしろ快適で、全員一律に心配してくれなくても問題ないですよ」「リモートワークのほうが作業に集中できて、効率が上がりました」という意見が多く寄せられました。こういうメンバーはリモートワークだから何か特別な対応をしなくても問題なかったわけです。
ただ、お子さんがいるメンバーは事情が違いました。仕事中にお子さんが乱入してきて集中できなくて困っている話や、自宅での作業場所を確保するのが難しい話などの、様々な相談を受けました。必要に応じて、私の上司にエスカレーションするなどの対応をとりましたが、緊急事態宣言中は先が見えない状況が続くため、ハッキリと回答を出せないところが辛い状況でした。

また、自宅に引きこもることによる運動不足の話や、椅子や机などの作業環境を整える話、作業中の座る姿勢の話など、身体のケアについて話すことが多かったですね。
自宅のモニターやキーボードについて雑談することもありました。21日目の記事はこうして生まれた次第。

施策の効果はメンバーによって様々でしたが、誰もメンタルダウンすることなく乗り切れたことはホッとしました。
肝心の仕事の成果ですが、リモートワーク開始当初は低下したものの、環境が整うにつれて徐々に解消されていきました。そして、今年も無事に弥生21シリーズをリリースできました！

もっとも、コロナ禍の状況は依然として続いており、東京都の新規陽性者数も増加傾向にあります。
弥生でも引き続きリモートワークも継続して、心身の安全を図りながら製品サービスの開発を継続していきます。

クロキ自身の結果

リモートワークで長時間自宅にいるようになったため、同居する妻から「心身が休まらなくなった」と苦情を受けております。
そんな理不尽なｗ