JaSST’2018 に行ってきました!

このエントリーをはてなブックマークに追加

みなさん、こんにちは!
han@QAです。

3月7日~8日開催のJaSST’2018に行ってきましたので、レポートをまとめたいと思います。


「基調講演:Googleのジョン・ミッコ氏による継続的インテグレーションテストの講演」

Google社のリリース前のテストで使っているツール・プロセスの講演でした。
Google社の自動テストは420万個存在し、ソースコード2,3行の改修で全てのテストを実施するのは、時間がかかるため非現実的です。
でもbranchは1つしかありません。
そこで、リグレッションテストはバイナリの依存関係で実施するテストを選別しています。
コードをリポジトリにsubmitした後は、平均して1.5回の別の組み合わせを自動的に自動テストを選別し、実行しているそうです。

Googleのような巨大プロダクトの集合体が、スピーディーにリリースできた理由が少し分かった気がします。
全テストがPASSしなくても、費用対効果があるならばリリースをする、という考え方が斬新な印象を受けました。

Googleでは自動テスト運用でflaky(不安定な、一貫性のないという意味)なテストは、0.2%だそうです。
非常に少ない割合で驚きました。それでもflakyなテストを再実行するとGoogle社のコンピューティングパワーを3%消費するので課題のようです。

弊社でもflakyな自動テストは悩みの種です。
まずは、テスト観点を整理して、下記方式のテストを必要最小限に抑えることが大事かと思いました。

・Selenium WebDriver
・モバイル
・マルチスレッド
現在既に存在するテストを全て変更することはできませんが、新規サービスはもちろん、少しずつ既存のflakyな自動テストを優先して改善していきたいですね。
また、Google社とは状況は違いますが、根拠を示した上でリリース前に全自動テストを実行するのではなく、十分な量の自動テストに絞ってスピーディーにリリースしていきたいと強く感じました。
(レポート:kzhirata)

「計画立案とふりかえりでリスクを捉えよう!~SaPIDTOC:未来予想型チーム運営WS(テスト編)~」

SaPIDという自律型プロセス改善実践手法を使って、プロジェクトのテスト工程を通じて継続的かつ効果的な改善を続けるためのチームマネジメント、リスクマネジメントの手法を体験するセッションでした。
(ほぼ一日使って実施するカリキュラムを2時間半で短縮してやりました。)

SaPIDは、簡単に言うと過去の人間の経験に基づいたプロアクティブに自律的に行動して、プロジェクトを進めていくやり方です。
実際にやってみて、具体的な問題を発見することが非常に難しいです。
具体的な問題というのは、対策として行動に落とし込むことができるレベルまでに問題を分解する必要があります。
また、その問題を放置したら、どんな悪い結果になるのかを書き出すことで、それが本当に問題なのかどうかも認識できます。
このトレーニングは、効果が出るまであきらめずに何度も繰り返し実際のプロジェクトでやる必要があります。

ワークショップを体験して、一番印象に残った言葉は、「リスクマネジメントとは、より大きなリスクを取ることを可能とすること」です。
問題が顕在化する前に対策を打って捻出した工数で、より価値のあるチャレンジをする。少なくても自分が参画するチーム、プロジェクトはそうありたいと感じたワークショップでした。
(レポート:kzhirata)


「コードを書きながら学ぶテスト駆動開発」

テスト駆動開発 (TDD) 第一人者である和田さんのチュートリアルに参加してきました。

TDDサイクル
1.次の目標を考える
2.その目標を示すテストを書く
3.そのテストを実行して失敗させる(Red)
4.目的のコードを書く
5.2.で書いたテストを成功させる(Green)
6.テストが通るままでリファクタリングを行う(Refactor)
7.1.から6.を繰返す

TDDのためのスキル
Todo、問題を小さく分割する
歩幅を調整する
 テスト⇒仮実装⇒三角測量⇒実装
 テスト⇒仮実装⇒実装
 テスト⇒明確な実装
テストの構造化とリファクタリング(重複の除去)

・ハードルを低くして少しずつ初める
・失敗する値を入れて失敗することを確認する return 0;
・期待値を先に書く、細かく考える
・予想通りの失敗はプログラミングの状態はやや良い方だ(前に進めている証拠)
・unitテストではテスト間の依存関係を作ってはいけない
・テストを増やすのは簡単、消すのは簡単ではない、消すにも消せない、テストを作った本人がいないとそのテストの重みをわからない
・不用なテストは用が済んだらその時に消す、数年経ってからだとわからない
⇒動作するコードをリファクタリングすると動かなくなることもある、現場では動くコードに手を入れるなとは噂になるわけです。

