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
機能性テストで設計の違和感を可視化
Search
takefumi
December 11, 2023
Technology
0
110
機能性テストで設計の違和感を可視化
2023/12/15 JaSST東海 2nd
ライトニングトーク資料
takefumi
December 11, 2023
Tweet
Share
More Decks by takefumi
See All by takefumi
テストは楽しい!
iseki
0
100
品質向上・生産性向上のため DevOps の開発プロセス目指して
iseki
0
570
保守 (Ops) での保守改修プロセス構築記
iseki
0
75
開発チーム内でのQAの役割
iseki
0
680
開発にテストプロセスを融合させていく取り組み
iseki
0
640
開発スピードと品質を向上させるための QA の関わり
iseki
0
190
テスト管理ツール (TestLink) の活用
iseki
0
300
JaSST nano Vol.5(健康と品質と、健康診断とテストと+)
iseki
0
360
品質をプロセスに組み込む文化つくり(Scrum Fest MIKAWA)
iseki
1
1.4k
Other Decks in Technology
See All in Technology
現地でMeet Upをやる場合の注意点〜反省点を添えて〜
shotashiratori
0
520
サイバーエージェントにおける生成AIのリスキリング施策の取り組み / cyber-ai-reskilling
cyberagentdevelopers
PRO
2
200
君は隠しイベントを見つけれるか?
mujyun
0
290
Forget efficiency – Become more productive without the stress
ufried
0
140
【技術書典17】OpenFOAM(自宅で極める流体解析)2次元円柱まわりの流れ
kamakiri1225
0
210
よくわからんサービスについての問い合わせが来たときの強い味方 Amazon Q について
kazzpapa3
0
220
オーティファイ会社紹介資料 / Autify Company Deck
autifyhq
9
120k
Aurora_BlueGreenDeploymentsやってみた
tsukasa_ishimaru
1
120
来年もre:Invent2024 に行きたいあなたへ - “集中”と“つながり”で楽しむ -
ny7760
0
470
ガチ勢によるPipeCD運用大全〜滑らかなCI/CDを添えて〜 / ai-pipecd-encyclopedia
cyberagentdevelopers
PRO
3
210
AWS CDKでデータリストアの運用、どのように設計する?~Aurora・EFSの実践事例を紹介~/aws-cdk-data-restore-aurora-efs
mhrtech
4
650
CAMERA-Suite: 広告文生成のための評価スイート / ai-camera-suite
cyberagentdevelopers
PRO
3
270
Featured
See All Featured
Building a Modern Day E-commerce SEO Strategy
aleyda
38
6.9k
Optimizing for Happiness
mojombo
376
69k
No one is an island. Learnings from fostering a developers community.
thoeni
19
3k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
7
150
A designer walks into a library…
pauljervisheath
202
24k
Making Projects Easy
brettharned
115
5.9k
Facilitating Awesome Meetings
lara
49
6k
KATA
mclloyd
29
13k
Rails Girls Zürich Keynote
gr2m
93
13k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
25
1.8k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
14
1.9k
Typedesign – Prime Four
hannesfritz
39
2.4k
Transcript
機能性テストで設計の違和感を可視化 2023/12/15 JaSST 東海 2nd 井関 武史
アジェンダ 目次 自己紹介 はじめに テスト・QA エンジニアの役割 機能性のテスト分析・設計 違和感しかない設計 まとめ
自己紹介 名前: 井関 武史 (いせき たけふみ) 所属: テストの街「葛飾」 職業: 某
ID 管理製品のQA・テストエンジニア 趣味 歴史 チンタラン(マラソン) ゲーム ポケモン(カード・Switch)、Acecombat、その他 Twitter: @katsushika_take 生息地: 葛飾、神田小川町
はじめに
はじめに プロダクト (サービス) の中核をなす機能性のテストで、どのようなテ スト分析・設計をしていますか? テスト実施の時点でアレコレ機能が足りないとか、動作がおかしいと か、依存関係が間違えているとか、そもそも機能が自体がおかしい (要件を満たしていない) とか そんな経験はありませんか?
はじめに そんな経験をたくさんしてきました (私はw) プロダクト (サービス) の中核をなす機能性で、実環境で動作させていると き、バグ・仕様変更などあったら、はてしなくしんどいことになる。(精神的に も、肉体的にも) 最終的に根性論とかになる そして、疲弊して品質はさがり、無駄にリリースが延びていいこと一つもない
そんなツラタンなことを防ぎたい。 三方ヨシっ!な世界になるプロダクト・サービスを作りたい
テスト・QAエンジニアの役割
テスト・QAエンジニアの役割 作成された設計書、プロダクト(サービス) が期待する (設計書どおり) に 動作することを確認することでしょうか? それも、大事なことかもしれません。(これが基本だと思います) 『機能性』としては、それだけではなく、テスト・QA エンジニアの役割とし て以下のようなことも大事なことの一つだと考えています。
(特にテスト エンジニア) 保証すべき (機能の) 品質を定義・実証 暗黙知となっている仕様の可視化 予期される例外の (パターンを) 定義 リスクの把握・可視化
テスト・QAエンジニアの役割 テスト・QA エンジニアは、早期警戒機・(対潜) 哨戒機の役割も担ってい るものだと思っています。 ※) 詳しい話はテストの街「葛飾」でします テスト分析・設計の時点で、発見しだいバグを掃討していくので対潜哨戒機に近いかも。
テスト・QAエンジニアの役割 品質を実証する後工程ではなく、分析・設計時点でバグ・仕様漏れを見 つけるので、「テスト実施」する前からすでに「バグ」はつぶされていきま す。 つまり。。。。 (テスト分析・設計中に) 「バグだ!」と心の中で思ったならッ、 その時スデに行動 (テスト) は終わっているんだッ!
というわけです。 機能性のバグ・仕様漏れの発見はテスト設計でほぼ見つけます。(私の 場合ですが)
機能性のテスト設計
機能性のテスト設計 テスト設計をするうえで VSTeP というテストフレームワークを利用し ています。 VSTeP のすべてを話すのは時間が足りないため、「テストアーキテク チャ設計」についてさわりだけ話します プロダクト (サービス)の機能を分析し可視化するのに使うことができ
ます。 ※) 機能性だけではなく様々な用途に利用できます。 テスト 要求分析 テスト アーキテクチャ 設計 テスト 詳細設計 テスト 実装 テスト 実施
機能性のテスト設計 テストアーキテクチャ設計をする上で、NGT 表記を利用し MECE になる ように機能性を分析しながら設計をしています。 分類は以下の5つとしています。 テスト対象 (機能) テスト観点
(品質特性) テスト要素 テスト条件 テストパターン ※) 用語は組織・チームで異なる場合があるため、定義していることが重要です。
違和感しかない設計
違和感しかない設計 私が出会った違和感しかない設計例の一部を見せます。
違和感しかない設計 まず最初に、私が『独り言』で、よく使う用語の説明をします。 アンノーン (なんか違和感があるなぁ。。。コレ) ボギー (マヂで違和感しかない、なんじゃこれ??) バンディット (これバグ・仕様漏れだろw) 「ボギー出現、分析を開始」とか 「バンデットと判定」とかいうと、
開発の人が振り向くw
違和感しかない設計 テストパターンがやたら多い アンノーンを補足 テスト要素 (やっていること) が大きすぎる可能性 要素を分離しないとテスト漏れが発生 1つのクラス (関数) で複数の仕事させんな
(SOLID の単一責任の原則に違反の可能 性)
違和感しかない設計 同じ(ような) テスト要素が乱立している ボギーを補足 コピペして増やしている可能性大 (修正漏れがいずれかにある) 電探には正常と欺瞞する可能性 というか、ドッペルゲンガー作るなw (DRY: Don’t
Repeat YourSelf に反している) どれをテストしたかわらんくなるやろ
違和感しかない設計 要素がやたらとネストしている (依存性が高すぎ) アンノーンを確認 要素の依存が多く伝言ゲームになり、テストがしにくい(パターンが多す ぎになる問題) ボギーと判定 要素の依存が多いのに、なぜかテストパターンが少なすぎ
違和感しかない設計 正常同値しかない バンデット! 異常同値が考慮されていない 考慮されているかもしれないが全てcatch されて捨てられている可能性 が大 (すべてヌルポで捨てるとかヤメレ)
違和感しかない設計 複数の要素での結果を1つの要素に入れているのに入力チェックがない バンディットと認識し設計を確認せよ 複数からの入力同期などの確認が必要 (NULL チェックとか) もし、要素がクラスで親子継承していればバンディット確定 派生開発でよくあるのが、知らぬうちに得体のしれない親を継承している
違和感しかない設計 関連している(継承されている) 要素でデータを制限としている アンノーンだけど、将来ボギーに変わる可能性大 事前条件を末端で制限している可能性 (リスコフの置換原則に違反) 『事前条件を派生型で強めることはできない。派生型では同じか弱められる。』 仕様が変わった瞬間、修正漏れでバグが埋まる ※) 仕様はコロコロかわるものを認識せよ
まとめ
まとめ テスト・QA エンジニアが「設計」のバグ・仕様漏れなどを (出来る限り) 早期 &正確に把握し警報を出して未然に防ぐことも重要なことです。
まとめ 機能性のバグ・仕様漏れを発見するためには、テスト・QA 担当は開発担 当者と協力して、機能を構造化する必要があります。 そのために。。。 幅広いコンピュータシステム (OS、ネットワークなど)、情報処理技術、ミドルウェ アの基礎知識は必要です。 最新のテクノロジーの知識もある程度必要です。 開発の設計・プログラムの手法(技法)
も知っている必要もあります。 歴戦錬磨の職人プログラマーのように美しいプログラムを創造する必要はありません が作ったものを理解できる (読める) 必要があります。 そして、ドメイン (業務プロセス) 知識 は絶対に必要です。 もちろん、テスト技法を使いこなせるスキルは必要です。 構造化・可視化して開発担当者に論理的に説明できる必要があります。
おまけ ライトニングトークのため表面しか話していませんので、完全版はどこかで 話せるかもしれません 要求・要件を満たせているかのテスト設計もありますが、別でお話させてい ただきます。 詳しくは、テストの街「葛飾」で!
テストの街「葛飾」? グループ:https://ost-zatu.connpass.com/ 通称 :葛飾テストの会 イベント 毎週火曜日 21:30 ~ 23:00 テスト関係の話を中心に雑談
(なんでもあり) 勉強会やセミナーが渋谷や新宿が多くて東側少ないよね、ないなら自分たちで作っ ちゃえで始まった会 キャベツは「中野甘藍」 (葛飾の野菜生産量 第二位) 第一位は「こまつな」だが、葛飾区の南にある某区によってゆるキャラ出ているから却下 虫はバグ、早急に発見・対処しないと大変なことに。。。
ご清聴ありがとうございました
None