Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
機能QA会のすゝめ
Search
Hiroki Tanaka
April 05, 2023
Technology
0
270
機能QA会のすゝめ
noteで行ってきたQA会の取り組みをまとめました。
Hiroki Tanaka
April 05, 2023
Tweet
Share
More Decks by Hiroki Tanaka
See All by Hiroki Tanaka
定期リリースの導入
hiroki_tanaka
0
190
noteの品質課題に立ち上げ直後のQAチームが挑んだ軌跡
hiroki_tanaka
1
1.5k
note初のBug Bashを やってみた
hiroki_tanaka
1
1.5k
コロナ禍の1年間でAWSの資格を 3つ取得した話
hiroki_tanaka
0
440
Rubocop対応のすゝめ
hiroki_tanaka
0
74
Gotanda.rb#48 ECS on Fargateでのハマりポイント
hiroki_tanaka
1
370
Gotanda.rb#47 Mailgun3分クッキング
hiroki_tanaka
1
7.3k
Gotanda.rb#46 権限管理のつらみとPundit
hiroki_tanaka
1
7.4k
Other Decks in Technology
See All in Technology
AI駆動開発の実践とその未来
eltociear
1
410
AWS運用を効率化する!AWS Organizationsを軸にした一元管理の実践/nikkei-tech-talk-202512
nikkei_engineer_recruiting
0
140
AI駆動開発における設計思想 認知負荷を下げるフロントエンドアーキテクチャ/ 20251211 Teppei Hanai
shift_evolve
PRO
2
440
日本Rubyの会: これまでとこれから
snoozer05
PRO
4
200
ハッカソンから社内プロダクトへ AIエージェント「ko☆shi」開発で学んだ4つの重要要素
sonoda_mj
6
900
MLflowダイエット大作戦
lycorptech_jp
PRO
1
150
AI時代のワークフロー設計〜Durable Functions / Step Functions / Strands Agents を添えて〜
yakumo
3
1.4k
30分であなたをOmniのファンにしてみせます~分析画面のクリック操作をそのままコード化できるAI-ReadyなBIツール~
sagara
0
180
【ServiceNow SNUG Meetup LT deck】WorkFlow Editorの廃止と Flow Designerへの移行戦略
niwato
0
110
AlmaLinux + KVM + Cockpit で始めるお手軽仮想化基盤 ~ 開発環境などでの利用を想定して ~
koedoyoshida
0
120
AWS Security Agentの紹介/introducing-aws-security-agent
tomoki10
0
340
子育てで想像してなかった「見えないダメージ」 / Unforeseen "hidden burdens" of raising children.
pauli
2
300
Featured
See All Featured
Pawsitive SEO: Lessons from My Dog (and Many Mistakes) on Thriving as a Consultant in the Age of AI
davidcarrasco
0
32
Leading Effective Engineering Teams in the AI Era
addyosmani
9
1.4k
Skip the Path - Find Your Career Trail
mkilby
0
23
Measuring Dark Social's Impact On Conversion and Attribution
stephenakadiri
0
89
Optimizing for Happiness
mojombo
379
70k
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai
PRO
60
37k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
16k
The Cult of Friendly URLs
andyhume
79
6.7k
Google's AI Overviews - The New Search
badams
0
860
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.8k
Building Applications with DynamoDB
mza
96
6.8k
Noah Learner - AI + Me: how we built a GSC Bulk Export data pipeline
techseoconnect
PRO
0
72
Transcript
機能QA会のすゝめ 2023/04/07 note,inc hiroki_tanaka
機能QA会とは - noteのQAチームでは機能の追加・改修がある際に、他チームからの依頼ベースで テストケースの作成からケース打鍵を行う機能QA会(以下、QA会)を実施していた。 - 「複雑な機能の改修をリリースする前に問題ないの確認」や「リリース前に第三者 (QAチーム)が打鍵 することで別観点からの不具合発見」を目的としている。 - 仕様に不明点がある機能や仕様が複雑な機能に関しては、まずはヒアリングして仕様や懸念点を
一緒に洗い出す所から始め、それを基にテストケースを作成する。 - 1回当たりのQA会の時間は30分〜1時間程度。
具体例:iOSのSign In With Apple対応 - iOSアプリではSign In With Apple経由で新規登録を行ったユーザはパスワード登 録無しでnoteを利用できるようにする。
- 新規登録後に改めてパスワード確認を行う画面や挙動など仕様が複雑だったため、理解度が人に よってバラバラでテストが属人化する恐れがあった。 - また、Sign In With Apple経由していない通常ユーザの挙動がデグレするリスクもあった。 - そのため、QAチームがテストケースを作成し、 iOSチームと一緒にQA会をセット
- 作成したテストケース 具体例:iOSのSign In With Apple対応
- 作成したテストケース 具体例:iOSのSign In With Apple対応 45分間のQA会で複数の不具合を検知することに成功
- アプリチームからの声 具体例:iOSのSign In With Apple対応
- アプリチームからの声 やって良かった、QA会🕺 具体例:iOSのSign In With Apple対応
- QA会で使用するテストケースは以下の手順で作成し、ケースに則って打鍵を行う。 a. テストしたい機能の因子を洗い出す。 b. 各因子のテストケースで使用する値を洗い出す。 (※各因子の値のことを水準と呼ぶ。 ) c. 因子と水準の組み合わせを作成する。
d. テストケース完成! - テストケース作成は機能実装者が行い、レビューは必ず実装者以外の方 (別エンジニアやPMな ど)が行うのが良い。 - 実装者がテストケースに機能へのバイアスが少し掛かってしまうため、その部分をレビューで炙りだす。 - また、実装者にはない観点からの気付きをテストケースに反映する事ができる。 QA会の進め方
(例) 美味しいラーメンの作り方の テストケース
QA会の進め方①:テストしたい機能の因子を洗い出す - 因子とはテストしたい機能の入力条件のことを表す。 - ラーメンを構成する因子は4つあり、ここから美味しいラーメンを考える。 - 麺 - スープ -
具 - 調味料
QA会の進め方②:各因子のテストケースで使用する値を洗い出す - 各因子の値となる水準を洗い出す。 - 異常系のパターンは単体テストでチェックしているという前提で、水準は基本的に異常系のパター ンを含まず正常系のみ。 - (例) ラーメンの具:ショートケーキのようなパターンは初めから考えない。 -
ただし、水準は因子 (数字やランダム文字列など)によって無限に出てきてしまうため、その場合は同値 分割や境界値分析を行って代表値を選ぶ。 - 美味しいラーメンの因子水準表
QA会の進め方③:因子と水準の組み合わせを作成する - シンプルに全ての組み合わせをテストするのがベスト。 - ただし、全ての組み合わせの総数 = 因子1の水準数×因子2の水準数×因子3の水準数×因子4の水 準数…となってテストケースの件数が爆発してしまう。 - ラーメンの因子水準表では
4×4×4×3 = 192ケースとなってしまう。 - そこでテストケースの間引きを行う。
QA会の進め方③:因子と水準の組み合わせを作成する - 間引き方法は以下の3パターンがある。 - 禁則と呼ばれる起こり得ない組合せの除外。 - OS:Android+ブラウザ:Safariといった絶対に起こり得ないケースを除外する。 - 影響度による除外。 -
品質・時間・コストのバランスを考えて、影響度や発生頻度の少ないテストケースを除外する or 別のテストケースで担保できないかを考えて除外する。 - ラーメンのケースだと例えば「調味料:唐辛子は非常に使用頻度が少ないので 1ケースのみ行 い、全てのパターンで行わない」といった形。 - 二因子間分析(ペアワイズ法)による除外。 - 二因子間分析とは2因子間の組合せは全て網羅し確かめるが、 3因子間・4因子間の組合せは 担保しないという考え方。多数の因子間の網羅性を犠牲とすることで組合せ数を削減する。
QA会の進め方④:テストケース完成 - 「麺とスープの組合せ・スープと具の組合せを網羅するペアワイズ法」を使用するこ とで192ケースは19ケースとなる。
QA会の進め方④:テストケース完成 - 「麺とスープの組合せ・スープと具の組合せを網羅するペアワイズ法」を使用するこ とで192ケースは19ケースとなる。 QA会を行うことが出来るのテストケース完成🎉
- テストケース設計する際は仕様に書いてないところにバグや不具合が潜むことが 多いので、そこをあぶり出すようにする。 - テストケース設計中に「これをする /しない場合にこの機能はどうなるの?」のような感じで自分自身 に心の中でツッコミ・問いかけしていくと漏れていたケースや意図していなかったケースに気づける 事が多い😎 - テストケース設計は機能を壊す気持ちで作ってみると意外と上手くいくことが多く、
何より楽しい😉 - 例えば、数字ならマイナス /小数点/異常に大きい数・複数人が同時に同じ操作をする・通信中にア プリをシャットダウンまたは PCの電源を切ってみる …etc QA会のTips
まとめ - 不具合をリリース前に事前に洗い出し、品質向上を目的とした機能QA会を導入し て頂けると嬉しいです - 仕様からテストケースの洗い出し・作成から実際にチームでケース実施を行うことで確実に品質は 向上します - 実際にこれまでQA会を行ってきて1件も不具合が見つからなかったということはありませんで した。
- また、不具合発見だけでなく、 QA会を通じて機能の仕様理解も深まります。 - そして、QA会を実施できる機能は Web/アプリ/バッチ問わずどんな機能でも実施することが出来ま す👌
ご清聴ありがとうございました