t_wadaさんと柴田芳樹さんの講演から、テスト駆動開発の良さを実感しました。 #JaSST

JaSST 勉強会 技術 TDD ペアプログラミング

はじめに

  • 先日、JaSST'18 Tokyoが開催されました。

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

JaSST'18 Tokyo チュートリアル「コードを書きながら学ぶテスト駆動開発」

  • テスト駆動開発(TDD)の第一人者であるt_wadaさんが講師となってTDDを学びました。

当日のツイートまとめ

  • 以下のページです。*1

togetter.com

チュートリアルの構成

t_wadaさんによるライブコーディング付きのTDDの方法についての発表

  • もう、この一言に尽きる。こんなになめらかなライブコーディングは初めて見た。

  • 滑らかすぎて、必死についてきてツイートしたので、それは上記のまとめページを見てください。

  • 自分は初めてTDDを学んだのですが、何よりも「TODOの出し方」から「1回目のRed解消」までのやり方は非常に参考になりました。

  • 今回は全員がeclipseを利用するという制限で行っていましたが、それによって「ライブコーディングで示したいたのと同じことを、自分が使っているIDEでできるのか！」と共感できました。

  • 特に、以下の一連の流れは、「テストコードを書く」というよりも、「実装する（それがたまたまテストコードだった）」という感覚になりました。

    • fail()でとりあえず失敗するテストコードを書く
    • まだ作っていない変数や関数を記述して、コンパイルを失敗させる
    • 変数を宣言させてコンパイルを通る状態にしていく
    • 関数を宣言させて、プロダクトのクラスを作成することでコンパイルを通る状態にしていく
    • でっち上げでも良いからテストコードの通る値をreturnして、テストも成功するように変更する

  • また、JUnit5ならではのテクニックも参考になりました。

ペアプログラミングでのTDD体験

  • さて、t_wadaさんの発表を聞いただけでは、理解はできても実感はできません。

  • 今回のチュートリアルでは、2人1組になり、ペアプログラミングをしてTDD体験をしました。

  • この体験を通じて、色々とTDDでの苦労を体験できました。*2

    • TODOの分割で、優先度の高いものがどれになるか考えられない
      • FizzBuzzの例でいえば、「数を文字列に変換」とかを考える前に「3の倍数だったらFizzと変換」とかを考えちゃう
    • 取り掛かるテストコードが具体的にならず、試行錯誤で具体的にしていた
      • 何を入力値で、何が期待結果になるか分からぬまま、取り掛かろうとしていました
    • 細かい関数に分けて考えられない
      • 1つの塊のコードで考えるクセが付いているらしく、それを細かく区切るというところに頭が回らない
    • ナビゲートが大変
      • 経験年数から見て、今回は自分がナビゲート役でしたが、TDDは初めてだったので、上記の苦労した点の改善策を上手く相方に伝えられませんでした…。

  • ここらへんは、もっともっとTDDに慣れ、ペアプロに慣れることで改善していきたいと思います。

  • チュートリアルならではの内容で非常に勉強になりました！

JaSST'18 Tokyo招待講演「私が経験したソフトウェアテストの変遷」

  • 今回の招待講演は柴田芳樹さんによるお話でした。

当日のツイートまとめ

togetter.com

招待講演の構成

  • 大きく分けて、以下の3部構成でした。

    • TDD、CIの話
    • 柴田さんの経験談
    • ソフトウェア開発とQA

TDD、CIの話

  • 個人的には以下で紹介する「フィードバックループを短くする」の図が招待講演の中で一番響いた部分です。

  • QAテストなどは開発者へのフィードバックが長い。

f:id:nihonbuson:20180329092359p:plain

http://jasst.jp/symposium/jasst18tokyo/pdf/A7.pdf#page=9

  • 単体テストになると開発者へのフィードバックは短くなる。
  • しかし、実はこれが最短ではない。

f:id:nihonbuson:20180329092432p:plain

http://jasst.jp/symposium/jasst18tokyo/pdf/A7.pdf#page=10

f:id:nihonbuson:20180329092445p:plain

http://jasst.jp/symposium/jasst18tokyo/pdf/A7.pdf#page=11

  • t_wadaさんのチュートリアルのおかげで、「常に実装している感覚」が実体験と共に実感できました。

  • 手で行ったテストは資産ではない…「自動テスト実装までやると余計なコストがー」という人に聞かせてあげたい。

柴田さんの経験談

  • ブログに書き残すことができない話もしていたため、あまりメモを残せていません…。
  • ただ、Flakyなテストに悩んでいた話も聞けて、「ここでもFlakyが！」と一人で反応してました。

ソフトウェア開発とQA

  • 実装より前に設計するという、ソフトウェア開発において当たり前の話がなかなかできていない気がします。
  • そして、それを上司が理解していない場合、考えをひっくり返すのにパワーがいるという話は「確かにー」と思ってしまいました。

