Submit Search
Upload
ソフトウェア開発工程とテスト入門
•
15 likes
•
17,280 views
T
tadaaki hayashi
Follow
ウォーターフォールの工程と各種テストについての勉強会資料
Read less
Read more
Software
Report
Share
Report
Share
1 of 41
Download now
Download to read offline
Recommended
最新版はこちらへ https://www.slideshare.net/zembutsu/say-hello-to-your-presentation ーーー 『IT系エンジニアのためのプレゼンテーション入門』 インフラエンジニアのためのプレゼン技術研究会 第0回 2015年2月21日(土) 14:00 ~ 17:00 さくらインターネット セミナールーム(東京都新宿区) #infrapre http://connpass.com/event/11739/
IT系エンジニアのためのプレゼンテーション入門
IT系エンジニアのためのプレゼンテーション入門
Masahito Zembutsu
当資料は、2012/1/14に開催された、以下の勉強会で発表した資料です。 わんくま同盟 名古屋勉強会 #20 & 第39回 名古屋アジャイル勉強会 & TEF東海 勉強会 http://www.wankuma.com/seminar/20120114nagoya20/ 1/19 ・当日のワークの結果を追加した ・TEFの紹介部分を微修正 ・P1タイトル誤字を修正 1/23 ・WACATEのリンクを追加 ・テスト設計関連の参考リンクを追加 ・P18の図にライフサイクルの補足を追加 ・P16の表示が変だったのを直したよ
テストを分類してみよう!
テストを分類してみよう!
Kenji Okumura
1)構造化シナリオ法と9コマシナリオ 2)9コマシナリオの使い方 ── 例 3)なぜ9コマでマンガにしているのか?
9コマシナリオの使い方
9コマシナリオの使い方
Mayumi Okusa
ギルド勉強会で使ったスライド。
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。
toshihiro ichitani
2022-03-05 YAPC::Japan::Online 2022
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
http://www.ustream.tv/recorded/45962241
ソフトウェアテスト入門
ソフトウェアテスト入門
Preferred Networks
【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine: プログラマの思索 https://forza.cocolog-nifty.com/blog/2022/01/post-d7c59a.html
チケット駆動開発の解説~タスク管理からプロセス改善へ
チケット駆動開発の解説~タスク管理からプロセス改善へ
akipii Oga
テストやQA (品質保証) には説明責任が求められます。しかし、仕様書のコピペにすぎないテスト設計、自己目的化した自動化、規格に準拠しただけの開発 / 機能安全プロセス、おざなりな保証ケース、属人化したレビュー、ハードウェア主導のQA組織によるピントを外した品質保証など、説明責任とはほど遠い組織が多く見られます。そこで本講演ではQAアーキテクチャというコンセプトを紹介し、テストやQAの全体像を俯瞰し説明責任を高めるための方策を概説します。これにより、テスト自動化をベースとしたパイプライン化によるテストのリズムの高速化や、フロントローディングによる上流での品質作り込みサイクルの構築も目指すことができるようになります。
QAアーキテクチャの設計による説明責任の高いテスト・品質保証
QAアーキテクチャの設計による説明責任の高いテスト・品質保証
Yasuharu Nishi
Recommended
最新版はこちらへ https://www.slideshare.net/zembutsu/say-hello-to-your-presentation ーーー 『IT系エンジニアのためのプレゼンテーション入門』 インフラエンジニアのためのプレゼン技術研究会 第0回 2015年2月21日(土) 14:00 ~ 17:00 さくらインターネット セミナールーム(東京都新宿区) #infrapre http://connpass.com/event/11739/
IT系エンジニアのためのプレゼンテーション入門
IT系エンジニアのためのプレゼンテーション入門
Masahito Zembutsu
当資料は、2012/1/14に開催された、以下の勉強会で発表した資料です。 わんくま同盟 名古屋勉強会 #20 & 第39回 名古屋アジャイル勉強会 & TEF東海 勉強会 http://www.wankuma.com/seminar/20120114nagoya20/ 1/19 ・当日のワークの結果を追加した ・TEFの紹介部分を微修正 ・P1タイトル誤字を修正 1/23 ・WACATEのリンクを追加 ・テスト設計関連の参考リンクを追加 ・P18の図にライフサイクルの補足を追加 ・P16の表示が変だったのを直したよ
テストを分類してみよう!
テストを分類してみよう!
Kenji Okumura
1)構造化シナリオ法と9コマシナリオ 2)9コマシナリオの使い方 ── 例 3)なぜ9コマでマンガにしているのか?
9コマシナリオの使い方
9コマシナリオの使い方
Mayumi Okusa
ギルド勉強会で使ったスライド。
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。
toshihiro ichitani
2022-03-05 YAPC::Japan::Online 2022
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
http://www.ustream.tv/recorded/45962241
ソフトウェアテスト入門
ソフトウェアテスト入門
Preferred Networks
【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine: プログラマの思索 https://forza.cocolog-nifty.com/blog/2022/01/post-d7c59a.html
チケット駆動開発の解説~タスク管理からプロセス改善へ
チケット駆動開発の解説~タスク管理からプロセス改善へ
akipii Oga
テストやQA (品質保証) には説明責任が求められます。しかし、仕様書のコピペにすぎないテスト設計、自己目的化した自動化、規格に準拠しただけの開発 / 機能安全プロセス、おざなりな保証ケース、属人化したレビュー、ハードウェア主導のQA組織によるピントを外した品質保証など、説明責任とはほど遠い組織が多く見られます。そこで本講演ではQAアーキテクチャというコンセプトを紹介し、テストやQAの全体像を俯瞰し説明責任を高めるための方策を概説します。これにより、テスト自動化をベースとしたパイプライン化によるテストのリズムの高速化や、フロントローディングによる上流での品質作り込みサイクルの構築も目指すことができるようになります。
QAアーキテクチャの設計による説明責任の高いテスト・品質保証
QAアーキテクチャの設計による説明責任の高いテスト・品質保証
Yasuharu Nishi
【豆寄席】今更きけないシリーズ第3回:ソフトウェア工学(要求工学編)2021年12月22日開催
今さら聞けないソフトウエアエンジアニアリング(要求編)
今さら聞けないソフトウエアエンジアニアリング(要求編)
豆寄席 (株式会社豆蔵)
「マージがなんとなく怖い」「リベースするなって怒られて怖い」「エラーが出て怖い」 Git 入門者にありがちな「Git 怖い」を解消するため、Git のお仕事(コミット、ブランチ、マージ、リベース)について解説します。
こわくない Git
こわくない Git
Kota Saito
長沢智治が実施している「プレゼン基礎講座」を公開しました。今までに大学、専門学校、法人営業、法人研究職、法人エンジニア職向けに実施してきたものです。あくまでエバンジェリスト長沢流です。
プレゼン基礎講座 2016.11
プレゼン基礎講座 2016.11
智治 長沢
Developers Summit 2015 基調講演第二部リレーセッションの登壇資料です。 ドワンゴの新卒エンジニア達が「ニコニ立体」というサービスを立ち上げました。 ニコニ立体の存在によって新卒エンジニア達が何を得たのかのご紹介です。
ドワンゴの新卒エンジニアが新規サービスを立ち上げるまで
ドワンゴの新卒エンジニアが新規サービスを立ち上げるまで
Kazunari Kida
シリコンバレーのスタートアップを数多く取材する中で気付いた「シリコンバレーにおけるディシプリン(規律)の存在」や「General Electric(GE)やIBM、SAPといった老舗企業が必死になってシリコンバレーのスタートアップを真似している理由」、そして「日本企業がイノベーションを実現するための処方箋」について解説します 詳しく知りたい場合は「GE 巨人の復活」をご覧下さい。 http://www.nikkeibp.co.jp/atclpubmkt/book/17/P55110/ 今後の記事は「シリコンバレーNext」をご覧下さい。 http://itpro.nikkeibp.co.jp/siliconvalley/
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
Atsushi Nakada
2021年にインフィニットループ社内の新卒向け研修で使われた資料です。
テスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるな
Kentaro Matsui
型安全性に関するカジュアルな解説です。
型安全性入門
型安全性入門
Akinori Abe
オリジナルはこちら https://www.microsoft.com/en-us/research/academic-program/write-great-research-paper/ http://research.microsoft.com/en-us/um/people/simonpj/papers/giving-a-talk/Writing%20a%20paper%20(seven%20suggestions).pptx 新しいバージョンはこちら https://www.slideshare.net/kdmsnr/how-to-write-a-great-research-paper-226669082
優れた研究論文の書き方―7つの提案
優れた研究論文の書き方―7つの提案
Masanori Kado
Product Requirements Documentの解説です。 プロダクトの強い軸を作るプロダクトマネジメントフレームワーク (https://www.slideshare.net/kumikokoshiro/ss-192896028 ) と合わせてお読み下さい。
はじめてのPRD
はじめてのPRD
Takuya Oikawa
Forkwell Meetup #3 https://forkwell.connpass.com/event/48147/
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
Takafumi ONAKA
ソフトウェアテストシンポジウム 2014 北海道基調講演 2014年9月5日(金)
Test Yourself - テストを書くと何がどう変わるか
Test Yourself - テストを書くと何がどう変わるか
Takuto Wada
WACATE 2015 冬 「60分でわかった気になるISO29119」セッションの事前公開スライドです
60分でわかった気になるISO29119 #wacate
60分でわかった気になるISO29119 #wacate
Kinji Akemine
統計的係り受け解析入門
統計的係り受け解析入門
Yuya Unno
鷲崎弘宜, "アジャイル品質パターン (Agile Quality, QA2AQ), アジャイル時代の組織ケーパビリティ向上 CMMI V2.0 / APH(アジャイルパフォーマンスモデル) / アジャイル品質パターンセミナー, 早稲田大学, 2019年6月6日
Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)
Hironori Washizaki
CEDEC 2021 の講演資料です。 ノートに講演で話した内容をそのまま記載ありますので、 講演内容を完全に把握したい方はダウンロードしての閲覧をお勧めします。 株式会社セガ 開発技術部 廣島岳史/竹原涼
CEDEC2021 Android iOS 実機上での自動テストをより楽に有意義にする為に ~端末管理・イメージ転送・動画記録等の周辺情報のノウハウ共有~
CEDEC2021 Android iOS 実機上での自動テストをより楽に有意義にする為に ~端末管理・イメージ転送・動画記録等の周辺情報のノウハウ共有~
SEGADevTech
メトリクスによるソフトウェアの品質把握と改善 -GQM法とメトリクス動向- ◆概要 測定とメトリクスの基本概念、および、GQMによる目標指向の測定の解説と演習。成功や失敗の事例紹介。 ◆講師 鷲崎 弘宜 氏 早稲田大学グローバルソフトウェアエンジニアリング研究所所長・准教授 略歴: 2003年早稲田大学大学院博士後期課程修了、博士(情報科学)。 2008年より早稲田大学准教授、国立情報学研究所客員准教授。 再利用と品質保証を中心としたソフトウェア工学の研究と教育に従事。 他の活動に日科技連SQiP研究会運営小委員会委員長、 同研究会演習コース主査、情報処理学会論文誌編集委員など。 本日、QuaSTom高品質ソフトウェア技術交流会 第1回例会にて「メトリクスによるソフトウェアの品質把握と改善-GQM法とメトリクス動向-」と題し、メトリクスの基本概念や落とし穴・コツ、事例、そしてGQM法のコツとワークショップ(+少しだけ GQM+Strategiesの解説)と盛りだくさんの内容を実施しました。ワークショップでは限られた時間の中で各チーム、ゴールからメトリクス、さらには仮定まで練られたものが得られた点はさすがです。議論においても今後の実践に踏み込んだものが多数あり、参加者の皆さんの問題意識の髙さやご経験を踏まえた関心の高さを感じました。ぜひ今後実践や連携いただければ幸いです。
Qua s tom-メトリクスによるソフトウェアの品質把握と改善
Qua s tom-メトリクスによるソフトウェアの品質把握と改善
Hironori Washizaki
https://www.youtube.com/watch?v=krnaOxKRhoQ&feature=youtu.be Machine learning system in Python. https://github.com/mercari/ml-system-design-pattern
Ml system in_python
Ml system in_python
yusuke shibui
言語処理学会第22回年次大会ワークショップ「論文に書かない(書けない)自然言語処理」
研究室における研究・実装ノウハウの共有
研究室における研究・実装ノウハウの共有
Naoaki Okazaki
JJUG CCC 2018 Fall #ccc_e3
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
Yoshitaka Kawashima
2015/6/22にアイ・ラーニング様にて開催された「悩める管理職のためのエンタープライズ・アジャイル導入セミナー」の講演資料です。
企業システムにアジャイルは必要か
企業システムにアジャイルは必要か
Hiromasa Oka
6/15(水)「はじめてのテスト講座~初心者向けソフトウェアテストのお話~ in Fusic」
はじめてのソフトウェアテスト
はじめてのソフトウェアテスト
Rina Fukuda
関数型言語とオブジェクト指向型言語について社内で勉強会を開いたときの資料です。第一回。
関数型言語とオブジェクト指向言語(序章)
関数型言語とオブジェクト指向言語(序章)
tadaaki hayashi
More Related Content
What's hot
【豆寄席】今更きけないシリーズ第3回:ソフトウェア工学(要求工学編)2021年12月22日開催
今さら聞けないソフトウエアエンジアニアリング(要求編)
今さら聞けないソフトウエアエンジアニアリング(要求編)
豆寄席 (株式会社豆蔵)
「マージがなんとなく怖い」「リベースするなって怒られて怖い」「エラーが出て怖い」 Git 入門者にありがちな「Git 怖い」を解消するため、Git のお仕事(コミット、ブランチ、マージ、リベース)について解説します。
こわくない Git
こわくない Git
Kota Saito
長沢智治が実施している「プレゼン基礎講座」を公開しました。今までに大学、専門学校、法人営業、法人研究職、法人エンジニア職向けに実施してきたものです。あくまでエバンジェリスト長沢流です。
プレゼン基礎講座 2016.11
プレゼン基礎講座 2016.11
智治 長沢
Developers Summit 2015 基調講演第二部リレーセッションの登壇資料です。 ドワンゴの新卒エンジニア達が「ニコニ立体」というサービスを立ち上げました。 ニコニ立体の存在によって新卒エンジニア達が何を得たのかのご紹介です。
ドワンゴの新卒エンジニアが新規サービスを立ち上げるまで
ドワンゴの新卒エンジニアが新規サービスを立ち上げるまで
Kazunari Kida
シリコンバレーのスタートアップを数多く取材する中で気付いた「シリコンバレーにおけるディシプリン(規律)の存在」や「General Electric(GE)やIBM、SAPといった老舗企業が必死になってシリコンバレーのスタートアップを真似している理由」、そして「日本企業がイノベーションを実現するための処方箋」について解説します 詳しく知りたい場合は「GE 巨人の復活」をご覧下さい。 http://www.nikkeibp.co.jp/atclpubmkt/book/17/P55110/ 今後の記事は「シリコンバレーNext」をご覧下さい。 http://itpro.nikkeibp.co.jp/siliconvalley/
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
Atsushi Nakada
2021年にインフィニットループ社内の新卒向け研修で使われた資料です。
テスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるな
Kentaro Matsui
型安全性に関するカジュアルな解説です。
型安全性入門
型安全性入門
Akinori Abe
オリジナルはこちら https://www.microsoft.com/en-us/research/academic-program/write-great-research-paper/ http://research.microsoft.com/en-us/um/people/simonpj/papers/giving-a-talk/Writing%20a%20paper%20(seven%20suggestions).pptx 新しいバージョンはこちら https://www.slideshare.net/kdmsnr/how-to-write-a-great-research-paper-226669082
優れた研究論文の書き方―7つの提案
優れた研究論文の書き方―7つの提案
Masanori Kado
Product Requirements Documentの解説です。 プロダクトの強い軸を作るプロダクトマネジメントフレームワーク (https://www.slideshare.net/kumikokoshiro/ss-192896028 ) と合わせてお読み下さい。
はじめてのPRD
はじめてのPRD
Takuya Oikawa
Forkwell Meetup #3 https://forkwell.connpass.com/event/48147/
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
Takafumi ONAKA
ソフトウェアテストシンポジウム 2014 北海道基調講演 2014年9月5日(金)
Test Yourself - テストを書くと何がどう変わるか
Test Yourself - テストを書くと何がどう変わるか
Takuto Wada
WACATE 2015 冬 「60分でわかった気になるISO29119」セッションの事前公開スライドです
60分でわかった気になるISO29119 #wacate
60分でわかった気になるISO29119 #wacate
Kinji Akemine
統計的係り受け解析入門
統計的係り受け解析入門
Yuya Unno
鷲崎弘宜, "アジャイル品質パターン (Agile Quality, QA2AQ), アジャイル時代の組織ケーパビリティ向上 CMMI V2.0 / APH(アジャイルパフォーマンスモデル) / アジャイル品質パターンセミナー, 早稲田大学, 2019年6月6日
Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)
Hironori Washizaki
CEDEC 2021 の講演資料です。 ノートに講演で話した内容をそのまま記載ありますので、 講演内容を完全に把握したい方はダウンロードしての閲覧をお勧めします。 株式会社セガ 開発技術部 廣島岳史/竹原涼
CEDEC2021 Android iOS 実機上での自動テストをより楽に有意義にする為に ~端末管理・イメージ転送・動画記録等の周辺情報のノウハウ共有~
CEDEC2021 Android iOS 実機上での自動テストをより楽に有意義にする為に ~端末管理・イメージ転送・動画記録等の周辺情報のノウハウ共有~
SEGADevTech
メトリクスによるソフトウェアの品質把握と改善 -GQM法とメトリクス動向- ◆概要 測定とメトリクスの基本概念、および、GQMによる目標指向の測定の解説と演習。成功や失敗の事例紹介。 ◆講師 鷲崎 弘宜 氏 早稲田大学グローバルソフトウェアエンジニアリング研究所所長・准教授 略歴: 2003年早稲田大学大学院博士後期課程修了、博士(情報科学)。 2008年より早稲田大学准教授、国立情報学研究所客員准教授。 再利用と品質保証を中心としたソフトウェア工学の研究と教育に従事。 他の活動に日科技連SQiP研究会運営小委員会委員長、 同研究会演習コース主査、情報処理学会論文誌編集委員など。 本日、QuaSTom高品質ソフトウェア技術交流会 第1回例会にて「メトリクスによるソフトウェアの品質把握と改善-GQM法とメトリクス動向-」と題し、メトリクスの基本概念や落とし穴・コツ、事例、そしてGQM法のコツとワークショップ(+少しだけ GQM+Strategiesの解説)と盛りだくさんの内容を実施しました。ワークショップでは限られた時間の中で各チーム、ゴールからメトリクス、さらには仮定まで練られたものが得られた点はさすがです。議論においても今後の実践に踏み込んだものが多数あり、参加者の皆さんの問題意識の髙さやご経験を踏まえた関心の高さを感じました。ぜひ今後実践や連携いただければ幸いです。
Qua s tom-メトリクスによるソフトウェアの品質把握と改善
Qua s tom-メトリクスによるソフトウェアの品質把握と改善
Hironori Washizaki
https://www.youtube.com/watch?v=krnaOxKRhoQ&feature=youtu.be Machine learning system in Python. https://github.com/mercari/ml-system-design-pattern
Ml system in_python
Ml system in_python
yusuke shibui
言語処理学会第22回年次大会ワークショップ「論文に書かない(書けない)自然言語処理」
研究室における研究・実装ノウハウの共有
研究室における研究・実装ノウハウの共有
Naoaki Okazaki
JJUG CCC 2018 Fall #ccc_e3
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
Yoshitaka Kawashima
2015/6/22にアイ・ラーニング様にて開催された「悩める管理職のためのエンタープライズ・アジャイル導入セミナー」の講演資料です。
企業システムにアジャイルは必要か
企業システムにアジャイルは必要か
Hiromasa Oka
What's hot
(20)
今さら聞けないソフトウエアエンジアニアリング(要求編)
今さら聞けないソフトウエアエンジアニアリング(要求編)
こわくない Git
こわくない Git
プレゼン基礎講座 2016.11
プレゼン基礎講座 2016.11
ドワンゴの新卒エンジニアが新規サービスを立ち上げるまで
ドワンゴの新卒エンジニアが新規サービスを立ち上げるまで
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
テスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるな
型安全性入門
型安全性入門
優れた研究論文の書き方―7つの提案
優れた研究論文の書き方―7つの提案
はじめてのPRD
はじめてのPRD
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
Test Yourself - テストを書くと何がどう変わるか
Test Yourself - テストを書くと何がどう変わるか
60分でわかった気になるISO29119 #wacate
60分でわかった気になるISO29119 #wacate
統計的係り受け解析入門
統計的係り受け解析入門
Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)
CEDEC2021 Android iOS 実機上での自動テストをより楽に有意義にする為に ~端末管理・イメージ転送・動画記録等の周辺情報のノウハウ共有~
CEDEC2021 Android iOS 実機上での自動テストをより楽に有意義にする為に ~端末管理・イメージ転送・動画記録等の周辺情報のノウハウ共有~
Qua s tom-メトリクスによるソフトウェアの品質把握と改善
Qua s tom-メトリクスによるソフトウェアの品質把握と改善
Ml system in_python
Ml system in_python
研究室における研究・実装ノウハウの共有
研究室における研究・実装ノウハウの共有
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
企業システムにアジャイルは必要か
企業システムにアジャイルは必要か
Viewers also liked
6/15(水)「はじめてのテスト講座~初心者向けソフトウェアテストのお話~ in Fusic」
はじめてのソフトウェアテスト
はじめてのソフトウェアテスト
Rina Fukuda
関数型言語とオブジェクト指向型言語について社内で勉強会を開いたときの資料です。第一回。
関数型言語とオブジェクト指向言語(序章)
関数型言語とオブジェクト指向言語(序章)
tadaaki hayashi
勉強会で使った資料です。
データベース入門3
データベース入門3
tadaaki hayashi
勉強会で使った資料です。
データベース入門1
データベース入門1
tadaaki hayashi
SEカレッジのフィードバック
ソフトウェアテスト入門
ソフトウェアテスト入門
iKenji
PHPカンファレンス福岡2016
日本で一番PHPのシステムをテストしている手動テスターが思うところ:PHPカンファレンス福岡
日本で一番PHPのシステムをテストしている手動テスターが思うところ:PHPカンファレンス福岡
Rina Fukuda
2012/01/14 にわんくま名古屋でLTした資料です。
うさみみのソフトウェアテスト勉強法
うさみみのソフトウェアテスト勉強法
kyon mm
IPA presentation of Agile Development in Japan, and contract model at Agile Japan 2011
Agile Development and Contract from IPA at AgileJapan 2011
Agile Development and Contract from IPA at AgileJapan 2011
Kenji Hiranabe
JaSST'08 Kyushu での発表資料の一部抜粋版。
マインドマップを使った 仕様分析&テスト設計
マインドマップを使った 仕様分析&テスト設計
Akira Ikeda
勉強外で使った資料です。
データベース入門2
データベース入門2
tadaaki hayashi
製造業のQA部門におけるソフトハウスの品質保証の問題点の典型例を示し、品質保証戦略およびQAアーキテクチャ設計の概要について述べる。またソフトウェアの品質保証の概略について述べる。補足としてVSTePとWモデルについて説明している。日本規格協会 品質経営システム研究会(COSCO)の2016/06/28の資料。http://www.slideshare.net/YasuharuNishi/ss-63412458 のアップデート版です。
ソフトウェアの品質保証の基礎とこれから
ソフトウェアの品質保証の基礎とこれから
Yasuharu Nishi
第1回自動テスト勉強会のたたき台。 思ったことを淡々とつなげただけのものです。
システム開発のテスト メモリーツリー
システム開発のテスト メモリーツリー
SE情報技術研究会
吉岡 弘隆、楽天株式会社 『TDD Boot Camp 大阪』 講演資料 25年以上のソフトウェア開発経験について、ソフトウェアのテスト、 日々の作業などを、実例を交えてお話します。
大規模ソフトウェア開発とテストの経験について
大規模ソフトウェア開発とテストの経験について
Rakuten Group, Inc.
「マインドマップから始めるソフトウェアテスト」のまとめスライドです。
「マインドマップから始めるソフトウェアテスト」まとめ
「マインドマップから始めるソフトウェアテスト」まとめ
Kosuke Fujisawa
2015/8/10 九州ソフトウェアテスト勉強会 vol.16 での発表資料です。新卒エンジニア向けに行っている「QAレクチャー」について話をしました。
九州ソフトウェアテスト勉強会Vol.16 発表資料 150810
九州ソフトウェアテスト勉強会Vol.16 発表資料 150810
Takayoshi Sakaino
http://connpass.com/event/21897/ 2015年11月27日に行った勉強会「Mass塾:SQiP論文を肴としたソフトウェアテスト分析の激論」の資料。
Mass塾:テスト分析
Mass塾:テスト分析
Masanori Kaneko
AgileJapan2010 官公庁でも取り組み始めたアジャイル! 山形県庁
AgileJapan2010 官公庁でも取り組み始めたアジャイル! 山形県庁
Akiko Kosaka
鷲崎弘宜, SWEBOKにみるソフトウェアエンジニアリングの全体、および、 つながる時代のソフトウェアモデリング&品質
SWEBOKにみるソフトウェアエンジニアリングの全体、および、 つながる時代のソフトウェアモデリング&品質
SWEBOKにみるソフトウェアエンジニアリングの全体、および、 つながる時代のソフトウェアモデリング&品質
Hironori Washizaki
t
Google mock for dummies
Google mock for dummies
Harry Potter
Presentation done at CodeCamp Winnipeg
every-day-automation
every-day-automation
Amir Barylko
Viewers also liked
(20)
はじめてのソフトウェアテスト
はじめてのソフトウェアテスト
関数型言語とオブジェクト指向言語(序章)
関数型言語とオブジェクト指向言語(序章)
データベース入門3
データベース入門3
データベース入門1
データベース入門1
ソフトウェアテスト入門
ソフトウェアテスト入門
日本で一番PHPのシステムをテストしている手動テスターが思うところ:PHPカンファレンス福岡
日本で一番PHPのシステムをテストしている手動テスターが思うところ:PHPカンファレンス福岡
うさみみのソフトウェアテスト勉強法
うさみみのソフトウェアテスト勉強法
Agile Development and Contract from IPA at AgileJapan 2011
Agile Development and Contract from IPA at AgileJapan 2011
マインドマップを使った 仕様分析&テスト設計
マインドマップを使った 仕様分析&テスト設計
データベース入門2
データベース入門2
ソフトウェアの品質保証の基礎とこれから
ソフトウェアの品質保証の基礎とこれから
システム開発のテスト メモリーツリー
システム開発のテスト メモリーツリー
大規模ソフトウェア開発とテストの経験について
大規模ソフトウェア開発とテストの経験について
「マインドマップから始めるソフトウェアテスト」まとめ
「マインドマップから始めるソフトウェアテスト」まとめ
九州ソフトウェアテスト勉強会Vol.16 発表資料 150810
九州ソフトウェアテスト勉強会Vol.16 発表資料 150810
Mass塾:テスト分析
Mass塾:テスト分析
AgileJapan2010 官公庁でも取り組み始めたアジャイル! 山形県庁
AgileJapan2010 官公庁でも取り組み始めたアジャイル! 山形県庁
SWEBOKにみるソフトウェアエンジニアリングの全体、および、 つながる時代のソフトウェアモデリング&品質
SWEBOKにみるソフトウェアエンジニアリングの全体、および、 つながる時代のソフトウェアモデリング&品質
Google mock for dummies
Google mock for dummies
every-day-automation
every-day-automation
Similar to ソフトウェア開発工程とテスト入門
Basis of software test. This presentation includes "What is software test", "Development process", "White-Box test", "Black-Box test".
Software Test Basic
Software Test Basic
Akinari Tsugo
昔、現場の人に頼まれて作った資料。何と名前をつければよいかよくわからなかったので、タイトルは敢えて大雑把。当時それっぽいと思ってたことを書いただけなので、今は違うことを思ってるかもしれない。
Software testing
Software testing
Masayuki Wakizaka
Game Comunity SummitのGamePM枠で講演した際の資料です https://sites.google.com/site/gamecomsummit/
GCSアジャイル開発を使ったゲームの作り方
GCSアジャイル開発を使ったゲームの作り方
Hiroyuki Tanaka
ゲーム開発環境勉強会#1の資料です
Gamedevenvstudy1
Gamedevenvstudy1
Takashi Kokawa
JaSST北海道2012での発表資料
テスト駆動開発の導入ーペアプログラミングの学習効果ー
テスト駆動開発の導入ーペアプログラミングの学習効果ー
Shuji Watanabe
【I-TRIZのIPSの基本プロセスとツール】 ①システムアプローチで、問題的状況を多面的に見て、理解を深め、そして、状況を改善するために着眼すべき様々な課題が見出される。理想像が描ける。 ②資源把握により、利用可能な資源が明確になる。見落としていた未利用資源に気付く。 ここまでに把握した事柄に基づき、機能の原因と結果の関係を表した機能ダイヤグラムを描く。様々な機能がネットワーク状の原因結果関係で結ばれる。混沌としていた状況が明確になる。 ダイヤグラムから、状況を改善するための種々のタスク(どこをどういう方向に変えればいいかという指針)が導かれる。 ③指針ごとに、オペレータ(アナロジーで具体的アイデアを出すための一般解)を使ってアイデアを出す。 ④アイデアを組み合わせて、解決策(コンセプト)作り上げる。
I-TRIZのエッセンスと事例
I-TRIZのエッセンスと事例
IDEATION JAPAN
2016年5月に開催された Microsoft de:code 2016 での、Windows OS 標準機能や Sysinternals, dump ファイル等を用いたトラブルシューティングに関するセッションスライドです。 [イベント名] Microsoft de:code 2016 [開催日] 2016年5月25日 [セッションID] INF-028 [セッションタイトル] そのエラーやお困りごと、ツールを使えば解決できるかも! ~ Sysinternals や OS 標準ツールの徹底活用術 ~
そのエラーやお困りごと、ツールを使えば解決できるかも! ~ Sysinternals や OS 標準ツールの徹底活用術 ~ (Microsoft de:c...
そのエラーやお困りごと、ツールを使えば解決できるかも! ~ Sysinternals や OS 標準ツールの徹底活用術 ~ (Microsoft de:c...
Takamasa Maejima
2018/06/23 国立情報学研究所 オープンハウス2018 「NII研究100連発」内の10連発
スマートなシステム、スマートなディペンダビリティ保証-次世代システムを頼れるものへ
スマートなシステム、スマートなディペンダビリティ保証-次世代システムを頼れるものへ
Fuyuki Ishikawa
少し分かった気になるテスト駆動開発
少し分かった気になるテスト駆動開発
lnial
長岡 IT開発者 勉強会(NDS) 第31回勉強会(2013/04/06) 発表資料
はじめてのテスト技法
はじめてのテスト技法
Tatsuya Saito
Developer's Summit 2005
Visualizing Software Development
Visualizing Software Development
Kenji Hiranabe
2012/12/22(土)の社内で開催した「プレゼン祭り」で発表した内容です。アジャイルに全く触れたことが無い人を対象にしたつもりが、「難しい」「内容が盛り沢山で覚え切れなかった」「寝ちゃった」などなどとあまり好評ではなかったのですが、自戒の念も込めて公開しておきます。 対象は「ウォーターフォール開発しか体験したことのない経験5〜6年程度の若者」です。 ※2022/04/11追記 Speaker Deckに移行しました。 https://speakerdeck.com/takigawa401/toriaesu30fen-tehitotoorifen-katutaqi-nihanareruasiyairuru-men
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
陽一 滝川
INF-028_そのエラーやお困りごと、ツールを使えば解決できるかも! ~Sysinternals や OS 標準ツールの徹底活用術~
INF-028_そのエラーやお困りごと、ツールを使えば解決できるかも! ~Sysinternals や OS 標準ツールの徹底活用術~
INF-028_そのエラーやお困りごと、ツールを使えば解決できるかも! ~Sysinternals や OS 標準ツールの徹底活用術~
decode2016
2013/12/6に実施された「リーンな現場の実際 ~企画サイドと開発サイドからみる失敗と成功~」で使用した資料です。 公開用に一部修正をしています。
リーン開発の本質 公開用
リーン開発の本質 公開用
ESM SEC
Ldd13 present
Ldd13 present
Masashi Kayahara
2012/04/30 鹿駆動勉強会のLT資料です
鹿駆動
鹿駆動
Shinichi Kozake
プログラミング手法について調べてみたので、その際に参考にしたリンク集です。
プログラミング手法について調べてみた
プログラミング手法について調べてみた
OgataAyaka
SeasarCon 2009 White TDD
SeasarCon 2009 White TDD
Takuto Wada
Jupyterを演習の環境として使ってみた
Jupyter勉強会 20160701 at NII
Jupyter勉強会 20160701 at NII
axsh co., LTD.
Eclipse を使った java 開発 111126 杉浦
Eclipse を使った java 開発 111126 杉浦
urasandesu
Similar to ソフトウェア開発工程とテスト入門
(20)
Software Test Basic
Software Test Basic
Software testing
Software testing
GCSアジャイル開発を使ったゲームの作り方
GCSアジャイル開発を使ったゲームの作り方
Gamedevenvstudy1
Gamedevenvstudy1
テスト駆動開発の導入ーペアプログラミングの学習効果ー
テスト駆動開発の導入ーペアプログラミングの学習効果ー
I-TRIZのエッセンスと事例
I-TRIZのエッセンスと事例
そのエラーやお困りごと、ツールを使えば解決できるかも! ~ Sysinternals や OS 標準ツールの徹底活用術 ~ (Microsoft de:c...
そのエラーやお困りごと、ツールを使えば解決できるかも! ~ Sysinternals や OS 標準ツールの徹底活用術 ~ (Microsoft de:c...
スマートなシステム、スマートなディペンダビリティ保証-次世代システムを頼れるものへ
スマートなシステム、スマートなディペンダビリティ保証-次世代システムを頼れるものへ
少し分かった気になるテスト駆動開発
少し分かった気になるテスト駆動開発
はじめてのテスト技法
はじめてのテスト技法
Visualizing Software Development
Visualizing Software Development
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
INF-028_そのエラーやお困りごと、ツールを使えば解決できるかも! ~Sysinternals や OS 標準ツールの徹底活用術~
INF-028_そのエラーやお困りごと、ツールを使えば解決できるかも! ~Sysinternals や OS 標準ツールの徹底活用術~
リーン開発の本質 公開用
リーン開発の本質 公開用
Ldd13 present
Ldd13 present
鹿駆動
鹿駆動
プログラミング手法について調べてみた
プログラミング手法について調べてみた
SeasarCon 2009 White TDD
SeasarCon 2009 White TDD
Jupyter勉強会 20160701 at NII
Jupyter勉強会 20160701 at NII
Eclipse を使った java 開発 111126 杉浦
Eclipse を使った java 開発 111126 杉浦
ソフトウェア開発工程とテスト入門
1.
ソフトウェア開発工程と テスト入門
2.
テストに行く前に。 ソフトウェア開発のプロセスと工程について少しお話し ます。
3.
ソフトウェア開発プロセス。 ソフトウェアを開発していく時の進め方として、 いくつかの方法論、開発プロセスがあります。 プロセスというと難しく感じるかもしれませんが、簡単に言えば どういう順番でシステム構築を進めるか、といった話です。 開発モデルなどとも呼ばれます。 代表的なものとして、以下のようなものがあります。 ・ウォータフォール型(上から順に) ・プロトタイプ型(サンプル作って見せて直して) ・スパイラル型(小さなウォーターフォールの繰り返し) ・アジャイル型(XP、リーン、スクラムなど)
4.
ソフトウェア開発プロセス。 これらの開発プロセスは、「情報処理技術者試験」の「基 本情報」でも触れられている基礎知識ですので、エンジニ アならば予備知識として知っておきましょう。 基本情報資格はIT業界ではほとんどの会社で、新人が取得する様に推 奨される資格で、毎年2回実施されています。 これらの中で日本で昔から一番広く使われているものが 「ウォーターフォール型開発プロセス」 になります。 今回は、このウォーターフォールを例に説明します。
5.
ウォーターフォール型とは。 ウォーターフォールでは、プロジェクト全体を 「要件定義」「基本設計」「詳細設計」、「製造(実装・コーディン グ)」、「テスト」、「運用」、「保守」等の工程と呼ばれる単位に 分割します。 これらの分割された各工程を、1つ終わったら次と、順番に進めて いくことで、システムを構築していく開発プロセスです。 WaterFallは滝です。 滝のように上から下へ、上流工程から下流工程まで開発を進めていく ため、「ウォーターフォール」という名前が付けられています。
6.
こんなイメージ。
7.
滝。。 (´・ω・`)ショボーン
8.
各工程ではどんなことをするか。 要件定義:ユーザーの要求・要望を抽出し、システム化するうえでの 機能要件・非機能要件(バックアップ方法、稼働時間etc)としてまとめます。 つくるもの:要件定義書とか。 基本設計:外部設計、概要設計などとも呼ばれます。要件定義書を ベースに、画面のイメージを起こしたり、システムで出力する帳票を 設計したり、ユーザインタフェース(画面操作周り)やソフトウェアイ ンタフェース(データ形式・やり取り)、システム間インタフェース(外 部・周辺システムとのやりとり)の仕様を起こしたりします。 DBの論理設計(どんなテーブルが必要か)や機能分割(どんな機能に分 けるか)なども、ここに含まれます。 つくるもの:画面仕様書、帳票仕様書、インタフェース仕様書、機能仕様書 、ER図、コード設計書とか。
9.
各工程ではどんなことをするか。 詳細設計:内部設計、プログラム設計などが前後にきたり、そのもの を意味することもあります。 基本設計書をもとに、プログラムを作れるレベル、より具体的なレベ ルの設計を起こします。DBの物理設計なども含まれます。 つくるもの:詳細設計書、エンティティ定義書(テーブル定義書)、DB物 理設計書など 製造:実装、コーディングなどとも呼ばれます。 詳細設計書をもとに、実際にプログラムを書きます。 つくるもの:ソースコード、スクリプト、実行ファイル(.exe)など これをテストにあてはめます。
10.
こんな関係になります。(V字モデル) その工程で何を作るか、どんな範囲で成果物(アウトプット)を作るかに より、どんなテストをするかが決まります。 それぞれ、上流工程と結びつけるとわかりやすいと思います。 対になっている上流工程が、テストで確認したいことを決めた工程です。
11.
つまり、ざっくり言えば。 1つのプログラムが不具合がなく、正常に動くかどうか、詳細 設計どおりに作られているか確認するのが、 ⇒ 単体テスト 単体テスト後、複数のプログラムをつなげて正常に動くかどう か、基本設計どおりに動くかどうか確認するのが、 ⇒ 結合テスト システム全体として、きちんとユーザの要望、要求をみたして いるかどうか、要件定義どおりの機能を実現できているか確認 するのが、 ⇒
システムテスト
12.
ほかにも。。。 総合テスト、ユーザーテスト、受け入れテスト、運用テスト、 セキュリティテスト、ユーザビリティテスト、 性能テスト、負荷テスト(ストレステスト)、 アドホックテスト(ランダムテスト)。。。。などなど。 テストの種類は、そのテストの目的によってたくさんあります。 代表的なものは前のページにあげた、単体テスト、結合テスト、シス テムテストなどですが、自分が担当する工程によっても実際にテスト をするかどうかは違ってきます。 とりあえず、単体テストと結合テストは覚えておくといいかなと思い ます。
13.
人はなぜテストをするのか。 不具合のことをバグ(Bug)といいますが、 バグがないシステムはありません。 プログラムのミスだったり、設計書の誤りだったり、 ユーザーのお願い(要望・要件)をちゃんと聞けていなかったり、 その原因はさまざまです。 正常に動いても、それがユーザーの要望と違っていたら、 それは不具合でしかありません。 テストをすることで、これらの不具合をなくすことを目標にします。 そうすると、何をテストすればいいかは自然とわかります。
14.
1点注意。 工程の呼び方や、種類、分かれ方は、会社・現場によって 違います!!。空気を読んであわせましょう。 基本設計 BD(Basic Design)、UI(User Interface
Design) 詳細設計 DD(Detail Design)、PD(Program Design)、 SS(System Structure Design)、PS(Program Structure Design) 単体テスト PT(Program Test)、 UT(Unit Test)、FT(Function Test) 結合テスト IT(Integration Test)、SI(System Integration Test) システムテスト ST(System Test)、PT(Product Test)
15.
某ふじつうの開発プロセス。
16.
某みかかデータの開発プロセス。
17.
単体テストいくよぉ ヽ(。・`ω´・)ノ!
18.
単体テストとは。 プログラムを書いたあとで、そのプログラムが仕様どおりに書かれて いるか、仕様どおりに動くかどうか、異常終了や強制終了などしない かどうか、作ったプログラムを1つ1つテストするのが、単体テスト です。 やり方としては、大きく分けると2つあります。 1)画面(ブラウザなど)から、作ったプログラムを操作していろ いろな値を入力したり、ボタンを押したりしてちゃんと動くかどうか 確認する 2)プログラムが正しく書かれているかどうかチェックするための プログラムを書いて動作を確認する 2はちょっと難しいので、ここでは、1の例で説明します。
19.
なにをつくるか。 画面を操作して確認する場合、作ったプログラムが正しく動くかどう かを見るために、あらかじめ入力するパターンを考えておきます。 例えば、電卓アプリの場合、 「1+1=」とボタンをおしたら、2が表示されます。 「2*3=」と入力したら、6が表示されます。 入力する値と、その結果どう動けばいいか、 そのパターンを洗い出してExcelなどに書いていきます。 その1つ1つをテストケースといい、 それらを書いて並べたドキュメントを単体テスト仕様書といいます。 テストの結果や実施日などを書く場合は 単体テスト仕様書兼結果報告書などとも言います。
20.
なにをかくか。 どんなテストをすればいいかは、仕様書・設計書を正として、 仕様どおりに動くかどうか、電卓なら 1+1=3ではなくて1+1=2となるかどうかなどを確認します。 テストケースとしては例えば、 「1+1=を入力した場合」や、 「1+1を入力し、=ボタンを押下した場合」などと書き、 想定結果として、 「2が表示されること」 などと書きます。 ほかに、実施日、テスト結果がOKかNGか、テストをした担当者名 などを書いたりします。記入例は後ほど。
21.
どうやってつくるか。 「単体テスト仕様書」は、ほぼExcelで作りますが そのフォーマットは、その現場で使っているものがあればそれに習っ て同じように作ります。 指定のフォーマットがなければ、何をどんな観点でテストすればいい かを担当者に確認するなどし、それを書けるようなフォーマット (A4横とか)で自分で作成します。 どんなテストをすればいいかも、その現場の組織の文化や進め方、 そのプロェジェクトによっても様々なので、すべて同じフォーマット、 同じやりかたでOK、なんていうことはありません。 その辺は、臨機応変に対応する必要があります。
22.
方法論とか。 テストの方法論として、代表的なもの ・ブラックボックステスト ・ホワイトボックステスト などがあります。 実際にはこの中間をとる、グレーボックス的なことも多いです。 ほかにも、テストの目的によってもどんなテストをするかは変わって きます。 ・ユーザーの要求が満たされているかどうかの確認 ・不具合が正しく修正されているかどうかの確認 ・追加仕様が正しく実装されているかどうかの確認 など、その時のテストの目的を考えるようにしましょう。
23.
ブラックボックステスト。 ブラックボックス:ユーザー視点のテスト 入力する値によって、出力する値が正しいかどうかを確認する テストで、中身の処理がどうなっているかは知らない状態で ユーザ視点でテストを行います。結合テスト以降に多いです。 例えば、「電卓アプリの足し算」をテストしたい場合、 1+1=2です。(仕様) この場合、 「入力が1と1の場合に、出力は2になることを確認」 といったテストをすることになります。 ブラックボックステストの場合、 どうやって2を計算しているかは考えません。
24.
ブラックボックステスト。
25.
ホワイトボックステスト。 ホワイトボックス:網羅性(カバレッジ)の確保を主眼としたテスト こちらは、入力する値、出力する値だけでなく、中身の処理が正しい かどうかを確認するテストです。 分岐処理や、繰り返し処理なども含め、プログラムの1行1行を すべて通るようなテストをし、不具合なく動くことを確認します。 「電卓アプリ」をテストしたい場合でも、 「入力が1+2の場合に、出力は3になることを確認」だけでなく、 「もし1x2だったら」、「もし1÷2だったら」、などの分岐 (if文)がプログラムに書かれていた場合、それをすべて通るよう なパターン分のテストをすることになります。
26.
ホワイトボックステスト。
27.
ホワイトボックステスト。 ただしすべての処理をとおっても、それが仕様どおりかどうかはまた 別の話で、仕様が間違っていたら不具合なので、仕様通りかどうかを 確認できるテストケースを詳細設計書などからつくる必要がありま す。
28.
テスト技法。 テスト技法とよばれる、テストケースをどうやって洗い出すかの方法もいろい ろあります。今日は軽く。 ・境界値、同値 例)「パスワードは8文字以上16文字以下」 パスワードの文字数のパターン(境界値)⇒7、8、16、17 パスワードの文字数のパターン(同値)⇒10、20(条件の範囲内と外) ・デシジョンテーブル 条件とそれを満たすかどうか(満たす場合Y、そうでない場合N)のルールを 表形式で並べ、その条件のときにどうなるべきかをケースとします。 例)年齢50歳以上(条件)で男性の場合(ルール)、チケット半額(結果) ・組み合わせ(順列、組み合わせの。PとかCとかのあれ。) 「xxが1で、xxが2で、xxが3の場合、こうなる」といった複数の条件 の組み合わせパターンが存在する場合、わかりやすく必要なパターンを洗い 出すために、直交表という表を記述します。
29.
同値と境界値。 4 5 6
7 8 9 10 11 12 13 14 15 16 17 18 19 20
30.
31.
32.
33.
デシジョンテーブルの例
34.
単体テストの結果。 テストをしたら、そのテスト結果を記録として残すようにします。 このテスト結果の記録のことを、 「エビデンス」 といいます。意味は、「証拠」とか「根拠」とか。 エビデンスは、 テスト結果が表示されている画面(ブラウザ)のキャプチャ画像 だったり、 テスト実行前・実行後のデータベースのデータの内容 だったり、 その時によって、記録はとらない場合もあります。
35.
かるぅく結合テストいくよぉ ネー(*≧∀≦)(≧∀≦*)ネー♪
36.
結合テストとは。 「結合」という名前のとおり、単体テストが終わった複数のプログラムを組み 合わせた場合に、仕様どおりに連携して動くかどうか、ちゃんと別の画面に移 動するか(画面遷移)、プログラム同士でデータの受け渡しがちゃんとできて いるか、異常終了や強制終了などしないかどうかなどを確認します。 単一のプログラムというよりも、それらを組み合わせたもう少し大きな機能と いった単位でのテストになります。 また、外部システムやサブシステムとのやりとりをする部分のテストなども含 みます。(サブシステムは例えば受発注サブシステム、在庫管理サブシステム など、システム全体の中の一部の機能です) テストのやり方としては基本は画面(ブラウザなど)から、作ったプログラム を操作していろいろな値を入力したり、ユーザーが操作するレベルでの確認作 業になります。
37.
結合テストとは。 テストケースの洗い出しは、基本設計ベースにユーザー操作の流れと複数の画 面のやりとり・画面遷移などを確認する観点で行います。 単体テストよりは粒度が大きくなりますが、テストデータは操作の流れが再現 できるようなものを事前に準備して(作って)おく必要があります。 例)見積入力後に受注入力の操作を行うパターン ①見積入力 ・仕入商品の登録 ・保守商品の登録 ・単価の手入力商品を登録 ↓ ②受注入力 ・見積入力の内容が表示されていることを確認
38.
結合テストとは。 結合テストのテストケース、もしくは「結合テスト仕様書兼結果報告書」を自 分で作成する機会は少ないかもしれません。 ですが、結合テストの実施だけならすることもあると思います。 結合テストの位置づけや、その書き方など単体とはだいぶ違うことに注意しま しょう。 テスト仕様書のフォーマットは結合テストの性格上、単体と同じような書き方 ではなく機能同士のやりとりの確認や基本設計レベルの要件の確認が主となる ため、もう少しシンプルになります。 「結合テスト仕様書兼結果報告書」も、その現場によってテストの粒度や書き 方も違うので、担当の人に確認してから作るようにしましょう。
39.
40.
41.
いや、ないって。 未定!(`・ω・´)シャキーン ご清聴ありがとうございました。
Download now