デモみながら、TDDとペアプログラミングも体験し、楽しい時間でした。
個人的には開発初心者にテストの大事さをわかってもらえるのに良いものではないかと思いました。
(レポート:han)

「不具合管理⽅法の改善によるテスト⼯程の効率化事例2018」

いつまでにたっても不具合が出続ける。もう少しでおわるはずなのにテスト工程がおわらない。どの現場でもありうるこういった状況を改善したことの話でした。

背景
テスト工程を受託していて、開発プロジェクト毎で人の入れ替わりによって製品知識にばらつき発生している。(テストのためのテスト対象の知識がばらついている。)

課題
不具合修正に対する確認が不十分で不具合が出続け、誤った不具合情報で無駄工数が発生

原因
テスト工程を受託していて、開発プロジェクト毎で人の入れ替わりによって製品知識にばらつき発生している状況でテスト実施

打ち手
・原因分析に基づいて検証
 ・不具合を1つずつ、きっちりクロース
・Q&A管理のDBの運用
 ・不具合以外の現象に無駄工数を使わない
 ・動作が仕様か不具合か困った時にQ&A管理のDBへ起票
 (以前は不具合管理DBへ起票していた)
 ・不具合管理の運用フローを改善
 ・不具合の混入原因分析
 ・類似確認(積極的にソースコードで確認)
 ・不具合原因から類似不具合が潜在している可能性のある機能を全部洗い出す
 ・混入原因から確認範囲を絞りこめないかを検討する
 ・流出原因分析
 ・追加テスト
  ・不具合が本来どの工程で検出すべきかをさかのぼって確認
  ・システムテスト⇒機能テスト⇒単体・結合テスト⇒コードレビュー⇒仕様レビュー
  ・前工程で検出すべきであるものだとわかったときは機能を広げて、類似機能も追加でテスト
・打ち手を回すための工夫
 ・リーダミーティング、品質ミーティング
 
効果
不具合検知を前倒しできた
誤った不具合情報の削減、無駄工数を削減できた

所感
仕様が明確ではないが暗黙的に認めている部分はありがちかと思いました。
そういった不明なところをどう判断して、仕様として明確化するか開発の早い段階で関係者と調整・決定し、テストする再に仕様かどうかの確認のために使っている時間を減らせば、テストにもっと時間を使えて良い結果を出せるのはないかと。
といっても忙しい日々になかなかそうならないのが現実で不明なところへの危機感を持つのが不具合を減らせる1つの道だと改めて思いました。
(レポート:han)

「無料で始める!「龍が如く」を面白くするための高速デバッグログ分析と自動化」

ゲーム「龍が如く」の開発においてデバッグログ解析を有効に使った事例の話でした。 デバッグログをうまく解析すれば、
バグの検出、ゲームの面白さも向上できるのではないかということです。

課題と解決について
まずログを集めて分析する基盤がない。

kibana + fluentd + elasticserchで作った。OSSなので無料でできた。またfluentdがスキーマレスなのでsqlとか詳しくなくても運用できた。
ログの埋め方が開発者によってバラバラでうまく分析できない。

形式をjsonで定義して使ってもらうようにお願いした。しかし使えてもらえなかったので自分で埋めた(!)
ログとして残ったものの意図がわからない。強制移動、レベルMAXなどのデバッグモードで実施したテストなのか、そうじゃないのかがわからない。

オートプレイするツールを作った。これはプレイヤーが操作できる範囲にとどめているので、オートプレイのログであることをわかるようにして収集した。
といういくつもの課題を解決して(さらに継続的に改善させて)、バグの検出率を大きく上げたという結果でした。 また、テストプレイ時のログを収集することによってゲームバランスの調整にも活用でき、より良い製品にできたとのことです。

所感
バグの種類として、メモリやCPUの使いすぎという手動では見つけるのが難しい(再現させるのが難しい)ものがあり、それらのバグを発見できるようになったのはものすごい効果が高いと感じました。また製品のUX向上にも活用したというのは大変興味深い事例だと思いました。
ただ、オートプレイは210台のPCを使っていたという話なので、決して無料ではないと思いました(笑)
(レポート:inomata)

