Veriserve - WebQA FunNight!! #01 #WQFN01

告知ページ

veriserve.connpass.com

はじめに

• このイベントでは、テスト管理クラウドサービス QualityForward のアジャイル開発において、どんな取り組みを行ってきたか、「守」「破」「離」の3点に分けて紹介していました。
• なお、最初の話と、最後の話は諸事情により記録できていません。*1ご了承ください。

目次

登壇者紹介

• 開発：遠藤大介さん（ソニックガーデン）
• テスト：大竹未紗さん（ベリサーブ）
• PO：松木晋祐さん（ベリサーブ）

守

• 以下の3点を行った。
  • 仕様を徹底的に議論する
  • 環境を最新に保つ
    • RailsのVersionをガンガン上げるとか
  • テストをちゃんと書く

仕様を徹底的に議論する

• PO（松木さん）がまずやりたいことを持ってくる
  • ビジネス的に何を実現したいのかについて、松木さん流に話す
• 中にはソフトウェア的に作るのが難しいことも
  • 開発者（遠藤さん）が「後々ガンになるよ」と伝えるようにしている
• 要求に対して色んな実現方法がある
  • ソフトウェアにとって優しい、優しくない
  • ユーザーにとって優しい、優しくない
  • これらの調整がエンジニアの腕の見せどころ
• 僕のオススメはこれ、と提案する
• どちらかが折れるのではなく、対等に議論する

• 週に2時間超のMTGをしているが、殆どがその議論

• 松木

  • 変な仕様ってある？
• 遠藤
  • いっぱいあるんですけど（笑）
  • テストスイートにタグを付けたいという議論とか。
    • 実際あった会話
      • 遠藤「何のために付けるの？」
      • 松木「目的のテストスイートを見つけるためにタグを付けたい」
      • 遠藤「タグの管理が破綻するよ」
    • タグのシステムは簡単なのですぐに作れるが、ユーザーは使いこなせないと思った。
• 作るのもメンテも大変ではないやり方を選び続けて1年半経った

環境を最新に保つ

• 技術は日進月歩
• セキュリティ的に固くしようと考えると、フレームワークも最新にすることになる
• 古いVersionだとセキュリティパッチも当てられない、使いたいライブラリが使えない
• しょっちゅう、ライブラリを最新版に上げろと言ってる
• 毎週リリースしているとリファクタするのを後回しにすると絶対にやらなくなる
  • →毎週リファクタをする
    • Redmine連携をした後に、JIRAなどにも対応できるようという要求があり、連携部分を抽象化した
• ベリサーブ社内用のツールとして開発していたためシングルテナントで作っていたが、他の会社でも使いたいと言われた
  • →2週間でマルチテナント化した
• 松木「ペースが落ちたことはない」

自動テストをちゃんと書く

• カバレッジを100％を目指すのは辛い、C1を85〜90%でキープしてる

• ライブラリのVersionを上げると挙動が変わるが、それを恐れてたらVerUpできない

  • 大事なのはすぐに気付けること

• 今回開発したサービスだと権限毎のふるまいが違うので、その関係性を整理した上で自動テストを描いたりした。

• 自分でできるところが守る、ただそれでも気付けないところはベリサーブさんに助けてもらってる

• 松木「日付をまたぐテストの書き方についてなどは勉強になった。」

• UIテストはどうやってる？

  • ブラウザで触った時の挙動については、Railsなのでcapybaraでやってる

• ヘッドレスか実ブラウザでやるか？

  • 殆どがヘッドレス。たまに実ブラウザでテストする。

• システムテストの成長系+αをプログラマに守ってもらってる

質問

Q 結構リッチなUIを使っていると思っているが、フロントエンド側は？

• A フロントエンド側は書きづらい。例えば、スプレッドシートの自動化は流石にコストがかかるので、効率的な部分を優先にやっている。

Q リファクタリングの（時間的な）割合は？

• A 空気を吸うようにやってる。ソニックガーデンの場合は、コードレビューを必ずやっているが、そこでも指摘があったりするので、リリース直前でもやってる

Q コーディングとテストコードの比率は？

• A テストコードが1.5倍ぐらいある。テストコードの方が圧倒的に多い

Q マニュアルでテストすることはあるか？

• A TDDに向いていないものもある。
  • 完成形が見えていないものとか。
  • そういうものは触りながらやる。
  • 逆に権限周りでガチガチに決まっている場合はテストコードを先に書く

Q テストコードとプロダクトコードは別リポジトリ？

• A 同じです。

Q CIってどこでで回ってる？master側？develop branch側？

• A 手元では開発側で回してるし、masterでもstagingでも回してる

Q 環境を最新に保つとあったが、最新Versionの環境ではライブラリが使えないような場合はどうするのか？

