デブサミ2023 / テストを学びたい開発者のためのソフトウェアテスト読書マップ / Software Testing Reading Map for Developers

1 / 53 テストを学んでみたい開発者のためのソフトウェアテスト読書マップ Feb. 9th, 2023 Developers Summit
2023 鈴木一裕 @ kz_suzuki Image: "First sunset | Emmet's Adventures" by chris.alcoran is licensed under CC BY-NC-ND 2.0.

2 / 53 Developers Summit 2023 Copyright 2023, Kazuhiro SUZUKI
◼ 参加書籍自己紹介 ◼ 鈴木一裕(*1) ◼ 職業: QAエンジニア ◼ Twitter: @kz_suzuki ◼ ブログ: ソフトウェアの品質を学びまくる(*2) ◼ コミュニティ ⚫ ISO/IEC/IEEE JTC1/SC7/WG26(*3)委員など ◼ 最近の社外発表 ⚫ 2022年3月 @JaSST’22 Tokyo(*4) - 『実践ソフトウェアエンジニアリング』第3部超概説 ⚫ 2022年8月 @JaSST nano vol.15 - 殺虫剤のパラドックスの真実 ⚫ 2022年12月 @JaSST nano vol.19 - AIシステムのブラックボックステスト (*1) デブサミに向けてこの「ろくろアイコン」を作るためにひっそり自撮り100枚くらい撮ったので称えてください。 (*2) 実際のところ、そんなに学びまくっていない。 (*3) ソフトウェアテストに関する規格などを作っている (*4) JaSST: ソフトウェアテストシンポジウム（Japan Symposium on Software Testing）システムテスト自動化標準ガイド翔泳社・2014年監訳・共訳 (1章分だけ) ソフトウェア品質知識体系ガイド(第3版) オーム社・2020年共著 (超一部) 実践ソフトウェアエンジニアリング(第9版) オーム社・2021年共訳 (3章分だけ) テスト・QA界隈にのみ出没周りの人の力で成果をレバレッジ

目的とおことわり ◼ この発表が終わる頃どうなっていたいか ⚫ 「ソフトウェアテストの知識って、何がうれしいのか」がわかる。 ⚫ 「ソフトウェアテストを、どこから勉強すればいいのか」がわかる。 ◼ おことわり ⚫ 主観がめっちゃ入ってます。 ⚫ いわゆる「QAテスト」と呼ばれる範囲が中心になります。 ⚫ ツイートは歓迎です。怖くないやつでお願いします。#devsumiB

話の流れ 1. はじめに 2. テストの勉強は役に立つのか？ 3. テストいろいろありすぎ問題 4. ソフトウェアテスト読書マップって何？ 5. テストプロセスとテスト設計 6. おわりに

5 / 53 テストの勉強は役に立つのか？ Image: "I'm studying" by rabbitneverlies
is licensed under CC BY-SA 2.0.

ソフトウェアテストに興味をもつ開発者が増えているとの噂がある。

一方で、テストについての言葉や概念が無数にあって、よくわからんとも言われる。

QAエンジニアでなくても、テストを学んでおくといい理由 ◼ QAエンジニアの活動に対する解像度が上がる ⚫ テストに関する概念は雑多にみえるが、ある程度体系的に整理されている。 ⚫ テストの用語や考え方を知るだけで、テストや品質についての視界がクリアになることがある。 ◼ テストで用いる思考を、開発の早期から取り入れられる ⚫ QAは日ごろ、プロダクトの情報を整理したりモデル化したりを繰り返している。これは、設計の段階から一緒にやっていくと効率がいい。 ⚫ QAのエキスパートには、尖った部分を生かしてもらうのがハッピー。 - プラクティスの導入経験、バグの知識、「こうしたらどうなる？」の発想力、異常に対する嗅覚、「神の手」、・・・ 1 2

しかし、何から手をつける？

プログラミング初学者に「プログラミングやりたいんだけど、どの言語がいい？」と聞かれたらら、みなさん何と答えますか？

