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
0
180
TPI NEXTを読みました
2024/3/2に開催された積読消化会@千歳で、TPI NEXTを読んだので、その紹介用スライドです。
Masatoshi Itoh
March 02, 2024
Tweet
Share
More Decks by Masatoshi Itoh
See All by Masatoshi Itoh
Hello - 本を書く- World !!
masatoshiitoh
0
80
非同期ツールキット「Vert.x」のご紹介
masatoshiitoh
0
330
サーバーサイド開発にありがたい GitHub Copilot / ChatGPT
masatoshiitoh
1
1k
コードを書いたら負けなのか?
masatoshiitoh
0
450
1999年 最新バックアップ事情
masatoshiitoh
0
210
Google I/O 報告 (Google Assistant)
masatoshiitoh
0
490
GDC報告会資料 海外に見る「生産性改善」動向
masatoshiitoh
0
1.3k
イケメンシリーズでのORMとスロークエリ対策について
masatoshiitoh
0
2.7k
Erlangご紹介 websocket編
masatoshiitoh
0
2.8k
Other Decks in Programming
See All in Programming
システム成長を止めない!本番無停止テーブル移行の全貌
sakawe_ee
1
210
20250704_教育事業におけるアジャイルなデータ基盤構築
hanon52_
5
820
0626 Findy Product Manager LT Night_高田スライド_speaker deck用
mana_takada
0
180
レベル1の開発生産性向上に取り組む − 日々の作業の効率化・自動化を通じた改善活動
kesoji
0
240
技術同人誌をMCP Serverにしてみた
74th
1
660
PicoRuby on Rails
makicamel
2
130
Blazing Fast UI Development with Compose Hot Reload (droidcon New York 2025)
zsmb
1
300
PHPで始める振る舞い駆動開発(Behaviour-Driven Development)
ohmori_yusuke
2
400
テストから始めるAgentic Coding 〜Claude Codeと共に行うTDD〜 / Agentic Coding starts with testing
rkaga
13
4.8k
GitHub Copilot and GitHub Codespaces Hands-on
ymd65536
2
150
すべてのコンテキストを、 ユーザー価値に変える
applism118
3
1.4k
GPUを計算資源として使おう!
primenumber
1
160
Featured
See All Featured
Embracing the Ebb and Flow
colly
86
4.7k
Thoughts on Productivity
jonyablonski
69
4.7k
4 Signs Your Business is Dying
shpigford
184
22k
The Invisible Side of Design
smashingmag
301
51k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
740
GitHub's CSS Performance
jonrohan
1031
460k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Art, The Web, and Tiny UX
lynnandtonic
299
21k
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)
刺さった 言葉 「複数のテストプロセスへの支援」から • 利害関係者のコミットメント • 利害関係者は、テスト戦略の基盤としてリスクを分析する責 任がある。特に地理的に分散している組織で は、起こり得るリスクや軽減策に対し
て意見はほとんど一致しない。意見の不一致 をあからさまに表すだけでは、テストプロジェクトの成功を 脅かすだけだが、かといって意見の不一致を表面に出さなく ても、明確に対処されていなければテストプロジェクトの結 果は確実に残念なものになる。
というわけで プロセスを改善する一般的な手法・考え方としても参考にな る点が多い書籍でした。 早く読めば良かった!!
ご清聴 ありがとう ございました (セガ札幌スタジオ、採用絶賛おこなってます)