• A いくつかパターンが分かれる。
  • デグレって使えない
    • プルリクを投げて対応
  • 思想から外れるのでコードから外された。
    • 乗り換え先を検討する。（別ライブラリを探す）

Q 松木さんが「ペースが速い」と言っていたが、ペースの速い、遅いの判断はどうやって？

• A 完全に松木さんの主観。
  • 今まで関わってきたプロジェクトと比較すると圧倒的に速い。
  • 速い場合、時間が経つと落ちてくるが、全然落ちない。
  • 最初からトップスピードで、その速度をキープしている感じ。
  • 逆にどんどん加速していくことも無い。
    • これ以上速くなるとPOが保たない

Q VerUpで不具合が見つかるタイミングは、自動テスト以外にあるか？

• A ある。その時は、テストケースを足したりQAが観点として足したりする。

Q ドメイン知識が無い人がコードレビューをしていても回るか？

• A いかに読みやすいコードを書くかを会社全体の流れとしている。
  • ビジネス的なものをコードレビューで見るのはそもそも難しい。
  • 「セキュリティ的に大丈夫かどうか」「読みやすいコードかどうか」を中心にレビューしている。
• 権限周りのコードレビューだと松木さんに相談したり。
• 松木「複雑な要求なのにコードが綺麗すぎるので、逆になんかあるのでは？と思ったりした。」

破

• エンジニアが守っていた後に流す。テストエンジニアが破る。

バグランク

• バグランクを予め決めている。
  • S セキュリティ、データ消失/破壊、システムの価値を致命的に損なう
  • A システムクラッシュ、復帰不能例外、システムの本質的な価値を毀損する
  • B 機能不具合、例外、ほか頻繁に利用されるケース
  • C 目立つ表示崩れ、軽微なユーザ期待との相違

テストサイズ

• 変更内容によって、テストのサイズも決めている

Sテスト

• 以下のような変更はSテストで対応
  • 軽微な変更
  • データの書き込みを伴わない変更
  • 表示される情報がユーザーにとってクリティカルでない変更
• →製品知識が豊富なテスターのアドホックテストで対応

Mテスト

• 以下のような変更はMテストで対応
  • 主要機能の追加や変更
  • データの書き込みを伴う機能
• →テスト分析、設計、設計レビュー、実行、レポートのプロセスを通すようにして対応

Lテスト

• 以下のような変更はLテストで対応
  • セキュリティ
  • データ毀損のリスクを伴う機能
  • ユーザーにとってクリティカルな情報を扱う機能の変更
• →仕様、影響を網羅するためのモデルから作る

出来上がった最小の製品に対してリスクベースドでテストスイートを作る

• 最初から1ヶ月ぐらい経ったときにまずは作った
• 「ユーザーがどれ位ショックか」と「この機能はどれぐらい複雑か」の積でスコアを算出し、優先度を決めた

変更部分について影響範囲分析に基づくテスト設計と実行

• 機能が加わったり、変更があったら、どれぐらい影響が表すかを図にしてまとめた
  • この機能を動かしたらどこに影響があるかについては矢印で表現した
    • 矢印の1本1本がテスト条件になっている
  • 例えば、ケースを作成した時に、「出力ができる」ものがあればエクスポートの機能に影響を与えるとか

Lテストの場合はPOと一緒に仕様のモデルを整理する

• 「なぜこんな仕様になっているのか？」「どういう思想なのか？」を徹底的に共有
• Lテストを実施する時は救援のQAも呼んで実施
• ユーザー権限は非常にクリティカルなので、Lテストを実施した
  • 横の権限、縦の権限というモデルを一緒に作った
  • この仕様とモデルにおいては、画面、ユーザーメニュー、機能実行×権限の昇格＆降格の組み合わせで網羅できることを発明した
• 納得できる網羅を毎回発明している
• このモデルを作ってテスト＆修正を行った結果、その後、テストエンジニアのエースが1週間やってもバグを1件も見つけられなかった

Q Sテスト、Mテスト、Lテストの比率は？

• A 5:3:2ぐらい

離

• 製品に対しての問い合わせの対応は、QA側で行っている。
• 開発側にはフィルタリングした情報のみ来る
• 開発が集中にしてくれる環境になってる。
  • 遠藤「POからすると『作らないなー』と思ってそう。」
  • 松木「最初の3,4ヶ月は本当にそう感じた。今では慣れた」
    • 今回のサービス（テスト管理クラウドサービス）の提案を最初にソニックガーデンに伝えた時に「エクセルでいいじゃん」と言われた。
    • プログラマがガンガン言うことで内容が洗練されていく

おわりに

• 最初にも書きましたが、これ以降は諸事情により記録が出来ていません。
• ただし、ここに書いた内容以外にも様々な質問が飛び出して、大変面白い＆タメになるイベントでした！

*1:最初は電車遅延で会場に間に合わなかったのと、最後はピザを食べながらだったのでPCを起動して記録していなかったためです