ABD「ソフトウェアテスト技法ドリル」に参加してきました

TECiY主催の
ABDで「ソフトウェアテスト技法ドリル」に参加してきました。

TECiYとは

TestEnginner Camp in Yokohamaの略で、
『都内にテストの勉強会は多いけど、横浜には少ない!
 →ないなら作ろう!』ということで、発足した勉強会だそうです。
確かに横浜にはテスト系の勉強会はないので、ありがたいですね!

ABDとは

Active Book Dialogの頭文字をとったものです。
詳しい説明は、公式サイトを見てみてください。
おおざっぱに言うと、
次のような手順で1冊の本をみんなで分割して共有することで
短時間で1冊の本の内容をみんなで理解しよう、ということらしいです。

  • 本を分割する
  • それぞれ担当者を決めて読んでまとめる
  • 各担当者が読んだ内容をプレゼンする
  • 分からなかったところ、深く聞きたいところをお互いに質問する

ソフトウェアテスト技法ドリルをABDで読む

ABDについて手順の説明を受けた後で、参加者が自己紹介を行いました。
自己紹介で、ソフトウェアテストの経験年数も言っていき、
年数の少ない人から、担当する章を選んでいく形式でした。
章によって難易度にばらつきがあるので、この形式はやりやすくて素敵だと感じました。

担当の章を決めてから、実際の読書スタート。
今回のお題の本はこちら。

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

今回は読書とまとめる時間は60分でした。
まず最初の30分で読む、残りの30分でまとめる、を目安にやってみました。
集中して読んで、その後迫りくる時間と戦いながら内容をまとめます。

参加者がまとめた結果がこちら。
f:id:yuki_shiro:20180805233754j:plain

まとめきれなかった内容については、
プレゼン時に口頭で補完してもOKでした。
一応読んだばかりの内容なので、各自だいたいの内容は覚えてます。
ほとんどの人が内容を書ききれてなかったので、
章の最後の部分は、口頭で補足する形になりました。

実際にやってみた感想を箇条書きで。
<読み手として>

  • 後で人にわかるような説明が求められるので、集中して読める
  • 自分の理解も進む
  • 3分でプレゼンするので、どこを拾うかの判断が難しい!
  • 30分あっても、他の人にわかるようにまとめるのは難しい! 時間足りない!

<聞き手として>

  • 自分の担当した章の補完になるので、聞きやすい
  • 同じ章を読んでいても、まとめ方が違って面白い
  • 相互質問があるので深められる
  • 参加者がテスト経験者なので、技法の背景などを相互に補完できてよかった

<全体として>

  • みんなで協力して、一冊の本を倒す感じが面白い!
  • 重たい本も協力すれば一日で片付けられそう
  • 言葉の定義とかの共通認識をつくるのにも良さそう
  • アジャイル界隈でこの手法を初めて聞いたのは↑の効果を狙ってたのかな?

最後に

懇親会まで含め、みんなで理解を深めあえて、とても面白い会でした!ありがとうございます!
TECiYの次の勉強会も楽しみにしています!

『感情の問題地図』から、ひとまずTryしてみること

最近イライラしてることが増えたなぁ、感情をうまく処理できてないなぁと思ったので読んでみました。

感情の問題地図 ~「で、どう整える?」ストレスだらけ、モヤモヤばかりの仕事の心理

感情の問題地図 ~「で、どう整える?」ストレスだらけ、モヤモヤばかりの仕事の心理

さらりと読めますが、「怒り」「悲しみ」「落ち込み」「不安」の4つの ネガティブな感情を否定せず、うまく味方につける方法が書かれています。

直近自分にとって対処が必要そうな「怒り」について、ちょっと整理してみました。

怒り

  • 自分はどのような時に怒りを感じるのか=自分は何を大事にしているのかの指標
  • 怒りを感じることと、それをどう表現するかは分けて考える
  • 怒りが攻撃として表れると関係性を壊す
  • 対処法の一つとして関係性を壊すのではなく、作る方向に表現するDSEC法がある
    • Describe 客観的に描写する。事実を述べる
    • Explain 「私は〜」で自分の考えを説明する
    • Suggest 「こうしてもらえると助かる」を提示する
    • Choose 選択を示す、相手に選んでもらう
  • 対処法としては、自分が落ち着く言葉を用意しておき、怒りを感じたときにそれを思い出すリマインダー法もある