「どんなことしたいの？」「何を作りたいの？」と聞くと思います。

テストも、何がしたいか、何に悩んでいるかによって、勉強のしどころが違ってきます。広くて深い分野なんです。

13 / 53 テストいろいろありすぎ問題 Image: "A Messy Milkshake Recipe"
by echo0101 is licensed under CC BY-NC-SA 2.0.

「テスト」と名の付く言葉たちシステムテストユニットテスト E2Eテスト組み合わせテスト状態遷移テストユーケーステストテスト計画テスト実装テスト実行機能テスト性能テストセキュリティテストユーザビリティテスト自動テスト探索的テストスモークテストテスト分析ビッグバンテストデシジョンテーブルテストリグレッションテストフレイキーテスト A/Bテストキーワード駆動テスト同値分割テストペネトレーションテスト結合テストモンキーテスト

「テスト」からイメージするものにもいろいろある ◼ 機能のテストなのか、性能テストなのか、セキュリティテストなのか、・・・ ⚫ テストの種類。「テストタイプ」という言葉で表される。 ◼ Webサービスなのか、組込ソフトウェアなのか、ゲームなのか、・・・ ⚫ テスト対象の分野。「ドメイン」という言葉で表される。 ◼ テストの管理なのか、分析・設計なのか、実行なのか、・・・ ⚫ テストの活動。「テストプロセス」という言葉で表される。 ◼ ユニットテストなのか、システムテストなのか、・・・ ⚫ テストの粒度。「テストレベル」 (*1)という言葉で表される。いろいろな「テスト」用語があり、切り口がそれぞれ違う。ごちゃ混ぜで、どう勉強していいのやら・・・。 (*1) あらためて「テストピラミッド」を見てみると、一番下のユニットテスト以外はばらつきがあります。最上位はUIだったりシステムテストだったり。

ある技術分野を勉強し始める場合に直面する困難 ◼ その技術分野の全体像がわからない ◼ 全体のうち、どの部分から手を付けていいかわからない ◼ 何を参照すれば、どの部分のどのレベルを学べるかわからない → はインターネッツ集合知で解決できるのでは？ 1 2 3 3

17 / 53 ソフトウェアテスト読書マップって何？ Image: "Stack of books" by
EverydayTrish is licensed under CC BY-NC 2.0.

テストの本は、たくさん出版されている。それだけに、「どの本に何が書かれているのか」がわかりづらい状況になっている。

技術書は安くない。各書籍がカバーしている範囲を俯瞰できるような情報がほしい！そこから必要な本の目星をつけたい！

Twitterでの適当な呼びかけに対し、ヤバい素晴らしい人たち、集まる。

想定とりあえず10冊。 2か月くらいでがんばって公開!? 現実 70冊をカバー、 1週間くらいで公開・・・これがアジリティか・・・わたしは1冊しか担当していないが・・・

◼ 読書マップの目的ソフトウェアテストを学ぶ人が、「どの本に何が書いてあるか」をざっくりつかめるようにすること。ソフトウェアテスト読書マップってこんな感じ書籍の一般情報レベル・一言メモテスト各エリアのカバー範囲書籍レベルの凡例 ▪入門: 一般の人への概念の導入。 ▪初級: テストの知識や経験が少しあれば読むことができる ▪中級: ある程度テストの知識・経験を踏まえて読むのが望ましい ▪上級: テストのベテラン向けテストのエリアテスト計画、分析、設計、実装、実行など、JSTQBの定義を参考に分類カバー範囲の凡例 ▪: 具体例ふくめ、詳細な記載がある •: 考え方や概要の記載がある ▲: 用語程度の記載があるー: 記載なし「どの本が、どのくらいの濃さで、どの範囲をカバーしているのか」を見える化