質問

  • この質問が印象的でした。
  • この質問では、「API設計」を前提とした質問でしたが、教育についてはどんな場合でも同じようにいえると思う。
  • 教育や研修については、どれだけ現場と近付いて協力的に行えるか、もっと考えるべきだなと思っている。
  • そういう意味でもペアプログラミングは教育的視点も含めて良い方法なのだろうなと感じました。

終わりに

  • 今回のJaSSTでは如何に開発とテストが協同して行われるかが（個人的に）テーマだった気がします。
  • 基調講演などでは自動テストがテーマでしたが、今回参加・紹介したテスト駆動開発もその一つだったと感じました。

関連記事

  • JaSST'18 Tokyoでは自動テストの話も盛んに行われていました。自動テストに関する記事はコチラです。

nihonbuson.hatenadiary.jp

nihonbuson.hatenadiary.jp

*1:自分以外、誰もツイートしてなくて、「あれ？これってツイート禁止のチュートリアルだっけ？」と不安になりました。

*2:これはTDD自体で残り続ける問題というよりも、慣れで解消できるような問題だと思っています

アメリカでは政府がコードレビューを義務付けている #JaSST

JaSST 勉強会 技術

はじめに

先日、以下の記事を書きました。

nihonbuson.hatenadiary.jp

その中で、以下のようなリアクションが大きかったです。

JaSST'18 Tokyoクロージングパネル「アジャイル・自動化時代のテストの現場のリアル」 #JaSST - ブロッコリーのブログ

"政府の規制によってコードレビューが義務付けされた" コレ自分もそう聞こえたんだけどマジかとビックリした ソースどっかにないすかねぇ #jasst

2018/03/09 12:18
b.hatena.ne.jp

そこで、カンファレンスの翌々日に、まだ日本にいたJohn Micco氏に急遽会いにいき、質問をぶつけてみました。*1

自分「政府の規制によってコードレビューを義務付けているのは本当か？」

Micco「そうさ。"sarbanes-oxley"によるものだよ。」

sarbanes-oxleyとは何か

いわゆるSOX法のことです。

www.legalarchiver.org

上場企業会計改革および投資家保護法 - Wikipedia

日本でも、日本版SOX法が存在しています。

参考： https://home.kpmg.com/jp/ja/home/insights/2013/10/jsox2.html

しかし、日本版SOX法は経営層に対しての決まりはあっても、従業員に対しての決まりが無いようです。

コードレビューが義務付けられるようになった経緯

当時、コードレビューもしていなかった頃、こんな事件が起きました。

  • ある取引では、端数の金額を切り捨てる決まりがあった。
  • その切り捨てられた端数を自分の口座に入れるプログラマが現れた。
  • 1回の端数は見逃しやすいような少額だが、積み重なって多額のお金を得てしまった。

これを二度と起こさないために、レビューを設けて、2人以上が必ず変更に関わることを義務付けたようです。

義務化されたコードレビューの内容

  • 個人的な利益に繋がる可能性のある、お金に関わる問題を発端としているため、それ以外のプログラムは義務から外れているようです。
    • 例えば、車のプログラムに関しては、今のところ、この義務の対象外のようです。
  • コードレビューの細かい指針というものは存在せず、「2人以上が関わる」ということのみが義務化されています。
    • 組織的に行わない限りは、別の人がコードを見ることによって防げると考えられるためです。

詳細は…

今回の内容としては、SOX法の第9章「WHITE-COLLAR CRIME PENALTY ENHANCEMENTS」が該当すると思われます。

しかし、具体的に「複数人のレビューを義務付けている」というような記述が見当たりませんでした…。

これについて詳しく分かる方、補足をお願いします！

*1:主にこのために往復1時間かけて会いに行ったら、Micco本人から「クレイジーだ！」と言われました。

GoogleのJohn Micco氏によるFlakyなテストとその判別方法の解説 #JaSST

JaSST 勉強会 技術

はじめに

と書い（てしまっ）たので、JaSST'18 Tokyoに参加した私なりのFlakyの解釈を書きます。

JaSST'18 Tokyoについては以下のページを参照してください。

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

お知らせ

この記事の内容を4/11に発表しました！

nihonbuson.hatenadiary.jp

発表スライドはこちら

speakerdeck.com

目次

Micco氏のお話

  • John Micco氏（以下、Micco）の話は、以下の3回聞きました。
    • ICST基調講演(2017年)
    • JaSST'18 Tokyo基調講演(★今回)
    • JaSST'18 Tokyoチュートリアル(★今回)
  • それぞれのタイミングで、特にFlakyの話の理解度が変わっていったので、Flakyを中心にMiccoのお話をお伝えします。

いいだろー！*1と言いつつも、t_wadaさんのように後悔した人にも伝われば幸いです。

ICSTでの話

  • Miccoは昨年行われたICST2017でもGoogleの自動テストについて講演されています。
  • その時の説明は、以下の記事を参照してください。

nihonbuson.hatenadiary.jp

