【イベントレポート】QAエンジニア勉強会

こんにちは!TECH Street編集部です!

今回は各社のQAエンジニアが集まり、実際の実務で得た知見や、課題、改善策などを共有しあう「QAエンジニア勉強会」の様子をレポートいたします。

登壇者はこの方々!
hagevvashiさん/株式会社カカクコム
長友 優治さん/クラスメソッド株式会社
銭丸 莉奈さん/株式会社iCARE

早速内容をご紹介いたします!

食べログのソフトウェアテスト自動化デザインパターン

■登壇資料はコチラ



まず食べログにテスト自動化を導入した背景について紹介します。
食べログではリリースから17年間、QA専門組織が存在せず、開発者が開発とQAを両方おこなってきました。その結果、テスト負担が増加しコード修正後のフィードバックが遅い、テストが再利用できないなどの課題を抱えていました。

そこで、2021年6月にQA専門組織を立ち上げ、テスト自動化を導入してソフトウェア化を進めてきました。

ただ、テスト自動化の導入は闇雲に行ってしまうと失敗しがちです。

(失敗例)
・今ある手動テストを単に自動化してしまう
・テスト実行の部分にしかフォーカスが当たっていない
・長期的にソフトウェアとしてメンテナンスしていくという視点が欠けている


そうならないためにテスト自動化で気をつけるポイントは3つあると考えています。

◆テスト自動化で気をつけるポイント
①最初から成功率100%を目指していないか
②テストケースの追加は簡単にできるか
③テスト実行ごとにテスト結果が同一か

この3つにフォーカスを当て事例と結果を紹介していきます。

Developer Productivityチームについて

内容に入る前に私が所属するDeveloper Productivityチームについて紹介いたします。

我々のチームは「開発サイクルのフィードバックを素早く、リッチにすることで最高の開発・テスト体験を実現する」というミッションを掲げて活動しています。

例えば【実装】や【テスト】など開発者の日々の業務がありますが、【実装】であれば<デバッグ>、【テスト】であれば<テスト結果のレポート>など様々な実行結果やテストレポートなどが開発者にフィードバックされています。開発環境やテスト環境の改善を通して、これらのフィードバックの充実化を図るようにしています。

このようなチームの特性をご理解いただいたうえで、DeveloperProductivityチームによる「食べログのテスト自動化」が、導入後どのような結果になったのか、デザインパターンの概要とともにお見せしたいと思います。

食べログのソフトウェアテスト自動化デザインパターン概要

赤い箱/食べログオリジナルのデザインパターン
白い箱/一般的な引用デザインパターン
箱同士の矢印/適応の順序

上から順にパターンを適用し、「このパターンを適用していくと、テスト自動化が成功しますよ」という風に読み取っていただけるかと思います。

結果的に下記の課題に対してテスト自動化を成功させることができました。

【課題】
・早期フィードバック
・テストの再利用の品質が低い

【結果】
・コード修正後、20分以内のフィードバック
・1日10回実行して成功率90%
・要件追従が2~3日でできる

 

テスト自動化基盤の登場人物とアーキテクチャの概要

続いて食べログテスト自動化基盤の登場人物とアーキテクチャの概要について紹介したいと思います。

今回の発表で説明するのは主にブラウザよりも左側についてです。

テストランナー/Cucumber
Cucumberは【SET】が管理する【Feature/Step/Page Object】といったモジュールで構成されていて、<テスト観点表>というテスト条件を網羅したものによって作られています。

これらのモジュールを構成するもととなるのがページ下段のテスト観点表です。
テスト観点表はテスト条件を洗い出したものとなっていて、ゆもつよメソッドを用いて作っています。

 

デザインパターンの詳細説明

続いてパターンの詳細説明に入りたいと思います。

テスト自動化で気をつける3つのポイントに対するパターンを紹介していきます。

最初から成功率100%を目指していないか
→いきなり100%を目指さない
テストケースの追加は簡単にできるか
→テストの実装容易性とフレームワークの変更容易性
テスト実行ごとにテスト結果が同一か
→安定したテストのためのテストケース自動化設計

<パターン概要①:いきなり100%目指さない>

図の状態としては、これからテスト自動化をプロジェクトに導入するところです。