ソフトウェアテスト読書マップの使い方 ◼ まず、横軸を見る ⚫ 一言に「テスト」といっても、いろいろなトピックがあることが、あらためてわかる。 ⚫ たとえば「テストチーム構築」と「テスト設計」は、まったく違う知識・経験が求められる。 ◼ 本の傾向を理解する ⚫ 「たくさんのセルが緑で塗られている」本は、広く浅くをカバーする辞書的なモノ。 →テストの概観を学ぶのに合っている。 ⚫ 「少な目のセルが赤で塗られている」本は、テーマを絞って深く説明したモノ。 →特定のトピックの専門性を深めるのに合っている。 ⚫ 「たくさんのセルが赤で塗られている」本は、鈍器。 ◼ 読む順番を考える ⚫ 特定のトピックの理解を深めるため、「色合いが似ていてレベルが違う本」を読んでいく、など。 1 2 3

お得情報: 読書マップに見るQAエンジニアあるある ◼ 散らばった情報があると、テーブルで整理しだす。 ◼ カバレッジを高めたがる。 ◼ マトリクスを書くと、縦軸と横軸の要素の妥当性について議論しだす。 ◼ 「定義」にうるさい。 1 2 3 4 自分だけじゃなかった・・・！

これですべての問題が解決した！ - 第3部・完(*1) - (*1) 往年の少年ジャンプの漫画のネタは、若者に対するハラスメントになりうるので注意が必要です。

26 / 53 顧客が本当にほしかったもの・・・？ Image: "Tree Swing in Winter"
by dbnunley is licensed under CC BY-NC-SA 2.0.

ある技術分野を勉強し始める場合に直面する困難 (再掲) ◼ その技術分野の全体像がわからない ✅ ◼ 全体のうち、どの部分から手を付けていいかわからない ◼ どの本が、どの部分のどのレベルをカバーしているかわからない ✅ → が解決できていない。 1 2 3 2

(*1) Rashem Panditさんのチャートの日本語版より引用。Visual guide to best books on Product Managementのリンク集 (*2) ProductZineの記事『「プロダクトマネージャーこそ、戦略的に読書せよ！」──最短で成果を出すための読書地図』より引用顧客が本当にほしいもの、これでは？蜂須賀大貴さん作「プロダクトマネージャーのための読書地図」(*2) 「最初の1冊」から始まって、しだいに領域が広がっていく。しだいに発展的な内容になっていく。 Rashem Panditさん作・渡辺悟史さん訳「Visual guide to best books on Product Management」(*1) ”世の中にあるあまたの書籍の中から「今の自分には何が必要なのか」。そして、「必要な知識が得られる書籍はどれなのか」を見極めるには、コツが要ります。少なくとも、表紙や目次を見て想像できるくらいのテーマに対する理解度は必要でしょう。しかし、初めての領域を学ぶには、これはハードルが高すぎるのです。”

「最初、何に手を付けるか」がわかるようにしてみた。

テスト計画・管理エリアテスト自動化エリアモダンなテスト文化エリアスルメエリアテスト設計エリア全体概要エリア (*) 書影はすべて、Amazonから引用。各書籍の情報はこのあとのスライドで一覧にします。ホワイトボックステストもカバーしたい場合もっと詳しく具体的な内容を知りたい場合コスパのよいテストを求めて演習＋勉強会で強くなる！テストの作り方はわかったので、自動化するぜ！アジャイルにおけるテストの位置づけや、先進企業のテストを学ぶマネージャーなどがソフトウェアテストの全体をより深く押さえる名著・古典。ちゃんと読めてない・・・ツールやドメインにあまり依存しない一般論を学ぶテストマネージャとしての一歩目を学ぶための良書ソフトウェアテスト全般について比較的平易に書かれた入門書テスト設計技法とツール、テスト分析について平易に説明 Webシステムに対する自動テストについてStep by Stepで説明アジャイルテスト全般の解説と事例紹介テストを何周か経験し、悩んだ後に読むと得るものが大きい実践書ソフトウェアテスト読書マップ Another View Feb. 9th, 2023 @kz_suzuki ⚫ このマップは、鈴木が好きな本を中心に並べたものに対し、マップ作成チームにいただいたコメントを取り込んだものです。 ⚫ ここにない本に対する否定的な意図はなく、おそらく単にわたしが読めずにいるだけです。不勉強でスミマセン。 ⚫ 開発者テストやテスト分析への言及も薄いです、これも不勉強です・・・。「暗黒大陸」へ「新世界」へ

