Upgrade to Pro — share decks privately, control downloads, hide ads and more …

システムテスト自動化カンファレンス2018.pdf

Koichi Nishide
December 08, 2018

 システムテスト自動化カンファレンス2018.pdf

Koichi Nishide

December 08, 2018
Tweet

More Decks by Koichi Nishide

Other Decks in Technology

Transcript

  1. freee 株式会社
    システムテスト自動化カンファレンス2018 前半
    freeeの品質トゥギャザー
    2018.12.08

    View full-size slide

  2. 2
    2
    freeeとQAの紹介
    01
    Section

    View full-size slide

  3. Koichi Nishide
    西出 皓一
    3
    2015年1月 freeeに入社
    最初の2年間は人事労務freeeのエンジニアをし
    て、今はQAマネージャーをしています

    View full-size slide

  4. 4
    創業からIPOまで、中小企業活性化のためのサービスを一気通貫で提供
    freee会社概要
    ❂ 納税する
    ↗ 育てる
    ↻ 運営する
    ✩ はじめる
    会社設立 freee
    開業 freee
    クラウド会計ソフト freee
    人事労務 freee
    (マイナンバー管理 freee 含む)
    クラウド申告 freee
    161億603万円 (資本準備金等含む)
    従業員数
    事業内容
    クラウド型バックオフィスサービスの開発・販売
    資本金
    設立年月日
    2012年7月
    465名(2018年6月末時点)
    2017年「働きがいのある会社」
    ランキング3位

    View full-size slide

  5. 5
    会計・給与共に法人シェアNo.1
    * BCN調べ
    * MM総研調べ
    * 2017年8月より、クラウド給与計算ソフト freeeは、機能を強化し、新たに
    「人事労務 freee」というサービス名に変更しました。
     
    クラウド給与ソフト
    市場
    40%
    クラウド会計ソフト
    市場
    35.2%

    View full-size slide

  6. 6
    6
    利用事業所数累計
    100万
    2014.3 2015.3 2016.3 2017.3 2018.3
    800,000
    600,000
    300,000
    65,000
    1,000,000
    1,000,000

    View full-size slide

  7. 7
    465人
    従業員数
    豊富な人員で、開発・導入支援・サポートを強化
    freee従業員数推移
    2013 2014 2015 2016 2018
    2017年「働きがいのある会社」
    ランキング3位
    2017
    2018年7月1日時点、アルバイト契約社員インターンを含む
    業務委託、派遣、出向を含めると614名

    View full-size slide

  8. 8
    QAチーム
    ● ミッション
    ○ 品質トゥギャザーでハッピー流出を防ぐ
    ● とにかくトゥギャザーが重要である
    ● ハッピーは不具合のこと
    ● やっていること
    ○ リスクを洗い出してテストする(プロダクトを知る)
    ○ テスト自動化
    ○ 品質向上に関する施策・リファクタリング etc

    View full-size slide

  9. 9
    言葉では伝わりにくいので
    トゥギャザー度の高そうな事例をいくつか紹介します

    View full-size slide

  10. 10
    10
    どういうハッピーが多いのかわからない問

    02
    Section

    View full-size slide

  11. 11
    どんなハッピーが起きてるか、が見えずらい
    ● 当時のハッピーの集計にはいくつか課題があった
    ○ スプレッドシート上でGAS + 手動操作で集計していて、属人性が高かった
    ○ 時間もそれなりにかかる
    ■ 約30h / 1month
    ○ 集計したい項目を追加しづらい
    ● でも、現状の品質を知るために、起きてるハッピーをいろいろな角度でみたい
    ○ 機能別
    ○ ユーザ種別
    ○ 優先度別
    ○ 残ハッピー数
    ○ 作成数 vs 解消数 など

    View full-size slide

  12. 12
    集計の自動化
    ● よし、freee社内のデータ基盤にのせれば属人性なくなるぞ!、ということで下記の構成でいこうかと
    ● ゼロコスト
    ● sqlで集計できる
    ● ハッピー以外の情報もredashでみるのが社内標準だったので、アクセシビリティup
    ● 集計項目の拡張もコード書けば可能

    View full-size slide

  13. 13
    そもそも、チケットの情報が正確とは言い難かった
    ● ハッピーチケットの運用フローが統一されてなかった
    ○ どっちがボール持ってるかわからないので、滞留ボトルネックがわからない
    ○ 優先度高と中の違いは?
    ○ 似たような機能名があって、名寄せが必要、などなど
    → サポート、エンジニアチームとハッピー運用フローをゼロベースで作成
    正確な情報得るためには、ハッピー運用フローから変えな
    いとだめだった

    View full-size slide

  14. 14
    最終的に
    ● Google Formで起票情報の品質底上
    ● チケット運用フローのアップデート
    ● JIRAへ移行
    ○ 運用フローのシステム化ができる
    ○ サードパティ連携豊富

    View full-size slide

  15. 15
    みんながハッピー分析できるようになってハッピー
    ここから進んだ品質改善プロジェクトもあります

    View full-size slide

  16. 16
    16
    複雑なドメインは複雑である問題
    03
    Section

    View full-size slide

  17. 17
    複雑なドメインは複雑
    給与計算
    年末調整
    勤怠
    所得税徴収高

    View full-size slide

  18. 18
    複雑なので専門家にテスト協力依頼した
    ● リスクや法律についてドメインスペシャリストの社労士さんや税理士さんに相談。リスク
    洗い出し。
    ● 具体的なテストケースの認識を合わせて、ドメインスペシャリストに期待値を計算しても
    らう
    ○ Googleスプレッドシート上でやりとり
    事前条件、入力パラメータ 期待値

    View full-size slide

  19. 19
    複雑で覚えられないので、spec化した
    社労士さん
    csv
    APIテスト(request spec)で実装。PR
    単位で実行。計算はAPIで完結できる
    ので、E2Eは使わない。
    https://martinfowler.com/bliki/TestPyramid.html

    View full-size slide

  20. 20
    ドメインスペシャリストのテストがCIで動いてるのは心強い
    スプレッドシートを見ればどういうケースが動いているかが見えるので、コード読めない人でも確認できるのも嬉し
    い。ただ、スプレッドシート地獄になりつつあるのが課題。

    View full-size slide

  21. 21
    21
    弊社のE2Eテストのびしろある問題
    04
    Section

    View full-size slide

  22. 22
    現状のE2Eテスト その1
    ● PRコミット→PRテストや静的解析がCircle CIでまわる→stagingにデプロイ→E2E(自動
    実行)→開発者動作確認→productionデプロイ
    ● ほぼ毎日リリースしているので、E2E自動テストは必須
    staging環境 production環境
    development環境
    (ローカル)
    静的解析
    Unit・Serviceテスト E2Eテスト
    integration環境 x N個
    QAテスト用
    リリース前の長期検証が
    必要な場合に使う

    View full-size slide

  23. 23
    現状のE2Eテスト その2
    ● Rspec x SitePrism x Capybara x Selenium
    ● 構成の理由
    ○ プロダクトがrailsなので、みんなrspecには慣れている
    ○ SitePrismはページオブジェクトパターンを簡単に使える
    ○ Capybaraはいい感じのDSLがある
    ● その他
    ○ E2Eテストコードは各プロダクトのリポジトリにある
    ■ QAだけでなく、エンジニアも気軽に修正できるようにするため(ユニットテスト感覚)
    ○ どういう時にシナリオを足しているか
    ■ 新機能リリース後が多い
    ○ テストデータどうしてる?
    ■ 秘伝のテストデータをもったアカウントを使ってるところもある
    ■ デモデータ事業所のバリエーションを増やしていくことで対応していきたい

    View full-size slide

  24. 24
    課題
    ● E2Eテストに実行環境の制限や属人性があるため、リリース手前でデグレに気づいた
    り、シナリオのメンテナンスが大変(自動E2Eテスト視点)
    ● プロジェクト数に対するテスト環境不足(手動E2Eテスト視点)
    ● マイクロサービス化によるテスト環境構築大変(エンジニアのレビュー視点)

    View full-size slide

  25. 25
    後半に続く
    スライド

    View full-size slide

  26. スモールビジネスを、
    世界の主役に。

    View full-size slide