『怒らないからヤバいと思っていること全部言う会』はSaPIDでもっと有効的にできるかも

目次

この記事で伝えたいこと

  • 『怒らないからヤバいと思っていること全部言う会』の内容はSaPIDでも言っている気がする。

  • SaPIDの紹介

  • SaPIDを用いて実践する、問題発見のコツ

『怒らないからヤバいと思っていること全部言う会』とSaPIDの繋がり

先日、以下の記事を読みました。

www.yutorism.jp

この記事の

むしろ、リスクを洗い出す場においては、『こんなヤバいことがあるぞ』『いや、もっとヤバいかもしれない』『そこがヤバいならたぶんここも・・・』と考えうる限りのアイデアをブレスト的に進めていったほうが良いんじゃないのかなあと思う。

という内容、まさに後述するSaPIDのSTEP1そのものな気がしました。

あと、この記事のコメント

『怒らないからヤバいと思っていること全部言う会』の有用性について - ゆとりずむ

「最悪の場合どうなるか」を先に考えとくといい。意外と「部長が社長にめちゃくちゃ謝る」ぐらいのことだったりする。

2018/02/20 10:15
b.hatena.ne.jp

という内容は、SaPIDのSTEP2にあたると思いました。

また、最近話題の『カイゼンジャーニー』のP25には、問題解決をナビゲートするための手順として、以下のように書かれています。

<手順>

①問題発見フェーズ

 ①-1 問題点を自由気ままに出し、全部意見へ仮置きする

②事実発見フェーズ

 ②-1 意見をもとに不利益を記載する

 ②-2 これらの深掘りのもと事実を記載する

③対策フェーズ

 ③-1 事実の問題が再発しない対策案を考え、ベスト案をマークする

 ③-2 これらの対策を誰が・いつ行うのかを記載する

しかし、これはコラムの1つに書かれているに過ぎず、具体的にどのように行えば良いか、どのようなところに陥りやすいのかは記載していません。*1

SaPIDでは似たような方法を行いつつ、対策までどうやって持っていくのかを考えています。

SaPIDとは

SaPIDの公式ページに以下のように書かれています。

SaPIDとは、”Systems analysis/Systems approach based Software Process Improvement methoD”の略語で、当事者自らが解決すべき問題点を特定し、現実的に解決(改善)しながら段階的・継続的にゴールを目指す手法です。

SaPID(SaPID2.0)の全体像は、以下のようになっています。

f:id:nihonbuson:20180225222356j:plain

https://www.software-quasol.com/sapid2-0/ より

冒頭で書いた『怒らないからヤバいと思っていること全部言う会』は、この中のSTEP1「問題洗い出し・引き出し」と似たようなことをしているように見えます。

真の問題発見のコツ

SaPIDでは問題だと思う点をSTEP1でどんどん付箋に書いていきます。*2

ヤバいと思っていることを言っていくと、例えば以下のような意見が出てくるはずです。

f:id:nihonbuson:20180226121830j:plain

これは問題なのでしょうか?

この「コードレビューが不足している」は、「不足」という単語を使うことで、問題点っぽく見せています。

また、「コードレビューをもっとしていけば良くなるだろう」という、解決策が思い浮かんでいる状態での意見に見えます。

SaPIDでは、このような意見を「不足型」「解決型」と呼んでおり、この意見はSTEP2で直していくことになります。*3

この段階では、解決策ではなく、問題となっているものを見つける必要があります。

そのために有効な質問(声かけ)の一つは、

「コードレビューが不足したことで、どんなことが起こったの?問題ないなら、むしろ効率的にレビューできてるじゃん。」

です。

そして、こういうことを言っても、実際に問題が起きているから「コードレビューが不足している」と言っているはずです。

例えば、

「実は、出荷後に重大な不具合が発覚して、コードレビューで防げる内容だったんだよね」

とか

「実は、読みづらいコードが大量にコピペして作られていて、その元となったコードは、コードレビューしてなかったんだよね」

とかいう回答が得られたら、これらも正に問題点です。

f:id:nihonbuson:20180226122813j:plain f:id:nihonbuson:20180226122826j:plain

そして、「重大な不具合」とか「読みづらいコード」の詳細を聞いてみましょう。

詳細な内容が例えば静的チェックで引っ掛けられる話であれば、「コードレビューに工数をかけること」ではなく、「自動の静的チェックを充実させよう」が解決策になっていくかもしれません。*4

ある案件に対して無数のプログラムの書き方があるように、ある問題点に対しては、複数の解決策があるはずです。

「コードレビュー不足」などの解決型の問題の出し方では、解決策を1つしか見れていないことに繋がります。もっと効果的な解決策があるかもしれないのに…。

f:id:nihonbuson:20180225232217p:plain

あくまでも私達がこの時点で見つけたいのは解決策ではなく、問題点です。

また、同時に

「コードレビューが不足になった経緯を教えて?」

と質問するのも良いかもしれません。

「実は、なかなかコードレビューに時間を取れなかった」

と答えるかもしれない一方、

「実は、コードレビューの経験が無くて、どこを指摘すれば良いか分からなかった」

という答えが出てくるかもしれないです。

このように、「コードレビューが不足している」に陥ったきっかけを聞いてみるのも良いと思います。*5

質問した時に、「実は○○で…」という回答を貰ったら大成功!それが本当の問題である可能性が高いです。

問題は時系列のある別の問題と繋がって発生していることがあります。

これをSaPIDではSTEP3「問題分析・構造化」で繋げる作業をしています。

