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
150
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
79
非同期ツールキット「Vert.x」のご紹介
masatoshiitoh
0
310
サーバーサイド開発にありがたい GitHub Copilot / ChatGPT
masatoshiitoh
1
970
コードを書いたら負けなのか?
masatoshiitoh
0
440
1999年 最新バックアップ事情
masatoshiitoh
0
210
Google I/O 報告 (Google Assistant)
masatoshiitoh
0
480
GDC報告会資料 海外に見る「生産性改善」動向
masatoshiitoh
0
1.3k
イケメンシリーズでのORMとスロークエリ対策について
masatoshiitoh
0
2.7k
Erlangご紹介 websocket編
masatoshiitoh
0
2.8k
Other Decks in Programming
See All in Programming
Cursorを活用したAIプログラミングについて 入門
rect
0
150
API for docs
soutaro
3
1.6k
On-the-fly Suggestions of Rewriting Method Deprecations
ohbarye
1
4.7k
GitHub Copilot for Azureを使い倒したい
ymd65536
1
310
Optimizing JRuby 10
headius
0
560
fieldalignmentから見るGoの構造体
kuro_kurorrr
0
130
Road to RubyKaigi: Making Tinny Chiptunes with Ruby
makicamel
4
540
note の Elasticsearch 更新系を支える技術
tchov
9
3.4k
The Missing Link in Angular’s Signal Story: Resource API and httpResource
manfredsteyer
PRO
0
140
ニーリーQAのこれまでとこれから
nealle
2
160
音声プラットフォームのアーキテクチャ変遷から学ぶ、クラウドネイティブなバッチ処理 (20250422_CNDS2025_Batch_Architecture)
thousanda
0
380
Cursor/Devin全社導入の理想と現実
saitoryc
28
21k
Featured
See All Featured
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
23
2.7k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
2.9k
Speed Design
sergeychernyshev
29
920
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
119
51k
What's in a price? How to price your products and services
michaelherold
245
12k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
GraphQLの誤解/rethinking-graphql
sonatard
71
10k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.8k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
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)
刺さった 言葉 「複数のテストプロセスへの支援」から • 利害関係者のコミットメント • 利害関係者は、テスト戦略の基盤としてリスクを分析する責 任がある。特に地理的に分散している組織で は、起こり得るリスクや軽減策に対し
て意見はほとんど一致しない。意見の不一致 をあからさまに表すだけでは、テストプロジェクトの成功を 脅かすだけだが、かといって意見の不一致を表面に出さなく ても、明確に対処されていなければテストプロジェクトの結 果は確実に残念なものになる。
というわけで プロセスを改善する一般的な手法・考え方としても参考にな る点が多い書籍でした。 早く読めば良かった!!
ご清聴 ありがとう ございました (セガ札幌スタジオ、採用絶賛おこなってます)