DESC法とリマインダー法は、すぐに試せそうなので自分のTry項目として、取り入れてみようと思います。
私のリマインダーには、中国古典『荘子』に出てくるフレーズで、気にいっているものを試験的に採用。
「至人之用心若鏡、不将不迎応而不蔵(至人の心を用いるは鏡のごとし、将(おく)らず迎えず応じて蔵(おさ)めず)」
『外面は相手によって自由に変化するが、内面はしっかりと自分の主体性を守っている』ということだそうです。和訳部分は『実践・老荘思想入門(守屋洋)』より引用しました。

体現するには至ってませんが、一つの在り方として惹かれるものがあるので、なんとなく気に入っているフレーズです。

まずは「怒り」を味方につけられるようDSEC法とリマインダー法を実験してみます。

第11回Ques「IoT時代の品質」参加レポート

第11回Ques「IoT時代の品質」に行ってきましたのでレポートします!TECH PLAYさん初めて行きましたが、オシャレできれいですね。
f:id:yuki_shiro:20180518214128j:plain

AkerunサービスのQA現場

株式会社 フォトシンス 石井大樹さん

役割
会社の紹介
  • akerun入退室管理システムの開発提供
  • スタートアップ
QAの担当

以下すべて内製

IoTサービスの難しさ
  • QAの規模=組合せの掛け算
  • QA用の端末も製造が必要
    • Internet スマフォ、パソコンは作らない
    • Thing 目の前にあるものを検証 → サーバサイドを検証するにも機器が必要
  • Webからの転向の注意点
    • QA用の端末も製造しなくてはならない ハードウェアの作成に時間とお金がかかる
    • →計画が重要!
    • QAに必要な数量は? → 壊す前提で計画する
    • 製造の予算は? → 壊す前提で計画する
    • 製造スケジュールの調整は?
IoTの現場
  • 環境試験
    • 高温、低温、ヒートショック、湿度
      • カタログスペックの検証
      • 本当はどこまで行けるのか(壊れるまでやる)
    • 静電気
  • 耐久性、連続稼働
    • キーワード「自動化」
    • 鍵を開けたり締めたりを100万回以上繰り返す
    • ボタンのプッシュを延々繰り返す ※初期はエンジニアが押しまくってた(手動)
    • ハードの自作っぷりがすごい
ハードの試験も自動化するメリット
  • 生産性上がる!わくわくする
  • →最近は手軽に作れる環境が充実
    • shell/python/golang
    • RasPy
    • 素人でも、ちょっと勉強すれば、手伝ってもらえば作れる!
    • 無料、またはお小遣い程度
チーム作り

Before

  • スーパーエンジニアでも抜け漏れは発生
  • 能力差が出る、非効率

After

  • 開発者と評価の分離
  • 品質基準の策定
  • ステークホルダーの再構築
    • →会社全体でQA、会社全体でドッグフーディング
    • 偉い人からみんなでやろうよと言ってもらう
    • オフィスに設置して実際に入退室管理
    • チーム分けして日替わりで体験
    • →サービスの仕様がみんなに浸透
    • 改善のフィードバックが速い
  • カスタマーサポートにテストしてもらう
    • リリース前に細かい仕様を把握
    • はまりどころのキャッチアップ
    • 「触るの楽しい!」を体験してもらうことで、ポジティブになる
    • ※カスタマーサポートは、普段クレーム処理なのでネガティブになりやすい
  • 社員全員akerunを持ち帰り
    • 設置のしやすさを体験
    • 合鍵発行などのフローも体験
    • 社員に愛着を持ってもらえる
  • 顧客先で張り付き検証
    • ユーザの使用環境・生の声が分かる
    • 先入観がなくなる(こう使われるだろう、と思ったら実際には違う)

組織全体でQA ⇔ 品質意識の向上

  • 専門性の高いドメインは委託
    • セキュリティ会社にライブインタビュー ※登壇中にSkypeつないでインタビューw

  akerunのテストどうですか?
   Q どこが難しい?
    問題が起きた時にWeb系よりもいろいろなこと考慮する必要があり難しい
   Q どこが楽しい?
    切り分けしてどこが問題ってわかったときは面白い
    Web系と観点違って面白い 木材立てて通信遮断とか

  • 外部にテストしてもらうときも楽しんでほしい→プロダクトの魅力が重要
    • →結果的にプロダクトの魅力がさらにあがる! 「わくわく感大事」
  • 魅力あるプロダクトとは
    • 新しく他にない
    • 先端技術
    • 他にない
まとめ
  • IoTスタートアップがQAをする難しさ
    • 範囲が広い
    • ハードの計画も
  • 生産性を上げる = モチベーションの維持
  • エンジニアリングの活用
  • 全社QA体制⇔品質意識の醸成
  • ただし専門性の高いドメインは委託