基調講演「Advances in Continuous Integration Testing at Google」

  • 上記のICSTから追加・変更した内容を中心に記載します。

講演資料

Advances in Continuous Integration Testing at Google – Google Research

テスト文化について (3ページ付近)

  • テスト文化を大切にしている
    • テストのテクニックはトイレに貼ってある
    • Google Testing blogで発信している
    • GTACでも発信している
  • テストが書けることを期待している
    • 新規採用の際はテストが書けないとダメ
    • Googleの新入社員に対してテストの仕方を教える
  • SETIエンジニアを各開発チームに配置している
  • モデルテストなどは実験をしている
  • 大体はエンジニアが書いた自動テストが回っている
  • 自動化テストを促進する文化がある
    • 10年の文化がある
  • コードビューがある
  • 450万のテストは開発者が行っている

回帰テスト (4ページ付近)

  • 1つのbranchで何十億ものコードがある
  • それを3万人の開発者がテストをする
  • どの回帰テストをするのかの選択が大切
    • これを選択する仕方が大事
  • 現在は2秒に1回テストが動いていく
  • 全ての変更リスト(CL)は2年間保管している。
  • これだけのデータがあれば、パターンが見えてくる
  • 明日のチュートリアルではラボを見ていく

Milestone Scheduling (8ページ付近)

  • 一定期間のマイルストーンで区切る
  • ここまでの変更の累積からテスト対象を決める
  • スケジューリングして実行する
  • NGになった場合、原因探し（犯人探し）を行う
  • NGだったものがNGになるものよりも、OKからNGになる（状態の遷移が起こる）テストの方が興味がある
    • 99.8%は状態の遷移が起きない
    • 0.2%のテストのみをスケジューリングしたい
      • コンピュータリソースを改善するため
    • ほとんどの問題はこの0.2%に集約される
  • 依存性ベースでやっているのは上手く行かない*2
    • すべてが依存しているものがあるから

RTS Affected Target Counts Frequency (13ページ付近)

  • 頻度のグラフを示した
  • コード変更の半分は、400万のテストケースの中の38のテストケースに影響する
    • すべてのテストを流し続ける必要はない
  • 何らかの方法でスケジューリングを減らさないといけない

Project Status and Groupings (16ページ付近)

  • リポジトリは1つだけだが、プロジェクト別にグループ分けをしている
  • GmailにもSearchにも一連のテストが紐付けられている
    • Searchで失敗していても、Gmailのリリースはできるようになっている
  • すべてのテストを見落としていない限り、Greenの結果にはならない
  • オーバースケジューリングを減らすには、Greenに近い確信レベルが必要
  • 実行していない自動テストは、決定的でない代わりに、確率論を用いる（スライド17ページ）
  • チームとしてはリスクを持ってリリースする

Safe Results (33ページ付近)

  • Skipしても、その前後でテスト結果が変化していないならばSkipして問題なかったと判断している
  • Unsafeな場合、どのコミットが原因なのか探さないといけない
  • 最終的にはマイルストーンを排除していきたい
  • 90%以上はテストをしなくても、きちんと動くものをコミットしている
  • 遷移が分かっているものはSkipする
  • Skipする割合とテスト結果の変化は直線的ではないことがわかった

Flaky (35ページ付近)

  • あてにならないテストのこと。
  • Flakinessは同じコードで成功と失敗の両方を観測されるテストのことをいいます。*3
  • 全体の16%はFlakyである
  • Flakyテストを再実行すると、リソースの2%〜16％を費やすことになる。

分析結果

  • 変更が多いファイルはFlakyが起きやすい
  • 開発者は1人よりも2人のほうが良い
  • 言語によってはFlakyが起こりやすい
  • C++ < Java < Go でFlakyが起きづらい
  • データセットにクエリをかけて、論文の結果を検証・再現するのは明日のチュートリアルで実施予定
  • リソースを待っていたり、WebDriverのテスト、スリープが入るテスト、マルチスレッドのテストはFlakyが起きやすい
  • テストの合否を記録して、時間によるテスト結果の遷移が多いのはFlakyなテストと言える
  • 816件のFlakyなテストがあった
  • 詳しくは明日のチュートリアルで！

質疑応答

その場でツイートしていたので、詳しくは以下のまとめを見てください。

togetter.com

その中から3つだけピックアップ

色々な質問の中で、手動で行っている話はこの3つだけであり、他は徹底的に自動化しているという印象を受けた。

