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

Web.JaSST Web Service QA Meeting in #JaSST '17 Tokyo

勉強会 技術 JaSST

登壇者

  • 泰楽
  • 西脇
  • 鶴岡
  • 福沢
  • 鈴木

泰楽「メルカリでQAプロセスを最速で構築したトリアージ術」

自己紹介

  • 泰楽
  • メルカリ
  • WebQA歴10年

メルカリとは

  • 日本最大のフリマアプリ

メルカリQAの創生期

  • QAプロセスが存在していなかった
  • USリリースに向けて検証対象の拡大
  • QAプロセスを構築しないといけない
  • このままだと2倍のリソースが必要になる

絶対的なリソース不足

  • 1人で行う検証作業の限界
  • 開発スピードに追いつかない(開発15名に対しQA1人)
  • このままではリリースできない

属人化の許容

  • 細かいゴールを多く設定し、QAに関わる業務の全てをゼロベースで見直し、小さな改善を繰り返し実施していく
  • プロダクトとしての成長に向けて、小さなゴールを決める。
  • QA活動としてモデル化や属人化の排除をすることが多いが、そうではなく属人化の許容をしていく
  • 変化に対応していく

QAプロセスの高速化1

  • やらないところを決めた
  • テストケースを作らないことにした
  • 10年の経験のキーワードは3つ
    • 正常系は不具合の検出率が低い
    • アドホックテストが不具合の検出率が高い
    • テストの質はテストの対象物に比例する
  • その代わり、仕様の背景や目的の理解に時間を割いた。
  • テスト結果やエビデンスはどうやって出すのか?

QAプロセスの高速化2

  • 品質ばらつき問題の懸念
    • 検証結果を第三者レビューすることで解決
  • WEBサービスのリリースに対しての制約は多くない
    • 逆に言うと、いつでもリリースできる環境が用意してある

QAプロセスの高速化3

  • 不具合の当たりをつけ、システムを理解する
    • エンジニアと外部設計レベルのコミュニケーション
    • 仕様変更に対してのテストケースの改修コストがほぼ0に

検証結果の精度向上

  • テストの結果に対して本当にそれで良いのか?
    • 検証結果にアクセスログを最大活用することで検証結果の妥当性を向上

不具合報告の精度向上

  • エビデンスの工夫
    • エラーログを活用する
    • エラーログなので人の感情が入らない
    • 再現性の低い不具合でもエラーログから判断できる

西脇「QAエンジニアからセキュリティエンジニアに転職した話」

自己紹介

転職してみて感じたこと

  • 転職できるとは思っていなくてダメ元で。
  • 意外とあり。セキュリティエンジニアとQAエンジニアは親和性あり

どんなスキルでも自分を裏切らない

  • 入社前はわけが分からない状態
  • 意外と前職の知識が役立った
  • 同じチームの方々が上手く仕事を振ってくれた
  • @ITで記事を書くときも既にあるスキルが役立った。 ** ボットネットの解説記事
  • 「どうしてこういう書き方をしているのか」というところの研究は、QA時代のスキルが役立った

思っていたよりも脅威は身近に潜む

  • 情報セキュリティの10大脅威
    • 組織に対しては標的型攻撃が猛威を振るっている
  • ファイルを暗号化&身代金(ランサムウェア)のウイルスにかかっている48%はお金を払っている
    • オーストラリアの4つ星ホテルでランサムウェアにかかってしまい、ホテルのお客が全員締め出される事件があった
    • ロサンゼルスの病院でランサムウェアに感染し、カルテが見れない状態に
    • 最近の標的型攻撃は怪しくない日本語で、怪しくない内容で、知っている人物になりすまして送ってくる
      • しかも実行した後に気付いていない
  • 組織のセキュリティ部門の人は、そもそも感染を防げない前提で動いている

  • WEBサービスの不正ログイン

  • IoT機器の脆弱性攻撃の顕在化
  • AWSのアクセスキーをハードコーディングしているものもあるので危ない

今後の展望

  • QA+SECURITY+AUTOMATION=?
  • 去年8月にCGCがハッカーカンファレンスの中で行われた。

鶴岡「QAが主導する仕様改善について」

事業紹介

  • るくみー
  • るくみーnote
  • ロボット(MEEBO)
るくみー
  • 写真販売サービス
  • 保育士が写真撮影→アップロード
  • 父母がネットで注文
  • BtoBtoCの事業
  • 保育士が使ってくれないと成り立たない
  • テスト対象はアップロード系と購入管理と社内管理のシステム

保育士の特徴

登場人物

開発プロセス

  • 早くて1週間、長くて半年
  • 企画→要件定義(※)→基本設計(※)→実装→テスト(※)→リリース

上流工程での仕様チェック

  • 要件を満たした仕様になっているか
  • 影響する機能の考慮漏れが無いか
  • ユーザビリティが良いか

上流工程での仕様改善

  • UI変更
  • 機能変更、追加
  • 機能削除(開発工数に見合わない機能の削除)
  • QAが承認するまでは何回か繰り返す

実装フェーズ

  • システムテストのテスト設計を実施している
  • 複雑なパターンだけはしっかりとしたテストケースを書いている。
  • 回帰テストのテストケースもきちんと書いている

テストフェーズでの仕様チェック

  • チェックする内容は上流工程と同じ
  • 実際に使ってみると気づきがある
    • 次どうしていいか迷うなーとか

テストフェーズでも仕様改善している

  • 仕様に基づく権限はQAが握っている

どう動くか

  • 発生頻度、影響範囲をもって改善案を出す
  • ユーザビリティが向上されるか精査する
    • 場合によってはサポートチームの方が分かっていたりもする
  • 工数を算出する