最初から100%成功率を達成してから運用開始を目指すと、テスト自動化を始めてからアウトカムが出るのが遅くなる、あるいは保守にすごく最初から時間かかってしまう、といった問題でテスト自動化の導入に失敗してしまいがちです。

プロジェクトで実用的に使える、すなわちテスト自動化のアウトカムが出てくるのはスプリントがいくつも経過してからということになってしまいます。そうではなく、最初の1スプリントで95%成功率を達成するような計画を立てて、次からのスプリントで100%を目指して改善していく、というようにします。

「100%を最初から目指さない」ということが重要で、”95%”という数字や”スプリント”という表現というものは、あくまでこのデザインパターンを表現する時はメタファーでしかないので、プロジェクトに合わせて適切なものを選んでください。

ではこの”95%”を改善する仕組みを紹介します。
食べログでは「テスト自動化品質のダッシュボード」としてCircleCIの【insights】を使っています。
この【insights】というダッシュボードの特徴は「過去のテストの統計データ」を可視化してくれるところにあります。

・テストのStep数の推移
・実行ごとのテスト失敗率
・テスト実行時間

上記を可視化してくれて、なおかつ過去のすべてのテスト実施結果からテスト失敗率も計算して可視化してくれます。また、テスト失敗率に基づいてStepをソートして可視化も可能です。上から順に失敗率が高いテストが並んでいるという見方ができるため、これによってFlaky Testの特定が簡単にできるようになります。

ではそもそもこのようなFlaky Testを作り込まないために、どういった工夫をしているのかを次から紹介していきたいと思います。

 

<パターン概要②:容易なテスト実装、変更に強いフレームワーク設計>

テスト自動化のアーキテクチャの要求分析や、設計を完了して自動テストのデモができている状態です。

ここで紹介するパターンは、いわゆるフレームワーク設計のことを示しています。
Cucumberは【Featureファイル】と【Stepファイル】という要素で構成されており、テストコードからテスト手順と振る舞いを【Feature】として切り出すというような設計思想を意味しています。

しかし、これだけではまだ【Stepファイル】には色々な責務が残っています。例えば、ページが受け付けるブラウザ操作や、UIパーツが受け付けるプラウザ操作、またライブラリ依存の集約などです。

これらを別のオブジェクトに切り出していくことがメインテーマとなっております。
では、まず【Browser Automation  API Wrapper】パターンから紹介していきます。

ブラウザ操作を自動化するようなテストでは、テストアクションに機能を追加したいことが多数あります。
「食べログ」で検索するときのことを想像してください。

※シナリオ例
食べログの一覧ページを開く

一覧ページで検索条件を指定して検索ボタンをクリックする

検索結果画面に遷移して、レストランの並び順が1番上の店舗をクリック

店舗詳細を確認する

この一連の操作を、Cucumberを用いたテスト自動化ではテスト条件として定義しますが、一連の操作のどこかでテストが落ちてしまった場合、特定が難しいです。

そうならないためにも例えばクリックなどのアクションの直後に「スクリーンショットを撮る」というような機能を追加する必要性が出てくると思います。
そうすると【Stepファイル】の中に「クリックしてスクリーンショット撮る」という実装が散らばり始め、保守が大変になってきます。そこで「クリックしてスクリーンショットを撮る」というアクションを1か所に集約することによって、見つけやすくします。当然変更をしやすくなり、結果DRYな実装となります。

続いて【Page Object/Component Object】もご紹介します。

ブラウザの操作を自動化するテストにおいて、Stepファイル要素の特定処理というのを、Stepファイルに直接書いてしまいがちです。そうすると要素の一部だけの変更があった時にStepファイルのあらゆる箇所を保守しなければならなくなります。
こういった問題を解決するのが【Page Object/Component Object】パターンです。

【Page Object】や【Component Object】は、テスト対象ページのブラウザ操作を集約したオブジェクトです。また、【Page Object】は他のページと共有のUIパーツを【Component Object】として持っています。ページ、UIパーツ固有の情報を集約したオブジェクトを用意することによって画面仕様の変更時に対象オブジェクトを修正するだけで済むようになる、というのが大きなメリットです。また、一度【Page Object】を作ってしまえば、そのページに対する新しいテストの追加が簡単になり、そのページの保守がしやすくなる、というメリットもあります。