これも、改善策を考えていく中で重要な作業になります。

何よりも問題の全体図が把握しやすくなり、会議の参加者に納得感が生まれます。

実際にSaPIDを書いてみた例

先日、私はSaPID+ Bootcampに行ってきました。

www.software-quasol.com

上述は、この中で得た内容を元に書いています。

ちなみに私の成果物の写真はこれです。内容の詳細は見えないようにしています。

f:id:nihonbuson:20180225234921j:plain

この写真の付箋1枚1枚が、私が出した問題点です。*6

そして、写真を見てもらうと分かる通り、問題点が矢印で結ばれています。

これが、問題点が繋がっている部分です。

f:id:nihonbuson:20180225235802j:plain

私が作成した成果物は、特徴が2つあります。

1つ目は、問題点がループしている、つまり悪循環になっているように見えること(赤矢印部分)

2つ目は、当初はまったく別タスクで、繋がりなんて存在しないと思っていた2つの事象が、実は問題で繋がっていたこと(青点線部分より上と下で別のタスク)

このように、SaPIDを用いることで、問題点を整理することができます。

問題点を整理することで、「まず取り組める改善策はなんだろう?」と考えることができます。

SaPIDを学びたい場合

私がここまで書いた内容は、SaPIDの中のごく一部でしかありません。

なので、興味を持った方は「こうやって使えば良いんだ」と思わず、SaPIDを勉強してみるのをオススメします。

書籍から学ぶ

以下の本を読むのが良いと思います。

体験型イベントに参加して実際に一通りやってみる

1泊2日で行うSaPID+ Bootcampが年1回開催されています。

www.software-quasol.com

体験型イベントに参加して雰囲気を知る

直近では3月7日に開催されるJaSST'18 Tokyo(ソフトウェアテストシンポジウム)で、SaPIDを用いたチュートリアルがあります。

リンク: JaSSTソフトウェアテストシンポジウム-JaSST'18 Tokyo-セッション概要

事前参加申込は終了しましたが、当日券の販売があります。

ネットから情報を取得する

SaPIDの公式ページも沢山の情報が載っていてオススメです。

www.software-quasol.com

さいごに

今回は、『怒らないからヤバいと思っていること全部言う会』をきっかけに、SaPIDの紹介と、問題発見のコツについて書きました。

この記事を読むことで、皆さんがSaPIDに興味を持ったり、業務での問題発見に役立つならば幸いです。

参考文献

  • SaPID公式ページ
    • 特に、SaPID_Blogの「[STEP1:問題洗い出し・引き出し]で「~不足」が出てきた場合の[STEP2:事実確認・要素精査]での対処例」はとても参考にしました。

*1:これは『カイゼンジャーニー』での本筋ではないので、詳しく書かれてなくても仕方がないことです。

*2:チームで行う場合、付箋に書くことで、誰の発言かを意識せずに済む効果もあります。

*3:このような意見が出ること自体はOKですし、変に萎縮して意見を出さなくなる恐れもあるため、STEP1ではどんどん付箋に書くべきです。ブレストの類いと同じです。

*4:ただし、ここで解決策まで考える必要はありません!ここではあくまでも問題点を洗い出しているだけです。

*5:実際は「コードレビューの時間が取れない」とか、「コードレビューで指摘する場所が分からない」とかは、やはり「不足型」「解決型」なので、もう少しツッコミをしたいところです。

*6:ちなみに、付箋を貼っているものはゴミ袋ではなく、移動可能かつ拡張可能なホワイトボードです。

「Cybozu Meetup #11 アジャイルQA」 参加レポート #CybozuMeetup

アジャイルネイティブなQA by 三牧 麻美

自己紹介

  • 新卒2年目
  • kintoneとkintoneモバイルの品質保証責任者
  • Scrum開発のみ経験済

kintone

  • 顧客管理などのアプリをクラウド上で作成
  • 多拠点開発

kintoneモバイル

  • US向け
  • 既存のモバイルアプリとは仕様を一新
  • 新しいチームでの開発
  • スクラムイベントなどが何も決まってない状態から始めた
  • PG4, PM1,QA2

開発がはじまるまで

  • 必要なことの洗い出し
  • 不安に思っていることなど
  • スプリント開始までにやることを整理

品質について

  • 開発が始まる前にPMとQAで意識合わせ

スクラムイベント

READY/DONEの定義決め

  • QAが関わっているのは以下の2つ
    • バックログに必要な受入試験手順が記載されている
    • 開発チーム全員が飼養管理アプリに書かれた仕様で疑問がない

READY

  • PGが仕様書を作成
    • PM/QAレビュー
    • リファインメントで全員で共有・疑問をなくす
  • QAが受入試験を作成する
    • PGレビューへ

開発プロセス

  • 設計・試験のタイミングは統一しない
  • バックログに合わせて決める
  • スプリントをまたぐこともあり

試験プロセス

  • 試験バックログで監理
    • QA工数の見積もり
    • 試験するPBLを監理
      • 関係ある試験は一緒に試験
    • 試験仕様書・試験結果の監理

問題となった点

  • 今後の見通しが明確でなかった
    • いつ機能試験を実施するか最初に計画してもあまり意味がなかった
    • 大まかに計画することに
      • →チーム全体でのコミュニケーションが大事

今後の課題

  • 2週間毎のリリースが目標
    • 1スプリントで試験まで完了するには?
    • 回帰試験をどうするか?

質問

1スプリントで開発とテストが別々だが、開発が進みすぎて、テストが積まれる状況にならないか?

  • プランニング以上のものは基本的には実装しない
  • 余った時間はリファクタリングなどをしている

