DeNA Testing Blog

Make Testing Fun, Smart, and Delighting End-Users

この1年すすめていた「プロジェクトの健康状態の可視化と予防」と「自動テストの適用範囲の拡大」という施策についての話

SWETグループの平田(@tarappo)です。

早いもので2021年度もとうとう終わりをむかえようとしています。 ふりかえりということで、ここ1年ほどの間に私も関わって進めていた次の2つの施策についてかんたんに紹介したいと思います。

  • プロジェクトの健康状態の可視化と予防(dev-vital)
  • 自動テストの適用範囲の拡大

今回紹介するこれらの施策は、SWETメンバーの今までの経験などを元に議論した中で出てきた課題から決めています。

プロジェクトの健康状態の可視化と予防(dev-vital)

私がSWETに所属してある程度の期間がたちますが、いろいろなプロジェクトに関わってきました。 その中で感じたのは、あるプロジェクトで出会った課題は他のプロジェクトでも起きていたりするということです。

今までのSWETの取り組みはプロジェクトですでに起きた課題に対してアプローチをとることが一般的でした。 たとえば、すでにテスタビリティがよくないプロダクトをリファクタしてテストをかけるようにするとか、CI/CDサービスが動いていない状態を直すといったようなところからです。

プロジェクトの早い段階からSWETのメンバーが関わっていれば、上記のようなことをあとから行わずにすんでいたかもしれません。 しかし、弊社のプロジェクトの数・規模感・スピードなどを考えるとすべてに関わるのは無理があります。

そこでどうすれば、このようなことが起きないかについて検討をしました。 その中で出てきたのが、次のような仮説です。

  • プロジェクトにおけるある指標が他の指標に影響をあたえて、最終的にユーザーに見えるレベルでの問題となるのではないか?
  • 影響をあたえる指標の関係性がわかれば、将来起こりうる問題の予兆がわかりその結果として予防ができるのではないか?
  • そのようなプロジェクトの健康状態といえるような指標を可視化できればよいのではないか?

この仮説をもとに「プロジェクトの健康状態の可視化と予防」という施策を2021年度からはじめました。 この施策を「dev-vital」と呼んでいます。

この施策では、まずプロジェクトの健康状態に必要と考えられる指標がどういったものかについてメンバーで検討を何度もおこないました。 そして決めた指標をプロジェクトからとれるようにプロセスを整え、集めた情報を保存できるようにして可視化をする必要があります。

そこで、開発プロセスの中で蓄積される次のような3種類の情報をまず可視化できるように整備を進めました。 すべてのプロジェクトで一度におこなうのは困難であるため、まずは特定の1つのプロジェクトをターゲットとして進めました。

  • (1)CI/CDサービスから得られる「ビルド時間」や「ビルドの成功・失敗率」「テストケース数」
  • (2)GitHubから得られる「エンジニア数」や「PRなどの情報」
  • (3)不具合チケット(JIRAチケット)から得られる「不具合数」や「クローズされるまでの時間」

なお取得するための情報元として上記に紐づくのもありますが「アプリ、サーバのリリース頻度」なども取得しています。

CI/CDサービスからの情報

(1)の情報を可視化するためにメンバーが開発しているCI Analyzerを活用しています。

このツールについては「CI/CD Conference 2021」で登壇をしていますので次を見ていただければと思います。

データを得るためにもCI/CDサービスを活用してPR時などをふくめビルドを継続的におこなえるような環境であることが望ましいです。 そもそもCI/CDサービスが動いてなければ、コードに問題があるのかどうかすらわかりません。

その一環も含めて、弊社の「Pococha」というサービスでCI/CDサービスを活用できるようにいかに開発に組み込んでいくかという次のような改善を進めました。

また、CI Analyzerでテストケース結果を確認できるようにCI/CDサービスの成果物としてJUnit.xml形式のファイルが保存されている必要があります。 それらの対応も併せておこなっています。

これにより、CI/CDサービスからいろいろな情報が得られるようになっています。

GitHubからの情報

(2)の情報はGitHubのGraphQL APIを活用することで得ることができます。

データを得るためにはPR時に記載する情報の整理ができていることが望ましいです。 PRには「誰が担当したのか(assignees)」「どのマイルストーンでリリースするのか(milestone)」「どのような対応なのか(label)」などいろいろな情報を含めることができます。

これらの情報はPRを出した人自身で入力することが望ましいもののどうしても人によって入力内容に差がでてしまいます。 そこで次を活用しました。

  • PR Templateの活用
  • Dangerの利用による自動設定
  • Dangerの利用による未入力箇所の指摘

これらにより、PRからの情報はある程度統一されるようになり、データの取得ができるようになりました。

JIRAからの情報

(3)は不具合チケット(JIRAチケット)の活用です。

検証を担当する品質管理部のメンバーがいる場合、検証時に不具合があればJIRAに不具合チケットを起票するようになっています。