<パターン概要③:安定したテストのためのテストケース自動化>

フレームワーク設計が完了し、効率的にテストを保守できるようになっている状態と仮定します。

この状態になったら安定したテストのためのテストケース自動化設計がおすすめです。Flaky Testを減らし安定したテスト実装ができるようになります。

▼安定したテストのためのテストケース自動化における3つのパターン

JSONデータ駆動テスト
StepにWait処理を書かない
ログインタグ

1、JSONデータ駆動テスト

JSONデータ駆動テストはその名の通り、データ駆動テストを更に発展させたものです。
JSONデータ駆動テストは、データ駆動テストのテストパラメータへのデータパターンの追加が難しいという制限を解決しました。
例えば、図の黒い部分、これは”食べログ”でのレストランの検索のシナリオだと思ってください。

青い部分に2次元表のところでかれたセルのデータが入ってきます。このシナリオでは<都道府県>と<エリア1>という検索条件で検索するシナリオですが、例えば<エリア2>や<駅>という検索条件を追加したシナリオを作りたいとします。そういった時にはまず2次元表に列を追加し、それに伴い、Whenに変数の埋め込みを追加するため、Whenの文章が長くなります。その結果、ステップ関数を修正する必要があります。それは仕方のないことですが、今ある<都道府県>と<エリア1>で絞り込むテストとは別に「<エリア2>や<駅>というものを新たに用意してください」ということになるとStep関数を新たに作って対応する必要が出てきてしまいます。もっと複雑なデータ構造の時も同様にStep関数を増やすことで対応していかなければなりません。その原因は、2次元の表形式というのは、表現にある程度の制限があるからです。

こういった問題に対して、我々はこの”検索条件”や”期待結果”というような、シンプルな2列構造にして、それぞれの中にJSON(オブジェクト)で複雑なデータを表現しました。そうすることで、データの種類の追加削除が起きたとしてもテストの手順を変更せずに済むという非常に良いメリットが生まれます。

2、StepにWait処理を書かない

ブラウザ操作を自動化する自動テストでは「対象の要素がない」というエラーで落ちる可能性があります。落ちたり成功したりを繰り返すと、特定が難しくなってしまいます。そういったFlaky Testの出現を防ぐため、stepファイルに要素表示を待つ実装をしがちですが、実装をし忘れてしまうと特定の難しいFlaky Testを作り込んでしまいます。

確実に要素表示を待ってからテストアクションを実行したいため、要素表示を待つComponent Objectのメソッドの実行が完了するのを待ってからPage Objectのインスタンスを返すFactoryメソッドを作りました。その結果表示を待つ処理の実装漏れによるFlaky Testの作り込みが完全になくなりました。

3、ログインタグ

ログインが事前条件となるようなテストはよく実施されていると思います。
”食べログ”のメディアサイトにおいてはログインをしなくても使える機能が大多数な一方、口コミ投稿やネット予約など、“ログインしなければならない機能”というのが、とても重要です。

よってログインを事前条件とするようなテスト実行をしたいのですが、Cucumberでは実行単位がFeatureファイルであり、Featureファイルをまたいだ事前条件などで絞り込みができない、という課題がありました。そこでCucumberにあるタグの絞り込み機能を活用しました。タグで事前条件として”ログイン”というようなものを表現することで、事前条件のタグで絞り込んでテストができるようになりました。ここではログインタグという名前でパターンを紹介しましたが、ログインタグというのはあくまでメタファーでしかなく、ログインユーザの種別であったり様々な事前条件についてこのパターンを適用できます。

ここまで<テスト自動化で気をつける3つのポイント>をご紹介させていただきましたが、いかがでしたか。
ぜひ皆さんの現場でも役立てていただけたらと思います。

食べログでは現在、一緒にお仕事をしてくれるQAエンジニアを募集しています。
こちらもぜひご覧ください!

 

 

より早い段階からテストを - シフトレフトからその先を目指した考え方 -

www.docswell.com