⚫ 「一冊目」として外せない、さすがのベストセラー。 ⚫ ソフトウェアテストの役割、手法、計画のやり方など、テスト全体について広くカバーしている。 ⚫ 軽妙な語り口で飽きさせない。硬い本からのスタートが苦手な人にもありがたい。逆に、粗さを感じる部分もある。 ⚫ ソフトウェアエンジニアとして押さえておくべき基本的なテスト設計技法をわかりやすく解説している。 ⚫ わたしが初めてちゃんと読んだテスト本であり、エンジニア人生を変えてくれた書籍なので、思い入れが強すぎる。 ⚫ なのに改訂版を積んでいる、申し訳ありません・・・。知識ゼロから学ぶソフトウェアテスト著者: 高橋寿一出版社: 翔泳社出版年: 2012年 Amazonリンク構成 1. はじめに 2. ソフトウェアテストの基本 3. エンジニアがもっともよく使う手法 4. 探索的テスト 5. 非機能要求のテスト 6. ソフトウェアテスト運用の基本 7. ソフトウェア品質管理の基本 8. テストの自動化 9. それでもテストがうまくいかない人へソフトウェアテスト技法ドリル著者: 秋山浩一出版社: 日科技連出版社出版年: 2022年 Amazonリンク構成 1. 点に注意を向ける 2. 線を意識する同値分割、境界値分析、・・ 3. 面で逃さないドメイン分析テスト、デシジョンテーブル、クラシフィケーションツリー、CFD法、・・ 4. 立体で捉える HAYST法、ペアワイズ、・・ 5. 時間を網羅する状態遷移テスト、並列処理テスト、・・ 6. 多次元の品質シナリオテスト、受け入れテスト、・・

紹介書籍一覧(*1) (*1) 著者の一部や訳者が、一部省略されております。なお、リンクにアフィリエイトはつけていません！一部の本は電子書籍のみ、あるいは残念ながら絶版となっております・・・。著者: 大西建児、佐々木方規他出版社: 翔泳社 Amazonリンクソフトウェアテスト教科書 JSTQB Foundation 第4版シラバス2018対応ソフトウェアテスト入門押さえておきたい <<要点・重点>> 著者: ソフトウェア・テストPRESS編集部出版社: 技術評論社 Amazonリンク現場の仕事がバリバリ進むソフトウェアテスト手法著者: 高橋寿一、湯本剛出版社: 技術評論社 Amazonリンク著者: Rick Craig、Stefan P Jaskiel 出版社: 日経BP出版センター Amazonリンク体系的ソフトウェアテスト入門はじめて学ぶソフトウェアのテスト技法著者: リーコープランド出版社: 日経BP Amazonリンクソフトウェアテスト技法練習帳～知識を経験に変える40問～著者: 梅津正洋、竹内亜未他出版社: 技術評論社 Amazonリンク著者: Jonathan Rasmusson 出版社: オライリージャパン Amazonリンク初めての自動テスト ―Webシステムのための自動テスト基礎システムテスト自動化標準ガイド著者: Mark Fewster、Dorothy Graham 出版社: 翔泳社 Amazonリンク Agile Testing Condensed 著者: Janet Gregory、Lisa Crispin 出版社: - Leanpubリンク著者: ジェームズ A ウィテカー、ジェーソンアーボン、ジェフキャローロ出版社: 日経BP Amazonリンクテストから見えてくるグーグルのソフトウェア開発ソフトウェアテスト293の鉄則著者: セムケイナー, ジャームズバック他出版社: 日経BP Amazonリンクソフトウェアテストをカイゼンする 50のアイデア著者: Gojko Adzic, David Evans 他出版社: 翔泳社 Amazonリンク