どう対応するか

  • リリースに間に合う
    • すぐに対応
  • リリースに間に合わない
    • リリース日をずらす
    • 今回のリリースでは見送る
  • 見送られた改善は開発プロセスの2周目へ

狙い

  • 保育士が使ってくれないと機能しない
  • ユーザビリティを向上させ続けないといけない
  • 保育士の作業負担が減るといろいろな写真をさらに録る→写真が増える→売上が増える

  • QAはサポートチームに話を聞きに行って、ぐちを聞いたり問い合わせの状況を聞いたり…

QAがやりたいこと

  • 利用してくれる保育士の作業負担の軽減
  • 保護者が購入写真で家族とのコミュニケーションに役立ててもらうこと

福沢「About “Pair work"」

なぜPair workをスタートしたのか

  • 色んなタスクが振ってくる

    • HOME'sに関するプロジェクトが年間数百あるが、それらのサポートをしたり、HOME's以外の新規プロジェクトのQAに行ったり…
    • スキルの属人化が増えていった
  • スキルの属人化を防ぐために行うのがPair work

    • タスクに対して2人以上で行う
    • タスクの割当は朝会で決定する
    • タスクに詳しい人1人と詳しくない人1人を割り当てる

Pair workの振り返りについて

  • 1習慣のサイクルをKPTで振り返る
  • 隣同士でやった方が良いよね→フリーアドレスへ

Pair workの詳細

  • タスクのゴールとTODOをきちんと話す
  • 役割を決める
    • 設計は2人で
    • 開発はAさん
    • 開発サポート、調査、レビューなどはBさん

Pairのパターン

  • アクティブ&サポート
    • 1人が不慣れな時にこうなる
  • アクティブ&アクティブ
    • より速く処理できる

結果

  • Pair workを元々期待していた効果は属人化防止
  • 自分が知らなかったTipsを教われた
  • トラブル時にすぐに気付ける。

やりづらかったこと

  • 他のペアチームがやっていることが見えづらい
    • ペアワークをやっていてもいなくても起こること
    • 朝会などで対応
  • ペアを変えるタイミングが難しい
    • 本当は1つのタスクが終わったタイミングで変えたかったが…
    • タスクではなく1つのプロジェクトが終わったタイミングで(1ヶ月〜2ヶ月程度)

まとめ

  • 作業効率の向上
  • スキルの属人化防止
  • 良いTipsの共有ができる
  • 問題点については、ペアワークの運用で何とかなる
  • おエアワークのメリットは大きいと思う

鈴木「現場から見るWebと組み込みのQAの違い」

発表資料

speakerdeck.com

略歴

  • 2012年まで組み込み
  • 2012年からは現職

狙い

  • 組織によっての品質の考え方やQAの働き方の違いを知る

比較

  • 開発者との距離
  • プロダクトに寄与できる最良
  • 品質の重要性の浸透

開発者との距離

組み込み
  • 縦割り
  • 開発との距離が遠い
    Web
  • わいわい
  • 如何に開発と協業するのかを求められる

プロダクトに寄与できる最良

組み込み

品質の重要性

組み込み
  • とにかく重要視される
  • Webは軽視される場合がある。納期や機会利益が品質に勝つことがある。
    Web
  • 不具合があってもすぐに直せる特性
  • 専属のQAを持たない組織が存在していた。

テストリソース・スケジュール

組み込み
  • 同じテストを延々と繰り返す
  • テスト実行の厳しい時間制約はあまりなかった
    Web
  • リソースまでのサイクルが短い

QAエンジニアの地位

組み込み
  • 地位が高かった
  • 組織にQAエンジニアの重要性が理解されている
    Web
  • 品質を低く見られがち。業界的に。

産業ドメインによるテストのギャップ

現場での取り組み・心がけ(一部願望を含む)

  • プラスのブロックは裁量について
  • マイナスの部分は品質の意識について

開発者との距離

  • 協業の度合いを深める
  • 開発だけのコミュニケーションラインを作らない
  • 仕様策定段階からコミット
  • 技術定例にも参加
  • 設計のレイヤーから

プロダクトに寄与できる裁量

  • とにかくオーナーシップを発揮する
  • QAとか関係なく、色々巻き込んで発揮しよう

品質の重要性の浸透

  • 組み込みでは現場に理解があったがどうやって浸透させるのか
  • プロダクトに求められている品質を理解し、過剰品質を目指さない
  • テストを妥協するのではなく、スケジュールの遅延や機会損失を招かないようにする
  • 過剰品質とはPMBoKで書かれている用語

テストリソース・スケジュール

  • 軽微な問題は直さないと割り切る
  • 当該リリースで必ず達成したいことを最優先に
  • できるだけテストを短い時間で敢行、停滞させないような工夫
  • できるだけ原因の把握をして、開発に伝えて開発のモチベーションを低下させない

QAエンジニアの地位

  • 地位を高めるには?
    • 課題解決の領域を広くする
    • 組織の成熟度を高くする

再掲

  • 組織による違いを知り、考え方の幅を広げる

視野を広げるには?

  • ソフトウェアテスト293の鉄則より
  • 社内で最適化された人材にならず、外部で技術や他の現場の事情を知ること
  • 組織による品質の考えの違いを知り、QAエンジニアの価値を高めよう。

質問

  • 泰楽さんに質問
  • 探索的テストはスキルのばらつきがあり、スキルアップが難しいと思うが、スキルアップの方法は?
  • QAは開発と同じような仕事をしているが、プログラミング経験が少ないとは思うが、プロダクトコードを読み込む、SSHでログインするなどのエンジニアに近い作業を行うことでスキルアップをした。