Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
機能QA会のすゝめ
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Hiroki Tanaka
April 05, 2023
Technology
290
0
Share
機能QA会のすゝめ
noteで行ってきたQA会の取り組みをまとめました。
Hiroki Tanaka
April 05, 2023
More Decks by Hiroki Tanaka
See All by Hiroki Tanaka
定期リリースの導入
hiroki_tanaka
0
210
noteの品質課題に立ち上げ直後のQAチームが挑んだ軌跡
hiroki_tanaka
1
1.6k
note初のBug Bashを やってみた
hiroki_tanaka
1
1.6k
コロナ禍の1年間でAWSの資格を 3つ取得した話
hiroki_tanaka
0
510
Rubocop対応のすゝめ
hiroki_tanaka
0
90
Gotanda.rb#48 ECS on Fargateでのハマりポイント
hiroki_tanaka
1
380
Gotanda.rb#47 Mailgun3分クッキング
hiroki_tanaka
1
7.4k
Gotanda.rb#46 権限管理のつらみとPundit
hiroki_tanaka
1
7.5k
Other Decks in Technology
See All in Technology
Keeping Ruby Running on Cygwin
fd0
0
180
AI駆動1on1〜AIに自分を育ててもらう〜
yoshiakiyasuda
0
150
目的ファーストのハーネス設計 ~ハーネスの変更容易性を高めるための優先順位~
gotalab555
8
2.5k
AI時代のガードレールとしてのAPIガバナンス
nagix
0
310
Practical TypeProf: Lessons from Analyzing Optcarrot
mame
0
1.2k
AI活用時代の事業判断高度化を導くエンジニアリング基盤 / 20260424 Atsushi Funahashi
shift_evolve
PRO
2
100
AIが書いたコードを信じられない問題 〜レビュー負荷を下げるために変えたこと〜 / The AI Code Trust Gap: Reducing the Review Burden
bitkey
PRO
8
1.4k
今年注目する!データ分析プラットフォームでのAIの活用
nayuts
0
170
AIコーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術(簡易版)
soysoysoyb
0
160
[最強DB講義]推薦システム | 評価編
recsyslab
PRO
0
110
Percolatorを廃止し、マルチ検索サービスへ刷新した話 / Search Engineering Tech Talk 2026 Spring
visional_engineering_and_design
0
170
M5Stack CoreS3とZephyr(RTOS)で Edge AIっぽいことしてみた
iotengineer22
0
360
Featured
See All Featured
Why You Should Never Use an ORM
jnunemaker
PRO
61
9.8k
Faster Mobile Websites
deanohume
310
31k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
1.9k
Max Prin - Stacking Signals: How International SEO Comes Together (And Falls Apart)
techseoconnect
PRO
0
150
30 Presentation Tips
portentint
PRO
1
280
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
133
19k
We Have a Design System, Now What?
morganepeng
55
8.1k
The Pragmatic Product Professional
lauravandoore
37
7.2k
Lightning talk: Run Django tests with GitHub Actions
sabderemane
0
170
The Limits of Empathy - UXLibs8
cassininazir
1
310
The Cult of Friendly URLs
andyhume
79
6.8k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.2k
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/アプリ/バッチ問わずどんな機能でも実施することが出来ま す👌
ご清聴ありがとうございました