IoT、ビッグデータ、サーバレス、品質管理

アイレット株式会社 鈴木 宏保さん

会社紹介
  • cloudpackのサービス展開
  • AWSのプレミアコンサルティングパートナー
  • KDDIの子会社化
  • IoTをもう一つの中心事業とする
  • フルマネージドサービスの利用。IoT案件
  • サーバレスアーキテクチャの利用
    • メリット
      • AWS利用料が削減できる
      • 運用保守費用が削減
      • ライセンス費抑えられる
    • デメリット
      • サービスが増える、更新されるのでキャッチアップが大変
      • 管理を任せられる分制限がある
サーバレスについて
  • お客さんからサーバレスでやってくれと言われているわけではない
  • 品質管理:求められている要件を満たしていることを管理
    • 機能要件:従来通り
    • 非機能要件:以下を変えてみた
      • 可用性
      • 性能/拡張性
      • 運用/保守性
      • 移行性
      • セキュリティ
非機能要件の詳細
  • 可用性
  • 性能/拡張性
    • 基本決まっている
    • 上限があるがUPできる(ユーザが設定変更してAWSに申請)
    • →という点を前提に設計を行う。
    • 顧客の合意をとる
    • →従量課金でコストがかかるため、コストのかかり方についても合意
    • インフラの試験は不要(アプリ部分の試験は必要)11
  • 運用/保守性
    • 人の動き
      • 従来通り
      • 障害に対してできることは少ない →AWS頼み
      • ただし、障害はそもそも少ない
    • 運用保守システム
      • 監視バックアップより、AWSの機能で実現
      • →簡単にできて試験いらず
  • 移行性
    • AWSから外へ → あきらめる。
    • AWS内(他アカウントへ)→ ツールが用意されている(うまくいけば非常に低コストで移行が可能)
  • セキュリティ
    • 仮想サーバとサーバレスの責任分岐点
      • 仮想サーバ:OS以上が自分たち
      • サーバレス:アプリとデータが自分たち
サーバレスの今後
  • サーバレスは流行るか?
    • 決済者にはコストダウンが響きそう
  • これからはサーバレスの時代が来る
    • 品質管理、サーバレスの達人になれば売れるエンジニアになれる!

感想

フォトシンスさんのチーム作りのやり方は、周りの巻き込み方が素敵だなと思いました。キーワード「わくわく感」が特に素敵です。
アイレットさんのサーバレスのお話は、サーバレスの非機能考えていかなきゃなー、なところだったので参考になりました。
登壇者、運営の方々ありがとうございました!

“Issueの書き方と伝え方”勉強会参加レポート

4/21(土)に、九州からいらしたリナさんを囲み、“Issueの書き方と伝え方”勉強会がありました。感想まじえてざっくりレポートしてみます。

イベント情報はこちら
https://connpass.com/event/83134/

『293の法則 第4章』(秋山さん)

概要

まずは用語の整理から
・エラー

  • ヒューマンエラー:思考の誤り
  • 失敗:失敗を導く要因

・欠陥

  • ディフェクト(defect):購入時に存在
  • フォールト(fault):経年劣化などで増えるもの

・インシデント

  • 故障(failure):期待と違う(異常な)結果
  • 不具合/バグ:表出した現象(問題)

・障害レポート

  • Issue:話題/論点
  • バグ票:バグを一件一葉にまとめたもの

・293の法則第4章のサマリ

  • 詳細は293の法則の第4章を参照

・優先度と重要度の補足

  • 緊急度、影響度、重要度を5段階で評価し各合計が優先度となる
  • 優先度単独で点を自分でつけない方が良い(優先度は結果として決まる)。同店の時は緊急度(リスクが見えている)>影響度(客観的)>重要度(主観的)
  • どの項目を誰がつけるのかは現場によって違う模様
  • 例えば緊急度は起票者、影響度、重要度はPLなど。チームの熟練度やどこまでをチームメンバに委譲したいか、で決まってくると思われる(会場でも、参加者の現場の場合を話して議論が盛り上がったポイント)
感想

用語の説明のところがすごく丁寧で助かりました。たまに自分でもdefectとかfailureとかどう違うのか忘れて、JSTQBの用語定義引っ張りだしたりするので。『293の鉄則』第4章もみんなで読んでみて、各現場の話が聞けて面白かったです。

『こんな○○は嫌だ(仮)』(シブヤさん)

資料は公開されてないので、差しさわりのない範囲でサマリします

概要

