いもろぐ

思い立ったら書いていくスタイルで

Ques#7 メモと感想

2015/11/20(金)に六本木のヤフー株式会社で行われたQues#7のメモ。

第7回Ques : ATND

私の感想

会の全体の雰囲気として、とても良かったと思います。山崎さんの講義の中に、ワークとその結果について周囲の人とのディスカッションがあったからかな。会場の集中力が高かった気がしました。

ヤフーでのテスト支援チーム(正式名称じゃなかったらごめんなさい)の話ですが、現実として「開発チームが品質で困っている」という状況があり、「今のやり方じゃダメだ」と開発者が実感しているという状況がテストの自動化推進のポイントだと思いました。

青野さんの話もE2Eテストの自動化(画面からユーザー操作のシミュレート)でしたが、本来のアジャイル、スクラムで言えば「ホワイトボックステストの自動化」が必要なわけで、ここらへんの導入・推進も気になりました。私のイメージですが、ホワイトボックステスト(つまりユニットテストというか、TDDというか、開発者が自分のためにコードで書くテスト)の導入って、結局は開発者自身が行うことなので、「支援」って難しいんだろうなと思っているところだからです。

にしても、100サービスあって支援チームが5,6人で、(全部のサービスを支援しているわけではないにしても)支援出来るだけの知識とスキルと「ガッツ」がないと実現できませんよね。。。

ベリサーブ山崎さんの「テスト分析」の話はとてもわかり易かったです。あぁ、そういうことだったのね、って思ったです。ただ、JSTQBの定義でもそうですがテストベースとしての「ドキュメント」がスタートになる一連の(分析→設計→実装...)行動なわけで、スタートアップ的なWebサービス開発(往々にしてドキュメントの作成とメンテが重荷になる)には適さないアプローチだなとも思いました。(思いましたというか前から感じてはいるのですが...)

「今の組織、チームで問題が起こっていないのであれば(プロセスをガラッと変えるようなことは)必要はない」みたいなことを話されていたのが印象的。個別の課題に対応することでOKならそれでいいよね、と。そりゃそうだよね。で、疑問に思ったのは、ということは今後のため、とか、未来を良くするため、という活動はどうなるのかな、ってのは気になりました。

(※以下、講演を聞きながらメモったので抜け漏れがあるかもしれないのと、私の言葉に置き換えているところもあるので、正しくは本人の資料を参照ください)

アジャイルとテスト自動化

登壇者：ヤフー山口さん

www.slideshare.net

チーム自らがテスト。テストだけやる人はいない。チームで決める。リリース権限はチームにある。

取り組んでいるテスト自動化

頻繁にテスト、はしんどい。それを自動化して楽する。
モバイル、Web、バックエンド(←これも頻繁にリリースしている)
全員でテストすることで品質を理解することができる

ヤフオクアプリでのテスト自動化事例紹介

登壇者：ヤフー青野さん

www.slideshare.net

自動テスト導入経緯

2015年4月ごろ、特定画面で100%クラッシュとか、古い端末、OSで100%クラッシュがリリース後に発覚。

当時は開発者＋リリース前にみんなで確認。リリースは隔週。リリース時に全機能は確認できない。

Androidアプリ

  • 不具合修正→すぐ修正版リリース
  • 段階的公開機能あり→影響小さい

iPhoneアプリ

  • アップル審査が必要→時間がかかる
  • 致命的

テスト支援チームからテスト自動化しませんか？を提案
社内サービスを横断的に支援している
開発チームが支援チームに協力してもらう形

導入時ノウハウ

解決したいこと

  • iOSにフォーカス
  • 致命的なクラッシュは事前に検知
  • 主要画面もうら
  • 古いOS
  • iOS9対応に間に合う

ツールの選択

  • テスト支援チームで知見がある 結果→Appium

選択理由

  • OSS更新頻度が高い
  • 企業サポートも付いている
  • ライセンスがつかいやすい
  • クライアントが複数言語ある
  • GUIツールがわかりやすい
  • iOS,Andoroidに対応
  • テスト対象に手を加える必要が無い

テストコードを何で書くか

  • Pythonを選んだ
  • 経験者多い。誰が書いても読みやすい

対象画面

  • 主要機能の画面から優先度をつける

実行概要

  • macにgitからclone
  • スクショをとってファイルサーバーに置く
  • (メモれなかった)

苦労話

  • appium不安定　UI要素が取得できない
  • 処理の同期が取れない
  • デバッグに時間がかかる
  • アプリのUIにidが振られていない→xpath
  • 画面修正でxpathが変わる
  • pythonのunitテストドキュメントが少ない
  • 結局appiumサーバー、unit testのフレームワークをつくった
  • iOS9からxpath構造が変わった
  • appium自体のiOS対応が遅れた

導入の効果（半年くらい取り組んだ）　

解決したかったこと

  • iOSにフォーカス → OK
  • 致命的なクラッシュは事前に検知 → OK
  • 主要画面網羅 → OK　(全画面の約９割をカバー)
  • 古いOS → できてない(サポート対象内だがiOS7ができていない→手動でカバー)
  • iOS9対応に間に合う → OK