スクラムで開発している一方でロールを分割しているが、分割のメリットは何か?

  • 一緒にやった場合を経験したことが無いので想像できない
  • 分けることで、スクラムはスプリント内で終わらせないといけないという意識があるが、試験は試験として終わらせることを強制してないので、柔軟な対応をするには逆に分けているのは良いことかなと。
天野さんの補足
  • 歴史的な経緯で開発とQAが分かれている。
  • 元々サイボウズは開発とQAが別組織だった。
  • スクラムをやることで垣根を小さくしようとしている
  • 今後はもっと一体となってやっていようとしている
  • 現在は自動化をエンジニアがやっているが、QAでもやれるようにと考えている

スクラムイベントでQAが参加しているが、仕様のレビューは参加していると思うが、QAからのフィードバックの内容はどのようなものか?

  • 例えば、kintone本体の機能を元にした指摘などをしている。

「開発チーム」とQA by 小山 晃久

自己紹介

  • 新卒2年目
  • QAとしてガルーンのお問い合わせ対応をしていた
  • 2017年7月からスクラムチームに参加

Scrumとは何か?

ガルーン

チーム構成

開発プロセス

スクラム以前

スクラム以降

  • リリースは3ヶ月に1度
  • 1リリース=6,7スプリント
  • 1スプリント=3weeks
  • 各リリースの最終スプリントは原則新規開発しない
    • 回帰試験、改善系中心

QAがやっていること

  • スクラムイベントへの参加
  • 仕様書レビュー
  • (場合によっては)ユーザーに提供する仕様書作成

スプリントプランニング

  • タスクの分割をする
  • QAは試験という観点からタスクの分割方法を提案する

リファインメント

  • 現段階で決めておくべき仕様に漏れがないか調査
  • 過去の不具合情報を掘り出す
    • 新しい機能を追加するとき、類似機能の不具合共有とか

レトロスペクティブ(振り返り)

  • チーム内でふりかえり→KAIZENへ
    • 開発中のブランチで動作確認したい
      • 開発環境の作り方をレクチャーしてもらう
    • ○○の試験に時間がかかった
      • 次スプリントでは試験する単位を変えてみる

試験設計・試験仕様書作成

  • 実装と同時に開始
  • できるだけ早く動くものを触ってみる
    • 試験対象を学ぶ
  • 分からなかったらすぐに聞く
  • 仕様の漏れが見つかったらFB・提案
  • 実装者にテストケースについて相談
    • ただし鵜呑みにしない

良かったこと

  • スケジュール感が良くなった
    • 以前は試験期間にしわ寄せがあった
  • チーム内の連携が良くなった
    • 品質の関心も向上した
  • QAのスキルを活かせる
  • 不具合の出そうなものを伝える

課題

  • 試験設計の成果物はスクラム以前のまま
    • エクセルで管理
  • スクラムチーム間の情報共有
  • 明確な成果はこれから
    • 技術的負債との戦い

最後に

  • スクラムガイドにおける「開発チーム」
  • スクラムは開発チームのサブチームを認めていない
  • 全員が開発チームのメンバー

問いかけ

  • 開発チームのQAは存在しない?
  • 開発チームとQAはどのように付き合っていけば良いのか?

質問

QAがスクラムチームに入ってみて、開発チームからのFBは何かあったか?ウォーターフォールからスクラムで変わったことによっての話とか

  • ネガティブなものは無い。
  • Agile testingなどを勉強して、一体になって行うことの重要性に気付いた
開発メンバーからの補足
  • 1スプリントでテストまで終わらせる取り組みをしていて、QAとのやり取りを初めてやることに。
  • 初めての頃は試験仕様書が読めず、「もう少し分かりやすく」とFBした。

リリース判定はPOがすると思うが、QAは情報やメトリクスを示したりするのか?

  • リリース判定会議をしている。
  • 不具合の重要度を示したり、予定したテストが終わっているか、性能が改善しているかなどを伝えている

「まだまだ品質向上せい!」と言ったりしないのか

  • 一緒にやっているので、QAが上からモノを言う形にはならない。

振り返りってどうやって進めているのか?また、その際にQAの立場として面白かったことは?

  • 基本的にはスクラムチームの中で行っているが、KPTを使っている。
  • 振り返りに優先順位を付けて、誰が何をするかまでTODOにして落とし込んでいる
  • QA側からは初期の頃、QAとPGが知りきれていなかった頃、お互い知るために、開発環境について教えてもらったり、試験にかかったことに対しての改善策を考えたりした。
  • 振り返りの場ではQAとしてでなく、メンバーの一員として参加している
補足
  • 1スプリント3weekでやっていると、長いので、改善のタイミングが遅くなる。
  • プチレトロという中間の振り返りを3weekの中日にやったりする
  • 毎回KPTだと飽きるので、たまに変えたりする

QAにおけるスクラム導入 Before/After by 匠 史朗

自己紹介

  • 松山品質保証部部長
  • 39歳
  • 2008年中途入社
  • 今日は苦労話を中心に

チーム概要

  • 社内向けシステムを担当
  • 主なユーザーは社内の人

チームメンバー

  • PO(東京1名)
  • PG5名(うち、東京2名)
  • QA6名

スクラム概要

  • スプリントは2weeks
  • 他にPG/QA定例(修1回)やQA定例(週2回)を実施

Before / After

