Teachme Bizの開発における QA の歴史・理想像・課題

Katsuhiko Tabei
Nov 13 · 9 min read

こんにちは、管理部 人事グループの田部井です。スタディストが提供する Teachme Biz は、サービスローンチから6年が経過しており、サービスの QA において、徐々に現状と理想に開きが出てきました。本記事では、スタディスト QA チームの岩崎に「 Teachme Biz の開発における QA の歴史・理想像・課題」について伺った内容をご紹介します。

要約

Teachme Biz はローンチから Ruby on Rails のアップグレード、UIリニューアルなどの大きな取り組みを経ています。明確なテスト観点がなくテスト項目書もない時代からはじまり、次第にテスト項目書や RSpec の単体テストが整備され、直近ではフロントエンドの品質課題の解消が行われていきました。

そして、 QA の主担当である岩崎が2019年1月に入社し、ドキュメント整備、テストプロセス改善を行ってきました。

今後、さらなる品質保証の理想像に向かうため、スタディストQAチームでは、「 QA の適用範囲の拡大」「QA x PM / QA x UX」「QA x Engineering」の3つの施策を行っていきたいと考えています。

スタディストでは、この理想にむけ、 QA プロセスの改善を岩崎とともに考え、実行していってくださる QA エンジニア, テストエンジニアを募集しております!

スタディストにおける QA の歴史

サービスのローンチ期

Teachme Biz はコンサルタント出身の創業メンバーが自ら Rails / iOS / Android の学習をして立ち上げたサービスです。
当時は、明確なテスト観点や、テスト項目書はなく、思いつくユースケースについて試行錯誤しながらブラックボックスのテストを実施していました。

拡大期

開発部門が拡大するにつれ、機能開発単位でテスト設計を行い、テスト項目書を作成し、クロスチェックを行ってリリースをするようになりました。また、テスト項目書を作成することで、テスターの方にテストを実施していただくことができる体制になりました。

大規模リファクタ期

Ruby on Rails のアップグレードを実施するタイミングで、 RSpec による単体テストの自動化が整備されはじめました。

フロントエンドの全面刷新期

開発開始から5年以上経ち、積み重なった技術的な課題によって、開発速度・品質が低下しているという課題がありました。
その中でもフロントエンドの改善対象が大きく膨れ上がったため、 Vue.js による大規模な UI リニューアルを実施しました。
詳細は以下の記事にあります。

Rails + Vue.jsでUIリニューアルしてみた(フロントフレームワーク選定編)
Teachme Biz UIリニューアル(デザイン編)
UIリニューアルの裏側(プロジェクトマネジメント編)

この取組によりフロントエンドの品質を一定改善することができました。
この時期にはまだ QA 専任の担当者は不在で、テスト設計、テスト実施ともに要件設計者やソフトウェア開発者が行っていました。

QA 担当者の参画後

2019年1月に QA を担当する私、岩崎が QA エンジニアとして入社しました。
入社から今までの間に大枠で2つの取り組みが実施されました。

1. ドキュメント整備
2. テストプロセス改善

です。

1. ドキュメント整備

まず、テスト計画書・テスト仕様書・障害報告テンプレート等のドキュメントを整備しました。

1つ目にテスト計画書です。
スタディストのテスト計画書では、以下のような項目を取り扱います。

・ テストの目的
・ 対象機能
・ 対象外機能
・ 要件・範囲・制約
・ アプローチ — (機能テスト, シナリオテストなどのアプローチを記載する)
・ テストのステータス(色分けで可視性を高めている)
・ 不具合解消フロー
・ スケジュール
・ 終了条件

テストのステータスは、例えば以下のように分類しています。

また、不具合解消フローは以下のような流れで行っています。

2つ目にテスト仕様書です。
テスト仕様書のフォーマットを作成しました。
もともとテスト項目書は存在しましたが、以前よりも記載粒度を細かくして内容をわかりやすくしたり、テストのカテゴライズをわかりやすくするなどの改善を実施しました。

また、テスト仕様書を利用する関係者がよく行う操作が円滑に行えるようにすることで操作コストを減らすように改善しました。一例として、プロジェクト管理ツールである Wrike の API を用いて GAS で Google Spreadsheet のテスト仕様書にテストのステータスを反映する処理を自動化しました。これにより、テストケースを管理している Google Spreadsheet の個別の項目から、それに対応する Wrike 上の課題の URL に飛び、ステータスを確認するという手間が大幅に短縮されることになりました。
例えば、下記画像内の「Close」は Spreadsheet にハードコードされているのではなく、 Wrike のステータスを API で取得した結果です。不具合URLの中身を確認せずとも、ステータスを更新することができます。

3つ目に障害報告テンプレートです。
プロジェクト管理ツールである Wrike に、障害報告テンプレートを作成することで、障害報告が十分な記載になるように標準化をしました。

2. テストプロセス改善

テスト計画、テスト設計、テスト実施など、開発に関わる QA のプロセスとして定義し、開発中のタスクのステータスを管理できるよう整備を行いました。

他にも、不具合対応の実施プロセスを定義し、開発タスク側にステータス管理できるよう整備を行いました。

これにより、 QA のプロセスが標準化され、より確実に実施されるようになりました。

理想の QA 体制とは?

ここまでの歴史を踏まえて、 Teachme Biz の QA として残っている以下のような課題をクリアしたいと考えています。また、これらの課題をクリアすることによって、プロダクトの品質向上や品質を保ちつつリリースサイクルを高速化したいと考えています。

QA の適用範囲の拡大

Teachme Biz の開発チームでは大規模案件開発チーム、小規模案件開発・保守チーム、ネイティブアプリチームにわかれています。
現状、私が対応した QA の取り組みの適用範囲は主に大規模案件開発チーム向けとなっていて、小規模案件開発・保守チームとネイティブアプリチームには部分的にしか適用できていません。 QA チームの施策を実行する担当が私のみになっているため、手が足りないというのが現状です。
この適用範囲を全体に広げたいと考えています。

QA x PM / QA x UX

要件定義段階で、仕様としての整合性を品質観点で確認することにより、初期フェーズでの問題の発見を強化したいと考えています。
これにより、リリース直前のテストフェーズでの手戻りを防ぐ事が可能になります。

QA x Engineering

GUI 操作も含め、自動テストの範囲を必要に応じて広げることでテストの実施コストや質を高めたいと考えています。
これによって、狩野モデルでいうところの魅力的品質を保証するためのテスト時間を捻出したいと考えています。

まとめ

Teachme Bizの開発における QA の歴史と未来、そして直近の課題についてまとめました。
先ほどご紹介した

・QA の適用範囲の拡大
・QA x PM / QA x UX
・QA x Engineering

これらを私と協力して推進してくれる QA エンジニアを求めています。
また、上記以外でも、 QA として取り組むべき課題を自ら発見して提案・推進してくださる方も歓迎しております。

現在スタディストでは一緒にマニュアル作成・共有プラットフォーム Teachme Biz の品質を高めてくれる仲間を絶賛募集しています。

ご興味を持っていただいた方は是非 ↓ をご覧ください!

スタディスト開発ブログ

スタディストの開発部がお届けする発展と成長の物語

Thanks to Kitano Katsuhisa

    Katsuhiko Tabei

    Written by

    スタディストの人事 Recruiting Operations です。またの名を「てぃーびー」といいます。

    スタディスト開発ブログ

    スタディストの開発部がお届けする発展と成長の物語

    Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
    Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
    Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade