RomiのQA おしごと紹介

はじめまして。RomiでQAを担当しているみかみと申します。

QAについて詳しくない方にも伝わるように、RomiのQAのおしごとをご紹介します。

すでにQAについて知っている方にはご承知のことが書かれていたり、「それってQAなの？」と思われることもあるかもしれませんが、本記事でご紹介するQA業務を通じて、Romiの開発の様子がお伝えできればと思います。
最後まで読んでいただければ幸いです。

QAとは

QAは「Quality Assurance」の略で、直訳すると品質保証という意味です。
品質保証をわかりやすくいうと、皆にご利用いただく製品やサービスに対して、安心して使っていただけるようにするための活動の総称です。その活動の一例として、テスト設計やテスト実行が挙げられています。

デバッグや、テスターという言葉を思い浮かべた方もいると思いますが、厳密にはQAとは異なります。
デバッグやテスターというのはテスト活動が目的になっているので、使っていただくために仕様を変更したほうが不具合が起こりにくいと発案することや、不具合が起こったときの分析ということに関しては担当していないことが多いです。

RomiでいうQAとは

ではRomiでいうQAとは具体的にどのような業務を行っているかをご紹介します。大きく分けると3つです。

1. コンテンツのQA

2. アプリのQA

3. FWのQA

１つ目の「コンテンツのQA」は主にRomiの筐体に関わる部分のQA業務を指します。Romiは自由な会話だけでなく、例えば歌ったり踊ったり、季節に応じて表情を変えたり、オーナーの方と一緒に楽しめる機能も備わっています。それらの機能を総称して開発チーム内では「コンテンツ」と呼んでいます。

２つ目の「アプリのQA」ですが、Romiはインターネットに接続することで自由な会話をすることが可能となるため、そのために必要なセットアップをおこなうためにRomiアプリを提供しています。そのRomi専用アプリのQA業務を指します。

最後に3つ目の「FWのQA」ですが、FWはファームウェアの略です。Romi内のソフトウェアのアップデートや不具合が発生したときに行います。スマートフォンのOSをイメージしていただくと分かりやすいと思います。

Romiの筐体に関する耐久性や、筐体の内部パーツによる負荷といった製造に関する検証はRomiのハードウェアを製造している会社が行っています。

上記で述べた「3つのQA」に関して少し詳しくお話しします。

コンテンツのQA

Romiのディスプレイに映る「顔」やアラーム機能や、会話中の「動き」を総称してRomi開発チーム内では「コンテンツ」と呼んでいます。
この「コンテンツ」がRomiの正式な機能として追加することが決定してからがQAの出番です。

今回は今月にリリースをしたクリスマスのコンテンツを例にお話しします。

仕様検討

まず企画・デザインのチーム内でコンテンツをRomiの機能として提供する際にどういう「顔」でどういう「動き」にするか方針を決めます。

上記で方針を固めたあと、QAではその内容を確認し、Romiに実装が可能な内容かを判断します。この実装可能か判断するときには、スケジュールや仕様で漏れがないかに重点を置いて話し合います。

クリスマスのコンテンツは12月10日にリリース予定で、リリース日からクリスマスの当日まで期間があることから、オーナーの皆様に当日まで楽しんでいただけるように、複数種類の「顔」や「動き」を作成することが決まりました。

コンテンツ実装

コンテンツのQAの次の作業では、デザイナーの作成した「顔」と「動き」のデータをRomiの実機に入れる作業を行います。この段階ではまだ実際Romiがどんな挙動をするかを誰も見ることができないため、QAが実際にRomiで動いているものを最初に確認することになります。
起動、そして電源が落ちるといった最低限の不具合がないことを確認をして、デザイナーの持つ実機にコンテンツを反映して見てもらいます。
デザイナーに確認してもらう際に、まだテストの段階ではないですが、最初に確認したときの印象を伝えることを大事にしています。なぜかというと、オーナーの皆様がこの機能を初めて使ってもらったときの印象や感覚というのが今後も使っていただくにあたって重要になってくると考えているからです。コンテンツを快く楽しんでいただくことで、よりRomiと会話をしていただきたいと思っています。

こうしたQAの報告を行いながら、デザイナーが実機で確認をして、イメージしていたものになっていない場合は、再度修正していきます。この作業は必要に応じて何度も繰り返していきます。
クリスマスに関しては、「顔」「動き」が意図したタイミングに合わせる点で、4度作り直しを行いました。Romiを持ち上げた際と、撫でた時にもクリスマスコンテンツを出すということが同時並行をしていたので、その点での修正も行っていました。