Before

  • 試験中やリリース後に見つかった問題は3ヶ月後〜6ヶ月後に対応だった
  • QAプロセスは全実装Fix後に実施
  • 機能説明会後に試験設計開始
  • 別々の製品をウォーターフォールでやっていたが、リリース日は同時にしていた(慣例)

After

  • リリースサイクルは1ヶ月。
  • 1スプリント2weeks
  • スプリント計画からQAも全員参加
  • 実装が完了したものからテスト設計を始めてる
  • 別々の製品は別々のリリース日に

問題点

今後の課題

  • 回帰試験の自動化
    • 自動化できれば前半から回帰試験ができる
  • PGによる試験設計レビュー
  • QAプロセス自体もアジャイル化したい

質問

品質保証部に所属しているようだが、サイボウズとして開発部とは別だと思うが、スクラムチームは部門を超えているということか?マトリクス組織ならば、縦と横がどちらが強い感じか?

  • 職能別の部門になっている
  • PMだけが集まっていたり、デザイナーのみの部署がある
  • 動き自体はプロダクトチームで動いている
  • マネージャはリソース調整や全体の成長を促すようにしている
  • ローテーションをさせたり

ウォーターフォールの場合のQAは非機能要件テストをやっていると思うが、スクラムになってから減ったのか?

  • ウォーターフォールの頃は通っていないとリリースNGになっていたが、スクラムになってからは少なくなったが、回数が増えているのでセキュリティテストは手厚くなっている
  • 性能検証は減っているかも
  • プロダクトチームとは別チームで性能試験やセキュリティ試験をやっている

ウォーターフォールのQAはブラックボックステストが中心的だったと思うが、今後の課題を見るとホワイトボックステストに寄っていきたいのか?

製品の試験期間とリリース日の間に空白の期間があるのは何か?

  • 運用試験やリハーサルなどがあるため。

ソフトウェアテスト・品質勉強会をもう一度行います! #test_study

今回、ソフトウェアテスト・品質勉強会を再演させていただけることになりました!

再演に至った経緯

実は、勉強会の発表についての解説記事で以下のように書きました。

耳を使うこと前提のスライドになっているため、この記事にいくら書いても、実際に受講しなければ伝わらないような内容になってしまっています…。

また、私自身「もっとこの勉強会を話して、色々な人に伝えたい!」という想いを持っていました。

今回、その想いを受け止めて下さり、場所を提供していただいたため、再演を行うことができました!

勉強会概要

  • 実施日:2018年2月27日

  • 告知ページ

connpass.com

募集は開始したばかりですが、既に多くの方から参加表明を頂いております!(ありがたや~)

気になるという方は是非、参加表明をしてください!

「ソフトウェアテスト・品質勉強会」のアンケートの回答

  • 先日の「ソフトウェアテスト・品質勉強会」で参加者にアンケートを書いていただきました。
  • ただし、それらのアンケートに答えられる場が無かったので、できるだけ回答して載せます。
  • 発表内容等はコチラ

nihonbuson.hatenadiary.jp

今回のような体験、ワークショップを社内のメンバーとやりたい、とずっと思っていました。例題集があったりするのでしょうか? 例題をつくるコツなどあれば、是非教えていただきたいです…!

  • 今回はほとんど、他の勉強会等から例題をパクりました。
  • ただ、私が例題を採用する時には、参加する人のレベルに合わせて、多少変更しています。
  • テストに興味が無い人に向けて行うには、社外勉強会で得たコンテンツをそのまま使わない方が良いことが多いです。
    • 特にJaSSTやWACATEなどで参加して知見を得ると、すぐに「社内に広めたい!」と思ってしまいますが、そこから社内向けに咀嚼するようにしています。*1
    • 例えば、社内に持っていくときには、極力テストの用語を使わないようにしています。難しい用語を持ってきた瞬間、拒否感を示す人もいると思いますので…。
  • ちなみに今回の場合は、そこまでテストが分からない人も対象にしていたので、コンテンツを社内に流用できる形になっていると思います。*2

テスト自動化をプロジェクトの中でどのように実現しているのか

  • 私の個人的な事例をここで紹介することはできません!(ごめんなさい!)
  • ただし、自動化をする時に参考になる資料としては以下の3つがあります。

1. いつどこをテスト自動化するべきか?

  • JaSST'16 Tokyoの講演資料です。
  • これからテスト自動化を始めようと思っている人には絶対に薦めたい資料です!

http://www.jasst.jp/symposium/jasst16tokyo/pdf/D4.pdf#page=5

2. テスト自動化の8原則

  • 今年の3月に行われた「システムテスト自動化カンファレンス2017」にて、このサイトが初めて紹介されました。
  • 実は最近、解説文も加わりました!

テスト自動化の8原則 - テスト自動化研究会

3. 初めての自動テスト

  • 発表中にも紹介した本です。
  • 自動テストを始めるにあたって最初に読むべき本といえます。

www.oreilly.co.jp

QAの育て方を知りたい

  • JaSST'17 Tohokuが「育成」をテーマにしていたので、色々と参考になるかと思います。

JaSSTソフトウェアテストシンポジウム-JaSST'17 Tohoku レポート

実際に1つの対象のテスト設計をしながら、なぜそうしているのかの解説をしていただきたい。

  • まさにそういう内容をしている、「テスト設計コンテスト」というものがあります。
  • 見学するだけでも勉強になると思いますよ。
  • 勝戦が2月24日にありますので、是非見学しに行ってみてください!

aster.or.jp

