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
87
機能性テストで設計の違和感を可視化
2023/12/15 JaSST東海 2nd
ライトニングトーク資料
takefumi
December 11, 2023
Tweet
Share
More Decks by takefumi
See All by takefumi
テストは楽しい!
iseki
0
92
品質向上・生産性向上のため DevOps の開発プロセス目指して
iseki
0
550
保守 (Ops) での保守改修プロセス構築記
iseki
0
73
開発チーム内でのQAの役割
iseki
0
670
開発にテストプロセスを融合させていく取り組み
iseki
0
630
開発スピードと品質を向上させるための 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
不感対策ソリューション
jtes
0
230
XP matsuri 2024 - 銀河英雄伝説に学ぶ
kawaguti
PRO
3
510
【shownet.conf_】ShowNet x 宇宙ネットワーク
shownet
PRO
0
310
成果のためのコミュニケーション - 語彙を育てよう -/communication-for-good-outcome-developing-vocabulary
hassaku63
4
150
【shownet.conf_】AI技術とUX監視の応用でShowNetの基盤を支えるモニタリングシステム
shownet
PRO
0
270
山手線一周のパフォーマンス改善
suzukahr
0
110
Making Linux sucks less
ennael
PRO
0
500
Sansanにおける全社横断データ分析基盤の挑戦と未来 / Challenges and Future of Cross-Organizational Data Analytics Platform at Sansan
sansan_randd
2
310
Amazon BedrockとPR-Agentでコードレビュー自動化に挑戦・実際に運用してみた
diggymo
0
560
普通の Web エンジニアのための様相論理入門 #yapcjapan / YAPC Hakodate 2024
ytaka23
2
530
【shownet.conf_】持続可能な次世代Wi-Fi運用に向けて
shownet
PRO
0
260
【swonet.conf_】NOCメンバーが語るSTMの実態!! ~ShowNetから若者への贈り物~
shownet
PRO
0
230
Featured
See All Featured
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
30
2.6k
Building Better People: How to give real-time feedback that sticks.
wjessup
360
19k
Facilitating Awesome Meetings
lara
49
6k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
7
560
Infographics Made Easy
chrislema
239
18k
A Tale of Four Properties
chriscoyier
155
22k
Debugging Ruby Performance
tmm1
73
12k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.6k
Embracing the Ebb and Flow
colly
83
4.4k
RailsConf 2023
tenderlove
28
840
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
44
2k
For a Future-Friendly Web
brad_frost
174
9.3k
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