「静的解析とチーム間レビュープロセス」

MathWorks社による静的コード解析ツールPolyspaceの紹介です。

製品特徴など
ソフトウェア開発においてバグは上流で見つけるほどコストは下がります。コードレビューを実施してビルドする前に問題を検出するのは上策(というか当然)ですが、目視によるレビューはやはり限界があります。

Polyspaceは動的テストじゃないと難しいオーバーフローや、使用されないコードの検出も行ってくれるそうです。またMISRA-Cなどのコード規約に則しているかも見てくれるらしいです。

所感
形式にのっとって解析して問題を見つけられるのであれば、やはり自動で行うほうがいいですよね。テストケースなんかも自動でレビューするツールとかあるといいんですが。(その前にテストケースの形式を標準化させる必要があるんですけど)
※MISRA-CとはC言語でコードの品質を保つためのコード規約らしく、これに準拠しないと製品を販売できない(しない)という会社もあるみたいです。知らなかった。
(レポート:inomata)

「Web.JaSST ~ウェブ系QAがみんなのお悩みに全力で提案を返す会~」

Web業界のQAの方々によるパネルセッションです。事前に、あるいは会場からお題を集めて登壇者が回答していく形でした。内容を抜粋してレポートします。

Question
・網羅的にテスト観点を出すにはどうしたらいい?
Answer
・大きい項目をとらえてから詳細化する
・漏れやすいところをテンプレート化してまとめておく
・要件をとらえる。業務知識が必要
・レビューなどコミュニケーションで認識合わせを行う
Question
・バグの分析やメトリクスの収集はやってる?どうやってる?
Answer
・障害情報から分析。再発防止策を確立させるために混入箇所の分析も行っている
・信頼度成長曲線をつくる。それでリリースの目途を立てている
・メトリクスとしてはバグの件数、重要度、機能、人、クラッシュ率、修正までのリードタイム
・バグのリオープンの回数
Question
・QAって給料安くない?適正価格ってどれくらい?どうやったら給料上がる?
Answer
・適正価格なんてない!事業に貢献できるならいくらもらってもいいじゃないか!
・スキルアップして会社にアピール
・求められることを行う(ちゃんと自分のキャリアアップとすりあわせしておく)
・プロジェクトの困りごとを解決して貢献する
Question
・プログラムできるQAを雇いたいけど見つからない(おそらくコードベースの自動テスト・を開発させたいという意図)
Answer
・同じく苦労している。開発エンジニアを募集して口説く。あるいは社内でコンバートする
・マニュアルテストできる人との兼任は、炎上したときマニュアルテスト要因として取られてしまう
・応募してくる人は出来上がったフレームの上で自動テストやりたい人が多い。自動テストのフレーム、インフラから開発する部分はニーズある(これをお願いしたい)
Question
・QAチームの仕事の範囲は?
Answer
・プロジェクトの隙間のタスクを拾っていく ※この質問は登壇者がほぼ同じ意見で、テスト等に限らないでプロジェクトに携わって自分たちで解決できることを積極的に拾っていくという意見でした。
Question
・テスト管理ツールってどうしてる?エクセル最強じゃない?(テストケースの管理という意味だと思われる)
Answer
・エクセルで困ってないならエクセルで十分。エクセル最強。
進捗などのメトリクスをとるためには自動で集計できるツールがあったほうが便利

所感
WebなのでWeb系の自動テストに関連することが多いのかと思っていましたが、テスト、QAという職種全般に言えるような内容でした。
採用の話から伺うに、最近では自動テストもできる人が重宝(というかスタンダード)になりつつあるみたいですね。あとテストケース管理ツールはやはりエクセルで行ってる組織が多いのでしょうか。スタンダードがないというのもありますが。
(レポート:inomata)

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

テスト会社の ベリサーブさんによるセッション
今年は、昨年よりもやや若手といわれる方々が パネリストとして登壇されていました。
良いテストとはどういうテストか、良いテストエンジニアとは、どうメンバーを成長させるか、20年後の自分はどうなっていたいかなどをパネリストの方がはなされていました。 ベリサーブさんはテストの会社なのでテストに対する意欲が高い方が多く層が厚いですね。
(レポート:kmt)

「 組織改善のための PMOのあり⽅と PMOの育成に関して」