皆さんはテストに対してどのような認識を持たれていますでしょうか?
私の周りではかなり重要だという認識を持っている方が多い印象です。最近は開発者の皆さんも、テストコードをしっかり書くというのが当たり前になってきているように思います。
実際にテストコードを書くと、フィードバックを早くもらえ、変更した部分をセーフティネットのようにチェック出来る、そういうメリットを感じ取られる方が多くなってテストの知見を持っている方は、すごく増えていると思います。

特にアジャイルでソフトウェア開発が主流になりつつあるいま、テストの自動化というのはすごく意識されているのでしょう。最後の方だけでテストするというのではなく、最初の方からテストを考えながら、ずっとテストし続けるということも、かなり意識されていると思います。

シフトレフトとは

私も最近は色々なイベントで【シフトレフト】という言葉をよく聞くようになりました。

【シフトレフト】とは
「テスト活動をソフトウェア開発ライフサイクルの最初の方にシフトすること」

というのが基本的な考えです。

図のように要件定義、設計、実装、テスト、リリースがある時に、左の方から意識してやっていくことで、【品質】の確認を計画段階から継続的に実施します。
【シフトレフト】のいいところはバグ予防やバグの早期発見ができることです。

私もテストには長く携わっていますが、今でも難しいな…と思うことがあります。
システムを十分にテストしたいと思っても、なかなか予算やスケジュールの関係で現実的に難しいです。ご存じかもしれませんが”テストの7原則”として<テストは欠陥があることは示せるけど欠陥がないことは示せません>や<全数テストは不可能>という原則があり、いろんな意味で頭を使う部分も多々あります。ある意味テストも”創造的な仕事”だと思っています。

 

テストレベルを考える

効果的にテストを作る=実用的といっていますが、そういうテストを考える際、最初に考えることの1つとしてコードの「どの部分」を「どのレベル」でテストするかが大切です。

系統的にまとめてマネジメントしていくテストの活動グループを指した言葉で【テストレベル】というものがあり、皆さんの馴染みのある言葉だと、「ユニットテスト」「統合テスト」「システムテスト」などが【テストレベル】です。
この【テストレベル】ごとにメリット、デメリットがあるので、よく考えてテストしていかなければならず、ここでもやはり頭を使います。

例えば「ユニットテスト」は高速でコントロールしやすくて、簡単に書けるというメリットがあります。ただ見つけられないバグなどがあり現実的でないのがデメリットです。ではシステムの「ある部分」を「どこのレベルでテストする」のかを考えるのか?

そこで参考になるものとして、【テストピラミッド】というものがあります。

【テストピラミッド】を見ると「ユニットテスト」が一番下にあり、大きなウェイトを占めています。「ユニットテスト」はより多く実施するようになってきていて、品質の貢献も増してきており、重要性がより求められています。ただ「ユニットテスト」だけでは、全ての品質を担保するにはなかなか難しいので、「統合テスト」「システムテスト」を使っての品質確認が必要です。

参考としてGoogleでは「ユニットテスト80% 統合テスト15% システムテスト5%」というニュアンスで小・中・大でテストを分けてとらえているようです。

 

テストに期待されること


次にテストに期待されることですが
・効果的かどうか
・体系的である
この2つだと思っています。


最初に「効果的である」ということですが、具体的には小さな労力で発見できるバグの数を多くすることが求められています。

テストはシステムのある一面しか発見できません。不具合が限られた部分しかわからず、結局選ばなければならない場面が出てくると思います。そうした時に効率的なテストというのは「何をテストすべきなのか」というのを知ることを考えることは、すごく大事になってくると思っています。

「体系的であること」ということは何かというと、テスト対象に対して、最近は誰が考えても同じようにテストケースの集まり(テストスイート)が出てくることが求められていると思います。なぜかというと「ユニットテスト」などはQAエンジニアやテストエンジニアではなく、開発者が考えるので、「誰がテストを作ったとしても、より良い効果的なテストが出来てこなければならない」となっています。そこで体系的に「誰がやっても」というのが重要だと思います。

