connpass
https://testautomationresearch.connpass.com/event/144768/
場所は渋谷ヒカリエにある株式会社ディー・エヌ・エーです。
渋谷ヒカリエと言えば、CHAOS;CHILDの最終決戦の聖地ですね。
STEINS;GATEもいいけど、CHAOS;CHILDも名作だと思うのですよ。
それはさておき、この日は秋晴れの快晴。品川区の自宅から自転車で渋谷に向かいました。
ヒカリエ行く前に、同じ渋谷区にある明治神宮に寄ってみました。素晴らしい神社ですな～
システムテスト自動化カンファレンス2019の前に、自転車で明治神宮へ寄ってきた。いいお天気～https://t.co/nZTb2fKtkU#stac2019 pic.twitter.com/BFIOd5V1wO
— makopi23 (@makopi23) November 30, 2019
今回の申し込み時に回答したアンケートの集計結果が公開されてます。
STAC2019_アンケート集計
あと、当日のセッション動画も公開されてます。
https://testautomationresearch.connpass.com/event/144768/presentation/
以下、聴講メモ。
AIを活用した交通事故削減サービスのテスト自動化
Googleの論文: Hidden Technical Debt in Machine Learning Systems
・AIシステムは技術負債を生みやすい
・データ集をめる、特徴量を集める、データ正確性、独特のクラスタを組む、マネジメント、推論のアーキテクチャとか、作る必要がある
・これらの品質を考えないと負債を生む
伝統的なソフトウェア開発フロー
・ユーザーストーリー→コードを書く、PR→・・・
機械学習のフロー
・機械学習のフローはぜんぜん違う
・まずは何ともあれデータ
・前処理が必要
・データ量がデカイ
・データサイエンティストがデータをローカルやクラウドでモデル開発
・開発がある程度できたらクラスタで長い時間かけた実験をする
・実験結果のレビューはJupyter Notebookを使う
・確認してもらって大丈夫ならモデルをピックルしてデプロイ
・専用のAPI立てたりしてサービングする
・実際のアプリと結合してリリースして
・実際のモデルの精度をモニタリングしていく
MLOps
・注目している
・DevOpsのML版
・開発者とデータサイエンティストが一緒に良い仕事すすめていくためのフレームワーク
・データやモデルのバージョニングは、コードのバージョニングとぜんぜん違う
・記録して比較できるようにしておく。パラメータの記録や再現性
学習データやモデルがでかくてGitに乗らない
→ クラウドストレージに置いたりする
・CI/CDは前処理を自動化したり、デプロイも極力自動化する
・モデルの再学習も自動化
AIプロダクト品質保証ガイドライン
・http://www.qa4ai.jp/QA4AI.Guideline.201905.pdf
・AIの品質保証技術は確立されてない
・５つの軸が提示されている
・Process Agilityは、プロセスが機動性あること（方向転換がすぐできるプロセスであること）
・Customer Expectationは、顧客との期待値調整。AIがなんでも解決してくれると顧客に誤解されないように調整するとか。
テスト条件を洗い出してみる
・カメラ位置、シート角度、性別、年齢、人種、眼鏡、サングラス、化粧、車種、高速道路、坂道、いっぱいある
→ ホント全部テストするのか？
テストケース再考
・特に注意してテストやるのはエッジのレアケース
・エッジケースは意識して集めないと集まらない
・でも現実世界のすべて事象カバーするのは不可能
・false positive/false negativeの影響を考える
・テストやろうと思えばどこまでもできちゃうけど、無理なので、過剰品質にならないよう関係者間で合意とっておくの重要
Q.
システムテストはどこまでやってるか
アーキテクチャやテスト容易性とか考えないといけない
A.
レポートラインは完全に分離してる
AIを作ってるチームと車載器チームは分離してる
本当は結合してしっかりやっていく必要あるかな
EM×QA視点で進めるテスト自動化への取り組み
まずEMとして考えた事
２．運用面
・開発フロー ・・・ どこで自動化するか
・運用メンテナンス
・育成 ・・・ 現場全員がテストコードを書いていけるように
QAとして考えた事
・品質を上げる、が前提にある
・スピードも上げていきたい。QA工程のスピードも上げたい。
・コストはできるだけかけたくない
・つまり、QA視点でいくと、ビジネス的な重要機能に絞る。
・テスト観点をベースとして自動化 → 自動化したものが何を担保できているのか説明できるようにしたい
・サービスの重要機能を洗い出してから進める。役員レベルと経営レベルですり合わせる。
・そこから上がってきたものに、テスト観点を洗い出す。
・それをテスト自動化で進めていく。これはEMが進めていく。
・QAとEMは、このような役割分担にしてる。
テスト自動化の導入はビジネスリスクを軸に
・EMとQAの視点の違いがあれば、両方の視点をもってることで導入はスムーズに進められると思っている。
Serverless automation UI testing by using AWS Fargate
テスト自動化プロジェクトを支える技術と仕組み
テスト自動化の8原則
・それ以外にもナレッジが蓄積されてきた
・一方で、やったことない人に見せると、所見の人は活かしきれない
・書いてある失敗をまんまちゃっちゃう
それだけでは不十分なことがわかってきた
具体的な仕組み化が必要なのでは。
施策
１．テスト自動化プロジェクトガイドライン策定
２．プロセス定義
３．ロールとスキル定義
４．社内教育
テスト自動化プロジェクトガイドライン
自社でテスト自動化プロジェクトを行う際に参照
ISTQBのシラバスなどを参照
標準プロセスを設定した
どのプロジェクトにもばちっと当てはまるというより、
ある程度あてはまるがテーラリングして使っていくもの
テスト自動化エンジニアのロールとスキルの定義をやった
どんなスキルを持ったエンジニアがいればいいのかわらかない
テスト自動化ができる、って何？
明示してあげないと、学習する側もわからない
なのでそれらを明らかにした
ロールは５つ
１．自動テストシステムアーキテクト
２．自動テストプロジェクトマネージャ
３．テスト自動化プランナー
最初のヒアリングとか本当にやりたいことを明らかにするところから入ってトライアルを担う
４．自動テストシステム運用エンジニア
５．テスト自動化エンジニア
５つのロールが綺麗に分かれるかと言うとそうじゃないことがある
社員教育
テスト自動化関連研修を毎週開催
数日～数週間の自動テスト集中トレーニング
まとめ
いろいろ策定して教育を強化した
社内の横連携とスキルアップにつながった
q.
どのくらいの人数を３つの上のロール育てられるのか
何人いるの
a
目標値は、現場常駐のチームの数、どのチームにもそれらの人がいるようにしたい
なので５０－１００
q.
現場のお客さん先に運用まで回してもらうか
お客さんに引き継ぐという工夫あるか
a.
ドキュメンテーションを実装や設計からやっていく
誰が引き継ぐかによるが、開発チームの一部がメンテ引き継ぐ場合は、開発と、メンテする人が読みやすいもの残す
q
自動化やるやらないの判断かなり重要
もうすこし詳しく
a.
リスクと自動化のしやすさの両方を加味してマトリクスつくってピックアップしていく
まずハッピーパスからしましょう、は提案する
テスト自動化はやってみないとわからないところある
着手前にきめれないのでまずハッピーパスからやって、やるやらないを決めていく
会社レベルの「テスト自動化普及」ミッションに立ち向かう話
自動テストが当然となる環境や時代への危機感
競争力の低下、
お客さんからも自動化を言われる
テストにフォーカスできないことへの危機感
テストを会社で軽視する傾向に危機感を感じる
品質に言及するのにテストを軽視する
見解
それぞれのｐｊでノウハウはあるが、手動でテストしてなんかあったら人海戦術でのりきって、自動テストできてない
テストは新人にやらせたり、外注に丸投げしたり、テスト技術について皆ほとんど知らない
1年前に調査した 技術会議
これからのテストを会議で考える 500人くらい
１．テストを取り巻く環境が変わってきたか
大きく変化１５％
一部変わった４７％
２．テスト手法・技術変化
自動テストやってるか
１．自動高 ４％
２．自動 １９％
３．手動 ７７％
アンケート書いてもらったらぎっしり書いてくれた 250人くらい
わかったこと
１．自動テストできない理由
人がいない
難しい
コストが見込めない
外注がテストやってるので外注次第
できるようにする
文化やマインドを変える
現場に代わってもらう
２．ちゃんと知らない
自動テストけっこうやってる
ただし、レベルの幅は広そう
互いに良く知らないといけないなぁ
でも、情報は自然には集まらない
意思と手段が必要
そもそもテストの情報が少ない
調べても、みんなが興味ないと知らせる相手がいない
３．普及って何だろう？
どんなテストやればいい？
どんくらいやったら普及なの？
決めないといけないけど決めきれない
ゴールを決めて計測する
・普及の定義
・計測の方法や数字が難しい
・kpi決めて数字だしてもはら落ちしない予感
経営層から、本当？とかそれだけ？とか言われる
計測大事
★何を計測するか
１．自動テストの実施率
テストタイプや手段は分けたほうがいい
ut, e2e, 性能など、分ける
テストツールの利用率しらべるのもいい
教育受講率
状況の変化
事例の増加、テスト組織や取り組みの立ち上がり
★どう計測するか
普及の計測が目的ではなく、効果を計測しないといけない
でも、普及率を報告しても、へー、で終わる
効果がどれだけあったといわないといけない
活動の価値の表示
普及活動の存続がかかってる
売り上げもってないので、なんかあると、やめたら？となる
存続をかけるためにひらきなおってはいけない
やめますよ、とか言わない。
説明責任がある。こういう効果があった、とか
自分たちのモチベーション大事
怒ってはいけない
おすすめ施策３つ
１．ツールを定める、いっそ作る
２．教育早めに
３．事例は作ってからが本番
１．ツール
テストツール作ってる
作らなくてもツール定めたほうがいいかな
それを布教、サポート、教育やっていく
それやらないとどこからやっていいかわからない
KPI
ツールの利用率
DL数、購入数
実際に使ってるのか調べる方法がいる。DL数と一致しない。
２．ツールを定める、いっそ作る
数字がとりやすい＆わかりやすい
社内ツールの要求高い
社内だと、ツールがなくなる、とか資産つかえなくなることない
テストツール統一の話にならないようにする
ほかのツールに目を光らせて、ツールの違いとか説明できるようにする。
本当に使ってるかを計測できる方法が必要。
DL数だと、DLしても使ってる数は少ないので。
３．教育は早めに
ライブ配信でやってる
KPI
開催数、受講者数 でも、伸びても響かない
アンケート取れることが価値
継続開催が大事。
需要があるからやってる、継続してやってること言わないといけない
教育は重要、と号令かかりやすい
教育参加はハードル低い
アンケートを継続で取りやすい
気を付けること
直接的な効果が見えない
コストがかかってないように見せる工夫
教育をメインの施策にしないようにしたほうがいい
なるべく無償。集客第一。
４．事例
自動化してるプロジェクトにヒヤリング
事例発表会
事例はみんなほしがる
普及活動の価値を数字以外で表現できる
事例対象のプロジェクト探しはアンテナ張り続ける
自動テストの効果をコスト改善と言わない工夫
コスト改善しない自動化ダメと言われちゃう
自動化、という言葉はよくない
コスト改善より、同じ期間でテスト増えて網羅率あがったとかのほうが大きい
コスト改善よりももっと深く
活動スケールを広げすぎると嘘っぽくなる
数じゃなくてセグメントを広げる
ポイント
重要案件の事例に組み込む
品質保証部門で重視される
会社の外堀から埋めていく
Karateによる開発プロセス改善の事例と、Zipkinと連携したマイクロサービスの障害点検知の仕組み
テストを書く＝みんながハッピーな状態にしよう
APIテストしてもらえない問題
画面があるものが管轄、というのがある。
APIは、画面があるプロダクトのQAで間接的にテストされがち
APIに対して十分なパターンのテストができてないことがある
画面がないプロダクトがある
画面がないとテストしてくれない
なのでDeveloperが動作確認する。
すると自動化したほうがよくない？
APIテストのメンテ大変問題
どうやってAPIをテストするか
Karate普及活動
開発チームとSETがテスト一緒に書く
テストは開発チームが書く
開発チーム自身がテストできるように
最初の10ケースはSETが作成
次の20件は開発チームがテスト作ってSETがレビュー
そっからは開発チームがテスト作る
Karateが品質を上げるわけではない
品質を上げるためのDeveloperの行動を促す
社内勉強会
参加者が実際に開発してるAPIのテストを実際に書いてお土産を持たせる
サンプル実装を用意する
分散トレーシング
複数のサービスに跨る処理を分析する仕組み
エンタープライズ領域へのテスト効率化推進
導入期
身近なテストを自動化する、を目的とする
excelで書くの面倒
だったら、つくちゃえ、が多い（テスト業界）
社内検索サイトのトップに表示されるようにした。
1位になった
自動化、っていう言葉アブナイ
何でもできる魔法のツールと誤解される
テスト自動化リテラシーの向上がないといろんな誤解をまねいて、いいものがあるのに使うことができない
AI自動テストツール導入と発生課題
LT大会
Karate による UI Test Automation 革命
Seleniumに疲れたら、TestCafeで一休みしていきませんか
フロントエンドの自動テストって何をすればよいの？
ノンプログラミングでゆくテスト自動化の道@ユーザ系Sier
- 関連記事
-
- 自転車で京都と奈良と和歌山の旅 1日目
- 「システムテスト自動化カンファレンス2019」に参加しました
- 「Agile Testing Night #1」に参加しました
