WACATE2012夏メインセッション講義資料。テスト設計技法を学んだ方を対象としています。実際のセッションでは時間短縮に合わせた圧縮版を使用しています。

プロジェクトファシリテーションパーティ2012 『Party1』セッション資料です。 平鍋さんのプロジェクトファシリテーション説明のあとで話した資料です。みなさんが「PFってすごい！面白そう！」とワクワクされているタイミングなので、あえて現場での苦労から、PFで失敗しそうな点、そのポイントなどをまとめました。

[例題]テニスのスコアボードのテストをしてみるのだが、まずテスト対象の分析をしてみる。分析をしてどんなテスト設計をするのか、テスト技法を使うのか、などなどを検討する。今回は、ソフトウェアテストPRESS Vol.2　「3色ボールペンで読む仕様書」にならってやってみようかな。 赤　－　客観的に見て、最も重要な箇所 今回は、同値分割や境界値などに使えそうな箇所もあげてみた。 青　－　客観的に見て、まあ重要な箇所 実は微妙に青色って難しい。。。 緑　－　主観的に見て、おかしいと感じた箇所 おかしいというか仕様があいまいであったり、矛盾がある箇所としてみた。 次回はマインドマップを分析ツールとして使ってみる。予定。

WACATE 2011 夏に申し込んだので、おさらいしましょう。ということでテスト手法、テスト技法を中心としたリンクをまとめてみました。 なので今回はTDDとかテストツールとかはあまり含まれていません。 いくつかかぶっているものもありますが、多面的な表現って大切だと思うので、多少のかぶりは気にせずに選択しました。 これを読めば良いソフトウェアエンジニアとして一歩階段を上れる気がしています。 他にも参考になるものがあったら、コメントやTwitterで@kyon_mmまで教えてくださるととっても嬉しいです！ 次の形式で書いています。 WEBサイト名、資料名：発表者（敬称略）：URL カテゴリー分けしたんですが、不適切であるかもしれません。間違い等あればご指摘ください。 また、ここでのリンクに問題がある場合は削除致しますので、その場合もご指摘ください。 TwitterID:kyon_mm mai

はじめに 前回に引き続き、発注者ビューガイドラインに書かれている「コツ」の中で、テストエンジニアにとって参考になりそうなところを絞って解説していきます。今回はシステム振舞い編とデータモデル編を取り上げます。 本記事の構成 システム振舞い編は、「⁠表現」「⁠記述確認」「⁠レビュー」に分かれています。本記事では「表現」から3つのコツを取り上げます。 データモデル編は、「⁠表現」「⁠記述確認」「⁠レビュー」「⁠レビュー時の確認」に分かれています。本記事では、「⁠表現」から3つのコツを取り上げます。 コツの説明はコツごとに、「⁠ガイドラインの引用⁠」⁠→「⁠テストエンジニアが知っておくべきポイント」という構成にしています。 システム振舞い編 システム化業務一覧 システム化業務一覧の書き方のコツとして7つのポイントが挙げられています。その中から2つのコツを紹介します。 機能は階層で捉えよう 図1　機

2016年09月02日： タイポなどふくめ微修正 2016年09月01日： スライドをいくつか追加。一部の文言を変更。参考資料追加。 2016年06月22日： タイポなどふくめ微修正 - - - - - - - - - - - - - - - - - - - - - 第7回Quesの講演資料です。 https://atnd.org/events/71474 Quesについてはこちら。 http://quesqa.com/ https://twitter.com/Ques_staff 当日のハッシュタグは #ques7 Read less

大塚先輩： 入社10年目。5年前に柏田マネジャーと一緒にソフトウェアテスト事業を立ち上げた。カメラが趣味で、暇さえあれば写真を撮りに出かける。 新しいメンバー テスト設計の成果物をテストケースの雛形と解釈した中山君。でき上がったもの（前回参照）を大塚先輩に持って行くと……。 大塚先輩：中山君のチームに今年2年目の小川君を入れようと思っているけど、小川君を知ってるかい？ 中山君：いえ、知りません。今までどのチームにいたんですか？ 大塚先輩：お客様先常駐のSUBARUプロジェクトだよ。 中山君：あの噂に聞く……。大変なプロジェクトにいたんですね。 大塚先輩：そうだ。いろいろと経験してきたみたいだけど、中山君もしっかりと小川君を指導して欲しい。 中山君：わかりました。 リーダとして部下を指導するのは、初めてです。身が引き締まる思いです。 大塚先輩は内線電話で小川君を呼びました。3分程度して、コン