テスト会社の ベリサーブさんによるセッション。ベリサーブさんでは、テストだけではなくproject management officeの支援も行っているそうです。
PMOには支援型や窓口型など、いくつか型があり業務は多岐に渡るので、役割と範囲を定義して業務をするとよいとのことでした。
また、育成に関しては広い視野を持って、問題を可視化する為に、まずは図にイメージを描いて学習し、そのあと、必ず実践のトレーニングをする。
この繰り返しをしてトレーニングを積むのがよいとのことでした。
(レポート:kmt)

「 探索的テストにおける ストーリーベースのアプローチ」 

一般的な探索的テストの方法だとテスターとのコミュニケーションが難しい場面があったので、ストーリーベースのアプローチをして不具合検出率が上げられないかといった取り組みでした。
結果として数値に差がなかったとのことでしたが、データを取得した母数やテスターのバックグラウンドを考慮していないのでそのあたりがどういう風に影響したかはちょっとわからないようでした。
本当に最初の取り組みを公開してくださったので、ご自分では内容が薄いといったようなことをおっしゃっていましたが、こういうふうにチャレンジして、試行錯誤するといったような取り組みを公開してくださるのは取り組んだことのない人にもどうやって試行錯誤するものなのかが追体験できてよいのではないかと思いました。
継続的に取り組んでいかれるということだったので、今後の取り組みにも期待しています!
(レポート:kmt)


「「UI⾃動テストツールとAI」 〜AIを使った⾃動テストの 「今」と「未来」〜 」

TRIDENTの伊藤 望さんが、機械学習を活用した自動テストサービスMagic Podの現状の仕組みと今後の展開を紹介してくださいました。
Magic Pod には画面キャプチャだけでテストを作成できる「テスト実行時検索方式」とシステム情報を活用した「テスト作成時検索方式」があり、現状では 「テスト実行時検索方式」だけでは要素の読み取りが厳しいところがあるので 、要素を読み取ったあとに「テスト作成時検索方式」で手直しして使用するのがよいそうです。 テスト実行時にはAppiumスクリプトに変換されて実行されます。
また、「テスト実行時検索方式」の画像の解析にAIを使用しています。AIの学習が意図した通りかというのは正答率でエンジンの性能を測る交差検証という方法を使うそうですが、正答率の数字では気づかないこともあるそうです。その為、MagicPodでは開発中に正答率をみつつ自動化テストケースでリグレッションを繰り返しているとのことでした。
学習データを増やしたことや学習しなおしたら自動テストが失敗する場合もあるそうなのですが、その場合は、間違えたデータを学習データに追加したり、再学習したり、機械学習ロジックの改良をしたりするそうです。ただ、どうしても無理な場合は諦めることもあるようです。機械学習は、厳密さを求めるところに利用するというよりは、タグ付けやリコメンド機能のような不安定さを許容できる機能や、工場の不良品検出のような人間がやっても誤差があるのでそれよりも精度が高いと思われるようなことに利用するのがいいとのことでした。
将来的には人間向けの手動テストケースをAIが理解し自動実行できるようにしたいとのことでした。
(レポート:kmt)

「NGTの記法を応⽤した 不具合分析からのテストの補強」

ベリサーブの吉川 努さんによる事例発表。
テスト開発のための記法として 西 康晴さんが考案したNGT(Notation for Generic Testing)があり、その記法を応用して不具合分析をし、テスト補強をして不具合を発見できたというセッションでした。
記法を応用することで一見関連性のないと思われる不具合を結びつけて、操作パターンを洗い出して、それに対して探索的テストを実施することで、見逃していたであろう不具合を見つけるというのは、簡単そうに見えても実はきちんと考えることができる人でないと難しいのではないかと思います。
これをすることによって、テストの経験があまりない方にもイメージがつきやすくなり、経験がある方とも相互理解が進みやすくなると思いました。
(レポート:kmt)

「「海外のテスト技術動向」 〜カンファレンス、国際会議、 海外テストチームの現場から〜 」