どの品質特性にあてはまるのか考えるのが難しく、うまくつかうのが難しいと思いました。

  • 品質特性については、先日のWACATEで小井土さんが話していただいたのが本当に参考になりましたので、そちらを確認してみてください。*3

www.slideshare.net

マトリクス、ディシジョンテーブルのテストの効率の良い実施方法などあれば知りたい。

  • ちょうど、自分自身も勉強している最中です。
  • 何かしら紹介できる形になれば、お伝えしたいです。

QAレビューの仕方を知りたい

  • 自分も勉強しているところです。
  • 1月16日にレビューを語る夕べがありますので、ぜひそこでお互いに情報共有しましょう!

kataruyube.connpass.com

テストエンジニアがいない組織の場合、開発者としてどこまでテストを行ったらよいか、気になりました。

  • おそらく、個々人のテストというよりも、組織としてどういう方針でテストをすれば良いか考えた方が良いように思います。
  • そういう話は、テスト戦略を語る夕べや、テスト網羅性を語る夕べでお話できると思いますので、そこで情報共有をしましょう!*4

kataruyube.connpass.com

JSTQBのFLは取ったのですが、ALへの壁が険しすぎます。そういう「脱初心者」の次ステップに参考になる話とかききたいです。

  • ちょっと自分もALを取っていないので、参考になる話ができる自信がありません…。(ゴメンナサイ!)
  • 将来、そういう人向けのお話もできるようになりたいです…!

ペアになって行うワークで、自社以外のテストについて聞いたり、コミュニケーションがとれてよかった。テストについて1人で勉強する気になれなかったが、今日の話をきっかけに勉強への意欲がかなりわいたので良かった。

  • 良かったです!
  • 発表中にもお伝えしましたが、テストについては1人で勉強するのが難しいと思います。社内や社外の仲間と一緒に勉強して、さらに良いテストができるようになりましょう!

テスト技法の話は巷でたくさん見聞きしますが、基礎的な部分を丁寧にしてくださる場があまりなかったので、色々、虫食いの知識を補完できたと思います。

  • 自分も最初は似たような状態で、ここ最近やっと全体感が分かってきた気がするので、それを伝えられて良かったです!

初めて外部の講座に参加したのですが、思っていた以上に楽しめました。

  • 前回の記事で書いたように、楽しんでもらうことを第一に考えた構成だったので、狙い通りの感想を頂けて嬉しいです!

本を読んで学習した内容も数多くありましたが、そこにプラスしていただけるような講義でした。

  • ありがとうございます!
  • (特に発表の前半は)本で読んだだけではなかなか理解しづらいところだったと思うので、参加して持ち帰って頂けたようで嬉しいです!

うちの会社の若手にもきいてほしい

  • ぜひぜひ!
  • 依頼があれば、出張でお話ししますよ!

*1:JaSSTやWACATEに参加している人というのはテスト好きばかりですから…。

*2:ただし、資料を読んだだけだと分かりづらいので、内容をちゃんと理解していないと社内に広めにくいかもしれません。

*3:きっとWACATEでの発表中のワークも踏まえて小井土さんの話を聞いていないと、品質特性の使いどころはわからない気がする。ただし、多分この質問者もWACATEに参加したので分かってもらえた気がする。

*4:勉強会告知ページが出来次第、追記して紹介します。

「ソフトウェアテスト・品質勉強会」での発表時に工夫したこと

先日、「ソフトウェアテスト・品質勉強会」で発表をしてきました。

connpass.com

connpass.com

発表資料

speakerdeckにupしました。

speakerdeck.com

発表時に重視したこと

今回は、「如何に勉強会を楽しんでもらうか」に重点を置きました。

そのため、色々な部分を工夫しました。

自分の頭で考えて、自分で手を動かす

ただ聞くだけの受け身になってしまうと、受講者の理解が進まないことが多いです。

そのため、今回は配布資料も用意し、所々穴埋めにしました。

speakerdeck.com

ちなみに、投影資料の一部で右下に数値を書いています。

f:id:nihonbuson:20171209175810p:plain

これは配布資料のページ数と紐付けています。

受講者に参加してもらう

例題を用意して考えてもらうだけでなく、受講者にも本当に参加してもらうようにしました。

そのために、2人組になってもらい、随所で意見交換をしてもらいました。*1

例えば、以下の例題(投影資料p16)

f:id:nihonbuson:20171209163052p:plain

これは3ステップで実施しました。*2

  1. 自分自身で考えてみる。考えた結果は配布資料のp13に書き込む。
  2. 隣の人と意見交換をする。(自分との意見の違いに気付く)
  3. 私が用意していた内容を伝える。(さらに自分との意見の違いに気付く)

これは、ただ単に説明を聞くだけの場合に比べて、圧倒的に理解度が異なります。

ちなみに、他人と意見交換すると新たな部分に気付けることがあります。

これを教育心理学の用語で「建設的相互作用」と言うようです。

先々月の「教育心理学Meetup」という勉強会でそのことを学んだので、早速活用させていただきました。

educational-psychology.connpass.com

納得感を上げる

より納得してもらえるように、できるだけ具体例を示したり、受講者の考えに寄り添った説明をしました。

例えば、以下の部分(投影資料p9)の具体例2

f:id:nihonbuson:20171209164133p:plain

もちろん、「デジタルニュースの普及」の一言で済ませても良いですが、 「オリンピックで日本人選手が金メダルという話題を次の日の朝刊まで待つことって無くなってきましたよね?」 と伝えたりしました。

また、以下の部分(投影資料p10)

f:id:nihonbuson:20171209164508p:plain