・バグ票はコミュニケーションツール
・こんなバグ票は嫌だ

  • 文章が長い
    • 一文が長大。「、」がいくつあるのかってレベル
  • タイトルが分かりにくい
    • 「xxがおかしい」「xxが仕様通りでない」など
  • 再現できない
    • 手順がないとか、「特定のタイミングで発生する」とあるが、タイミングについて言及がないとか。
  • 偉そう
    • 思いこみで書いてるとか、文句が入っているとか

・それでもみんな、何かをよくするためのシステムを作ってて、テスターは何かをよくするためのシステムが気持ちよく使えるかをテストしてる

  • シブヤさんがテストするのは世界平和のため
感想

シブヤさんが、テスターあるあるな、嫌なバグ票を恨み節的な感じではなく、笑いに昇華して発表されてるのが、聞きやすくて面白かったです。「タイトルが分かりにくい」は、バグ票書き始めのころに自分もよくやってしまいました。今は具体的に書こうとしてタイトルが長くなりすぎる傾向にあるんですが、みなさんどうされてるんでしょうね。
平和のためにテストしているシブヤさんが素敵でした!

『年間2000件以上Issueを書く私が思う、しあわせになるIssue』(リナさん)

概要

・リナさんの組織と背景の紹介

  • テスター(メイン1名とヘルプ数名)、担当のエンジニアの顔が見える組織
  • 探索的テスター
  • 環境はGitHubを使用、GitHubのIssue機能を使ってバグを報告している
  • Issueで起票するが、以下のようなパターンを使用(起票したものがバグとは限らない)
  • バグ票ワーストプラクティス検討プロジェクト(「ダメなものを避ける」ことで良いものを作る方がやりやすいのではないか)

・Issueってなぁに?

  • エンジニアとテスターとシステムをつなぐお手紙みたいなもの
  • コミュニケーションツール

・しあわせになれるIssueってなぁに?

  • エンジニアには「修正しやすい」、テスターには「修正確認しやすい」。つまり「Issueがあれば、思い出せる」もの

・テンプレート(補足:リナさんのテスト対象はWeb系が多い)

  • タイトル
  • 本文
  • ラベル ★ここがリナさんの工夫の箇所

・ラベルで工夫

  • ある程度ラベルに裁量が与えられてるそうなので、「Bug」「Request」「Question」「UI」などで工夫
  • (探索的テストメインで進めており、現象について)事前合意がないので、バグかどうか判断できない

・こんなときどうする?

  • 一覧画面にて絞込→編集画面に遷移→一覧に戻ると絞込が解除されている

・リナさんならどう書くか

  • Requestとして起票する:「xx編集画面」更新後も条件を保持してほしい

・Issueを書くときに考えていること

  • できるだけ検索条件は保持されてほしい。
    • 登録後の一覧に戻るときだけでいい
    • セッション保持とともに持つのは要件として重すぎる
    • 技術的に最短距離でできるところに落としてほしい
  • エンジニアがしていたであろう操作を考慮したい
    • それ確認してたのに(Chromeでは)
    • それ前に確認してたのに(デグレ)

・IssueをCloseするとき

  • 「ありがとうございました」と書く

・エンジニアからもらってうれしかったIssue

  • タイトルに【おねだり】と書いたら即対応してくれた
  • http://underscore42rina.hatenablog.com/entry/2013/09/07/104513
  • ていねいな説明
    • 結論(対応あり・なし)
    • バグの発生パターン(調査結果)
    • パターンに対する対応と懸念点
    • 対応なしの場合の理由
  • 弱音
    • バグって言われるとつらい→いい感じにラベルの名前を変える
    • 「モンスター」とか「セフィロス」とか
感想

リナさんと、リナさんの周りの人たちが作ってるやさしい世界が素敵だなーと思いました!真似させてもらいます。私も開発者から「バグ」って言われるとつらいので「改善要望」にしてほしいとか、リクエストをもらうことがあるので、裁量もらってる範囲で、チームや人の状況みつつ言葉を選んでみようと思います。
IssueをCloseするときの「ありがとうございました」はさっそく真似させてもらってます。考えてみれば、「確認しました。OKです!」は言ってたけれど、「ありがとう」は言ってなかったように思います。自分が見つけて報告したものについて、開発者が対応してくれたんだから、確かに「ありがとうございます」ですよね。欠かさず言えるようにしようと思いました。感謝大事!
あと、私の所属コミュニティにも言及してくださってありがとうございます!バグ票ワーストプラクティス検討プロジェクトのサイトもよかったら見てみてください(宣伝)
https://sites.google.com/site/swworstpracticesite/