やってよかった。

運用

  • 毎日１回定期実行
  • 開発用ブランチが対象。リリース前はリリース用ブランチでやる
  • 失敗したらすぐ調査、プロダクトバックログに積んでスプリントで対応

今後の予定

  • CIツールとの連携
  • 自動テストのバリエーション
  • 任意のタイミング
  • 処理の高速、並列化
  • アンドロイド対応

まとめ

  • 支援という形で背中をおされた (←ここ、サラッと言ってるけど開発チームと支援チームでいい関係ができてるんだろうなと思った)
  • 形になるまで試行錯誤
  • 毎日自動テストが実行される＝安心
  • より恩恵を受けるための作業はまだある
  • (他社でも)導入ネタに使ってほしい

Q&A

Q：自動化で見る観点。何を確認しているか。画面遷移が正しいか？　例えば検索機能では、検索結果が正しいかの確認は？
A：画面遷移は見ている。検索については特定キーワードはみているが、検索結果件数とかはみてない。

Q：(テスト工数の)削減効果　(←メモしきれませんでした)
A：手動はまだ残っている

Q：チーム全員で品質を、とのことだが、意識は高かったのか
A：チームのメンバーは導入の方向は賛成だった。協力してくれている。１週間１スプリント。不具合修正は割込みタスクとして考えている。(スプリント内に収まる工数として)

Q：半年かけてやった人数
A：支援チーム2人、開発チーム1人、週一回集中して活動する。がっつりやったら一ヶ月で終わる

Q：1回のテストでどれくらいのテストがどれくらいの時間で完了するのか
A：スクショ取ると２，３時間。スクショなしで１時間くらいで終わる。

Q：支援チームがやることは？
A：必要に応じてやれることをやる。100サービスあって、全部には入れないので、極力やりかたを教えて自立してもらう

Q：支援チームは何人？
A：５，６人

概説テスト分析

登壇者：ベリサーブ山崎さん

(多分資料がアップされるハズ)

www.slideshare.net

「テスト分析」って何？どうやって説明すればいいの？

仕様書からテストケースを導出する → これは失敗フラグ

デキる人は脳内で何かが補完されている。

(スライドのP16参照)
テストベースをもとに
↓
テスト分析をして
↓
テスト条件を導出
↓
テスト設計(効果的にテストをするため)
↓
テストケースを導出
↓
テスト実装　何をテストするか
↓
テスト手順/スクリプトを導出
↓
テスト実行　作ったものを動くかどうか確認する行為

JSTQB AL「テストマネージャ」「テストアナリスト」のシラバスからわかることは、テスト分析とは、テストベースを分析して「テスト条件」を導出する作業

では「テスト条件」って何？

例)
・PWは４文字以上１２文字以下の英数字のみ許容する
・PWを３分以内に連続して４回以上間違うと、アカウント５分間ロックする

この場合、

  • 文字列長
  • 文字種
  • 誤入力期間、回数
  • アカウントの状態（ロックか、正常か）

みたいのが「テスト条件」。表現の仕方はいろいろあるけど一例として階層構造にすると

スライドP27より

f:id:sakaimo:20151123001714p:plain

この場合、「セキュリティ」も「文字種」もテスト条件だが、粒度が違う。

テスト分析のメリット

  • 欠陥の早期摘出
  • テスト対象への理解
  • テスト容易性の判断　←ここ大事。ミリ秒まで精度が求められるなら手動テストじゃ無理だよね、とかを事前に把握・共有しておく。

テスト分析の仕方(例)

  1. テストベースを3色で書き込む、読み込む、洗い出す
  2. マインドマップで思考の発散と集約
  3. ガイドとして「テスト分析の三角形」をつかう

分析結果は人によって異なる

これは大前提。一意的には決まらない。つまり「ゆらぎがある」。例えばエライ人がテスト担当者に任せておしまい、だと結果も(期待値と結果が)ブレる

だから重要なのは分析結果をレビューして、ステークホルダーとコンセンサスを得ておくこと。どんなテストをやるのか。

テスト分析を方法論化すると→出力形式が共通化できる→レビューが容易になる→テストノウハウとして蓄積できる →形式知となり組織に展開できる

方法論

  • HAYST法(ラルフチャート)
  • VSteP(NGT)
  • ゆもつよメソッド(論理的機能構造)

Q&A

Q：仕様書がない、あいまいな場合、要件は曖昧でコードはある場合、テストベースはコード。。。？
A：いい加減な仕様だと、いい加減な分析しかでない。ステークホルダーがどこまでやれば安心できるか（自分もエンジニアもそうじゃない人も）でどこまでやるか絞る

Q：どういう範囲で分析をするか。システム全体？何らかの基準で一部？
A：状況による。担保したい部分はどこか。(機能ごとで分割するとか)

Q：分割する、ということもテスト分析では？
A：その通り。システムを分割できることも分析の結果。粒度を細かくすればするほど工数がかかる。そこまでしなければ設計できないのか？