「ASTERセミナー標準テキスト」読み合わせと「ソフトウェアテスト勉強会「やってみよう!探索的テスト~ハイクオリティな妄想の高速ループ~」」参加レポート

先日ASTERから公開された「ASTERセミナー標準テキスト」の有志による読み合わせと、「ソフトウェアテスト勉強会「やってみよう!探索的テスト~ハイクオリティな妄想の高速ループ~」」に参加してきたので、その感想レポートです。

ASTERセミナー標準テキスト読み合わせ

「ASTERセミナー標準テキスト」は、こちらからダウンロードできます
http://www.aster.or.jp/business/seminar_text.html

発端

ASTERの資料が公開されたので気になっている、とTwitterで呟いたら、有志による読み合わせ会が発足しました。テストクラスタありがたすぎる。
というわけで、三連休の初っ端からファミレスに集まり、セミナー標準テキストの読み合わせが行われました。今回は初回ということもあり、対象は1章+αくらいで進めました。

やり方

やり方は、時間を決めて各自読み込む、気になったところをそれぞれコメントしあう、という形でやってみました。エクストリームリーディングというそうです。
当日集まったメンバが、組み込み、第三者検証、開発、自社サービスと四社四様だったので、それぞれの立場からの見方があって興味深かったです。

読み合わせで気になったところ

詳しい話は割愛しますが、面白かったのは、ほぼ全員がP18の「テストの目的の拡大(機能充足→目的達成→価値提供)」を気にしていた点です。
f:id:yuki_shiro:20180919011351p:plain
※画像は、「ASTERセミナー標準テキスト」p18のスライドを引用させていただいています。

P18が気になってるのは、私の場合、次のような理由からです。

  • 拡大円の一番外側「ソフトウェア・システムが他の要素と連携し、ライフスタイルやビジネススタイルを変革しているか把握する」まで行きたいけど、どうすれば行けるんだ?
  • 外側から2番目「ソフトウェア・システムが目的を達成し、顧客(利用者)が満足しているかを把握すること」これは、最近気にしていることなので目下の課題。永遠の課題ではあるけど、今個人的には一番力を入れてるところ
  • 外側から3番目「非機能要求を含めてソフトウェアの品質情報を収集し、品質リスクを軽減する・より品質を高めること」については、最近、非機能って何だろう?と少しモヤモヤしているところ。
    • 性能とかセキュリティについては、ほぼほぼ機能では?
    • とはいえ、機能単体だけ見てると漏れる部分ではあるので、別出しになっているのは分かる気はする。
    • 『非機能』という訳語の問題?
  • この図、非常にいい図だと思うので印刷して会社にひそかに貼っておきたいw

あとは気になったページというか、耳が痛いページはP36の「テストの独立性と開発との関係」です。

  • 「対決ではなく、協調姿勢で開始する。全員のゴールは、高品質のシステムであること再認識するとよい。」この通りなのですが、守れていないことも多いので自戒。。

ソフトウェアテスト勉強会「やってみよう!探索的テスト~ハイクオリティな妄想の高速ループ~」

TEF道の中岫さんと根本さんが、JaSST'18 Tokyoで行われたセッションの再演をしてくださったものです。

探索的テストとは

資料はこちらから
http://jasst.jp/symposium/jasst18tokyo/pdf/E2.pdf

探索的テストとは、「「対象を動かしながら、テスト設計~実行~フィードバックを行っていく(ハイクオリティな妄想のループ)対話型のソフトウェアテスト」だそうです。詳しくは、上記の資料をどうぞ!
仕事でも自己流でやってみていますが、私はテストチャータとタイムボックス決めて、気になるところを重点的に動かしてみる、というやり方をしています。

ワークショップ内容

実際に探索的テストを行う対象のサイトを用意していただき、それを実際に動かしてみました。

  • 初めに一人で手を動かして、気になったところを出してみる
  • グループワークで気になったところと、どうしてその気になった点を出せたかについて報告しあう

このやり方を、テストチャータを変えて2度行いました。

ワークショップからの気づき

気になったところは、人によって出せる数が本当に異なるのが面白かったです。気になるところが出せる数が少ない人には、だいたい2パターンくらいあるのではないでしょうか。

  • 経験、知識があまりなく、「そういうものかな」と思ってしまう人
  • 気になるところを見つけてるけど、「仕様って書いてあるし、指摘していいのかな」と遠慮してしまう人

後者の場合、グループワークをやると「あ、それ、指摘してよかったんだ」という契機をもらえるので、後々、気になるところの検出数が上がる気がします。私は気になったところについて、「仕様」とある場合は、あげるべきかちょっと迷ってしまうので、勇気づけられましたw グループワークで、「どうしてその気になった点を出せたのか」をお互いに話せた点も、他の方から素敵な視点をもらえてよかったです。
前者の場合は、どうすればいいんでしょうね? ペアテストしてみる、とかでレベルアップできるんでしょうか。

感想

JaSST'18 Tokyoで、ちょっと出遅れていったら会場が満員で入れなかったので、再演がとても嬉しかったです! ありがとうございました!

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)

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

感想

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