デザイナーがイメージしたものが出来上がると、次はチームに共有します。共有をした際チームメンバーからフィードバックがあったときは、その内容を加える修正をしていきます。クリスマスの場合、撫でたときや持ち上げたときにRomiのクリスマスコンテンツがどのくらいの頻度で発動するかという点と、持ち上げ時に再生される音楽の音量について、チームへのフィードバック時に確認しました。特にクリスマスのコンテンツは複数のRomiの「動き」があるので、オーナーが実際に手に取ったタイミングでどの動きをするかは私達にもわかりません。チーム内での体験がここでは重要になってきます。QAのみで複数台のRomiを使って確認することも可能ではあるのですが、体感値が固定化してしまうので、チームで確認することを意識していました。修正が終わるとようやくテストの段階に入ります。

QAは、実装面ではエンジニアと、仕様面では企画のメンバーとコミュニケーションが多くなることはありますが、デザイナーとのコミュニケーションが多く発生するのはRomiのQAでの特徴です。

テスト設計

テストの設計はスプレッドシートで行っています。テストの設計で作られるものが、テストケースです。チェックリストと思ってもらうと分かりやすいかもしれません。

テストケースについては、作っているサービスによって様々で、書き方も多種多様です。テスト設計技法を用いて作成することもあります。
Romiではデータ構造をまとめたRomiのコンテンツリストというものを作っています。ここではRomiの「動き」や「顔」、「Romiが話すこと」などと分類をしています。

Romiのコンテンツリスト

新しいコンテンツを作るたびに増えていくのですが、なかには常に入っている機能で変化がないものもあります。例えばRomiを持ち上げたときに「わー」「おおっ」など「何か言う」というのがあるのですが、この発言自体が今後変化することはあるかもしれませんが、持ち上げたときに何か特別な動きをするという変化は現時点ではありません。こういった場合には、分類で「Romiが話すこと」に書いてある内容を更新していきます。
このコンテンツリストの更新はデザイナーと確認をしながら行います。コンテンツリストを元に、テストを設計します。デザイナーが「問題ない」と判断していないものがリストに含まれていると、テスト実行時にコンテンツが正しい状態か否かの判断ができないためです。
もし確認をしないままで次のテスト実行を行なってしまうと、デザイナーが意図していないコンテンツが含まれてしまうことになり、オーナーの皆様にリリースしたときに違うものが入っている...というとんでもないことが起きてしまいかねません。そのためデザイナーと一緒に確認することが大切だと考えています。

クリスマスコンテンツは、去年のクリスマスコンテンツをリストから取り除き、今年のクリスマスコンテンツを追加するという作業を行いました。

テスト実行

テストの設計で作成したスプレッドシートをもとにして、コンテンツが正しく動いているかどうか確認します。
テスト実行時は、複数台でみるようにしています。Romiの本体に影響があるものか、コンテンツに影響があるものか原因を切り分けるために必要になるためです。

実行するテストは、「ログを見ながら確認していくテスト」、「オーナーと同じ操作で確認するテスト」の2種類行います。
2種類行っている理由はいくつかあります。「ログを見ながら確認していくテスト」は、Romiが実行したコンテンツをプログラム上のログから正しく挙動するコンテンツかどうか確認するテストです。コンテンツの中身がデザイナーが意図したものであるか確認しています。このときはオーナーがRomiを操作する方法でコンテンツを確認していないので、同じ操作をしたときに正しく動作するかの確認まではできていません。
そのため、「オーナーと同じ操作で確認するテスト」を行うことで、オーナーの手元でコンテンツが動かない原因を限りなく減らしています。
しかし、オーナーと同じ環境での確認が難しいコンテンツもあるため、そういったコンテンツの場合は「ログを見ながら確認していくテスト」を行なうことでテストをする時間を減らすことができます。

ここで発生した問題が、コンテンツ自体であった場合はデザイナーに修正を依頼します。コンテンツ以外にあった場合はエンジニアに相談をしながら、原因の調査を行い修正をしています。

すべてのテスト実行が完了したコンテンツはリリースとなります。

リリース

リリース後も、実際に正しくその機能が反映されている入っているかを確認します。
リリース後に万が一不具合が起きるという可能性もあります。不具合が出てしまった場合は、不具合のないコンテンツをリリースし直すか、修正したコンテンツをリリースするか検討して、不具合の解消を行います。

