読者です 読者をやめる 読者になる 読者になる

MasaoApril's Library.

Software Testingなネタを書いてみた。

システムテスト自動化カンファレンス2015(7)「Testing Tools for Mobile App」

 2015/12/13(日)にテスト自動化研究会(STAR)主催のシステムテスト自動化カンファレンス2015に参加しました。
 本blogでは、聴講したセッションから数回に分け、メモとしてまとめたものを紹介します。

セッション

 講演内容は、下記セッションです。
(※<資料>にリンクを貼りましたので、参照下さい。)

1.テスト自動化のスキルを考えよう! ~テスト自動化エンジニアに求められるスキル、期待される役割~ 早川 隆治(テスト自動化研究会)/テスト自動化スキル標準 AutomationTest.SSF 考えてます。 コヤマン(テスト自動化研究会), →<資料1>/<資料2>
2.自動家は見た~自動化の現場の真実~ /".reviewrc"→"おいしが" →<資料1>/<資料2>
3.広告システム刷新よもやま話 - テストが当たり前となるまでにやったこと - /森下 大介(ヤフー株式会社MSC開発本部マーケッターPF開発部) →<資料>
4.楽天の品質改善を加速する継続的システムテストパターン /荻野 恒太朗(楽天), 菊川 真理子(楽天) →<資料>
5.キーワード駆動によるシステムテストの自動化について /小井土 亨(SQiP 運営委員会メンバー、株式会社OSK) →<資料>
6.Testing Tools for Mobile App /松尾 和昭(クックパッド) →<資料>
7.パネルディスカッションLIVE! テスト自動化”エンジニア” の今とこれから/登壇者:森下 大介(ヤフー株式会社), 荻野 恒太朗(楽天), 小井土 亨(SQiP 運営委員会メンバー, 株式会社OSK),松尾 和昭(クックパッド), AAA(review.rc)メンバ, モデレータ:浅黄 友隆(ヒューマンクレスト), 松木 晋祐(ベリサーブ)

 今回は、「6.Testing Tools for Mobile App」について紹介します。

6.Testing Tools for Mobile App /松尾 和昭(クックパッド)

(1)モバイルアプリ

 組み込みの次に難しい開発。

(1-1)実情
  1. OS
  2. 利用場面の多様化
  3. サービス開発中心
  4. 開発サイクルの短期化
  5. サービス成長、コード肥大化
  6. アプリのデプロイリスク
  7. リジェクトリスク
    Apple:1week待ちやポリシー変更
  8. ダウンロード(できない)リスク
  9. アプリ評価のビジネスへの影響
(1-2)必要されているもの
  1. 安定したリリースを回す
  2. 内的要因への対応
    リリース前後の不具合や障害増加防止
  3. 外的要因
    外部サービス障害対応など
(1-3)OSの変化
  • 環境変化が激しい
    • 必然的に標準で提供されるツールが中心
    • 破壊的な仕様変更

(2)事例

(2-1)チーム事情
  1. 実装
    10人以下(iOSAndroidも)
  2. サーバ実装
    たくさん
  3. 特性
    Android:開発者視点で内部品質を気にする人多い
    iOS:UIや内部の作りを気にする人が多い
  4. テストエンジニアの役割
(2-2)発生した障害
  • Androidアプリ
    1.機能的に問題ない
    2.CPU/メモリ資源が過剰消費
    3.発覚したきっかけ:レビュー、お客さんからのお問い合わせ
    4.対策:資源の監視
(2-3)学び
  • 学び
    • 計測から:見えないものを見えるように(CPU使用率やメモリ消費量)
    • 開発の流れに組み込むことで習慣化
  • 失敗
    • 開発の流れに組み込まれていない
    • 検出できない
  • 学びと失敗を踏まえ
    必要なものは実装しよう
(2-4)課題
  • シナリオ管理
  • 結果のフィードバック
    開発者やテストエンジニアだけでなく、デザイナへ拡大。
  • サーバーとの協調
    API変更の追従。

(3)One More Thing:手動テストから現在に至るまでやったこと

  • 自動化を進めた理由
    • 開発量やリリース頻度が増加したら破綻する。
    • ビジネスのコアとして継続的な改善の土壌。
  • 実績を残す ソフトウェアテストへの専門性:ディレクターに施策の効果を説明するなど。
  • デファクトを変える
    これまでの概念を変える。
  • マインドマップ
    • 仕様の落とし込むと理解
    • 複雑さの理解:テンプレートを作り情報整理
  • 開発者に近いところに入る
    • 外から内へ
    • 開発者が機能実装時にGUIテストが書けたりできたりする。

所感

 リスクに繋がる予兆を検知するため何の情報(メトリクス)が必要かを見極めた上で、ツールの活用や自前で作成することも開発方針に盛り込み、開発スピードや開発者の体力気力が落ちないように工夫してみようと思います。