今までも、一部のプロジェクトではこの不具合チケットのデータはまとめてBigQueryに保存してデータポータルを使って可視化していました。 今回ターゲットとしたプロジェクトにおいては、その整備ができていなかったこともあり、保存し可視化できるようにしました。

dev-vitalの現時点のまとめ

このようにいろいろと情報を取れるようにするにはプロセス含め整えることが必要でした。 その上で、データを保存できるようにし可視化をすすめました。

今は上述したようないくつかの情報について可視化できるようになっています。 この可視化された情報からだけでもある程度の情報が得られる状態ではあります。

しかし、当初かかげている仮説は次のようにそれぞれの指標が影響を与えているというものです。 「プロジェクトにおける指標が他の指標に影響をあたえる」

一歩目をあるき出したとはいえ、この仮説に対して検証ができるフェーズについてはこれからというところになります。

今まで話したようなこの1年間でおこなえたことについては次の勉強会でメンバーが登壇をしますので是非聴講してもらえればと思います。

自動テストの適用範囲の拡大

SWETは今までいろいろな自動テストを実装し、運用してきました。 ユニットテストといったフィードバックの早い自動テストは重要ですし、全社的な教育や事業部との連携などは次のブログにあるように進めてきました。

これらは今後も続けていきますが、ユニットテストよりも結合度の高い自動テストも重要です。 SWETが取り組んできた自動テストとしては、次のようなものがあります。

  • (1)パフォーマンステスト
  • (2)スクリーンショットテスト

パフォーマンステスト

1つ目のパフォーマンステストは「Pococha」のiOSアプリで取り組んできました。

Pocochaはライブ配信サービスであり「パフォーマンス」という観点は非常に重要です。 たんに機能が動けばいいわけではなく、高負荷時においてもアプリがユーザーにとって問題なく使えることが求められます。

取り組みをはじめた時点では、パフォーマンス計測自体が実施できていませんでした。 そこでまず、パフォーマンスを計測できるようにして、それを継続的に確認できる状態にする必要がありました。

そのために、パフォーマンス計測を自動でおこなえるようにしました。 このパフォーマンス計測周りについてはPocochaでおこなった事例として次のような記事を書いています。 この記事時点ではおおがかりな基盤にはなっていますが、この時点ではこのぐらいの基盤を作って計測する必要性がありました。

そして、そこから年月がたって必要なことはかわってきてこの基盤についても見直しをすすめています。

パフォーマンス計測がどのレベルで必要かはプロダクトの性質やそのときの状況によって異なります。 しかし一切関係ないというプロダクトはないともいえます。

今では、パフォーマンスに関してはiOS、Androidともにプラットフォーム側がいろいろと機能を提供してくれるようになってきています。 たとえばiOS側では、MetricKitXcode OrganizerなどがWWDCで発表されています。 Android側では、Android Vitalsといったものもあります。

これらのようなプラットフォームが提供する機能を活用することも重要です。

iOSアプリにおけるパフォーマンス計測についての話は2022/3/24に開催した「iOS Test TeaTime #4」でメンバーが登壇しました。

毎年のように変化があるので是非まとまったこの資料を見てもらえると嬉しいかぎりです。

スクリーンショットテスト

2つ目がスクリーンショットテストです。 ここでいうスクリーンショットテストは、ある時点での画面をキャプチャしたものを検証に利用することを指しています。

スクリーンショットはいろいろなプロダクトで活用されています。 すぐにスクリーンショットがとれる状態になっていればよいですが、必ずしもそういうコードになっていないことはよくあります。 そこで、まずはスクリーンショットをとれるようにする必要があります。

Androidにおいて、それらについておこなったことについては2021年の「DeNA TechCon 2021」でメンバーが登壇しました。

この登壇から1年がたち、スクリーンショットの活用方法は広がってきました。 今、Pocochaでおこなっている活用方法については先日おこなわれた「DeNA TechCon 2022」でメンバーが登壇しました。

このようにいろいろな自動テストを活用できる場所で使えるようにしています。

おわりに

こんかいは2021年度におこなった施策についてかんたんに説明をしました。 こうして振り返ると、おこなったことについてはある程度アウトプットしていることがわかります。 今後もアウトプットしてくと思うので、是非ウォッチしてもらえればと思います。

さいごになりますが、私はこのたびSWETを卒業します。

入社してから、ずっとSWET(SWETがグループになる前から)としていろいろなことをおこなってきました。 そのすべてをブログにまとめようかと思いましたが、あまりにも長くなるので2021年度に私がかかわった施策についてかんたんに説明しました。

長い間、働けたのは今回説明した施策みたいな非常に魅力的な仕事に取り組めたことや関わってきたメンバーの魅力によると思っています。

SWETでは上述した施策以外にもいろいろなことをおこなっています。 次のサイトに本件以外の情報についても載せているので見てもらえればと思います。

非常に魅力的で面白い仕事が待っているので、是非とも興味がある方は次から応募していただければと思います。