なぜ、概要の次に、テスト設計なのか。というか「テストプロセス」「テスト設計」とは？

34 / 53 テストプロセスとテスト設計 Image: "Architecture #1" by Andrew
Dupont is licensed under CC BY-SA 2.0.

「テストプロセス」という言葉の定義 ◼ テストプロセス(*1) ⚫ 相互に関連する活動のセット。 ⚫ テスト計画作業、テストモニタリングとコントロール、テスト分析、テスト設計、テスト実装、テスト実行、テスト完了といった活動から構成される。 ◼ 「テスト開発」という考え方 ⚫ テストの分析・設計・実装という言葉からもわかるように、テスト自体もマクロからミクロへ、論理的な順を追って実現されていく「開発物」であると考える。 - いきなり「テストケース1,000件レビューしてください」と言われても困りますよね。 - まず「何を実現したいの？」から始める。 (*1) ISTQB Glossaryから引用。

テストプロセス(*1)が整えられていく例(*2) 本当にアドホックな世界・・・ (*1) アジャイル開発をしている人たちの前で「プロセス」という言葉を使うことに、恐怖感を覚えている自分がいます。 (*2) この順番に必ずプロセスが追加されていくというものではないです。 (*3) 「学習」という観点では、これが必ずしも悪いわけではないです。これだけだとつらいですが。テスト実行できたソフトウェアを、とにかく叩いてみる！(*3) テスト実行テスト実装実行する内容が不明だと、再現性がない・・・。テストケースをちゃんと具体化して書き下そう。テスト実行テスト実装テスト計画テスト完了見積もりとか計画とか、報告・情報整理・次の開発へのフィードバックは必要だよね。モニタリングとコントロールテスト実行テスト実装テスト計画テスト完了進捗・品質状況を定量的に把握して、必要に応じたアクションを取れるようにしよう。モニタリングとコントロールテスト分析テスト実行テスト実装テスト計画テスト完了テスト観点が足りていない。テストケースをいきなり作り始めるのではなく、まず観点を列挙・整理しよう。モニタリングとコントロールテスト設計テスト実行テスト実装テスト計画テスト完了ある観点に対して、テストが冗長だったり不足してたりする。テストケースをロジカルに導出できない？テスト分析

象をテストする場合のテストプロセス ◼ この人たちは、「現実の象がいかなるものか」を、いろんな「観点」できっちり見ている。 ⚫ 胴体、しっぽ、牙、・・・、特徴ある箇所を確認。 ⚫ 象のユーザビリティという非機能要件もカバーしている。 ◼ 象に関する情報を事前に調査したうえで、では実際に出てきた象のどこをチェックするかという観点を特定するのが、テスト分析。 ◼ それぞれの観点を効果的・効率的にチェックする方法を決めるのが、テスト設計。 ◼ 設計したものを実際に書き下したり、行う順番を決めたりするのが、テスト実装。 ◼ 実際の象チェックを行うのが、テスト実行。 ◼ 目隠しを外すのは、スクラムマスターの仕事？ The Blind Men and the Elephant: A Metaphor to Illuminate the Role of Researchers and Reviewers in Social Science - Scientific Figure on ResearchGate. Available from: https://www.researchgate.net/figure/The-Blind-Men-and-the-Elephant_fig1_290127733 [accessed 14 Jan, 2023] 有名なこの The Blind Men and the Elephant 「部分しか見ておらず、全体が見えてない」というメタファーで使われがちだけど・・・。