『不具合票あれこれ ー不具合票をテーマにしたブログ記事を調査しました』(鈴木三紀夫さん)

大変面白いので、リンク先の資料をみることを強くお勧めします!特に論点が面白いです。
https://docs.google.com/document/d/1_t43JDi6moOPx-TJHns2Yjr0qQAwvZWP32drjulkLhk/edit#

概要

・不具合票
・不具合報告

・論点

  • 不具合票のタイトルは要約を記載すべきか、内容が把握できるレベルまで記載すべきか
  • 不具合票のタイトルに隅付括弧を入れるか、入れないか
  • 不具合票に書くのは、欠陥・バグかインシデントか
  • 不具合票に要望を書くか、書かないか
  • 不具合票のテンプレートは必要か、不要か
  • 不具合票は必ず書くか、開発者に説明できれば書かないか
  • 不具合票に考察を書くか、書かないか
  • 不具合票にはたくさんの情報を記述すべきか、簡潔にすべきか
  • 不具合票の現象に「どうならなかったか」を書くか、書かないか
  • 重箱の隅をつつくような不具合を起票してもよいのか、そのような細かい不具合はまとめて起票するほうがよいのか
  • 不具合票に「本来は〜であるべき」を書くか、書かないか
感想

全体的に調査の網羅率がすごいです!論点のところが議論が盛り上がってよかったです。自分のプロジェクトや自分はどうしているだろう、と考えながら読むと、特に面白いと思います。
個人的には隅付括弧を入れる派なんですが、全体的にはどうなんでしょうね。機能名でフィルタすればわかるのはその通りなんですが、タイトルでぱっと見分かりやすくなるので、機能名とか画面名をつい隅付括弧で入れてしまいます。情報量は、チームの熟練度とか開発者との関係性によって変えてますね。

全体の感想

Issueにテーマを絞る勉強会ってなかなかないので、濃い話がたくさん聞けて楽しかったです。各社、各現場でどうされてるのかな、と疑問に思ってたところで色々「うちではこうやってるよー」というのが聞けました。
その後のテスト酒場もとても楽しかったです。バスケ、野球の話からバグ票の話、ゆるファシワークショップのその後の話まで、たくさん話しました。テストってちょっとニッチなところがあるので、同業者で集まる場っていいですね。
講演してくださった皆さま、企画してくださった皆さま、ありがとうございました!

自分から話すのは苦手なので、とりあえず巻き込まれてみた記録

概要

自分から話すの苦手、人を巻き込んで何かやるの苦手、ならいっそとりあえず巻き込まれてみる方針で行こう、と決めて1年半くらいやってみた記録です。JAWS DAYSに登壇した後輩が、「巻き込まれ力」というテーマで話していて、いい言葉だなーと思ったので書いてみました。ちょっと勢いで書いてみた感があるので、読みづらい部分はお許しください。

きっかけ

勉強会はちょいちょい参加してたけど、どうも自分から話しかけに行くのが苦手なので、なかなか話せる人ができず、ちょっとどうしたもんかなーと思ってました。
そんなところに、ワニ氏からWACATEに誘われ、ついでにコミュニティ活動に興味ないか、と声をかけてもらいました。それが「バグ票ワーストプラクティス検討プロジェクト」。バグ票はもともと困ってた&技術書翻訳に興味があった、で参加を決めました。
2016年冬のWACATEに初参加。この年は、物心ついてから初めて、カープのリーグ優勝を見たのも、新しいことにチャレンジしてみるきっかけになりました(ホント感動しました)

WACATE

参加してみて、ソフトウェア品質に関わる方々と、夜中まで話せたり、色々な方とのつながりができました!参加レポートはこちらに書いてますので、よかったらどうぞ。
WACATE2016冬「あなたのためのアラカルト」に参加してきました(1日目編)
http://d.hatena.ne.jp/yuki_shiro/20161225/1482659762

WACATE2016冬「あなたのためのアラカルト」に参加してきました(2日目編)
http://d.hatena.ne.jp/yuki_shiro/20161231/1483184966

参加の効果

WACATE後の初JaSST、後輩の登壇で話しかけに来てくれる人がたくさんいたし、WACATEで知り合った人たちが情報交換会で声をかけてくれたり、飲みに誘ってくれたりしました。ぼっち気質の自分にとって、見かけて手を振って声をかけてくれる人のいることはとてもありがたかったです!

SQiP登壇のお誘い

