開催概要
- 日時
2015-12-13（日）09:30 - 18:15 - 場所
東京都港区赤坂9-7-1 ミッドタウン・タワー - 詳細URL
https://4deb81d081862e256eb240be7c.doorkeeper.jp/events/34145
システムテスト
うまくいくことはない
スキル知識不足が大半だと思うエンジニアが多い
- テストエンジニアのキャリアだとプログラミング知識が不足しがち？
戦略不足
- テストプロセスが確率されていない
- ダメなところが自動化されて意味が無い
セッション内容
テスト自動化スキルを考えよう
テストに必要なスキルは現在策定中
テスト自動化スキルの種類
- 管理
- 戦略
- 開発
- 実行
管理
すべてのテスト自動化のベースとなるスキル。
やることは自動化の推進と維持。
要求を明確化して、各テストエンジニアにインプットしたり、技術を分析して適用範囲や方法を考えて効率良くサイクルを回す仕組みを考えるのがお仕事。
- トレーニング(教育)
- テストライフサイクル策定(計画の立案・策定)
- テストの予測・計測
開発
テスト実行プロセスの設計〜開発
テストを実現させるものを作るのがお仕事。
言ってしまえば、テスト対象のシステムとは別のシステムを作るようなもの。
テスト自動化しても工数が減らないのはここからくる気がする。
実行
レポーティングを行う。
テスト対象に開発したテストを行い、結果を残す。
これからさらに必要と思われるもの
SBST
テストケース探索アルゴリズム
結果分析
テスト実行結果を元に、ソースが悪いのか環境起因(テストデータが悪いなど)のか判断して、自己修復させる。
自動家は見た
ノリが芸人っぽい。。。
関西の人ってみんなこうなの？
勉強会で関西の人と公演聞くとみんな茶番とか入れたがる。
自動化の進め方
- プロダクトの構造把握
- テスト準備(テストデータ生成、テストプログラム準備)
- CI環境の構成 ビルドからデプロイまでの道筋を確保するのがメイン
自動化が廃れないもの
デベロッパーとクライアント(マネージャー)が両方とも望むもの＝風化しない
片方もしくは、両方望まないものの自動化は、すぐに風化する。
自動化とマネージャーの付き合い方
- あきらめる
- 自動化のメリットを説明する
マネージャーの開発の考え方
リリースの分配(人の配置)≒投資
投資した結果の成果物がマネージャーの評価に一番関わる。
出力が増える＝マネージャーの能力が向上したからだと判断される＆交渉材料に使える。
今までの経験則からモノを言うのがマネージャー。
因果関係が理解できない意見は通らない。
通そうと思ったら数字を使って、因果関係を論的に説明されるのが一番効果的。
つまり、マネージャーには論理攻撃が「こうかはばつぐんだ！」
広告システム刷新 よもやま話
求めていたものと違った。。。
自動化の話ではなく、開発の話になっていた気がする。
聞いているのがきつくなったので、スピーカーには悪いが、寝落ち。
楽天の品質を改善するパターン
スライドURL http://sssslide.com/www.slideshare.net/kotaroogino/2015-stac2015
成長しないサービスはいずれ廃れるため、サービスは成長する必要がある。
テストも同じく、サービスと共に成長する必要がある。
成長するテストは、以下の特性を持つ必要がある
- 高信頼性
- 継続的
- 高生産性
上記条件を満たすシステムテストを継続的システムテストとする。
継続性
やること・目的
テストの品質可視化をする。
日々コミットして素早く対応するのが目的
可視化のためにメトリックをとる＝結果が数字で見える
- 管理者の説得に使える
- 成果がわかるのでやる気が上がる。どうやっていけばいいかわかるので露頭に迷わないで済む。
簡易的なレポーティングを必ずできるようにする。
いつでもテスト価値が見えると管理職が満足してくれる。
生産性と自動テスト
フィードバックは常に見えるような形にする。
障害が発生したら即対応。技術負債はなるべく早いうちに解消しておくと生産性も上がっていく。
後半で対応するのはコストも高く、スケジュールも買えられないため、めんどくさい。(俺の意見)
貯金箱に例えて説明していた。
- ブタさん貯金箱(中が見えなくて、割らないと結果がみえない)
一回テスト作ったらそのまま。テスト足らなかったら、すべて壊して一から作り直す！(男前！) - 貯金額が見える貯金ば後
テストしたら結果がすぐ見える都度都度テスト追加できる。
プロダクトと自動テスト
自動テストは２つ目のシステムではない。
自動テストのためのコンポーネントを踏まえたうえで、サービスを検討する。
要件としてテストのタイミングを入れるとサービス展開の戦略を考えている人がテスト戦略も意識するので、効果的なテストが実施できる。
例えば、リリースを月１でやるから、自動の実行のタイミングはその１周間前にしてバグの蓄積量を把握してリリース時期の判断するとか。
自動テストと品質
テストを自動化しても品質が向上しないのは、人が悪い。
テスト自動化がもたらすのはテスト実行の時間の短縮で、品質の確保はしてくれない。
品質の確保は人間の役割。
感想
アジャイル４現象とかの話は資料が見えなくて、イマイチ分からんかった。
要するに、行き当たりばったりなテストはやめないと、品質向上の意味ない。
ちゃんと計画的にすべし。みたいな締めだった。
最後に新入社員に自動化をやらしたら案外すんなり対応して驚いたみたいな話があった。
規定概念が少ない分、吸収が早いのだと思った。
案外、無知な人に、今抱えている問題を聞くと解決するものなのかも知れないと感じた。
プロダクトの中に自動化やテストの要素を入れて、要件の段階から考えだすのは良いアイデアでした。
自動化はどうしても別システム的な位置づけになってしまうので、要件から踏まえた状態で開発をすれば効率化に繋がる気がします。
キーワード駆動によるシステムテストの自動化について
キーワード駆動とは
テストの挙動も外部ファイルに記載する。
操作内容はキーワードで挙動がきまるため、キーワード駆動と言われる。
データ駆動と比べて
結局はプログラマー以外でもテストケース作れるしかメリットない気がしました。
コードに回収入ればどっちにもテスト用にプログラミング必要で、改修しなくても対応できるには疑問が残りました。
ロジックが外部ファイルになるので、それのメンテコストがデータ駆動より高い気がします。
アーキテクチャについて
制約ないアーキテクチャは何もできない。なぜならルールを強制できないから。
アーキテクチャは本来ルールを使用する人に強制するもので、制約ないアーキテクチャは本来の目的から逸脱している。
感想
アーキテクチャの話は同意するが、キーワード駆動が優れているかは疑問。
適材適所で使うのを選ぶべきと言っていたが、データ駆動がメリット多い気がする。
そう感じるのは、自分がプログラマーだからだろうか？
Testing Tools for Mobile App
スライドURL
http://www.slideshare.net/KazuMatsu/20151213-system-test-automation-conference
モバイルの開発事情
変化スピードが早い
開発手法もそれに変化スピードに合わせるため高速化
- 繰り返し
- 継続的改善
- 高頻度リリース
速さを求めるので、いろいろなリスクと戦う必要が出てくる。
- コードの肥大化
サービスが成長してきて、ビルドの時間が長くなる - アプリのデプロイリスク
- リジェクトリスク
Appleの審査待ちの間にポリシー変わったからダメとか。 - ダウンロードできないリスク
- アプリ評価のビジネス影響
出だしでバグがあると評価が悪くなり、ビジネスへのインパクト大。しかも初期が悪いと上がりづらい。
リスクへの対応で必要とされるもの
- 安定したリリース
- 内部障害対応
リリース前後の不具合解消
- 外部障害対応
Apple/Googleなどの外部サービスの障害対応
開発の変化
OSの変化
iOS
- 年１の大規模更新
- 開発環境の変更(後方互換なしの破壊的変更もある)
Android
- 年１の大規模更新
- 開発環境の変更(細かいバージョンアップが頻発)
変化が激しく、開発は必然的に即時対応されている標準ツールになってしまう。
変化から逃れられず、強制される。
開発環境の変化
iOS
Andoroid
- eclipse → Andoroid Studio
Flakyなテスト(信用出来ないテスト)を減らすためのTips
- 閉じた環境を作る。
Mock/Stubなどで環境作る - DI
- テストごとのゆらぎ(比較しにくいもの)を減らす。
アニメーションOFFとか
テストエンジニアの役割とは
- 開発サイクルを安定・円滑にするのが仕事
- リリース後の障害抑制
- 組織的な改善を続けるための支援
課題とこれから
- 知識の共有
- 結果のフィードバック範囲の拡大
- サーバーとの強調
感想
リーン開発で高速なテストを回すのはサーバー側も同じだが、アプリは更に環境面で辛いイメージが浮かんだ。
外部起因のリスクが多い気がする。
その対応にもスピードが求められるから、いろんな意味できつい開発環境な印象を受けた。
Appleの申請承認待ちにポリシー変更されて、通らなかったはヒドい。。。
手動では対応しきれないので、自動化を推進しなくてもそうせざるを得ない状況なのかと思った。
パネルディスカッション
結構どうでも良かった。
やたらとカナリアリリースをプッシュしていた印象がある。
IoTの出現により、自動化の立ち位置は変わらないと思うが、原因の切り分けの自動化など他分野でも自動化は推し進めるられるような予想があった。
手動化自動化の判断基準は、スピーカー陣もケースバイケースで一概に言えないが、判断が容易化できるなら自動化、そうでないなら手動でやるしかないような意見が全員の見解のようだった。
全体感想
自動化はやはり範囲の選定が問題だと思いました。
今後、範囲が拡大してスピードがもっと求められる気がしました。
強化学習もそうですが、自己判定・自己修復機能ができるようになると更にテスト自動化のスピードが加速しそうです。
早めに、現在のテスト自動化事情をキャッチアップして、来る時代に備えたいです。
遊戯王のアニメを犠牲にして行ったが、新しい概念に触れたことは収穫。
あと、モバイル関連の現状を知れたのはありがたかった。
帰って録画しておいたのを見たが、ユーリの登場は鳥肌が立ったわ。。。
*1:一部ユーザのみ新環境に移行し、問題があれば切り戻す。ブルー・グリーン・デプロイとも言う。