テストプロセスで、テストの課題を仕分けしてみると・・・ ◼ テストなんて考えてもみなかったところで本番障害が。。。 ⚫ テストの「分析」するプロセスの改善が必要かもしれません。 ◼ AIベースのソフトウェアってどうやってテストすればいいのだろう？ ⚫ ドメイン特有のテストの「設計」をするための「技法」を学ぶ必要があります。 ◼ 手動のテストに時間がかかりすぎるので、自動化したい・・・ ⚫ テストの「実装」というプロセスです(*1)。自動テストツールも関係してきます。 ◼ アジャイルで人気のある「探索的テスト」をやりたい！ ⚫ テストの「実行」というプロセス(*2)であり、実行のスタイルを学ぶことになります。 ◼ 手動テストと自動テストが混在して、進捗が全然わからん。 ⚫ テストの「管理」というプロセスで、ツール導入も含めて考える必要があります。 (*1) テスト自動化は実装のみが関係するわけではありません。テスト設計など実装以前の活動もとても重要です。また実行も、そのための計画ももちろん大事です。 (*2) 探索的テストは、テストの実行・学習・設計を短時間で反復・継続していくスタイルなので、「実行」のみではありません。このうち、なぜテスト設計をオススメするのか？

「テスト設計」とは何か ◼ テスト設計とは ⚫ テスト分析において「テストするぞ」と特定した対象を、テストケースに落とし込む作業。 - これ以外にも、テスト環境の設計やテストデータの検討も、テスト設計プロセスに含まれる。 ⚫ この作業において使うのが、「テスト技法」。 ◼ テスト技法とは ⚫ テスト条件の定義、テストケースの設計、およびテストデータの明確化をするための手続き。(*1) ⚫ 最適なテストケースを導出するために、以下の3つの手段と、対応する技法がある。(*2) 1. テストケースを合理的に少なくする - 同値分割法、組み合わせテスト 2. 多くの欠陥が見つかるようにする - 境界値分析、エラー推測、探索的テスト 3. テスト対象を漏れなくテストする - 制御フローテスト、データフローテスト、デシジョンテーブルテスト、状態遷移テスト、ユースケーステスト (*1) ISTQB Glossaryから引用。 (*2) 『ASTERセミナー標準テキスト』参照。

「テスト設計」がオススメな理由 ◼ 効果的と考えられるテストケースをロジカルに導出できるので、気分が良い。 ◼ テスト設計において利用するモデルは、ソフトウェア設計段階で使える。 ◼ 最初のプロセスの「計画」の詳細を先に学ぼうとすると、たぶん面白くない。 ⚫ テスト計画の重要性は、テストを何周か経験してからじゃないと身に沁みない。 ⚫ テンプレの定義された各種ドキュメントも、ただの儀式文書に思えてしまってやる気を失う。 1 2 3

テスト設計の具体例

SNSでこんな機能があったとする ◼ 仕様: グループへの参加手順① 1. ユーザは、そのグループのポータル画面で、「参加を希望する」ボタンを押す。 2. グループの管理者に承認依頼が通知される。 3. 管理者はそれを「承認」または「却下」する。 ◼ 仕様の検討: 状態遷移のにおいがする ⚫ 状態遷移テストでは、状態遷移モデルを描くことになっている。状態遷移図を描いて(*1)みよう！ ⚫ モデルから、状態遷移表を生成できる。 ⚫ 状態遷移テストでは最低限、状態遷移表のすべてのセルを網羅することになっているが・・・空欄だらけ。仕様が定まっていない可能性があることに気づく。 (*1) 状態遷移図・状態遷移表は、ベリサーブ社のサービス「GIHOZ」を利用して描いています。状態遷移図状態遷移表ユーザが一度「参加希望ボタン」を押した後、承認の前にもう一度ボタンを押したらどうなる？何も変わらないという動作なのか？そもそも押せない作りにするのか？自動生成

SNSでこんな機能があったとする ◼ 仕様追加: グループへの参加手順② 1. あるグループの管理者は、そのグループの管理画面でユーザを指定し、「招待する」ボタンを押す。 2. そのユーザに招待が通知される。 3. ユーザはそれを「承認」または「却下」する。 ◼ 仕様の検討: 状態遷移図の更新 ⚫ 管理者とユーザを入れ替えた遷移を追加するだけ？ ⚫ 状態遷移表を描くことで、「ユーザ承認待ちかつ管理者承認待ち」という新しい状態が発生しうることに気づく。 ⚫ ここでも、テスト設計のためのモデルを描くことで、「曖昧な仕様」を早く特定することができる。状態遷移図管理者がユーザの承認を待っている状態で、ユーザが「参加希望」ボタンを押すとどうなる？「参加状態」にしてしまうか？ ??