4月末くらいに、SQiPのSIGに応募してみようという話がコミュニティであがり、せっかくなのでまだ登壇したことのない自分に、登壇してみたら、と背中を押してもらいました。正直、お仕事があまりうまくいってなかったり、忙しかったりで不安な部分も大きかったんですが、でも、全力で巻き込まれてみることにしました。ワークショップ的なことをやってみるのは初めてだったのですが、

  • やりたいことの整理、コンセプト決め
  • ワーク作り
  • 例題に必要なダメな例探し
  • タイムテーブル作成
  • オフラインでの合宿、レビュー

などなど、コミュニティのメンバに助けられて、何とか準備できました。レビューを通して、コミュニティメンバのアウトプットやコメントの正確さに圧倒されました。(コミュニティ活動されている方って行動力すごいなあ)

SQiPでSIGやってみた

初めてのSIGにして、初めてのSQiP参加でした。ワークショップで、タイムテーブル通りにはいかずちょっと焦ってましたが、参加してくださった方にも助けてもらい、無事終了。

SQiPフィードバック実施

会社の勉強会でSQiPのフィードバックを行ったところ、「会社でもワークショップやってみなよー」と背中を押され、全力で巻き込まれてみました。twitterで、会社でもワークショップやってみなよーといわれて企画中と呟いたら、テストクラスタの方々から「やっちゃいなよ!」とか「いいね」をもらえたので、それにも背中を押されました。(呟くことによってやる方向に自分を追い込んだとも言う)11月の連休の真ん中という日程でしたが、ワークショップを実施したところ、先輩、若手が計8人も来てくれて、すごくありがたかったです。社外コミュニティでやったことを、社内にも生かせるとやりがいありますね。

会社のプロジェクトで試験チーム任せてもらう

それまで社外でのプロジェクトに従事していたのですが、9月頃から社内に戻り、機械学習を使ったシステムのテスト。初めてでちょっとビビりつつ、試験チームのリーダをやらせてもらいました。メンバの方にスケジューリングやらなにやらよく助けてもらいました。何かあったら、チームのメンバ集めて共有、作戦会議「ちょっと見てもらっていいですかー」とか、技術書典の戦利品置いといてみたりとか、雰囲気作り的なものをちょっと意識してやってみました。メンバがそれにノッてくれる方ばかりで、私も助かりました。

社内でのバグ票レビュー

12月から1月にかけて、社外コミュニティでバグ票の改善活動をやってることを見た上司から、以前に所属していたプロジェクトのバグ票レビューをやってみないか、と声をかけてもらいました。後輩がいくつか、ダメそうなバグ票をピックアップしてくれたので、そちらにコメントをつけて返却。
ここで、気持ちの良いコミュニケーションをやりましょう、といってた自分がコミュニケーションの失敗をやらかしました。社内SNSのコメントだけのやり取りをしてしまったので、開発チームから「それだとちょっとしんどい」とコメント受けて反省しました。なので、開発チームのメンバに集まってもらい、MTGを実施。

  • QAチームはこのバグ票の書き方だと、ここが困ってる
  • こう直してもらえると助かるので協力してくれないか

 ただし、「こう直してもらえる」は無理ない範囲で。
バグ票で困っていることを開発チームに聞いてみたら、バグ票の項目で一部書き方が分からない、という部分があったりと、一応やってみてよかったと思える会にはできたかと思います。

とりあえず、巻き込まれてみる

1年半くらいやってみて、相変わらず、自分から話しかけるの苦手ではあります。けど、話しかけてみたりやってみたりして、なんとかなった、という経験の蓄積中なのでちょっとずつよくはなってるんじゃないかなーと期待。この辺自分ではよく分からないので。
分かってきたことは、「困ったら巻き込んだ人を頼ってみる。素直に助けてっていうと、結構みんな助けてくれる」ということでしょうか。次のステップは巻き込まれついでに、周りもついでに巻き込む、あたりを目指してみますかね。

JaSST'18 Tokyo参加レポート 1日目

今年もJaSST'18 Tokyoに参加してきたのでレポートします。

「Advances in Continuous Integration Testing at Google