基調講演の感想

  • ICSTの頃に比べ、どのようにすれば少ないリソースで効率的に不具合を見つけられるテストを行えるか考えられていた。

    • ICSTでは、依存関係から判断する話はあったが、テストをSkipする話をそこまで伝えていなかったので…。
    • 以下の文章ぐらい？
      • 例えば、テストが成功ばかりしている場合、そのテストは必要ないのかもしれない （ICSTの聴講レポートより）
        • ICST当時は、「不具合を見つけられないテスト」と解釈していたが、今となっては「本来Skipすべきだったテスト」という意味で必要ないと言っていたのかも。

  • Flakyなテストというのが「過去のテスト結果とも照らし合わせて判断するもの」という意味で使われている（とこの時点では感じた）のは、去年のICSTでの話と異なっている点だと感じました。

    • 「FailedになるとFlakyになるか確認する」という文章が、「テストをリトライした結果を見てFlakyか判断する」「（過去のテスト結果ではなく）リトライした今のテスト結果を見て判断する」という風に捉えていたので…。
    • ICSTとJaSST基調講演で定義が異なるという疑問は、この後に記載しているチュートリアルを受講したことで、払拭されていくわけですが…。

チュートリアル「How to identify test flakiness in your test result data」

  • チュートリアルの内容をどこまで載せてよいのか悩みましたが、Miccoと連絡を取り、ブログに載せても良いという許諾を頂きました。
    • Thank you, Micco!

概要

  • Googleでのデータを用いて、どのようにFlakyであるか判別するのかを体験しました。
  • 体験時に利用したSQLは以下のGithubページにあります。

github.com

  • ここにコミットされているSQLをGoogleのBigQueryを用いて実行しました。

  • チュートリアル中のツイートは以下にまとめました。

togetter.com

対象データ

  • Fullデータは以下の通り
    • 143万件のテストケース
    • 5億件のテスト結果
  • 「数が多いので、もっと数を絞ってシンプルなデータを用意した。」by Micco*4
    • 1万件のテストケース
    • 340万件のテスト結果

テスト結果の種類

  • 以下のようにテスト結果を分類している。
    • PASSED…テスト成功
    • FAILED_TO_BUILD…ビルド失敗
    • FAILED…テスト失敗
    • INTERNAL_ERROR…テスト開始の準備が整わなかった
      • 例えば、ブラウザが立ち上がらなかったなど
      • インフラチームが責任を持っている部分
    • PENDING…実行開始しようとしたけどできなかった
    • ABORTED_BY_TOOL…開始したけど制限の15分を超過したので強制終了した *5
    • FLAKY…テストが失敗し、そのテストをリトライしたら成功したもの
      • ここでのFLAKYは、この後に話しているFlakyと別の使い方をしているように思えるので注意！
  • テスト結果を細かく分けることで、以下の点をハッキリさせている。
    • 成功・失敗だけでなく、どんな失敗なのか
    • 失敗の原因はどのチームが責任を持つべきなのか

テスト結果のEdgeを元に、Flakyなテスト（候補）を特定する

  • テスト結果をさらに以下の4種類に分ける。*6
    • Keep Succeed…前回も今回も成功しているテスト
    • Keep Failed…前回も今回も失敗しているテスト
    • Positive Edge…前回は失敗し、今回は成功したテスト
    • Negative Edge…前回は成功し、今回は失敗したテスト

f:id:nihonbuson:20180310105503p:plain

  • 基調講演でも話したように、我々が興味を持っているのは遷移が発生している(Edgeの)部分である。
  • Edgeの中の84%はFlakinessである。
  • これらはすべてのテストの16%に集中している。
  • より多くの遷移に発生しているのはFlakyである。
    • これらはSQLを引っ張り出すことができる
      • 同じテストケースの前回結果と今回結果が変わったどうかでカウントをとる
    • 一番多いテストケースで、1ヶ月に884回も遷移が発生した。
  • 300万ケース中7590ケースで1ヶ月に4回以上の遷移が発生した。
    • これ以下のテストケースはFlakyではない、つまり純粋なテスト失敗の可能性が高い
  • PASS/FAILを記録するだけでもFlakyの判断をすることができる

テスト結果のパターンを元に、Flakyではないテストを特定する

  • Flakyなテストケースはランダム性がある。
  • Flakyではないテストケースはパターンが存在する。
  • 下記の図の場合、「t4とt6」や「t2,t3,t5,t7」は同じパターンで成功や失敗を遷移している。
    • このような組はFlakyではないと考えられる。

f:id:nihonbuson:20180310105623p:plain

  • 過去1ヶ月間のテスト結果のデータを解析すると、以下のことが分かった
    • 最大5000ケースが同じパターンだった
      • これらはFlakyではない
      • これらが同じタイミングで成功・失敗が遷移するとなると、ライブラリ起因の失敗などの可能性が高い
    • 同じパターンのテストケース数が2つ以下のものが、Flakyの疑いのケースだった。

おまけ：テスト失敗の分類をする

  • Flakyかどうかを判別することで、純粋な失敗のテストケースについて分類をすることができた。
  • どんな拡張子がテストの失敗を起こすのか
  • 誰がテストの失敗を起こしやすいのか
    • ただし、これは匿名化している。
      • これを人事情報を結びつけないようにするため。
      • これらは開発者にFBするのではなく、解析したものを機械学習に投入するために使っている
  • Flakyはテストコードとプロダクトコードのどちらを指すのか？
    • どちらに原因があるかを区別していない
    • よく聞かれる質問です。