大塚先輩： 入社10年目。5年前に柏田マネジャーと一緒にソフトウェアテスト事業を立ち上げた。カメラが趣味で、暇さえあれば写真を撮りに出かける。 テスト設計 前回大塚先輩に大目玉をくってしまったテスト分析もなんとか終了。「⁠なんとなく」で行ってしまったテスト分析にもう一度しっかりと取り組み、何回かのアドバイスをもらいつつ大塚先輩に再提出することになりました。 大塚先輩：さて、テスト分析も終了だね。 中山君：はい、ようやく終わらせることができました。本当にボクはなにもわかっていなかったんですね。ご迷惑をおかけしてばかりです…。 中山君は、はじめてまともに取り組んだテスト計画とテスト分析の苦労に、精神的にも肉体的にも疲労がたまりつつありました。いつになく神妙な中山君を見た大塚先輩、次のように声をかけました。 大塚先輩：初めてのときは誰もが上手くいかないものだよ。…スケジュールを見ると、マイルスト

2016年09月02日： タイポなどふくめ微修正 2016年09月01日： スライドをいくつか追加。一部の文言を変更。参考資料追加。 2016年06月22日： タイポなどふくめ微修正 - - - - - - - - - - - - - - - - - - - - - 第7回Quesの講演資料です。 https://atnd.org/events/71474 Quesについてはこちら。 http://quesqa.com/ https://twitter.com/Ques_staff 当日のハッシュタグは #ques7

当資料は、2012/1/14に開催された、以下の勉強会で発表した資料です。 わんくま同盟 名古屋勉強会 #20 ＆ 第39回 名古屋アジャイル勉強会 ＆ TEF東海 勉強会 http://www.wankuma.com/seminar/20120114nagoya20/ 1/19 ・当日のワークの結果を追加した ・TEFの紹介部分を微修正 ・P1タイトル誤字を修正 1/23 ・WACATEのリンクを追加 ・テスト設計関連の参考リンクを追加 ・P18の図にライフサイクルの補足を追加 ・P16の表示が変だったのを直したよRead less

パターン QA to AQ: 伝統的品質保証（Quality Assurance）からアジャイル品質（Agile Quality）へ

数千人が利用する楽天Redmineの過去と未来 - The past and future of Rakuten Redmine that is the...Dai FUJIHARA

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） テスト仕様書の書き方のまとめ （なぜ、そんなのを書くのかは聞かないでくれ。書きたくなったからだ） ＜＜何を書くべきか（目的）＞＞ テスト仕様書の目的は、テストをしてもらうために書くことという意味はもちろんあるのだけれど、そんなことより ・後で見たとき、テストが網羅されていることがわかること（他人が確認できること） ・その仕様書に書かれているテストの目的と、そのためのテストの操作の妥当性が、ほかの人が見ても（コンピューターのことを知らない弁護士や裁判官、国の仕事なら会計検査院の人が見ても）確認できること が必要になる。これがないと、品質がわからないので、プログラムを作りっぱなしと同様と、ユーザーやシステム監査人、裁判官に判断されても、また、「会計検査院が、予算を適正に使っているかど

仕様書の読み方がわからない！ A君は、ソフトウェアテストは単純にプログラムを動かすだけではなく、 明確な目的を持つこと その目的を達成するために事前の準備が必要であること を学習しました。では、テストの準備とはどういうことをしなければならないでしょうか。 A君はその後、K先輩に質問を行い、次のようなアドバイスをもらいました。

運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します⁠。個別にライセンスが設定されている記事等はそのライセンスに従います。

ソフトウェアの品質を上げるためにはテスト仕様書の品質が大事です。糞みたいなテスト仕様書だと、多くの不具合を見逃してユーザーに供給されてしまうことになります。どんな天才プログラマーを集めても、テストが糞だと完成品も糞になってしまいます。というわけで、今回は職場で遭遇した悲しいテスト仕様書たちを集めてみました。多くの人が触ったことがあるであろうWindowsのペイントソフトのテスト仕様書を作る場合で考えてみます。 悲しくて残念なテストたち 人によってテスト結果が変わってしまう 基本中の基本です。上図のテスト仕様書はNo.2がダメですね。この仕様書だと人によって結果が変わってしまいます。鉛筆で1本の線を描くだけの人もいれば、たくさん線を書いて塗りつぶす人もいます。また、色を変えて赤で描く人もいれば、太い線を選択して線を描く人もいます。もし、黄色を選択したときに問題が発生する場合、上図のテストでは