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
TPI NEXTを読みました
Search
Masatoshi Itoh
March 02, 2024
Programming
250
0
Share
TPI NEXTを読みました
2024/3/2に開催された積読消化会@千歳で、TPI NEXTを読んだので、その紹介用スライドです。
Masatoshi Itoh
March 02, 2024
More Decks by Masatoshi Itoh
See All by Masatoshi Itoh
Hello - 本を書く- World !!
masatoshiitoh
0
100
非同期ツールキット「Vert.x」のご紹介
masatoshiitoh
0
410
サーバーサイド開発にありがたい GitHub Copilot / ChatGPT
masatoshiitoh
1
1.1k
コードを書いたら負けなのか?
masatoshiitoh
0
490
1999年 最新バックアップ事情
masatoshiitoh
0
220
Google I/O 報告 (Google Assistant)
masatoshiitoh
0
500
GDC報告会資料 海外に見る「生産性改善」動向
masatoshiitoh
0
1.3k
イケメンシリーズでのORMとスロークエリ対策について
masatoshiitoh
0
2.7k
Erlangご紹介 websocket編
masatoshiitoh
0
2.9k
Other Decks in Programming
See All in Programming
権限チェックの一貫性を型で守る TypeScript による多層防御
mnch
2
120
いつか誰かが、と思っていた フロントエンド刷新5年間の実践知
kiichisugihara
1
280
20260514 - build with ai 2026 - build LINE Bot with Gemini CLI
line_developers_tw
PRO
0
450
柔軟なPDFレイアウトエディタを支える型システム設計 — Discriminated UnionとConditional Typeの実践
minako__ph
1
130
ソースコード→AST→オペコード、の旅を覗いてみる
o0h
PRO
1
130
TSKaigi2026-静的解析への投資がAI時代のコード品質を支える ── カスタムESLintルールの設計と運用
hayatokudou
2
170
Are We Really Coding 10× Faster with AI?
kohzas
0
190
〜バイブコーディングを超えて〜 チームで実験し続けたAI駆動開発
tigertora7571
0
210
When benchmarks go bad - what I learned from measuring performance wrong
hollycummins
0
390
[BalkanRuby 2026] Drop your app/services!
palkan
3
510
AWSはOSSをどのように 考えているのか?
akihisaikeda
0
120
関係性から理解する"同一性"の型用語たち
pvcresin
1
190
Featured
See All Featured
Discover your Explorer Soul
emna__ayadi
2
1.1k
Bootstrapping a Software Product
garrettdimon
PRO
307
120k
Building an army of robots
kneath
306
46k
Claude Code のすすめ
schroneko
67
220k
The Director’s Chair: Orchestrating AI for Truly Effective Learning
tmiket
1
170
Measuring Dark Social's Impact On Conversion and Attribution
stephenakadiri
2
190
Data-driven link building: lessons from a $708K investment (BrightonSEO talk)
szymonslowik
1
1.1k
Mind Mapping
helmedeiros
PRO
1
190
DevOps and Value Stream Thinking: Enabling flow, efficiency and business value
helenjbeal
1
190
Designing Experiences People Love
moore
143
24k
Practical Orchestrator
shlominoach
191
11k
Tips & Tricks on How to Get Your First Job In Tech
honzajavorek
1
510
Transcript
TPI NEXTを読みました 2024/3/2 積読消化会@千歳 @masatoshiitoh (twitter/X)
自己紹介 いとうまさとし(Twitter: @masatoshiitoh) 株式会社セガ札幌スタジオ 今回の発表はセガサミーグループの技術スタックや開発・運 営中のタイトルとは全く関係ありません
過去作品 Speed.rbbtoday.com(IRI-CT、現イード在籍当時に開発) 最近のGist Camel から Camel Vert.x component 経由でVert.xクラス タのイベントバスを読み書きする とにかくApache Camelを動かしてみるための最初の手順
今回は 積ん読状態にしていた「TPI NEXT」を読みました
TPI NEXT 現在は絶版。本の中身は古びておらず、版元が書籍出版事業 を停止し、本が絶版になったから 「TPI(Test Process Improvement)」を「アップデート したもの(Next)」、という書名。
テストプロセスの本ではなく、テストプロセス改善の本 とはいえオリジナルのTPIを知らなくてもテストプロセスの 改善に踏み出すことが出来る本。
キーワード BDTPI = Business Driven Test Process Improvement
SDLC = Software Development Life Cycle
第1章 テストプロセ ス改善は次の ステップへ ビジネス主導のTPI 組織のビジョンやビジネス戦略から導き出した方向性 ビジネス主導要因は、テストプロセスを改善するための理由、
モチベーション、課題となるもの ビジネス主導要因の例: 運用の年間コストの削減 市場投入時期の短縮と、プロダクトやサービスの市場における品 質の向上 外部の法や規制の順守 など テスト作業は低コストな品質対策ではない。 後半なので 修正コストは高い。 構造的な品質強化には、トップダウンが必要 予防は是正よりも優れる。
従来のV字モ デル否定では ない 従来のV字モデルはSDLCにおいてテスト作業をいつどのよ うに行うべきかを明確・正確に説明している。各テストレベ ルと開発フェーズ(要件~設計の成果物)は対応する。
BDTPI モデルとは BDTPIモデルはテストプロセスの品質に対して見識 を与える モデルは現状分析をすばやく行えるように支援できる • 特定の改善ステップにフォーカスできる •
違う人が分析しても同様の結果が出せる • 成熟したテストレベルから、初期のテストレベルまでカバー • 特定のテスト手法やソフトウェア開発手法に依存しない • ビジネス主導要因の検討に対応 BDTPIモデルではテストプロセスを16のキーエリア に分割する
16の キーエリア 利害関係者と の関係 1. 利害関係者のコミットメント 2. 関与の度合い 3. テスト戦略
4. テスト組織 5. コミュニケーション 6. 報告
16の キーエリア テスト管理 7. テストプロセス管理 8. 見積と計画 9. メトリクス 10.
欠陥管理 11. テストウェア管理
16の キーエリア テスト業務の 専門性 12. 手法の実践 13. テスト担当者のプロ意識 14. テストケース設計
15. テストツール 16. テスト環境
成熟度レベル 各キーエリアごとに… 成熟度がある 成熟度を客観的に測定するチェックポイントがある 1.初期レベル:アドホックな活動 → テスト品質が職場の英雄に大きく左右される
2.コントロールレベル:適切なものごとを行う 3.効率化レベル:ものごとを適切に行う 4.最適化レベル:刻々と変化する状況に絶えず順応する
テスト成熟度 マトリクス
テスト成熟度 マトリクス テスト成熟度マトリクスの各マス目は、A~Mの13のクラス タに分けられ、各クラスタのチェックポイントを満たしてか ら次の段階のクラスタに進むことが推奨されている TPIでの「マトリクスの各要素間の依存関係」を改定し、カ スタマイズ可能にしたのがクラスタ
たとえば、依存関係では「自動テストが実行できる」ようにな るには、「テスト管理ツールを使用する」が満たされ、さらに は「テストを作るための共通の方法があり、かつ、メンバーが テストの教育を受けている」必要がある。これが依存関係とし て記述されていた。
テスト成熟度 マトリクス 各チェックポイントに対して継続的に改善を進めていくため のツール どのようにチェックポイントを満たすかの改善提案もある テストプロセスと他のSDLCプロセスを関連付けるキーエリ ア達成のコツも示されている
改善のための メトリクス テスト作業に関する事実を示す数字がないことが多いが、で きるだけ初期の段階から採るようにする • 事実と数字の作成 • 指標を定義する •
指標を1つ以上のゴールと結びつける • データを定義する • データソースを定義する • 分析手順を説明する • 報告する • 初期状況を分析する
刺さった 言葉 成功のためには、 チーム内のスキルや知識を 問題とすべきではない。スキルや知識は伸ばす べきものであり、できればプロジェクトの開始前、あるいは プロジェクトの早期段階にトレーニングを計画すべきもので ある。(P.204)
刺さった 言葉 「複数のテストプロセスへの支援」から • 利害関係者のコミットメント • 利害関係者は、テスト戦略の基盤としてリスクを分析する責 任がある。特に地理的に分散している組織で は、起こり得るリスクや軽減策に対し
て意見はほとんど一致しない。意見の不一致 をあからさまに表すだけでは、テストプロジェクトの成功を 脅かすだけだが、かといって意見の不一致を表面に出さなく ても、明確に対処されていなければテストプロジェクトの結 果は確実に残念なものになる。
というわけで プロセスを改善する一般的な手法・考え方としても参考にな る点が多い書籍でした。 早く読めば良かった!!
ご清聴 ありがとう ございました (セガ札幌スタジオ、採用絶賛おこなってます)