では効果的で体系的なテストを作るには、どうした方がいいのか?テストエンジニアもより【シフトレフト】してどんどん関わっていくというのが大事になってくるのかなと思います。そうすることでバグの探索というのがより進んでいくことになりますし、エンジニアとテストエンジニアがうまく交流することで、テストの知見がどんどん広がっていく…ということがよりよくなっていくためには必要になってくるでしょう。

シフトレフトがどんどん進んでいくと、デリバリーサイクルの早い段階でテストに色々と取り組んでいくことになります。よりシフトレフトが深まって、色々な知見が出てくると、パフォーマンステストやセキュリティのテストなど「色々なテストをやろう」「こういうのをやっていかなきゃねとか」という状況が生まれます。すると「テストエンジニアが【品質】のことを考えればいい!」ということではなく、「品質はチームの責任」となって、チーム全体で様々な品質の確認を行うための適切なテストの知見を身につけることが不可欠になってきています。そうすることで、スピード感を持ってソフトウェアを提供できるようになっていくと思います。

テストもいろんな意味で進化してきており、今後もダイナミックに進化していくということが予想されます。よって新しいものが出てきた時に、考えるべきはテストの原理に立ち返ることがより重要になってくると私は考えています。

★欠陥の検出よりも欠陥の防止
★エンドユーザーの利益を念頭に

この2つを考えて「新しいものが出てきた時に、自分たちでどう取り入れるのか」を意識して動くといいでしょう。
また”品質”を高めるためにはチームの良好な協力関係っていうのを築くことがすごく大事になってきます。効果的なコミュニケーションを皆さんも意識して、どんどんテストの世界に進んでください。

QA経験2年で1人目QAエンジニアになって感じた課題と取り組み

■登壇資料はコチラ

まずはiCAREのプロダクトについてご紹介します。iCAREは健康管理システム『Carely』というプロダクトを開発しており、『Carely』は昨年、HRアワード2021を受賞しました。従業員のスマホからストレスチェックや健康診断の予約と結果閲覧、産業医メンバーとの面談などができる健康管理システムです。紙媒体ではなくてデータで従業員の健康管理ができるプロダクトを提供しています。

チームの成り立ちから現在

私が2021年6月に入社した時にQAEチームが発足して所属することになり、半年後1名追加され現在チームメンバーは2名です。
入社時点ではエンジニアの数が25名程度で、開発チームが3チームに分かれていて、各チームで新規機能のプロジェクトを並行して進めていました。
各プロジェクトのリリース頻度は平均的に1〜2か月に1回のミニウォーターフォールのような開発手法で、QAEチームが発足するまでは、エンジニアがテストを実行していました。

 

取り組みと感じた課題 

QAEチーム発足時は毎週1回の定常リリースに対して、重要項目リストのリグレションテストを実施していました。また各プロジェクトに対して、可能なプロジェクトのみテストを実施。
新機能のリリースに伴う一部ドキュメントの更新なども並行して行い、目の前の仕事を必死にこなしていく中で、いくつかの課題にぶつかりました。
 

 
課題①リリース直前に「この機能のテストできる?」という依頼が多発
→これにより首が回らなくなりました。
課題②定常リリースのリグレッションテストの工数が膨大
→1回そのリグレッションテストを回すのも300ケースありリソース的に苦くなりました
課題③チームメンバーのテストに関する知識が不足、さらに経験も浅く、テスト実施に対して自信が持てなかった
→こちらは知識不足な部分もありますが、バグが発生してCSチームにテストケースのレビューをしていただいても、どこか不安なままテストチェックをしていて、自信が持てないということが続いていました。

そこでこの3つの課題に対してそれぞれ改善策を打ち出しました。

課題①
リリース直前にテスト実施の依頼が多発し業務がひっ迫
 
改善策
「バグを発見ではなく防止」というのがQAEチームの理想だということを全社に対して啓蒙活動をしました。また全てのプロジェクトのキックオフミーティングに参加し、上流工程の段階で、QAEチームがどのようにプロジェクトに対して参加できるかというのをPMと相談するようにしました。
また、QAEチームは「今何やっているのか」がリアルタイムでわかるようにガントチャートを作成し、リソースの見える化を図りました。
 
依頼が来てからキャッチアップするのではなく、キックオフミーティングの上流工程から参加することで概要や進捗が見えているため、計画がしやすくなりました。また啓蒙活動することによって、エンジニア側の関心がテストに対しても高くなり、積極的にテストケース作成に協力してくれるようになりました。
 
