Street編集部です!今回は各社のQAエンジニアが集まり、実際の実務で得た知見や、課題、改善策などを共有しあう「QAエンジニア勉強会」の様子をレポートいたします。莉奈さん/株式会社iCARE早速内容をご紹介いたします!食べログのソフトウェアテスト自動化デザインパターン■登壇資料はコチラまず食べログにテスト自動化を導入した背景について紹介します。食べログではリリースから17年間、QA専門組織が存在せず、開発者が開発とQAを両方おこなってきました。その結果、テスト負担が増加しコード修正後のフィードバックが遅い、テストが再利用できないなどの課題を抱えていました。そこで、2021年6月にQA専門組織を立ち上げ、テスト自動化を導入してソフトウェア化を進めてきました。テスト自動化の導入は闇雲に行ってしまうと失敗しがちです。(失敗例)・今ある手動テストを単に自動化してしまう・テスト実行の部分にしかフォーカスが当たっていない・長期的にソフトウェアとしてメンテナンスしていくという視点が欠けているそうならないためにテスト自動化で気をつけるポイントは3つあると考えています。◆テスト自動化で気をつけるポイント1最初から成功率100%を目指していないか2テストケースの追加は簡単にできるか3テスト実行ごとにテスト結果が同一かこの3つにフォーカスを当て事例と結果を紹介していきます。Productivityチームについて紹介いたします。我々のチームは「開発サイクルのフィードバックを素早く、リッチにすることで最高の開発・テスト体験を実現する」というミッションを掲げて活動しています。【実装】や【テスト】など開発者の日々の業務がありますが、【実装】であれば<デバッグ>、【テスト】であれば<テスト結果のレポート>など様々な実行結果やテストレポートなどが開発者にフィードバックされています。開発環境やテスト環境の改善を通して、これらのフィードバックの充実化を図るようにしています。このようなチームの特性をご理解いただいたうえで、DeveloperProductivityチームによる「食べログのテスト自動化」が、導入後どのような結果になったのか、デザインパターンの概要とともにお見せしたいと思います。上から順にパターンを適用し、「このパターンを適用していくと、テスト自動化が成功しますよ」という風に読み取っていただけるかと思います。続いて食べログテスト自動化基盤の登場人物とアーキテクチャの概要について紹介したいと思います。今回の発表で説明するのは主にブラウザよりも左側についてです。Object】といったモジュールで構成されていて、<テスト観点表>というテスト条件を網羅したものによって作られています。これらのモジュールを構成するもととなるのがページ下段のテスト観点表です。テスト観点表はテスト条件を洗い出したものとなっていて、ゆもつよメソッドを用いて作っています。続いてパターンの詳細説明に入りたいと思います。テスト自動化で気をつける3つのポイントに対するパターンを紹介していきます。最初から成功率100%を目指していないか→いきなり100%を目指さないテストケースの追加は簡単にできるか→テストの実装容易性とフレームワークの変更容易性テスト実行ごとにテスト結果が同一か→安定したテストのためのテストケース自動化設計<パターン概要1:いきなり100%目指さない>図の状態としては、これからテスト自動化をプロジェクトに導入するところです。最初から100%成功率を達成してから運用開始を目指すと、テスト自動化を始めてからアウトカムが出るのが遅くなる、あるいは保守にすごく最初から時間かかってしまう、といった問題でテスト自動化の導入に失敗してしまいがちです。プロジェクトで実用的に使える、すなわちテスト自動化のアウトカムが出てくるのはスプリントがいくつも経過してからということになってしまいます。なく、最初の1スプリントで95%成功率を達成するような計画を立てて、次からのスプリントで100%を目指して改善していく、というようにします。「100%を最初から目指さない」ということが重要で、”95%”という数字や”スプリント”という表現というものは、あくまでこのデザインパターンを表現する時はメタファーでしかないので、プロジェクトに合わせて適切なものを選んでください。この”95%”を改善する仕組みを紹介します。食べログでは「テスト自動化品質のダッシュボード」としてCircleCIの【insights】を使っています。この【insights】というダッシュボードの特徴は「過去のテストの統計データ」を可視化してくれるところにあります。上記を可視化してくれて、なおかつ過去のすべてのテスト実施結果からテスト失敗率も計算して可視化してくれます。テスト失敗率に基づいてStepをソートして可視化も可能です。Testの特定が簡単にできるようになります。Testを作り込まないために、どういった工夫をしているのかを次から紹介していきたいと思います。<パターン概要2:容易なテスト実装、変更に強いフレームワーク設計>テスト自動化のアーキテクチャの要求分析や、設計を完了して自動テストのデモができている状態です。ここで紹介するパターンは、いわゆるフレームワーク設計のことを示しています。Cucumberは【Featureファイル】と【Stepファイル】という要素で構成されており、テストコードからテスト手順と振る舞いを【Feature】として切り出すというような設計思想を意味しています。これだけではまだ【Stepファイル】には色々な責務が残っています。ページが受け付けるブラウザ操作や、UIパーツが受け付けるプラウザ操作、またライブラリ依存の集約などです。これらを別のオブジェクトに切り出していくことがメインテーマとなっております。Wrapper】パターンから紹介していきます。ブラウザ操作を自動化するようなテストでは、テストアクションに機能を追加したいことが多数あります。「食べログ」で検索するときのことを想像してください。店舗詳細を確認するこの一連の操作を、Cucumberを用いたテスト自動化ではテスト条件として定義しますが、一連の操作のどこかでテストが落ちてしまった場合、特定が難しいです。ならないためにも例えばクリックなどのアクションの直後に「スクリーンショットを撮る」というような機能を追加する必要性が出てくると思います。すると【Stepファイル】の中に「クリックしてスクリーンショット撮る」という実装が散らばり始め、保守が大変になってきます。そこで「クリックしてスクリーンショットを撮る」というアクションを1か所に集約することによって、見つけやすくします。変更をしやすくなり、結果DRYな実装となります。Object】もご紹介します。ブラウザの操作を自動化するテストにおいて、Stepファイル要素の特定処理というのを、Stepファイルに直接書いてしまいがちです。すると要素の一部だけの変更があった時にStepファイルのあらゆる箇所を保守しなければならなくなります。Object】パターンです。Object】は、テスト対象ページのブラウザ操作を集約したオブジェクトです。Object】として持っています。ページ、UIパーツ固有の情報を集約したオブジェクトを用意することによって画面仕様の変更時に対象オブジェクトを修正するだけで済むようになる、というのが大きなメリットです。Object】を作ってしまえば、そのページに対する新しいテストの追加が簡単になり、そのページの保守がしやすくなる、というメリットもあります。<パターン概要3:安定したテストのためのテストケース自動化>フレームワーク設計が完了し、効率的にテストを保守できるようになっている状態と仮定します。この状態になったら安定したテストのためのテストケース自動化設計がおすすめです。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処理を書かないブラウザ操作を自動化する自動テストでは「対象の要素がない」というエラーで落ちる可能性があります。落ちたり成功したりを繰り返すと、特定が難しくなってしまいます。Testを作り込んでしまいます。Objectのインスタンスを返すFactoryメソッドを作りました。Testの作り込みが完全になくなりました。3、ログインタグログインが事前条件となるようなテストはよく実施されていると思います。”食べログ”のメディアサイトにおいてはログインをしなくても使える機能が大多数な一方、口コミ投稿やネット予約など、“ログインしなければならない機能”というのが、とても重要です。よってログインを事前条件とするようなテスト実行をしたいのですが、Cucumberでは実行単位がFeatureファイルであり、Featureファイルをまたいだ事前条件などで絞り込みができない、という課題がありました。そこでCucumberにあるタグの絞り込み機能を活用しました。タグで事前条件として”ログイン”というようなものを表現することで、事前条件のタグで絞り込んでテストができるようになりました。ここではログインタグという名前でパターンを紹介しましたが、ログインタグというのはあくまでメタファーでしかなく、ログインユーザの種別であったり様々な事前条件についてこのパターンを適用できます。ここまで<テスト自動化で気をつける3つのポイント>をご紹介させていただきましたが、いかがでしたか。皆さんの現場でも役立てていただけたらと思います。食べログでは現在、一緒にお仕事をしてくれるQAエンジニアを募集しています。-www.docswell.com皆さんはテストに対してどのような認識を持たれていますでしょうか?私の周りではかなり重要だという認識を持っている方が多い印象です。最近は開発者の皆さんも、テストコードをしっかり書くというのが当たり前になってきているように思います。実際にテストコードを書くと、フィードバックを早くもらえ、変更した部分をセーフティネットのようにチェック出来る、そういうメリットを感じ取られる方が多くなってテストの知見を持っている方は、すごく増えていると思います。アジャイルでソフトウェア開発が主流になりつつあるいま、テストの自動化というのはすごく意識されているのでしょう。最後の方だけでテストするというのではなく、最初の方からテストを考えながら、ずっとテストし続けるということも、かなり意識されていると思います。シフトレフトとは私も最近は色々なイベントで【シフトレフト】という言葉をよく聞くようになりました。【シフトレフト】とは「テスト活動をソフトウェア開発ライフサイクルの最初の方にシフトすること」というのが基本的な考えです。テスト、リリースがある時に、左の方から意識してやっていくことで、【品質】の確認を計画段階から継続的に実施します。【シフトレフト】のいいところはバグ予防やバグの早期発見ができることです。私もテストには長く携わっていますが、今でも難しいな...と思うことがあります。システムを十分にテストしたいと思っても、なかなか予算やスケジュールの関係で現実的に難しいです。ご存じかもしれませんが”テストの7原則”として<テストは欠陥があることは示せるけど欠陥がないことは示せません>や<全数テストは不可能>という原則があり、いろんな意味で頭を使う部分も多々あります。ある意味テストも”創造的な仕事”だと思っています。テストレベルを考える効果的にテストを作る=実用的といっていますが、そういうテストを考える際、最初に考えることの1つとしてコードの「どの部分」を「どのレベル」でテストするかが大切です。系統的にまとめてマネジメントしていくテストの活動グループを指した言葉で【テストレベル】というものがあり、皆さんの馴染みのある言葉だと、「ユニットテスト」「統合テスト」「システムテスト」などが【テストレベル】です。この【テストレベル】ごとにメリット、デメリットがあるので、よく考えてテストしていかなければならず、ここでもやはり頭を使います。「ユニットテスト」は高速でコントロールしやすくて、簡単に書けるというメリットがあります。見つけられないバグなどがあり現実的でないのがデメリットです。システムの「ある部分」を「どこのレベルでテストする」のかを考えるのか?そこで参考になるものとして、【テストピラミッド】というものがあります。【テストピラミッド】を見ると「ユニットテスト」が一番下にあり、大きなウェイトを占めています。「ユニットテスト」はより多く実施するようになってきていて、品質の貢献も増してきており、重要性がより求められています。「ユニットテスト」だけでは、全ての品質を担保するにはなかなか難しいので、「統合テスト」「システムテスト」を使っての品質確認が必要です。システムテスト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ケースありリソース的に苦くなりました課題3チームメンバーのテストに関する知識が不足、さらに経験も浅く、テスト実施に対して自信が持てなかった→こちらは知識不足な部分もありますが、バグが発生してCSチームにテストケースのレビューをしていただいても、どこか不安なままテストチェックをしていて、自信が持てないということが続いていました。そこでこの3つの課題に対してそれぞれ改善策を打ち出しました。「バグを発見ではなく防止」というのがQAEチームの理想だということを全社に対して啓蒙活動をしました。全てのプロジェクトのキックオフミーティングに参加し、上流工程の段階で、QAEチームがどのようにプロジェクトに対して参加できるかというのをPMと相談するようにしました。QAEチームは「今何やっているのか」がリアルタイムでわかるようにガントチャートを作成し、リソースの見える化を図りました。依頼が来てからキャッチアップするのではなく、キックオフミーティングの上流工程から参加することで概要や進捗が見えているため、計画がしやすくなりました。啓蒙活動することによって、エンジニア側の関心がテストに対しても高くなり、積極的にテストケース作成に協力してくれるようになりました。結果的に限られたQAEチームのリソースの中で、プロダクトにおいて優先度が高いタスクに着手できるようになりました。改善策ローコードテストツールの『mabl』を導入しました。このテスト自動化というのは作成やメンテナンスがボトルネックになる要因となりますが、週に1回、1時間は絶対にそのツールを触るという時間設定して、エンジニアも交えながらリグレッションテストの項目を少しずつ自動化していきました。その結果、300ケースほどあるリグレッションテストの5%にあたる15ケースのテスト自動化に成功しました。今のところ時間的に時間的な効果で言うと、10分〜15分程度削減されただけですが、現在も引き続き自動化の作業時間を確保して進めています。週に1回1時間、チーム内外のメンバーと勉強会を開催しました。Condensed』という本の輪読会や『ソフトウェアテスト技法の練習帳』を共に実施していきました。チームメンバーの基礎的な技法の理解と、それを生かしたテストケースの作成ができるようになればと思っています。QAEチーム以外のメンバーも巻き込むことでコミュニケーションが取れ、品質に対してもエンゲージメントが高まりを期待しています。エンジニア自身の動作確認の精度向上というところを目指していければと考えています。これまでの取り組みを通して成長したことこれまでの取り組みを通して、個人的に1年間として成長した部分として、前職のスマートフォン向けアプリのQAだった時よりも”行動力”がすごく飛躍的に上がりました。自分の裁量で、いくらでも結果が変わるので、自分がやるしかないという気持ちでいろんなことに挑戦できたと思っています。チームが立ち上がってからしばらくは、私も受け身で開発側からすると「依頼すれば何か発見してくれる」という認識だったと感じていました。最近はエンジニアさん側から自発的に上流工程でのテスト作成に取り組むチームが増えているので、今後は上流工程から開発チームやそれ以外のチームなど全社的に巻き込んでテストを作り上げていきたいです。自分とチームメンバーの成長や、社内を巻き込む意味も込めて、勉強会の成果をアウトプットして積極的に情報発信していきたいと思います。◆まとめいかがだったでしょうか。テストに携わるQAエンジニアたちのそれぞれの思考や工夫が見えた勉強会だったと思います。今後の開発に役立ててください。テストマネジメントツールなどが利用されている場合、どのように運用されているか知りたいです。hagevvashiさんまず、ざっくり「ゆもつよメソッド」で分析したテスト観点という大きな単位をMiroで管理しています。そこから細分化される個々の自動テストシナリオは、CucumberのFeatureファイルとして管理しています。優治さんスプレッドシートやマークダウンで書かれていたり。統一されているというところまではいっていないです。銭丸莉奈さん各チームでもっているテストケースもあれば、QAチームでもっているテストケースもあります。優治さんより良いものをお客様に提供しようと思っているという点から考えても、特に違いはないと思っています。銭丸莉奈さんビジネスサイドと開発サイドのどちらもテストを行うため、違いというよりは他のエンジニアよりもユーザーとの距離が近いのかなと思います。(Q)QAエンジニア業務におすすめのツール・サービスがあればお聞きしたいです。優治さんご自身の携わっているものによると思うので、それぞれの状況で合ったものを探されるといいと思います。私の方から何かおすすめするものは今はないです。銭丸莉奈さんデシジョンテーブルや組み合わせテストなど、いろいろなテスト技法を手軽に利用できる「GIHOZ」というツールを重宝しています!現在は主に社内のテスト技法の勉強会のために使用しています。(Q)QAエンジニアのキャリアについて聞いてみたいhagevvashiさん私は元々フロントエンジニアで、QAエンジニアになったばかりです。Level資格をもっていたので、QAチーム立ち上げのときにお声がけいただきました。優治さんQAエンジニアを続ける人もいるし、エンジニアにいったり、プロマネにいったりという道もあります。自分がやりたい道があれば、選択肢は沢山あると思います!(Q)食べログさん自動化基盤すばらしい。どれくらいの期間でここまでたどり着いたのでしたのでしょうか?過去からの体制なんかも聞いてみたいです。hagevvashiさん専門家がいないことによる失敗体験もあり、専門組織ができたことはありませんでした。自動化基盤は設計が2〜3か月、開発が1か月、追加が1か月です。(Q)カカクコムさんの中でも食べログは特殊ですか?他の有名サービスもあるかと思いますが、共有化とか横連携はありますか?hagevvashiさん食べログでも始めたばかりなので、どれだけ使われるか、どれだけ成果が出るかを測ってから、横展開もあるかなと思ってます。今後に期待したいプロジェクトです!(Q)95%はプロジェクトや期間によって適切な数値に変更するとのことですが、食べログの95%はどのようにして決まったのか教えて欲しいです。hagevvashiさんどんぶり勘定で、目途を付けてやりました。結果論として効果が出ているので取り組んでみてよかったと思っています!(Q)テスト観点の粒度を聞いてみたいです。hagevvashiさんゆもつよメソッドでいうとカテゴリ分けします。「入力」というカテゴリにはどういう観点があるんだろうなど食べログで言うと、都道府県が1観点です。全部揃っているわけではないですが、入力における条件を羅列して、過去の観点や障害報告で挙がったポイントなどを目安に作成しています。(Q)使っているツール、サービス、フレームワークとかも聞いてみたいです。優治さんテストはJUnitで書かれていて、CircleCIとか使ってデプロイ時に自動で動くようになっています。テスト設計とかは、チームによっていろいろで、スプレッドシートを使っているところなどもあります。銭丸莉奈さんテストケースの管理についてはスプレッドシートで管理しています。回帰テストの自動化のためにローコードテスト自動化ツールの「mabl」を使用しています。Leftは弊社でも取り組んでいるのですが、炎上するPJTであればあるほど開発者が設計・開発に注力してしまいテストに対する対応がおざなりになってくることが多く。炎上系PJTの特徴として、DevとQAの仲が悪いというのがあります。リモートワークで顔がみえないせいも相まって。優治さんそういう例は幸いないのですが...。レビューの場にテストの人も入れてもらう。ド素人な質問でもいいのでコミュニケーションをとっていくと、エンジニアさんにも気づきがあるし関係構築もできてくる。炎上しているエンジニアさんは困っているので、プロマネとの間に入っていってあげたり、寄り添えるところは寄り添ってあげる。テストができる状況であれば、その場でやってあげて、フィードバックを早く返してあげるとか、できることをやってあげるといいと思います。(Q)体系的なテストって、「テスト観点」みたいなことでしょうか。優治さん「観点」というより、もっと広いです。セキュリティなども含めて、「全部やるテスト」みたいなものです。テストの全てについて体系的にみんなが理解できるようなものを作れると良いなと思います。優治さんQA担当者、私1人しかいないのですが、開発者の人と一緒にやる場面があり、そこでコミュニケーションを取れるタイミングがあった。その関係があったので、テストも早めに実施することができた。それはすごくよかったです!(Q)2名!がんばってますね!(ウチとおなじだからエールを送りたい)マジきついこと沢山ありますよね?エンジニアチームと仲良いです......?銭丸莉奈さん私は仲が良いと思っています(笑)バグ報告をすると感謝されるので、驚きました!企業文化に温かさを感じています。(Q)仕様などのドキュメントはどうやって管理されていますか?利用されているツール、更新頻度などお伺いしたいです!銭丸莉奈さんドキュメントの管理は、ほぼスプレッドシートを活用しています。更新頻度は月に1回くらいです。(Q)プロジェクトのテストと定期リリースのテストは別のテストスイートを使っているのでしょうか銭丸莉奈さん定期リリースについては定常のものがあります。プロジェクトは別途テンプレートがあるので、そちらを使っています。(Q)全社への啓蒙活動、理解を得るのは大変ですよね。具体的にどんな啓蒙活動をされてますか?銭丸莉奈さん会社の文化として、各部署によって何を目指しているのか何を行っているのか、月に一度報告をしているので、QAチームの活動や目指すところを発信しています。(Q)リソースの見える化をしたら、無茶振りは無くなりましたか?銭丸莉奈さん鋭い...!なくなってはないですが、少なくはなったかなと感じています。(Q)めげずに情報発信、大事!(工夫とか聞きたい)銭丸莉奈さんわたし自身経験が浅いのですが、QAに対する知識がない方向けに分かりやすい記事を共有したり、啓蒙活動をしています。(Q)上流工程での巻き込みではどんな取り組みがされていますか?銭丸莉奈さんプロジェクトの最初のMTGに参加したり、各チームとコミュニケーションをとって、QAをどうしたらいいか確認しています。請負系の案件の場合、テスト結果の成果物が必要なイメージなので。優治さん不具合が見つかって報告する場合には取ります。問題がないのであれば取りません。UI系で自動化しているテストでは、最近はスクショより動画を撮っておく方が実際にどのような不具合なのかわかりやすいので、そういうのを取れるといいと思っています。銭丸莉奈さん不具合報告や不具合まで行かなくても気になったUIについてはスクショや動画を撮ったりエビデンスに使用しますが、それ以外のテストの成果物についてはスクショは撮っていないです。優治さんシステム仕様、サービス仕様と区分けされているのであれば、それぞれをよく読み、また作られた方々にもいろいろ聞いて、テストを考えると思います。サービス仕様だからといったような取り組みの違いはないのかと思っています。お客様の求める品質がどういうものなのか、ご自身たちのイメージとのギャップをなくす。したところからキャッチアップしていくといいのではないでしょうか。銭丸莉奈さんサービス仕様についてのアプローチとしては、実際のユーザーの使用例などをCSチームなどにヒアリングを行うことがあります。優治さん案件やプロジェクトごとに違います。その案件やプロジェクトで決めたものを成果物としています。最初に何をゴールとするかを関係者で握っておくということが大事になってきます。銭丸莉奈さんテスト実施したテストケースも成果物ですが、プロジェクトによってテストケース作成だけを行ったり、開発側で作成されたテストケースをレビューするだけの時もあり、その時々で成果物は違いますね。StreetではIT・テクノロジーに関する様々なイベントや勉強会を開催しています!参加ご希望の方はフォームよりご登録をお願いいたします。引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。