このページを示す前に、「テストの目的について隣の人に話してみて」という指示を出すのですが、その時に私は受講者の話に耳を傾けて意見を拾うようにしています。

そして、その中で出てくる

「きちんと動いているか確かめたいから」

というようなワードを拾ってきて、*3

○○を確かめたい→実装したものありきの話(受講者の考えに寄り添う)→実は「欠陥の作り込みの防止」という目的もある

というストーリーにすると、その後の話も絡めて、最終的に納得してもらえることが多いです。

目と耳を同時に使ってもらう

私は、スライドに詳細な説明を書きません。

また、基本的にスライドの説明をそのまま読むことをしません。

それは「スライドを読む」という目を使うことと、「私の説明を聞く」という耳を使うことの両方を実施してほしいからです。

ただスライドに書いてある内容を読むだけだと、受講者側の集中力も散漫になっていくと思っているのでこの方式を採っています。

一方で、耳を使うこと前提のスライドになっているため、この記事にいくら書いても、実際に受講しなければ伝わらないような内容になってしまっています…。

飽きさせないようにする&本当に伝えたいことを印象づける

聞いている人が飽きないように、また本当に伝えたいことを印象づけるために、言葉の強弱やスピードを調節しています。

例えば、以下の部分(投影資料p8)

f:id:nihonbuson:20171209165709p:plain

ここはあえて、「言葉の強弱をつけない(棒読み)」「速く読む」ようにしています。

そして、「なんだかよく分からないですよね?」と言っちゃいます。*4

一方で、次のページ(投影資料p9)

f:id:nihonbuson:20171209164133p:plain

ここでは、さきほどと真逆に「言葉を強弱をつける」「受講者の人が共感できるように語りかけるような早さで話す」ということを心がけてます。

こうすることで、私がより伝えたいのはp8よりもp9だということを把握してもらうようにしています。

twitter上で、今回の発表内容をマインドマップにしていただいた方がいましたが、私が伝えたかった内容を概ね書いて頂いており、きちんと伝わっていたんだなと感じました。

おわりに

この発表資料自体は随分前に作成しました。

ただ、上記で書いたようなこともあり、「ただ資料公開しただけだとあまり伝わらないな…」と思っていました。

そんな時に、アカツキ様から発表の機会をいただくことができました。

アカツキ様、発表の機会をいただき本当にありがとうございました!

もしも、今回の勉強会に参加していたり、この記事を見て、詳細な発表内容や発表方法について知りたい方がいましたら、連絡を頂ければと思います。

*1:「知らない人と2人組ということに抵抗感がある人がいるかもしれない…」と思っていましたが、アンケートを見たところ、そのような意見を書いた人はほとんどおらず、概ね好意的に受け止めてくれました。今回は参加者に恵まれました。

*2:なお、元々の発表でも同じようなやり方をとっており、私のやりかたは例題の文章を含めて完全なパクリです。

*3:だいたい「○○を確かめたい」「○○を保証したい」というワードは出てきます。

*4:本当は分からない訳ではありません。

テスト戦略を語る夕べ(第3回)の内容をまとめてみようとした #STS1031

告知ページ

connpass.com

目次

テストの在り方を変える軸

  • テスト戦略を考える上で、テストの在り方を変える軸というのが様々存在しているっぽい
  • それらを勉強会の中で話した結果、5個ぐらいはありそう。
    • 実際にはもっとありそう
  • 勉強会の中で軸までを考えたのは以下の5つ
    • 垂れ流し
    • 警察
    • 大富豪
    • コーチ
    • まつお(仮)
  • これら以外にも、「がんじがらめ」「執事」といったワードも出てきてた
  • 今回話した内容についてまとめてみます。

ケース1「垂れ流し」

  • 軸…コストとクオリティ
  • クオリティを維持してコストを減らすために、安いコストの人へ依頼する傾向にある。
  • これを行うと、一見目的が達成されているように見えるが、長期的に見るとコストがあまり変わらずクオリティが下がる結果となる。

f:id:nihonbuson:20171101214029p:plain

ケース2「警察」

  • 軸…規律(自律か他律か)とムダの許容度
  • ルールを作り、クオリティゲートによって監視するやり方。
  • 監視が強くなればなるほど、他律の組織になり、物事のムダが多くなる。
    • レビューでくだらない指摘をする必要とかも出てくる。
  • 監視が強い(他律&ムダが多い)状態をPMOはする傾向にある。
  • 逆方向(自律&ムダが少ない)状態になれば幸せなように見えるが、人月商売で成り立っているSI系がこの傾向に移るのは稀。

f:id:nihonbuson:20171101214804p:plain

ケース3「大富豪」

  • 軸…技術的先進性と定着度
  • 金にモノを言わせて解決するやり方。
  • そのまま放置すると技術的先進性は勝手になくなっていく。
    • 常にアップデートが必要。
  • 上手くいくと、技術的先進性を一定以上キープしつつ定着度が上がっていく。
  • ただし、ツールの導入に関わっていた人などがいなくなり、上手く伝承されないと、ツールが陳腐化し、定着度も高まらなくなる。
  • もしくは陳腐化したツールを意図も分からず使い続けて埋もれる。

f:id:nihonbuson:20171101234638p:plain

ケース4「コーチ」

  • 軸…学ぶ機会と納得感
  • 共に汗をかくタイプ。ちょっと離れてサポートする執事型はこれの亜流。
  • 学ぶ機会が増えることで、徐々に納得感が出てくるはず。
  • 学ぶ機会が増える方法の一つに、リリース間隔を狭める考えがある。