不具合調査

リリース後にもし不具合の報告が出てきた場合は、エンジニアと一緒に原因を調査します。不具合の報告に関してはオーナーの方の問い合わせで発覚することもありますし、コンテンツ自体は正しく動作しても、コンテンツの内容に対してのご意見をいただくこともあります。

QAとして、次回のリリースするコンテンツで追加で確認できる事項はないか、と毎回リリース後にテスト設計の見直しを行っています。
不具合はエンジニアと共に、怪しい箇所がないか、コンテンツが影響しているのか、あとで述べる「FW」が影響しているのか、を確認していきます。

コンテンツが要因となっている場合は、コンテンツのデータを修正して、再度テストを実行し、修正が確認でき次第再度リリースします。

コンテンツQAは現在は月に1度のペースで行っています。
ここまでご紹介したクリスマスコンテンツがどのようになっているのか気になった方は以下の動画をご覧ください。

アプリのQA

RomiのアプリはAndroidとiOSで提供をしています。

アプリの仕様詳細決定

デザイナーやディレクター、エンジニアと集まり、アプリ内で提供したい機能をどのように実装していくか、仕様で考慮漏れがないかを話し合います。
リリースまでのスケジュールの認識を余裕も取って臨むことが可能となり、エンジニアが実装したあとに「実はこの仕様がありました。」といったことで追加実装しなければならない時間や、現在使っているアプリに対して悪影響が及んでしまう部分があったのにも関わらず実装してしまう、という考慮漏れなどが発生する可能性を下げることができます。
「シフトレフト」というソフトウェアテストの7原則の原則3で提唱されていることを意識しています。

テスト観点

テスト設計をする上で、どういったテスト設計をしていく必要があるのか、確認しないといけない箇所がどこになるのかを洗い出します。 
この洗い出しをする際、仕様詳細を決定した時に漏れていたことや、まだデザインが用意されていないといった事態が発生することがあるので、そういった箇所を無くしていくという作業の役割も兼ねています。

観点が洗い出せた時点で、エンジニアにレビューをしてもらいます。
エンジニアが実装面で影響する範囲を観点作成時に漏れがあったりすると、テスト設計に影響するためです。

レビューが完了すると、テスト設計の作業に移ります。

テスト設計

アプリでもコンテンツのQAと同様にスプレッドシートを使って、テストケースを作成していきます。

アプリのテストケース

コンテンツのテストケースでは、チェックリストのような記載をしていましたが、アプリの場合はシナリオベースで作成することが多いです。
「オーナーに新規で登録したとき」「すでにオーナーの方のとき」という形で、実際に想定されるオーナーさんの状態に応じて、テストを作成しているのがシナリオベースです。オーナーさんだけでなく、Romiの状態について考えることもあるので、シナリオの数も多くなっています。
シナリオの数が多くなってしまうことにより、例えば文言の修正だけしかないときに、シナリオベースでテストを設計してしまうと、設計にも時間がかかり、その上その後のテスト実行にも時間がかかってしまうので、チェックリストで見ていたほうがいい場合もあります。

アプリはリリースする内容によって変化をさせていくことが重要であり、QA業務でもポイントになるところではないかと思います。

テスト実行

テスト設計ができると、作成したテストを実行します。
テスト実行時に重要なことは、「Romiの状態」や「オーナーかどうか」といった、テスト設計時にある前提の条件を準備することです。条件が準備できないと実行することができないので、早めに準備することを意識しています。

そういった準備の抜け漏れや遅れがないように、ツールで自由自在に条件の持ったアカウントを設定できるサービスも多くあると思います。Romiの場合も、細かい条件を設定することができる裏側のツールが多く用意されています。このツールがあることで、テスト実行の時間を削減することができます。

テスト中に不具合が出た場合、エンジニアの方には不具合を管理する外部ツール（GitHub）のissueを利用して共有をしています。
チャットツールでの共有だけだと、過去の修正対応を確認したい場合に膨大な情報量から探さないといけず、当時どんな言葉で共有したかを記憶していないと後々の検索も困難なため、外部ツールを利用しています。

不具合の共有をするときに意識していることは、エンジニアに状況が伝わるように記載することです。