SNSでこんな機能があったとする ◼ テストの検討(*1) ⚫ 状態遷移表を描くことで、そこから特定の条件のテストケースを生成することができる。 - 0スイッチテストケース: 状態遷移が1度だけ起こるケース。状態遷移表の各セルを網羅することになる。 - 1スイッチテストケース: 状態遷移が2度起こるケース。 - この機能のハッピーパス（未参加→承認待ち→参加）や、「却下された後に再度申請」というケースも含まれている。 ⚫ 「状態遷移については、コレコレという条件で網羅性 100%である」と論理的に説明ができる。 - 「いろいろランダムにやってみて、問題ありませんでした！」だけだと不安ですよね？ (*1) ここではあくまでも、機能の状態遷移にのみ着目したテストについて述べています。状態遷移表 0スイッチテストケース 1スイッチテストケース自動生成

「テスト設計」がオススメな理由 (再掲) ◼ 効果的と考えられるテストケースをロジカルに導出できるので、気分が良い。 ⚫ 「状態遷移を2回起こすテストは3パターン。3つ実行すればカバレッジ100%」のように論理的・定量的にテストを実行・評価することができる。 ◼ テスト設計において利用するモデルは、ソフトウェア設計段階で使える。 ⚫ たとえば状態遷移図・表は、そもそもソフトウェア設計で使われる技術である。 ⚫ モデルを描くことで曖昧さが減り、検討漏れに気づきやすくなるうえに、自動生成までできる。テスト設計は、学習のコストパフォーマンスのよい技術です。 1 2

テスト計画・管理エリアテスト自動化エリアモダンなテスト文化エリアスルメエリアテスト設計エリア全体概要エリア (*) 書影はすべて、Amazonから引用。各書籍の情報はこのあとのスライドで一覧にします。ホワイトボックステストもカバーしたい場合もっと詳しく具体的な内容を知りたい場合コスパのよいテストを求めて演習＋勉強会で強くなる！テストの作り方はわかったので、自動化するぜ！アジャイルにおけるテストの位置づけや、先進企業のテストを学ぶマネージャーなどがソフトウェアテストの全体をより深く押さえる名著・古典。ちゃんと読めてない・・・ツールやドメインにあまり依存しない一般論を学ぶテストマネージャとしての一歩目を学ぶための良書ソフトウェアテスト全般について比較的平易に書かれた入門書テスト設計技法とツール、テスト分析について平易に説明 Webシステムに対する自動テストについてStep by Stepで説明アジャイルテスト全般の解説と事例紹介テストを何周か経験し、悩んだ後に読むと得るものが大きい実践書ソフトウェアテスト読書マップ Another View Feb. 9th, 2023 @kz_suzuki ⚫ このマップは、鈴木が好きな本を中心に並べたものに対し、マップ作成チームにいただいたコメントを取り込んだものです。 ⚫ ここにない本に対する否定的な意図はなく、おそらく単にわたしが読めずにいるだけです。不勉強でスミマセン。 ⚫ 開発者テストやテスト分析への言及も薄いです、これも不勉強です・・・。「暗黒大陸」へ「新世界」へ

ところで、テストの全体像みたいな話をしましたが・・・