f:id:nihonbuson:20171101235154p:plain

ケース5「まつお(仮)」

  • 軸…信頼感(距離感の逆数)とサーバントシップ
  • 最初は縦割りで信頼感も無い状態
  • 信頼がお互いにできるようになると、さらにお互いを支え合うような仕事の仕方になる。
  • そこから組織が変わる(人が増えたりする)と、信頼感が減りC&Cになりがちだが、その時の経過からまたサーバントシップに向かえるようになるのが理想。

f:id:nihonbuson:20171102000026p:plain

感想

  • 今回は5つのケースを話しましたが、他にもまだまだありそうな予感です。
  • 自分の会社・組織ではどのケースに当てはまるのかorまた別のケースに当てはまるのか考えてみるのも面白いかも

勉強会中にホワイトボードに書いたメモ

明日はJaSST Kyushu

JaSSTソフトウェアテストシンポジウム-JaSST'17 Kyushu

  • そういえば、明日はJaSST Kyushuです。
  • 基調講演では、中野さんがQAの組織としての取り組み事例を話して頂けるようなので、今回の勉強会とも照らし合わせてみるのも良いかもしれません。*1

*1:気になった方へ。当日券もあるみたいですよ!

Veriserve - WebQA FunNight!! #01 #WQFN01

告知ページ

veriserve.connpass.com

はじめに

  • このイベントでは、テスト管理クラウドサービス QualityForward のアジャイル開発において、どんな取り組みを行ってきたか、「守」「破」「離」の3点に分けて紹介していました。
  • なお、最初の話と、最後の話は諸事情により記録できていません。*1ご了承ください。

目次

登壇者紹介

  • 開発:遠藤大介さん(ソニックガーデン)
  • テスト:大竹未紗さん(ベリサーブ)
  • PO:松木晋祐さん(ベリサーブ)

  • 以下の3点を行った。
    • 仕様を徹底的に議論する
    • 環境を最新に保つ
      • RailsのVersionをガンガン上げるとか
    • テストをちゃんと書く

仕様を徹底的に議論する

  • PO(松木さん)がまずやりたいことを持ってくる
    • ビジネス的に何を実現したいのかについて、松木さん流に話す
  • 中にはソフトウェア的に作るのが難しいことも
    • 開発者(遠藤さん)が「後々ガンになるよ」と伝えるようにしている
  • 要求に対して色んな実現方法がある
    • ソフトウェアにとって優しい、優しくない
    • ユーザーにとって優しい、優しくない
    • これらの調整がエンジニアの腕の見せどころ
  • 僕のオススメはこれ、と提案する
  • どちらかが折れるのではなく、対等に議論する
  • 週に2時間超のMTGをしているが、殆どがその議論

  • 松木

    • 変な仕様ってある?
  • 遠藤
    • いっぱいあるんですけど(笑)
    • テストスイートにタグを付けたいという議論とか。
      • 実際あった会話
        • 遠藤「何のために付けるの?」
        • 松木「目的のテストスイートを見つけるためにタグを付けたい」
        • 遠藤「タグの管理が破綻するよ」
      • タグのシステムは簡単なのですぐに作れるが、ユーザーは使いこなせないと思った。
  • 作るのもメンテも大変ではないやり方を選び続けて1年半経った

環境を最新に保つ

  • 技術は日進月歩
  • セキュリティ的に固くしようと考えると、フレームワークも最新にすることになる
  • 古いVersionだとセキュリティパッチも当てられない、使いたいライブラリが使えない
  • しょっちゅう、ライブラリを最新版に上げろと言ってる
  • 毎週リリースしているとリファクタするのを後回しにすると絶対にやらなくなる
    • →毎週リファクタをする
      • Redmine連携をした後に、JIRAなどにも対応できるようという要求があり、連携部分を抽象化した
  • ベリサーブ社内用のツールとして開発していたためシングルテナントで作っていたが、他の会社でも使いたいと言われた
    • →2週間でマルチテナント化した
  • 松木「ペースが落ちたことはない」

自動テストをちゃんと書く

  • カバレッジを100%を目指すのは辛い、C1を85〜90%でキープしてる
  • ライブラリのVersionを上げると挙動が変わるが、それを恐れてたらVerUpできない

    • 大事なのはすぐに気付けること
  • 今回開発したサービスだと権限毎のふるまいが違うので、その関係性を整理した上で自動テストを描いたりした。

  • 自分でできるところが守る、ただそれでも気付けないところはベリサーブさんに助けてもらってる

  • 松木「日付をまたぐテストの書き方についてなどは勉強になった。」

  • UIテストはどうやってる?

    • ブラウザで触った時の挙動については、Railsなのでcapybaraでやってる
  • ヘッドレスか実ブラウザでやるか?

    • 殆どがヘッドレス。たまに実ブラウザでテストする。
  • システムテストの成長系+αをプログラマに守ってもらってる

質問

Q 結構リッチなUIを使っていると思っているが、フロントエンド側は?
  • A フロントエンド側は書きづらい。例えば、スプレッドシートの自動化は流石にコストがかかるので、効率的な部分を優先にやっている。
Q リファクタリングの(時間的な)割合は?
  • A 空気を吸うようにやってる。ソニックガーデンの場合は、コードレビューを必ずやっているが、そこでも指摘があったりするので、リリース直前でもやってる
Q コーディングとテストコードの比率は?
  • A テストコードが1.5倍ぐらいある。テストコードの方が圧倒的に多い