チュートリアルの感想

  • Flakyを色々な使い方で言っていることが分かった。
    • 1つのテストケースを（コードの変更もせずに）リトライするとテスト結果が変わる場合
    • 前回のテスト結果と今回のテスト結果が違う場合
      • 特に、他のテストケースとテスト成功・失敗のパターンが異なる場合
  • Flakyの判別は特殊な操作をしているのではなく、単純なクエリで推定できることが分かった
    • ただし、Googleは推定するためのデータ数がとてつもなく多いのでできる部分もあるけど
      • 自動テストをどんどん増やす方向になっていくと良いメリットの1つともいえる

おわりに

という、Micco尽くしのJaSST'18 Tokyoでしたが、おかげでFlakyとその判別方法について少しだけ近づけた気がします。

  • 去年のICSTでは、「1つのテスト結果の中で、リトライするとテストが成功したり失敗したりするもの」がFlakyだと思っていました。
  • 今回のJaSSTの基調講演では、「前回のテストと今回のテストの結果が違うもの」がFlakyだと思いました。
    • あれ？Micco、定義が変わってない？と思いました。

  • 今回のJaSSTのチュートリアルで、「1つのテスト結果でも複数回のテスト結果でも結果が変わるもの」をFlakyだと理解できました！

  • 大満足なJaSSTとなりました！

関連記事

  • Miccoも参加したパネルディスカッションについても記事にしました。こちらもどうぞ。

nihonbuson.hatenadiary.jp

*1:t_wadaさんに対してこんな風に言える数少ない機会

*2:ここは私の理解が曖昧です。依存性ベースというのがどういうことを指しているのか…

*3:ここでの「同じコード」というのは、おそらく「同じテストコード（プロダクトコードに変更はあった）」ともとれるし「両方とも同じ」ともとれる。ここが（私個人の）混乱の原因と分かったのは、チュートリアルを受講した後だが…。

*4:いや、これでも十分多いっす…

*5: @yuki_shiro_823 さんと @kz_suzuki さんにご指摘いただきました。ありがとうございました！

*6:実際に説明で述べているのはPositive EdgeとNegative Edgeだけで、それ以外の2つは区別するために勝手に命名しました。

JaSST'18 Tokyoクロージングパネル「アジャイル・自動化時代のテストの現場のリアル」 #JaSST

勉強会 技術 JaSST

はじめに

  • この記事はJaSST'18 Tokyo（ソフトウェアテストシンポジウム）のパネルセッションを書いたものです。

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

自己紹介

  • バックグラウンドが違い、コンテキストが違うことがある
  • そこで自己紹介時に、どれくらいの頻度でDeployしているのか、どれくらいの頻度でリリースしているのかを踏まえて話してほしい。

荻野 恒太郎（以下、荻野）

  • 楽天
  • テスト自動化とDevOpsのマネージャをしている。
  • デプロイは毎日数十回実施
  • 1週間に数回リリースしている

天野 祐介（以下、天野）

  • サイボウズ
  • kintoneの開発チームに所属
    • エンジニアが10数名、QAなどを含めると30名ぐらいのチーム
  • 2015年にチームリーダーになった
  • 今はスクラムマスター中心
  • 最近、WaterFallからAgile開発に変更していっている
  • 今は1イテレーション2週間で行っている
  • Deployの回数は1日数回から十数回実施
  • 2週間に1回リリースしている

山口 鉄平（以下、山口）

  • ヤフー
  • 全社横断の支援部門のマネージャ兼プレイヤー
    • 実際にプロダクトを持っているわけではない
  • 特定のサービスの話ではないが、多いところだと一日数十回のDeploy、2週間や1ヶ月に1回のDeployをしているところもある
  • テストの自動化はどんどん薦めている
  • Deployやリリースの自動化もどんどん進めている
  • セキュリティのテスト（というかライセンス周り）の自動化を進めている。

松尾 和昭（以下、松尾）

  • クックパッド
  • 海外事業部に所属
    • 半年前に異動
    • 開発拠点はUK
    • リモートで東京で働いている
    • 日本人は60名中10名ほど
  • モバイルの自動化やワークフロー構築をしている
  • OSSのコミッタとして活動している
  • 書籍のレビューもしている
  • 色々なサービスを分割して、それぞれで活動している
    • 1サービス6,7名ほど
  • GithubでMergeをAcceptすると、Deployを開発者が伝えればすぐにDeployできる
    • Deploy回数は30回/日ほど
  • モバイルアプリはAppStoreの審査が必要なので、1週間〜1ヶ月に1回は定期的にリリースしている

John Micco（以下、Micco）

  • Google
  • 26名のエンジニアが所属しているインフラでマネージャしている
  • 中核製品Gmail, SearchなどのCIを担当
  • 33000エンジニアをサポートしている
  • Deployやリリースなどは行っていない
  • 15年間はCIに特化している
    • この15年間、同じテストの課題に直面し続けている
  • リリースの頻度は2万/日
    • そのすべてが本番にPushされるわけでない
      • 本番にPushされるのは全体の5%
  • チームによって違う
    • 1日に1リリースしたり、1ヶ月に1回リリースしたり
    • 各チームによってリリース頻度は違う。中央管理はしてない