⾠⺒ 敬三さんによる海外テストカンファレンス紹介、yahooの⼭⼝ 鉄平さんによる実際のカンファレンス参加体験、cookpadの松尾和昭さんによる海外テストチームでの現場のお話の3部構成でした。海外テストカンファレンスは、ヨーロッパが多く、アメリカも多いのですが、日本のJSTQBのような団体が世界各国にあるので、Jasstのような感じで様々な国でテストカンファレンスが行われていました。マレーシアやロシア、エストニアなんかは想像がつきましたが、ウルグアイなどでもテストカンファレンスが行われていたり、イスラエルの方主催でオンラインのカンファレンスが開催されていたりするのが聞けて世界は広いなと刺激になりました。また、実際に海外ではどのような雰囲気でどのような内容が話されているのかなと思っていましたが、STARWEST2017とAgileTestingDays2017に参加された山口さんのおかげで雰囲気や目的がそれぞれ違っているのがわかりました。お値段もかなりするので、もし参加することがあれば事前にリサーチして目的をもって参加するのがよさそうですね。
また、cookpadの松尾さんは現在、海外事業部に所属されていてイギリスオフィスからみると日本でリモートしているメンバーとのことでした。
今後こういう働き方もふえていくかもしれませんね。イギリスでの採用も試行錯誤でされていて、そのあたりのお話を聞かせていただけたのは貴重でした。
(レポート:kmt)


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

ソラミツの柴田芳樹さんが、 ご自身の経験をもとに時代毎にどのような開発をして、テストをしてこられたかをお話してくださいました。
特に印象に残っているのが、 1990年代までの夜間ビルドから、2000年以降は継続的インテグレーションの時代、2010年以降は、継続的インテグレーションから継続的デリバリーへと変遷してきたお話で、1990年代にリリースが予定どおりにいかなかったという失敗談から得た教訓がフィードバックループが2週間と長すぎたとお話されていたことです。このような教訓がいろんなところであったからこそアジャイル開発へと続いているのだなと感じました。
また、1990年代までの手作業によるテストから、2000年以降はテスト駆動開発による自動化されたテストがソフトウェア開発の基本だったそうですが、なぜ取り組もうかと思ったかというと、もうそれしか方法がなかったというようなことをおっしゃられていました。ですが、今も自動化されていないところもたくさんあるので、時代とか量が多いとかパターンが多いとかではなくて、いつの時代というよりはやる人の考え方なのかなと思いました。
柴田さんは、「今日ではバージョン管理、継続的インテグレーション、自動テストを実践するのは強みではない。それらを実践しないことがソフトウェア開発組織の「弱み」となる。組織としてそれらの実践を推進しない、あるいはサポートできないマネージャも「弱み」。」という名言をおっしゃっていました。
(レポート:kmt)

「クロージングパネル: アジャイル・⾃動化時代の テストの現場のリアル」

googleの John Miccoさん 、 cybozuの天野祐介さん 、 cookpadの 松尾和昭さん 、yahooの⼭⼝鉄平さんがパネリストでした。
基調講演でもお話されていましたが、 googleは、莫大な数のテストを莫大なコンピューターリソースを使ってテストするのが厳しくなってきているので、分析をしていかに関係あるテストだけを実行するかに注力しているとのことでした。その他の会社の方は、製品の数だったり、組織の規模感だったり、各々の考え方でそこまでではありませんが、どの企業も自動化は当たり前にされていました。
cybozuは、1年くらい前からアジャイルをはじめたそうですが、以前よりも開発スピードが上がって、最後のイテレーションに改善活動がいれられるようになったとのことでした。1年くらいで成果が出せるのは、何か困難やトラブルがあっても、チームメンバーがお互い助け合うという文化が共通認識としてあるのが大きそうでした。
cookpadは、webのほうでは、修正してテストして本番にデプロイされるまでが20分程度ということで、googleのJohnMiccoさんもgoogleより早い!とおっしゃってました。
yahooではQAという職責はなくなったそうですが、チームとして品質に責務をもっているとのこと。googleもそうですが、アジャイル開発をして、リリースまでのスピードアップを目指すようになると自然とそういう形になってくるなと感じました。
(レポート:kmt)

いかがでしたでしょうか?

今回も各会場でテストに関わる取り組みについて、様々な話を聞くことができました。
様々の事情の中で品質向上のためにやっている施策や努力した話しを聞くと、自分ももっと頑張らなきゃと向上心上がりますよね!
品質に関わる業務をやっておられる方はもちろん、テストのことをもっと知りたい開発エンジニアにとっても、本当に良いイベントなので、行ったことの無い方はぜひ参加してみてください。

それでは!

次の記事
« Prev Post
前の記事
Next Post »
Related Posts Plugin for WordPress, Blogger...