Q マニュアルでテストすることはあるか?
  • A TDDに向いていないものもある。
    • 完成形が見えていないものとか。
    • そういうものは触りながらやる。
    • 逆に権限周りでガチガチに決まっている場合はテストコードを先に書く
Q テストコードとプロダクトコードは別リポジトリ
  • A 同じです。
Q CIってどこでで回ってる?master側?develop branch側?
  • A 手元では開発側で回してるし、masterでもstagingでも回してる
Q 環境を最新に保つとあったが、最新Versionの環境ではライブラリが使えないような場合はどうするのか?
  • A いくつかパターンが分かれる。
    • デグレって使えない
      • プルリクを投げて対応
    • 思想から外れるのでコードから外された。
      • 乗り換え先を検討する。(別ライブラリを探す)
Q 松木さんが「ペースが速い」と言っていたが、ペースの速い、遅いの判断はどうやって?
  • A 完全に松木さんの主観。
    • 今まで関わってきたプロジェクトと比較すると圧倒的に速い。
    • 速い場合、時間が経つと落ちてくるが、全然落ちない。
    • 最初からトップスピードで、その速度をキープしている感じ。
    • 逆にどんどん加速していくことも無い。
      • これ以上速くなるとPOが保たない
Q VerUpで不具合が見つかるタイミングは、自動テスト以外にあるか?
  • A ある。その時は、テストケースを足したりQAが観点として足したりする。
Q ドメイン知識が無い人がコードレビューをしていても回るか?
  • A いかに読みやすいコードを書くかを会社全体の流れとしている。
    • ビジネス的なものをコードレビューで見るのはそもそも難しい。
    • 「セキュリティ的に大丈夫かどうか」「読みやすいコードかどうか」を中心にレビューしている。
  • 権限周りのコードレビューだと松木さんに相談したり。
  • 松木「複雑な要求なのにコードが綺麗すぎるので、逆になんかあるのでは?と思ったりした。」

  • エンジニアが守っていた後に流す。テストエンジニアが破る。

バグランク

  • バグランクを予め決めている。
    • S セキュリティ、データ消失/破壊、システムの価値を致命的に損なう
    • A システムクラッシュ、復帰不能例外、システムの本質的な価値を毀損する
    • B 機能不具合、例外、ほか頻繁に利用されるケース
    • C 目立つ表示崩れ、軽微なユーザ期待との相違

テストサイズ

  • 変更内容によって、テストのサイズも決めている
Sテスト
  • 以下のような変更はSテストで対応
    • 軽微な変更
    • データの書き込みを伴わない変更
    • 表示される情報がユーザーにとってクリティカルでない変更
  • →製品知識が豊富なテスターのアドホックテストで対応
Mテスト
  • 以下のような変更はMテストで対応
    • 主要機能の追加や変更
    • データの書き込みを伴う機能
  • →テスト分析、設計、設計レビュー、実行、レポートのプロセスを通すようにして対応
Lテスト
  • 以下のような変更はLテストで対応
    • セキュリティ
    • データ毀損のリスクを伴う機能
    • ユーザーにとってクリティカルな情報を扱う機能の変更
  • →仕様、影響を網羅するためのモデルから作る

出来上がった最小の製品に対してリスクベースドでテストスイートを作る

  • 最初から1ヶ月ぐらい経ったときにまずは作った
  • 「ユーザーがどれ位ショックか」と「この機能はどれぐらい複雑か」の積でスコアを算出し、優先度を決めた

変更部分について影響範囲分析に基づくテスト設計と実行

  • 機能が加わったり、変更があったら、どれぐらい影響が表すかを図にしてまとめた
    • この機能を動かしたらどこに影響があるかについては矢印で表現した
      • 矢印の1本1本がテスト条件になっている
    • 例えば、ケースを作成した時に、「出力ができる」ものがあればエクスポートの機能に影響を与えるとか

Lテストの場合はPOと一緒に仕様のモデルを整理する

  • 「なぜこんな仕様になっているのか?」「どういう思想なのか?」を徹底的に共有
  • Lテストを実施する時は救援のQAも呼んで実施
  • ユーザー権限は非常にクリティカルなので、Lテストを実施した
    • 横の権限、縦の権限というモデルを一緒に作った
    • この仕様とモデルにおいては、画面、ユーザーメニュー、機能実行×権限の昇格&降格の組み合わせで網羅できることを発明した
  • 納得できる網羅を毎回発明している
  • このモデルを作ってテスト&修正を行った結果、その後、テストエンジニアのエースが1週間やってもバグを1件も見つけられなかった
Q Sテスト、Mテスト、Lテストの比率は?
  • A 5:3:2ぐらい

  • 製品に対しての問い合わせの対応は、QA側で行っている。
  • 開発側にはフィルタリングした情報のみ来る
  • 開発が集中にしてくれる環境になってる。
    • 遠藤「POからすると『作らないなー』と思ってそう。」
    • 松木「最初の3,4ヶ月は本当にそう感じた。今では慣れた」
      • 今回のサービス(テスト管理クラウドサービス)の提案を最初にソニックガーデンに伝えた時に「エクセルでいいじゃん」と言われた。
      • プログラマがガンガン言うことで内容が洗練されていく

おわりに

  • 最初にも書きましたが、これ以降は諸事情により記録が出来ていません。
  • ただし、ここに書いた内容以外にも様々な質問が飛び出して、大変面白い&タメになるイベントでした!

*1:最初は電車遅延で会場に間に合わなかったのと、最後はピザを食べながらだったのでPCを起動して記録していなかったためです