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
Hiroki Tanaka
April 05, 2023
Technology
0
260
機能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
420
Rubocop対応のすゝめ
hiroki_tanaka
0
72
Gotanda.rb#48 ECS on Fargateでのハマりポイント
hiroki_tanaka
1
360
Gotanda.rb#47 Mailgun3分クッキング
hiroki_tanaka
1
7.2k
Gotanda.rb#46 権限管理のつらみとPundit
hiroki_tanaka
1
7.3k
Other Decks in Technology
See All in Technology
AWSが好きすぎて、41歳でエンジニアになり、AAIを経由してAWSパートナー企業に入った話
yama3133
2
200
データとAIで明らかになる、私たちの課題 ~Snowflake MCP,Salesforce MCPに触れて~ / Data and AI Insights
kaonavi
0
170
20251024_TROCCO/COMETAアップデート紹介といくつかデモもやります!_#p_UG 東京:データ活用が進む組織の作り方
soysoysoyb
0
130
Amazon Athena で JSON・Parquet・Iceberg のデータを検索し、性能を比較してみた
shigeruoda
1
240
Observability — Extending Into Incident Response
nari_ex
1
590
文字列操作の達人になる ~ Kotlinの文字列の便利な世界 ~ - Kotlin fest 2025
tomorrowkey
1
190
Open Table Format (OTF) が必要になった背景とその機能 (2025.10.28)
simosako
2
500
ゼロコード計装導入後のカスタム計装でさらに可観測性を高めよう
sansantech
PRO
1
560
AIとの協業で実現!レガシーコードをKotlinらしく生まれ変わらせる実践ガイド
zozotech
PRO
1
170
ViteとTypeScriptのProject Referencesで 大規模モノレポのUIカタログのリリースサイクルを高速化する
shuta13
3
230
RemoteFunctionを使ったコロケーション
mkazutaka
1
150
AIエージェントによる業務効率化への飽くなき挑戦-AWS上の実開発事例から学んだ効果、現実そしてギャップ-
nasuvitz
5
1.5k
Featured
See All Featured
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
55
3k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
Optimizing for Happiness
mojombo
379
70k
Agile that works and the tools we love
rasmusluckow
331
21k
Making Projects Easy
brettharned
120
6.4k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3.1k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
127
54k
Documentation Writing (for coders)
carmenintech
75
5.1k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
We Have a Design System, Now What?
morganepeng
53
7.8k
Mobile First: as difficult as doing things right
swwweet
225
10k
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/アプリ/バッチ問わずどんな機能でも実施することが出来ま す👌
ご清聴ありがとうございました