ソフトウェア品質知識体系 ◼ テストは「品質保証」という技術の一部 ◼ 『ソフトウェア品質知識体系ガイド』の第3版では、こんな構成になっている。テストは、ごくごく一部・・・ ◼ 品質という広大な「暗黒大陸」(1)が・・・！ (*1) 往年の少年ジャンプの漫画のネタは、若者に対するハラスメントになりうるので注意が必要です。 SQuBOK V3の構造 (樹形図) 1. ソフトウェア品質の基本概念 2. ソフトウェア品質マネジメント 3. ソフトウェア品質技術 5. ソフトウェアの応用領域 1.1 品質の概念 1.2 品質マネジメントの概念 1.3 ソフトウェアの品質マネジメントの特徴組織レベル 2.1 ソフトウェア品質マネジメントシステムの構築と運用 2.2 ライフサイクルプロセスのマネジメント 2.3 ソフトウェアプロセス評価と改善のマネジメント 2.4 検査のマネジメント 2.5 監査のマネジメント 2.6 教育・育成のマネジメント 2.7 法的権利および法的責任のマネジメントプロジェクトレベル (共通) 2.8 意思決定のマネジメントプロジェクトレベル (個別) 2.13 品質計画のマネジメント 2.14 要求分析のマネジメント 2.15 設計のマネジメント 2.16 実装のマネジメント 2.17 レビューのマネジメント 2.18 テストのマネジメント 2.19 品質分析および評価のマネジメント 2.20 リリース可否判定 2.21 運用および保守のマネジメント 4. 専門的なソフトウェア品質の概念と技術工程に共通な技術 3.1 メトリクス 3.2 モデル化の技法 3.3 形式手法工程に個別な技術 3.4 要求分析の技法 3.5 設計の技法 3.6 実装の技法 3.7 レビューの技法 3.8 テストの技法 3.9 品質分析および評価の技法 3.10 運用および保守の技法 4.1 ユーザビリティ 4.2 セーフティ 4.3 セキュリティ 4.4 プライバシー 5.1 人工知能システムにおける品質 5.2 IoTシステムにおける品質 5.3 アジャイル開発と DevOpsにおける品質 5.4 クラウドサービスにおける品質 5.5 オープンソースソフトウェア利活用における品質 2.9 調達のマネジメント 2.10 リスクマネジメント 2.11 構成管理 2.12 プロジェクトマネジメント

49 / 53 まとめ Image: "goal!" by dannipenguin is licensed
under CC BY-NC-SA 2.0.

まとめ ◼ 「ソフトウェアテストの知識って何がうれしいのか」がわかる。 → ソフトウェア設計に生かせたり、QAの活動に対する解像度が上がります。 ◼ 「ソフトウェアテストを、どこから勉強すればいいのか」がわかる。 → 「テスト設計」は、コスパの高い技術でオススメです。書籍を選ぶ際には、「ソフトウェアテスト読書マップ」も参考にしてください。 → 「テスト、実は面白いのでは？」となったら、QAの世界にきてください！

テスト・QAイベントや勉強会 ◼ JaSST (ソフトウェアテストシンポジウム) ⚫ 長年続いている「各地開催版」の他、オンライン開催を主導したJaSST Online、テストでなくレビューを対象としたJaSST Review、敷居を極限まで下げたJaSST nanoと、スピンオフがたくさんある。 ⚫ JaSST ’23 Tokyoは、2023年3月9日～10日開催です！わたしもしゃべります。 ◼ WACATE (Workshop for Accelerating CApable Testing Engineers) ⚫ 年2回、1泊2日の合宿形式で、セッションやワークショップを通じてテストを学ぶ勉強会。 ◼ 企業主催のイベント ⚫ Ques: ヒューマンクレスト主催。ソフトウェアQAエンジニアの活性化を目的とする。 ⚫ QA Tech Night: AIQVE ONE主催。ゲームのテストなどを中心に、QAについて語る。 ⚫ ベリサーブ: テスト技法、管理ツールなどをテーマにしたイベント。 ⚫ Forkwell Community: grooves主催。TEST Studyというテーマの回がある。

One more thing … キミだけの最強の読書マップを作ってみないか!? 各技術分野のマップが充実していると、みんな嬉しい！

Happy Testing!!

デブサミ2023 / テストを学びたい開発者のためのソフトウェアテスト読書マップ / Software Testing Reading Map for Developers

デブサミ2023 / テストを学びたい開発者のためのソフトウェアテスト読書マップ / Software Testing Reading Map for Developers

More Decks by Kazuhiro SUZUKI

Other Decks in Technology

Featured

Transcript