Micco氏が紹介したGoogleのやり方について

荻野

  • 自己紹介を聞いて、随分GAPを感じた人も多いのでは
  • どういう風な現場になっているかについてディスカッションをします
  • これから自動化を考えてる人も多いと思うので、その人達の参考になれば。
  • 例えば、基調講演の話で、200万件のすべてのテストケースが終わらないとリリースできないと思っていたのでは？
  • 会場にアンケート
    • もしも100％の自動化が終わっている場合、デグレッションテストの研究を使ってみたい（もしくは買ってみたい）人はどれくらいいるか？
  • 登壇者の皆さんは、このGoogleのツールもしくはやり方を利用したいか？

天野

  • サイボウズではSeleniumを使ったテストをしている。Pushをしてmasterに入ると、Seleniumで1700件のテストを20分程度で実行する。
  • Flakyと思われる原因で落ちることがある
    • Flakyかどうか勘で調査している
  • Flaky効果的に探し出せるならば使ってみたい

山口

  • 現在はそこまでのボリューム感がない
  • 優先順位はチームごとによって違う
  • 紹介されていた方法論を使えれば良いが、開発者、チームの感覚を確認した上で使う
  • 「良いから使う」とはならない

松尾

  • 簡単にはすべてを実行できないというときに、必要なぶんだけ実行するためには入れたい
  • Googleの方法を使うことで、自分のコミットがどれだけ影響があるのか見え、責任を持たせる効果も出るのではと思う。

荻野

  • Miccoさんに質問。
  • 実際にはバグを見逃している可能性があるのでは？
  • 全てのテストを実行しないというのはどういう思想をもとに行っているのか？

Micco

  • 確かに全てのテストを実行しないでリリースするのはリスクがある
  • ただ、思想としては否応なしにこのような取り組みになった
    • コンピュータリソースが大きくなり、莫大なコストがかかってしまった

荻野

  • 機械学習で行うといっているが、人間がテスト選択の妥当性を確認しているのか？
  • 将来はAIが完全に担うと思うか

Micco

  • 人間が介在するのはほぼ不可能
    • 1億5千万のテストケースを1日に実行するので
  • 機械学習による見逃しの欠陥を見ながら、それも機械学習に入れたいと思っている

荻野

  • AIのテストをどのようにしているかについては、後でまた聞きたいと思う。

テストの「価値の定義と計測」

  • 自動テストでは、バグを見つけるという価値以外に、コストや時間の短縮に価値を見出していると思う。
  • テストを行った時の価値について聞きたい
    • 例えば、開発・QAの生産性など
  • また、実際にどのように計測しているか

松尾

  • 自動テストはリグレッションの防止の為というのは組織で共通認識になっている
  • 製品を壊さないようにするために自動テストがある
  • CIでどれだけGreenになっているかは計測している
  • カバレッジを計測しているかはチームによる
  • マニュアルテスト（ユーザビリティテスト）はデザイナーを含めてチームでやっている
  • 我々はサービス会社なので、市場に出してよいのか見ている
  • 計測結果は逐次共有している
  • リリース前にそれによって継続して開発していくかの判断はあまりしていない
  • テストについては、カバレッジがあるからこのチームは良いとかいう話はしていない

荻野

松尾

  • Webの場合、テストでAll Greenになるのは時間がかかっても20分におさえている部署がある
    • はやいときだと10分いかなかったり

荻野

  • もっと早いという方？会場に…いませんね
  • これを実現するためにテスト自動化が貢献しているのではないか
  • 続いて、サイボウズさんの場合はどうか？

天野

  • QA部門があり、開発組織と別れてはいる
  • 欠陥検出率は計測している
  • 遷移を確認して、効率的に検出できたか確認していた
  • 自動化しきれない部分をマニュアルで行っている
  • 価値の計測はうまく行ってはいない

荻野

  • Googleではどのようにテストの価値やQAの価値を行っているか

Micco

  • Googleでは完全に自動化されているので、開発者にはコミット前でも後でもすぐにFBできている
  • テストが成功に終わっているのは1つの証でもある
  • ただ、コミットからリリースまで20分というクックパッドさんの例は世界で最速なのでは

テストプロセスとアジャイルについて

荻野

  • 楽天では、DevOpsの研修をしていて、迅速にFBをしていく図を伝えている
  • ドキュメントの管理だったり、リスクベースドテストなどの方法もある
  • サイボウズさんの例（ウォーターフォールからアジャイルの変化）が面白いと思ったが、簡単に説明してほしい