結果的に限られたQAEチームのリソースの中で、プロダクトにおいて優先度が高いタスクに着手できるようになりました。

課題②
定常リリースのために毎週実行するリグレッションテストの工数が膨大
 
改善策
ローコードテストツールの『mabl』を導入しました。
このテスト自動化というのは作成やメンテナンスがボトルネックになる要因となりますが、週に1回、1時間は絶対にそのツールを触るという時間設定して、エンジニアも交えながらリグレッションテストの項目を少しずつ自動化していきました。
その結果、300ケースほどあるリグレッションテストの5%にあたる15ケースのテスト自動化に成功しました。今のところ時間的に時間的な効果で言うと、10分〜15分程度削減されただけですが、現在も引き続き自動化の作業時間を確保して進めています。

課題③
チームメンバーのテストに関する知識や経験が浅く、テスト実施に対しての自身が持てない
 
改善策
週に1回1時間、チーム内外のメンバーと勉強会を開催しました。
具体的には『Agile Testing Condensed』という本の輪読会や『ソフトウェアテスト技法の練習帳』を共に実施していきました。
チームメンバーの基礎的な技法の理解と、それを生かしたテストケースの作成ができるようになればと思っています。またQAEチーム以外のメンバーも巻き込むことでコミュニケーションが取れ、品質に対してもエンゲージメントが高まりを期待しています。またエンジニア自身の動作確認の精度向上というところを目指していければと考えています。

これまでの取り組みを通して成長したこと

これまでの取り組みを通して、個人的に1年間として成長した部分として、前職のスマートフォン向けアプリのQAだった時よりも”行動力”がすごく飛躍的に上がりました。
自分の裁量で、いくらでも結果が変わるので、自分がやるしかないという気持ちでいろんなことに挑戦できたと思っています。チームが立ち上がってからしばらくは、私も受け身で開発側からすると「依頼すれば何か発見してくれる」という認識だったと感じていました。しかし最近はエンジニアさん側から自発的に上流工程でのテスト作成に取り組むチームが増えているので、今後は上流工程から開発チームやそれ以外のチームなど全社的に巻き込んでテストを作り上げていきたいです。
また自分とチームメンバーの成長や、社内を巻き込む意味も込めて、勉強会の成果をアウトプットして積極的に情報発信していきたいと思います。

 

◆まとめ
いかがだったでしょうか。テストに携わるQAエンジニアたちのそれぞれの思考や工夫が見えた勉強会だったと思います。ぜひ今後の開発に役立ててください。

 

Q&A

ここからは当日のQ&Aを紹介します◎

 

>>次のページへ

 



(Q)テストケースの管理はどのようにされていますでしょうか? テストマネジメントツールなどが利用されている場合、どのように運用されているか知りたいです。
hagevvashiさん
まず、ざっくり「ゆもつよメソッド」で分析したテスト観点という大きな単位をMiroで管理しています。そこから細分化される個々の自動テストシナリオは、CucumberのFeatureファイルとして管理しています。

長友 優治さん
スプレッドシートやマークダウンで書かれていたり。統一されているというところまではいっていないです。

銭丸莉奈さん
各チームでもっているテストケースもあれば、QAチームでもっているテストケースもあります。

 

(Q)QAエンジニアは他のエンジニアとはココが違う(良い意味でも悪い意味でも)みたいな話ありますか?
長友 優治さん
より良いものをお客様に提供しようと思っているという点から考えても、特に違いはないと思っています。
銭丸莉奈さん
ビジネスサイドと開発サイドのどちらもテストを行うため、違いというよりは他のエンジニアよりもユーザーとの距離が近いのかなと思います。

 

(Q)QAエンジニア業務におすすめのツール・サービスがあればお聞きしたいです。
長友 優治さん
ご自身の携わっているものによると思うので、それぞれの状況で合ったものを探されるといいと思います。私の方から何かおすすめするものは今はないです。
銭丸莉奈さん
デシジョンテーブルや組み合わせテストなど、いろいろなテスト技法を手軽に利用できる「GIHOZ」というツールを重宝しています!
現在は主に社内のテスト技法の勉強会のために使用しています。

 