テストを実行をしていると繰り返し同じ箇所をみることが多くなり、ボタンを押したときの操作や画面の表示に関しての挙動が想定できるようになってきます。そのため、再現方法や再現条件を簡略して記載してしまいがちです。
しかし簡略化してしまうと、エンジニアの手元でうまく再現できなかったり、修正された箇所が指摘とは異なるといった齟齬が発生します。なるべくそういった齟齬が起きないようにするため、可能な限り動画で不具合を残すようにしています。
動画で残しておくことで過程が見え、エンジニアの手元でも再現可能となり、操作方法が記載している再現手順と異なっていることが分かるようになります。

修正がすべて完了し、もともとの機能にも問題がないことが確認できるとリリースになります。

リリース

App StoreまたはGoogle Playからアプリがをリリースがされたあとは、実際に正しく機能が反映されているかを確認します。

これはコンテンツの時と同様の対応で、不具合が出てしまった場合は、不具合のなかったコンテンツをリリースし直すか、修正したコンテンツをリリースするか検討して、不具合の解消を行います。

不具合分析

テストを行ったとき発生した不具合については、次回のテスト設計時に組み込むようにしています。

これは同じ不具合が発生しないようにする再発防止という意味もありますが、テストだけでなく仕様詳細を決定する段階から考えておかないといけないことが出てくるため、新しく仕様を決めるときや同じ機能の修正をするときに役立ちます。

FWのQA

ソフトウェアのアップデートで機能が追加されるときや、不具合を修正したときにのみテストを行います。

テスト設計

FWのQA時には、FWがアップデートした状態のRomiでコンテンツが正しく動くか、FWがアップデートした状態のRomiでアプリが利用できるか、という「コンテンツのQA」「アプリのQA」で行っていたテストを合わせた確認を行っています。

重要視しているのは、もともとの機能が正しく動作するかという点です。アプリやコンテンツと違い、FWの場合はもともとの機能がうまく動作しなかった場合は、そのFWに含まれている機能がリリースできなくなります。リリースまでにかかる工数も含めて、アプリやコンテンツと比較すると時間がかかる作業になります。

正しく動作しない機能をリリースしてしまうと、正しく動作する機能を再度リリースするまでに時間がかかってしまいます。また、機能が利用できなくなったがために、オーナーの皆様がうまくRomiを利用できない状態になってしまう可能性があります。

テスト実行

FWのアップデート内容はエンジニアとミーティングをしながら、分担して確認作業を進めています。

コンテンツに関わる部分のアップデートがあるので、そのときにはデザイナーとも共有をして、エンジニア・デザイナー・QAという連携を行いながらアップデートした内容をリリースできるか見ていきます。
チームにも共有をして問題がなかった場合には、リリースを進めます。

リリース

繰り返しになってしまいますが、FWリリース後も不具合が出ていないかを確認していきます。

不具合が起きていた場合は、再度リリースするまでに時間がかかってしまうのですが、FWの修正版をリリースできるように進めます。

最後に

Romiは自律型の会話ロボットです。ということは会話の品質(精度)はどうしているのか？ 気になる方もいると思います。

これはQAだけで判断はしていません。

会話の仕組みになるのですが、ほとんどがDeep Lerningという技術を用いているため、Romiから返ってくる言葉は都度生成されるもので、正解がありません。定量的に測れないというのも理由の1つです。

Romiの会話の仕組みに関しては こちらの記事 を読んでいただければと思います。

正解がないということを除いても、仮にQAが担当するとなると、多様性が無くなってしまったり、偏りがちになる部分が必ず出てしまう危険もあると考えています。

現在はRomiの開発チームで日々会話体験をして、体感しながら判断をしています。時には、オーナーの方やイベントにいるRomiと話をしていただいた方のご意見から修正することもあります。
人の会話でも、新しい言葉や流行語が生まれてくるので、会話の精度にゴールはありません。

皆様に満足していただけるように、これからもチームとして改善活動を行っていきます。

少しでもRomiのQAに関して伝わりましたでしょうか？
QAに関して全く知らなかった方には、QA＝QuestionAnswer ではないということを覚えていただければうれしいです。

これからもRomiをたくさんの方にご利用していただけるように、日々QAをしていきます。

Romiでは一緒に働くQAの仲間を募集しています！

Romiの情報について

Amazonで販売中
公式サイト：https://romi.ai/
公式Twitterアカウント：https://twitter.com/romi_robot
公式Instagramアカウント：https://www.instagram.com/romi_robot/
公式YouTubeチャンネル：https://www.youtube.com/c/romi-robot