天野

  • 以前は3ヶ月のウォーターフォールだったが、2週間スプリント×6スプリントに変えた
  • スプリントを導入した最初の頃は、6スプリント目をKAIZENスプリントとした
  • 現在では、3週目のスプリントでの残存不具合がほぼ0になったので、KAIZENの工数も一定になった
  • 6スプリントでリリースしていたが、スプリント2回分で1回のリリースになった
  • 1年ぐらいかけて少しずつプロセスを変えていった
    • 初期はバーンダウンチャートがバーンアップしてしまったり…
    • それでも風土のおかげもあって、スクラムを止めようとはならなかった
  • スクラムを導入しようとしたのは私の提案がきっかけ
  • 結果として、不具合報告数が70%減となった

荻野

  • 1年でサイボウズさんのような成果を上げられるのは珍しいのでは？

山口

  • 成果との因果関係が分からないので、一概にアジャイルのおかげとは言えない
  • アジャイル導入前後の結果を見ると、すごいと思うと同時に、導入前はどうなの？と思った
  • ただ、上がったことは良いのでは？
  • スクラム以外のおかげもあったりすると思う
  • ただ、ここまでになったのは、より上手く作りたいと思った結果なのではないか。

荻野

  • GTAC2014でYOUTUBEのテスト自動化に衝撃を受けた

Micco

  • タイミングが一致していた。
    • 全社的に自動化に舵を切った2006年にYOUTUBEを買収した
  • Google全体で文化が根付いた一番の要素は、コードレビュー時にテストコードもコミットするようにしたこと
    • こういう変更というのは、インクリメンタルに一段階ずつ行っていった。
      • この領域はまずすべて自動化する、から会社全体に広がっていくとなっていった

荻野

  • 2006年からテスト自動化の取り組みを開始したと行っていたが、いつごろに100％になったのか

Micco

  • 私が2011年に入社した時には、手動テストはほとんど残っていなかったと思う
    • 全てのプロジェクトに関わっているわけではないので何ともいえないが

荻野

Micco

  • 色んな出来事が重なった結果
    • 政府の規制によってコードレビューが義務付けされた
      • この発言について、後日、Micco本人に確認して、別記事にしました。

nihonbuson.hatenadiary.jp

  • 開発者の振る舞いも変えたかった
  • 現在はコードレビューを存分に活用している
    • アナライズをしたり
    • 自動的にフィードバックしたりレビュアーでフィードバックしたり…
  • 私にとって日本に来て喜びだったのは、テスト自動化は良いものだと思っているが、日本では経営者への説得が大変だと分かったということ
    • アメリカの大手の企業は自動化はされているうえでどう改善するかの話になっているから
    • 自動化を経営幹部に薦めるためのスライドは用意していなかった
  • 自動化をすることで得られるメリットは、バグを見つける時間が短くなることなどがある
    • これだけでは日本のCEOを説得するには材料が足りない
  • 文化が変わるだけの大きな変化になるはず
    • 例えば、QAチームから各開発チームに派遣したら良いのでは？
      • 私の組織ではQAが独立部門にあるわけではない
      • SETIが各開発チームにいる
      • QAと開発者はより密に関わる必要がなる
  • 上層部に自動化を売り込むためには、価値を語れる必要がある。
  • エンジニアの生産性向上を伝えられると良いが、なかなか難しい
  • 具体的に、これだけの金額を節約できる、生産性がこれぐらい上がるという話は難しい
  • コード1行あたり…といったような公式に落とし込むことはできない
  • 今回のカンファレンスでも、そういった主張ができるように研究を薦めて、具体的な数値を示せるようにしていきたい

荻野

  • このような価値を数字で示せるようにしたい
  • ちなみに私は4年前のJaSSTで発表したのでその例を示す。
    • 継続的にテストを行っていると、自動化前後のバグの修正完了日数が短くなったという成果が出た
  • Googleではテストの組織をなくしたほうが良いと言っていたが、ヤフーさんの例を聞きたい。
    • テスト組織をなくしたと聞いているが。

山口

  • QAという職責を持っている人は現在いない
  • リリース速度を早めるために、ゲーティングとしてのQAの価値がないと判断したから
  • リリース権限とともに、チームにテストの責務を持たせるように変えた。
  • テストをする人をなくしたわけではない。
    • 行為としてのテストは残っている
  • チームの中でどうにかするようにしている

荻野

  • QAチームを無くすことに対して混乱は起きたか？

山口

  • 混乱は特に起きていない
  • 開発者が自分が作ったものをテストしないということは無いと思う。
  • なのでやることは変わっていない
  • 重箱の隅をつつくのはやらなくなったと思うが、ビジネスとしてダメージが大きい時に、次の時に何とかする
  • リリース速度を早めたメリットの方が大きかった。

Flakyテスト、保守性など、自動テストの品質特性の課題をソフトウェアエンジニアリングで解決している事例について

荻野

  • テスト自動化するしないで変わることについて
  • テストエンジニアが自動化しているのではなく、エンジニアが自動化をしていると思う。
  • また、自動化でよく出てくるのはメンテナンスの話
  • ソフトウェアエンジニアリングとして解決すべき課題は多いはず
  • 不安定なテストどのように解決していくか

松尾

  • Androidアプリを対象としたテストでは、統一性が無かった
    • 外部での通信もしたり
    • 描画でのテストだったり
    • モックやスタブを利用して、できるだけ最小のテストをしたり
  • Flakyなのは色々な依存関係を持っているところに発生していた
  • 色々な取り組みをしてきた。
    • どのくらいの時間をかけて実行するのかなどをまずは決めた
    • 実際のコードを書き換えて提供した
    • テストサイズやテストのピラミッドを使った説明をした
      • 狭い責任範囲にして高速で回すとか、時間をかけるテストはダメ、とか
  • WEBの場合、色々なサービスが入っていた
    • MSAの風潮に従って、単体の責務に分割するようになっていた
    • 本来の責務だと20分かかるテストは無くて、10分や5分でできるように崩していった
  • あとは、サービス間をどのように保証するかを取り組んでいっている
    • 依存性のあるものを別のテストに置き換えたり
    • 例えば、Facebookログインなら、スタブとかモックとかに置き換えていく
      • ただ、それは内部で依存を持っていないと、外部のログインの仕様が変わったとき、壊れてしまうので注意が必要

山口

  • SETIにあたるような部門が色々頑張ってくれている
    • テストに限った話ではないが、開発環境やDeployなどのツールを開発している
    • CI、CDやその並列化を進めている
  • モバイルアプリについては、Flakyなものがあるのは事実なので、E2E用の環境に順次投入していって、開発部隊とは切り離すようにしている

Micco

  • これはチュートリアルでも紹介したが、責任を明確に分担する必要がある
  • 失敗したテストがFlakyであるという情報も伝えるべき
    • 例えば、テストはサブミットされる前からFlakyである話なので、開発者の責任ではない、とか
  • テストそのものが失敗であったこととインフラが失敗したことを別問題と扱って情報提供するようにしている
  • 重要なのは、適切な人に適切な責任を持たせる
    • そのためにインフラ側にも働きかける

荻野

  • 今の話は痛かった
  • 現在、インフラの問題でFlakyになっていることが多いので…

Micco

  • メジャーな方法は、インフラそのものの不具合をシステムが認識出るようにする。
  • インフラ側の問題だったらリトライを行う
  • 例えばSeleniumで上手くいかなかった場合、Failにするが、インフラ側の問題の場合、Failにはしない

荻野

  • テストの方でもExeptionをしっかり入れることは重要だということですね。

最後に一言

Micco

  • 私はテストの自動化を強く支持しているが、エヴァンジェリストとして困っていることがあれば、是非お手伝いさせてください。
  • 一緒に皆さんのCEOに説得させたいと思う
  • 皆さんにお会いして、皆さんの会社について知れたことを感謝しています

松尾

  • テストの自動化は色々やりたいと思っていると思うが、Deploy回数を増やすのはまずは必要
  • リグレッションという一つの中でも自動化は必要
  • 1人に責任過多にさせると厳しくなる
    • 責務を分割して、テストとか意識しなくても確認できる世界になれば良いと思う
  • 色々話をして楽しかったです。

山口

  • 2人共コメントがかっこいい。ずるい。
  • ヤフーの状態が良いと思っているかもしれないが、それは違うと思う。
    • 何をすると良くなるんだっけ？と考えた結果
      • ゲーティングをなくしたり
      • パイプラインを変えたり
  • 届けるにあたって何をすれば良いのか考えるのがネクストアクション
    • その結果の1つがテストの自動化
  • 弊社の場合はこのようになったが、これがベストではない
  • 何かやらないと変わっていかない
  • 少しでも楽しんで頂けてれば幸いです。

天野

  • 自分はアジャイルを初めてスクラムを投入したが、それは早くユーザーに価値を届けたいと思った結果
  • エンジニアの立場で投入したが、テストをどうにかしたいと考えていた
  • こういう試みが大事だと改めて思った

荻野

  • 私個人はすごい楽しめた
  • ヤフーのように前から自動化していく話とか、サイボウズさんの最近の取り組みとか
  • Googleの取り組みとして、100%の自動化からさらにSKIPしたりとか
  • クックパッドさんがリードタイムが世界一というのも良かったと思う

感想

  • 奇抜なことをやっているのではなく、正攻法を実直に行っていると感じた

  • 「これをやればOK」ではなく、問題は何か、次に何を行えば解決できるのかを常に考えていくことが大切だと感じた

  • 山口さんの以下の想い、すごく伝わりました！

関連記事

  • この記事の中にも随所に出てくる、John Miccoの基調講演やFlakyの話については、別記事にまとめました。そちらもどうぞ。

nihonbuson.hatenadiary.jp

『怒らないからヤバいと思っていること全部言う会』は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人からはじめて、「越境」するチームをつくるまで

しかし、これはコラムの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を勉強してみるのをオススメします。

書籍から学ぶ

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

ソフトウェアプロセス改善手法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

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

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

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