(Q)QAエンジニアのキャリアについて聞いてみたい
hagevvashiさん
私は元々フロントエンジニアで、QAエンジニアになったばかりです。
QAエンジニアになったきっかけはJSTQBのFoundation Level資格をもっていたので、QAチーム立ち上げのときにお声がけいただきました。
長友 優治さん
QAエンジニアを続ける人もいるし、エンジニアにいったり、プロマネにいったりという道もあります。
自分がやりたい道があれば、選択肢は沢山あると思います!

 

(Q)食べログさん自動化基盤すばらしい。どれくらいの期間でここまでたどり着いたのでしたのでしょうか?過去からの体制なんかも聞いてみたいです。
hagevvashiさん
専門家がいないことによる失敗体験もあり、専門組織ができたことはありませんでした。
自動化基盤は設計が2〜3か月、開発が1か月、追加が1か月です。

 

(Q)カカクコムさんの中でも食べログは特殊ですか?他の有名サービスもあるかと思いますが、共有化とか横連携はありますか?
hagevvashiさん
食べログでも始めたばかりなので、どれだけ使われるか、どれだけ成果が出るかを測ってから、横展開もあるかなと思ってます。
今後に期待したいプロジェクトです!

 

(Q)95%はプロジェクトや期間によって適切な数値に変更するとのことですが、食べログの95%はどのようにして決まったのか教えて欲しいです。
hagevvashiさん
どんぶり勘定で、目途を付けてやりました。結果論として効果が出ているので取り組んでみてよかったと思っています!

 

(Q)テスト観点の粒度を聞いてみたいです。
hagevvashiさん
ゆもつよメソッドでいうとカテゴリ分けします。「入力」というカテゴリにはどういう観点があるんだろうなど食べログで言うと、都道府県が1観点です。
全部揃っているわけではないですが、入力における条件を羅列して、過去の観点や障害報告で挙がったポイントなどを目安に作成しています。

 

(Q)使っているツール、サービス、フレームワークとかも聞いてみたいです。
長友 優治さん
テストはJUnitで書かれていて、CircleCIとか使ってデプロイ時に自動で動くようになっています。テスト設計とかは、チームによっていろいろで、スプレッドシートを使っているところなどもあります。
銭丸莉奈さん
テストケースの管理についてはスプレッドシートで管理しています。
また、回帰テストの自動化のためにローコードテスト自動化ツールの「mabl」を使用しています。

 

(Q)Shift Leftは弊社でも取り組んでいるのですが、炎上するPJTであればあるほど開発者が設計・開発に注力してしまいテストに対する対応がおざなりになってくることが多く。炎上系PJTの特徴として、DevとQAの仲が悪いというのがあります。リモートワークで顔がみえないせいも相まって。 開発者が忙しい中でもQAに時間を割いてもらう、仲をよくする工夫は何かしていますでしょうか?
長友 優治さん
そういう例は幸いないのですが…。
レビューの場にテストの人も入れてもらう。ド素人な質問でもいいのでコミュニケーションをとっていくと、エンジニアさんにも気づきがあるし関係構築もできてくる。
炎上しているエンジニアさんは困っているので、プロマネとの間に入っていってあげたり、寄り添えるところは寄り添ってあげる。テストができる状況であれば、その場でやってあげて、フィードバックを早く返してあげるとか、できることをやってあげるといいと思います。

 

(Q)体系的なテストって、「テスト観点」みたいなことでしょうか。
長友 優治さん
「観点」というより、もっと広いです。セキュリティなども含めて、「全部やるテスト」みたいなものです。
テストの全てについて体系的にみんなが理解できるようなものを作れると良いなと思います。

 

(Q)シフトレフトを意識された具体的な取り組みなどお伺いしたいです!(開発者との関わり方、タイミングなど)
長友 優治さん
QA担当者、私1人しかいないのですが、開発者の人と一緒にやる場面があり、そこでコミュニケーションを取れるタイミングがあった。その関係があったので、テストも早めに実施することができた。
それはすごくよかったです!

 