John Micco(Google

Googleのテスト
  • 1日、1億5000万件のテスト実行 (420万件のテストを1日35回繰り返す)
  • マニュアルテストはない。100%自動化している
  • 99%のテストはPASSSする
  • コードをコミットするときは、当然のごとくテストコードも一緒
テストの選び方
  • 依存性関係を持ったテスト
  • コードの依存性グラフを作っている
  • テストは450万件あるが、依存関係グラフによって実行対象を絞れる→影響のないところはテストしない、割り切り
テスト結果への対応
  • テストの合否はすべて記録(2年分)
  • ひたすら自動テストを実行
  • PASSからFAILに移行した場合 →スケジューリングをさかのぼってどこから変わっ・たのかすぐにチェックする。
  • 結果のパターンが見えてくる
  • 結果は何種類かに分類することで、開発者とインフラチームが責任を持つべき結果を分けている
Flakyなテスト
  • 同じテストを実行する中で、結果が成功から失敗(またはその逆)に状態が切り替わるもの。不安定なテスト。
  • テスト結果を蓄積して、Flakyの原因が何なのか分析中。問題がない場合もある
Googleの文化
  • テストを自動化する価値→イテレーションの高速化。手動はない。100%自動化。人が死ぬようなシステムないからね!という割り切り。
  • コードレビュー時に同時にテストコードをサブミットしてもらうようにしている
感想

愚直な正論の積み重ね。日本の周回遅れを感じました。
あまりに印象が強すぎて、思わず当日券買って次の日のチュートリアルに参加しました。
基調講演聞いて、がぜんチュートリアルに興味が出たので、チュートリアルも受講してきました。

「はじめてみようテストプロセス改善〜テストプロセス改善モデルを使った改善活動の勘所〜」

TPI NEXT、TMMi、ISO/IEC 33063といった各種改善モデルの紹介。

改善の勘所

1.アセスメント
 やってみる
 認識合わせた
 振り返り

2.計画
 関係者の要求を確認
 関係者との調整
 バッファを持った計画

3.実行
 状況確認
 改善アクション
 更なる改善

重要だと思ったポイント

改善は大変。何より大事なのは1人で悩まないこと。いろんな人と話す。困ったら誰かに話す。

「テスト会社のテストリード達はどのようにテストを成功に導いているのか?」

いいこと色々いってたのですが、自分的にはツイートした内容がクリティカルだったので、そこについて。

とても良い例えだと思いました。そして、最近自分はこのように行動できてるかな?と自問するきっかけになりました。一応機能の目的とか、どういうユースケースを想定してるのか前よりつっこんで聞くようにしてますが、もうちょっと開発者と一緒に考えられるようになりたい。

「開発がスクラム導入するんだって!試験どーしよ!?」-サイボウズQAスクラム奮闘記-」

クラウドサービスcybozu.comの管理者機能開発の事例

開発:QA:PO=5:5:1

スクラム導入前の問題>
 バグの検出が遅い
 要件があいまいなまま開発がスタート
 開発とQAの隔たり感

 →スクラム研修受ける
  やってみよう
  
<開始までの準備>
(1)「カンバン仕事術」輪講

(2)もろもろ定義
 完了の定義
 テストに関することをどこまで含めるか定義
 開発チームの実力に合わせることが大事
 →含めなかったこと
  ・テスト実行を完了する
  ・脆弱性検証
  
(3)アジャイル第一人者の講演を聞く

<導入後のプロセス>

  • スプリント2週間
  • リリース単位は6スプリント+リリーススプリント

<よくなったこと>
(1)バグの早期検出
 類似バグの量産を防げる
(2)要件の明確化
(3)開発チームの一体感
 QAは開発のリクエストにこたえられるようになった
 開発はQAのことをより気に掛けてくれるようになった
 
<実際>
スクラムは問題発見のフレームワーク

Garoonの開発チームの事例

<開発のプロセス>
 スプリントは3週間
 リリースサイクルは3か月
 
<導入前>
全員スクラム未経験、拠点は日本、中国、ベトナム三箇所
→とりあえず日本のみ
 スクラムチームに日本QAが足りない
  当時PG7名、QA2名
  →1名SMやるため実質QA1名
 
スクラムの基本にのっとるのはあきらめた
 スプリント内では実装完了、次のスプリントでテスト設計・実施
 テスト設計、実施は海外拠点
★結論:失敗した失敗した失敗した

主な原因
 価値分割できず、バックログアイテムが巨大化
 仕掛中タスクが大量発生
 職能の壁が発生

課題はあれど、海外拠点でもやることに

開発と比べると、QAの方が変化が大きいのでは

<解決>
チームの有志で勉強:実践アジャイルテスティング
 ABD(Active Book Dialogue)

職能間の障壁を下げる
 できる作業は職能に関係なく着手

感想

★結論のところで、スクラム導入当初のバーンダウンチャートをさらす勇気が素晴らしいと思いました。下がるはずのバーンダウンが炎上している!って紛れもなく失敗で外部に出したくないものだと思うんですが、出してくださって勇気づけられます。失敗しても改善して前に進んでいるチームがいるって事実はちょっとほっとしますね。ありがとうございます。

バグ票の改善観点の紹介と、やりやすいところからの改善のおすすめ

これはソフトウェアテスト Advent Calendar 2017の14日目の記事です。
この1年、バグ票ワーストプラクティス改善プロジェクトというコミュニティで活動して、得たこと、感じたことを書こうと思います。

そもそもバグ票はなんのために書くのか?

バグ票の一番大事な目的は、バグを直してもらうことだと思っています。テスト実施者がバグを見つけ、それを開発者に伝えてバグを直してもらう、そのためのコミュニケーションツールですね。

バグ票のどういう点が問題になりやすいのか?

先日、ソフトウェアテストの小ネタ Advent Calendar 2017の記事である、リリカル氏のブログ記事「エンジニアに「は?」とキレられたバグ票ワースト5」を見ていただくとよく分かりますが、バグ票はよくテスターと開発者の間で問題になります。
・再現できない
・そもそも何がもんだいなのかわからない
・テスターと開発者、または、複数社またがる開発だと開発会社間などで
 やたらとコメントのやり取りばかりが続く etc
色々パターンはありますね。

バグ票改善観点のご紹介

そんな問題の起こりやすいバグ票を改善するためのヒントとなる本を紹介します。

Bug Advocacy: A BBST Workbook (English Edition)

Bug Advocacy: A BBST Workbook (English Edition)

コミュニティが主催/担当したワークショップで何度か紹介してますが、
こちらは、Cem Kerner, Rebecca L. Fiedler らが2015年7月下旬に出版した書籍で、著者が大学で行った講義の内容をまとめたものになります。
講義資料や、実際の講義のビデオもこちらのサイトから見られますので、興味のある方はぜひどうぞ。

おすすめポイントは、バグ票改善のヒントとなる「RIMGEN」の観点を学べることです。
RIMGENとは、バグ票の記載内容を改善するための6つの要素の頭文字をつなげたものです。

  • Replicate(再現性):再現できるか
  • Isolate(独立性):単純な手順となっているか、1件/レポート となっているか
  • Maximize(発端性):最悪なことが起きるバグの兆候をみつけているか
  • Generalize(普遍性):プロダクトに対するバグの影響範囲を識別できているか、そのバグは他の環境や条件で発生することはあるか
  • External(第三者性):プロダクト利用時にバグの影響範囲を開発者やテスト担当者、開発組織外の視点から識別できているか
  • Neutral(中立性):困惑させるような推測や思い込みなどがないか

※日本語訳は、つけてみたものの、自分でもしっくりきてないところがあるので、何かよい訳があればコメントいただけると助かります。

バグ票の見直しを行う場合や、バグ票の書き方について教育を行う場合に参考にできると思います。

バグ票が、このRIMGENの観点にそって書かれていない場合には次のような問題が起こると考えています。
まず、大きな問題として「関係者間の信頼関係が崩れる」ということがあげられます。
もう少し細かく分類すると

  • 再現不能なバグとして却下される
  • 修正されるべきバグにフォーカスが当たらない
  • バグの内容を理解するのに時間がかかる
  • バグが非現実的、不合理として却下される

ということがあげられます。

バグ票の改善をやりやすいところから始めよう

上であげた問題と、RIMGENの観点、改善ポイント、改善難易度をマッピングしてみた図です。

図の通り、観点によって改善のやりやすいもの、やりにくいものが存在します。
個人的なおすすめは、比較的取り組みやすい「書き方で防げる問題」の対処から始めることです。
可能であれば、開発者とテスターに集まってもらい、
何が書いてあればお互い困らないかを話して、その場でフォーマットを決めてしまうとよいと思います。

ワークショップで、困ったバグ票のサンプルを提示し、それを改善するためのフォーマットを作るという試みをしましたが、
だいたい、どこでも「ファクト・事象」「再現手順」「期待する動作」はフォーマットの内容として挙がってきました。
それだけ、多くのバグ票関係者が困っているところであり、逆にここが改善されると効果の大きいところなのだと思います。
再現手順欄がなければ、欄を作る。
欄があっても書いてくれなければ、理由をヒアリングして対処を打つ、などやりやすいところから着手していくと
テスターと開発者の間で伝わるバグ票に一歩ずつ近づけるはず、と思って活動してます。

まとめ

バグ票の目的は、バグを直してもらうことです。そのためには伝わるバグ票を書くことが必要です。
紹介したRIMGENの観点を使って、やりやすいところから改善することで、お互いに伝わるバグ票を書きましょう!