(Q)2名!がんばってますね!(ウチとおなじだからエールを送りたい)マジきついこと沢山ありますよね?エンジニアチームと仲良いです......?
銭丸莉奈さん
私は仲が良いと思っています(笑)
バグ報告をすると感謝されるので、驚きました!企業文化に温かさを感じています。

 

(Q)仕様などのドキュメントはどうやって管理されていますか?利用されているツール、更新頻度などお伺いしたいです!
銭丸莉奈さん
ドキュメントの管理は、ほぼスプレッドシートを活用しています。更新頻度は月に1回くらいです。

 

(Q)プロジェクトのテストと定期リリースのテストは別のテストスイートを使っているのでしょうか
銭丸莉奈さん
定期リリースについては定常のものがあります。プロジェクトは別途テンプレートがあるので、そちらを使っています。

 

(Q)全社への啓蒙活動、理解を得るのは大変ですよね。具体的にどんな啓蒙活動をされてますか?
銭丸莉奈さん
会社の文化として、各部署によって何を目指しているのか何を行っているのか、月に一度報告をしているので、QAチームの活動や目指すところを発信しています。

 

(Q)リソースの見える化をしたら、無茶振りは無くなりましたか?
銭丸莉奈さん
鋭い...!なくなってはないですが、少なくはなったかなと感じています。

 

(Q)めげずに情報発信、大事!(工夫とか聞きたい)
銭丸莉奈さん
わたし自身経験が浅いのですが、QAに対する知識がない方向けに分かりやすい記事を共有したり、啓蒙活動をしています。

 

(Q)上流工程での巻き込みではどんな取り組みがされていますか?
銭丸莉奈さん
プロジェクトの最初のMTGに参加したり、各チームとコミュニケーションをとって、QAをどうしたらいいか確認しています。

 

(Q)エンジニアさんはとにかくテストしたくない!不具合があったら修正すればいいんじゃない?ということでテストをほぼしないのですがどういう啓蒙からはじめるといいでしょうか・・・(同じくQA1人目です
銭丸莉奈さん
チーム全員で品質担保に対する意識上げを行ったらよいと思います!

 

(Q)手動テストは、スクショのエビデンスがセットですか? 請負系の案件の場合、テスト結果の成果物が必要なイメージなので。。。(自社サービスだと明確なフォーマットが決まってないのかなと感じました)
長友 優治さん
不具合が見つかって報告する場合には取ります。特に問題がないのであれば取りません。
UI系で自動化しているテストでは、最近はスクショより動画を撮っておく方が実際にどのような不具合なのかわかりやすいので、そういうのを取れるといいと思っています。
銭丸莉奈さん
不具合報告や不具合まで行かなくても気になったUIについてはスクショや動画を撮ったりエビデンスに使用しますが、それ以外のテストの成果物についてはスクショは撮っていないです。

 

(Q)プロダクトの仕様についてシステム仕様とサービス仕様があり、システム仕様はUTやテストコード、E2E自動化でのアプローチが有用かと思うのですが、サービス仕様へのテストのアプローチはどのような取り組みをされていたり、気にされてますでしょうか
長友 優治さん
システム仕様、サービス仕様と区分けされているのであれば、それぞれをよく読み、また作られた方々にもいろいろ聞いて、テストを考えると思います。特にサービス仕様だからといったような取り組みの違いはないのかと思っています。お客様の求める品質がどういうものなのか、ご自身たちのイメージとのギャップをなくす。そうしたところからキャッチアップしていくといいのではないでしょうか。
銭丸莉奈さん
サービス仕様についてのアプローチとしては、実際のユーザーの使用例などをCSチームなどにヒアリングを行うことがあります。

 

(Q)皆さん何を成果物としていますか?
長友 優治さん
案件やプロジェクトごとに違います。その案件やプロジェクトで決めたものを成果物としています。最初に何をゴールとするかを関係者で握っておくということが大事になってきます。
銭丸莉奈さん
テスト実施したテストケースも成果物ですが、プロジェクトによってテストケース作成だけを行ったり、開発側で作成されたテストケースをレビューするだけの時もあり、その時々で成果物は違いますね。

 

以上が今回のイベントレポートです!次回のイベントもお楽しみに^^