【レポート】長崎IT技術者会 第8回勉強会「ソフトウェアテストことはじめ」

【レポート】長崎IT技術者会 第8回勉強会「ソフトウェアテストことはじめ」

去る2015年10月30日に長崎IT技術者会第8回勉強会を開催しました。今回は「ソフトウェアテストことはじめ」と題して,開催しました。■当日のアジェンダ当日のアジェンダは以下です。19:15 開会挨拶:長崎IT技術者会19:20 セッション1:ソフトウェアテストことはじめ:藤沢耕助氏20:00 ショートワーク:自分のテストスキルを測ってみよう:池田暁氏20:20 全体ディスカッション:モデレータ:池田暁氏20:45 閉会挨拶,後片付け勉強会タイトルと同名のセッションとスキル測定についてのショートワークの二本立てです。■ソフトウェアテストことはじめ「ソフトウェアテストことはじめ」は藤沢さんの入社してからこれまでに取り組んだテスト技術に関するスキルアップをまとめたものです。一年目はWACATEに参加した経験を中心に,当時「なぜテストをつまらないと思っていたのか」について考察していました。二年目は開発の現場での経験とテスト設計コンテスト見学にて自身が持った疑問や焦り,そして気付きについて考察,そして三年目はプロセスについて考察しています。けっこう泥臭いことを扱っていたのですが,それだけに...

マインドマップから始めるソフトウェアテスト Advent Calrendar 2015 のおわりに

マインドマップから始めるソフトウェアテスト Advent Calrendar 2015 のおわりに

読者の方々へのご恩返しのつもりで始めた「マインドマップから始めるソフトウェアテスト Advent Calrendar 2015」も25日目,最終回となりました。 ■全25件の記事 これまでに書いた記事を(今回も含めると)リスト化すると次のようになります。 12 / 1 マインドマップから始めるソフトウェアテスト Advent Calrendar 2015 12 / 2 MM本が出版されるきっかけとテストPRESSの記事概要 12 / 3 MM本のコンセプト 12 / 4 MM本の全体構成とおすすめの読む順番 12 / 5 MM本の勉強会 「マインドマップ読書会」 12 / 6 MM本 第I部Chapter1「ソフトウェアテストって何?」についてのあれこれ 12 / 7 MM本 第I部Chapter2「マインドマップって何?」についてのあれこれ 12 / 8 マインドマップとテストとのちょっとイイ関係 12 / 9 MM...

おわりに SQuBOKv2読破会が得たものと今後

おわりに SQuBOKv2読破会が得たものと今後

Happy Holidays!SQuBOK V2 読破会によるAdvent Calendar もいよいよ最終日となりました。最終日はこれまでカレンダーの記事を書いてきた読破会について紹介し,シメとしたいと思います。■読破達成!このAdvent Calendar に取り組んでいる最中に行われた12月度定例会によりSQuBOK V2 を読破しました!実にまる一年12回の定例会を経て読破ということになりますが,3h×12回と考えると頑張れば日中5h取り組むととして1週間ほどで音読による読破がか可能であるということを身をもって実証しました。もっとも,毎回の3hにはディスカッションの時間を含むので,実際はもう少し短期間で読破可能かと思われます。■メンバが読破により得たもの読破会メンバが読破によって得たものはそれぞれにたくさんあったと思いますし,それについては各自が別途Blog記事を起こしてくれるのではないかと思いますが,モデレータとして一歩引いたところから挙げてみようと思います。ソフトウェア品質に関する技術の体系的全体像KAやSKA,Topicsレベルでの知識関連する参考文献等それらについて...

[発表資料紹介] テスト設計へのマインドマップの適用の基本とTAME

[発表資料紹介] テスト設計へのマインドマップの適用の基本とTAME

「マインドマップから始めるソフトウェアテストAdvent Calendar 2015」 の24日目です。 今回は,マインドマップから始めるソフトウェアテストで書いたことをベースとして検討して実践しているテスト分析設計手法「TAME」について紹介します。 ※ご注意:本Advent Calendar はあくまで池田の個人企画です。 ■TAMEとは TAMEとはTesting Aid using Mindmap Effectively の略で,マインドマップを利用したテスト分析設計手法です。JaSST'09Tokyoで発表した際の資料は次の資料です。 JaSST'09Tokyo当時の資料ということで内容は古いのですが,今回はこの資料をベースに簡単に紹介します。 ■テスト分析設計を対象とする マインドマップから始めるソフトウェアテストで挙げたテストプロセスは「テスト分析」「テスト設計」「テスト実装」「テスト実行」「テスト報告」をベースとしたものですが,このうちもっとも創造性が必要になるのは「テスト設計」です。従って,マインドマップの効果をもっと生かしやすいのはこのテス...

[発表資料紹介] ソフトウェアテストにおける発想支援ツールの活用

[発表資料紹介] ソフトウェアテストにおける発想支援ツールの活用

「マインドマップから始めるソフトウェアテストAdvent Calendar 2015」 の23日目です。 今回は,筆者がこれまでに発表した際の発表資料を紹介します。マインドマップから始めるソフトウェアテストを読み終わった後に参考としていただけると,理解を深めたり補足になったりするかと思います。 ※ご注意:本Advent Calendar はあくまで池田の個人企画です。 ■ソフトウェアテストにおける発想支援ツールの活用 本資料はマインドマップから始めるソフトウェアテストをベースにしつつも,よりマインドマップをどう使うかということを強調して作った資料です。少々古い資料となりますが,書籍と合わせて参照ください。 この2つの資料には書籍には書いていない以下のようなことに触れています。 マインドマップ以外の発想支援ツール ソフトウェア開発/テストにおけるテストとは 自由記述型/テンプレート型それぞれの特性 コミュニケーションツールとしての利用 是非情報を活用いただけたらと思います。 ■おわりに マインドマップをテストに使うといい効果を沢山与...

MM本 第IV部Chapter11「まとめ ~テスト現場でマインドマップを使うために~」についてのあれこれ

MM本 第IV部Chapter11「まとめ ~テスト現場でマインドマップを使うために~」についてのあれこれ

「マインドマップから始めるソフトウェアテストAdvent Calendar 2015」 の22日目です。 今回は,第IV部Chapter11「まとめ ~テスト現場でマインドマップを使うために~」を取り上げます。いつものように読む上で注目して欲しいポイントと補足をします。 ※ご注意:本Advent Calendar はあくまで池田の個人企画です。 ■あらためてソフトウェアテストにおける作業の全体像とつながりを押さえてほしい 本Chapterは全体をとおしてのまとめとマインドマップを現場に入れるためのあれこれについて補足をしています。読者の皆さんにお願いしたいのは,ここであらためてテストにおける作業の全体像を整理して欲しいということです。 作業をテストプロセスをベースにChapterとして区切り,それぞれに解説をしましたのでそれら個別の(塊の)作業は理解できていると思います。ですが,それらのつながりについては解説していません。例えばテスト設計のアウトプットがどのようにテスト実装のインプットとなっているのか,テスト実装をうまくやるためにそれ以前にどのようなことが行われていな...

MM本 第III部Chapter10「PC用のツールを活用しよう」についてのあれこれ

MM本 第III部Chapter10「PC用のツールを活用しよう」についてのあれこれ

「マインドマップから始めるソフトウェアテストAdvent Calendar 2015」 の21日目です。 今回の記事は,第III部Chapter10「PC用のツールを活用しよう」を取り上げます。いつものように読む上で注目して欲しいポイントと補足をします。 ※ご注意:本Advent Calendar はあくまで池田の個人企画です。 ■Chapter10での記述の多くは陳腐化している このChapter10ですが,8年を経て内容が陳腐化しています。ただし,記述の全てが陳腐化している訳ではありません。紹介したツールの情報が古くなっているため,そういった意味で陳腐化しています。ツールは各自新しい物を探していただくとして,ポイントを紹介しておきます。 ■アナログ情報をデジタル情報として変換しておくこと 本書ではマインドマップは手描きを推奨していますが,手描きしているとその成果物として,当然ながら紙に書かれたマインドマップが作成されます。テストの活動の折々に作成されたマインドマップはおそらく,一連のテスト活動が完了したときには数十枚から数百枚の単位となっています。これらをアナロ...

MM本と関連する関連入門記事のご紹介

MM本と関連する関連入門記事のご紹介

「マインドマップから始めるソフトウェアテストAdvent Calendar 2015」 の20日目です。 19日の記事で,第II部の解説が終了しました。途中で挫折するんじゃないかと思うこともありましたが,ひとまず達成できてほっとしています。この本は先輩と若手の対話にて解説を進行していますが,本では書けなかったもっと基本的なことがあります。それについて紹介します。 ※ご注意:本Advent Calendar はあくまで池田の個人企画です。 ■新人注目! テストを極める最初の一歩(gihyo.jp) これはgihyo.jpにて第6回で連載した,入社したての新人クンを対象とした記事です。マインドマップで始めるソフトウェアテストは入社したての新人クンにはまだ距離があると思っていました。ベテランや入社して半年たったくらいの方には当たり前だろうと思うことが,入社したてのころにはそのすべてが難しいことに感じますし,どう対応してよいかわかりらない方もいるでしょう。そういった方に特化した内容としてこの連載記事を書いています。あと半年もすれば,読者の皆さんの職場にも新人クンが配属されて...

MM本 第II部Chapter9「テスト報告 ~報告書を作成しよう~」についてのあれこれ

MM本 第II部Chapter9「テスト報告 ~報告書を作成しよう~」についてのあれこれ

「マインドマップから始めるソフトウェアテストAdvent Calendar 2015」 の19日目です。 今回の記事は,第II部最後となるChapter9「テスト報告 ~報告書を作成しよう~」を取り上げます。いつものように読む上で注目して欲しいポイントと補足をします。 ※ご注意:本Advent Calendar はあくまで池田の個人企画です。 ■テスト実施結果リストはテスト報告書ではない このChapter9で伝えたいことは、テスト実施結果リストはテスト報告書ではないということです。よく見かける例として「テストケースリスト(表)に実施日と担当者,合否結果を記入したものの表紙をテスト報告書とする」があります。テストケースリスト(表)に実施日と担当者,合否結果を記入したものは単なる劣化テストログであって,決してレポートではありません。なぜならば,報告の要素が一つも入っていないからです。 ■テストにおける報告はそれほど普及していない おそらくですが,国内においてテスト報告はあまりきちんと実施されていないのではないかと思います。テストケースをすべて実行したら終了といったよう...

操作を記録してくれる「ステップ記録ツール(問題ステップ記録ツール)」を使ってみる

操作を記録してくれる「ステップ記録ツール(問題ステップ記録ツール)」を使ってみる

「マインドマップから始めるソフトウェアテストAdvent Calendar 2015」 の18日目です。 17日の記事では,Chapter8「テスト実行 ~テストログとインシデントレポートを書こう~」を取り上げましたが,テスト実行ログを手作業でとるのはなんだかんだ大変です。今回は簡単なTIPSを紹介したいと思います。 ※ご注意:本Advent Calendar はあくまで池田の個人企画です。 ■テスト実行効率はどれだけ細かい作業を自動化できるかが鍵 テスト実行効率を改善したい場合,すぐにテストケース実行ツールを導入したくなりますが,ちょっとまってください。それだけが解ではありません。実行そのものだけではなく,記録の手間や記録の分析をどれかけ省力化できるかということも大切で,それの改善はかなりの効果を生み出します。 テスト実行という言葉から,実行のみだけをイメージすることにならないようにすることが大切です。 ■実行ログを自動記録する 今回は1つだけ紹介をいます。 現在ではテストケースの実行時にはその手順やスクリーンショットを残しエビデンスとするということが求められ...

MM本 第II部Chapter8「テスト実行 ~テストログとインシデントレポートを書こう~」についてのあれこれ

MM本 第II部Chapter8「テスト実行 ~テストログとインシデントレポートを書こう~」についてのあれこれ

「マインドマップから始めるソフトウェアテストAdvent Calendar 2015」 の17日目です。 今回の記事は,Chapter8「テスト実行 ~テストログとインシデントレポートを書こう~」を取り上げます。いつものように読む上で注目して欲しいポイントと補足をします。 ※ご注意:本Advent Calendar はあくまで池田の個人企画です。 ■テスト実行では実行に加えて記録が重要 勘の良い方だとChapetr8のタイトルを見て気がついたかもしれません。「テストケースを実行しよう」ではなく「テストログとインシデントレポートを書こう」としています。 もちろん実行することは(当たり前かつ)大切でなのですが,テストケースの実行そのものはテスト実装がきちんとなされていれば(よほど実行に専門性が必要な場合でなければ)すんなりと対応できるでしょう。 テスト実行では実行と共に大切な作業として「記録」があります。この重要性に余り目を向けられることがないのですが,直接的な実行と並んで大変重要です。なにせ実行したことを証明するための物だからです。記録を伴わない実行は信用に値されない...

マインドマップそのものの学習について

マインドマップそのものの学習について

「マインドマップから始めるソフトウェアテストAdvent Calendar 2015」 の16日目です。 これまでの記事ではマインドマップについてはあまり言及してきませんでした。ですが,ソフトウェアテストにマインドマップを活用する場合,当然ながらマインドマップに習熟すると効果が高まります。そこで今回はマインドマップの学習について描いてみようと思います。 ※ご注意:本Advent Calendar はあくまで池田の個人企画です。 ■マインドマップは単なるツリー図ではない ソフトウェアテストに関する勉強会などに参加するとマインドマップを使うこと自体はもはや当たり前の状況になっていますが,マインドマップをマインドマップとして利用できていない方をちらほらと見かけます。当たり前のことですが,マインドマップはツリー図ではありませんし連関図でもありませんから,そのように使うのは不適です。またツリー図や連関図として使っている場合,そのほとんどがあまりテスト観点を発想できていません。無意識的に情報の整理に思考が誘導されているからだろうと想像します。 ■マインドマップを学ぶためには マ...

MM本 第II部Chapter7「テスト実装 ~テストケースを作成しよう~」についてのあれこれ

MM本 第II部Chapter7「テスト実装 ~テストケースを作成しよう~」についてのあれこれ

「マインドマップから始めるソフトウェアテストAdvent Calendar 2015」 の15日目です。 今回の記事は,Chapter7「テスト実装 ~テストケースを作成をしよう~」です。いつものように読む上で注目して欲しいポイントと補足をします。 ※ご注意:本Advent Calendar はあくまで池田の個人企画です。 ■テスト項目とテストケースは別として説明 よくテスト項目をテストケースの意味で使っている場面に出くわすことがありますが,本書ではテスト項目とテストケースは別のものとしています。ざっくりと説明すると,テスト項目はどういった事に着目しているのかを表し,テストケースは具体的な手順等を含むものです。テスト項目はテスト観点として表現されることもありますし,テストカテゴリやテストタイプとして表現されることもあります。ISTQB的に言うと,ここでのテスト項目はハイレベルテストケースということもできるでしょうか。テスト項目やテストケースという言葉の意味は今でこそISTQB用語集を参照すれば良いと思いますが,執筆当時はJSTQBの試験も始まって居らず日本語訳された用語...

MM本 第II部Chapter6「テスト設計 ~テスト設計をしよう~」についてのあれこれ

MM本 第II部Chapter6「テスト設計 ~テスト設計をしよう~」についてのあれこれ

「マインドマップから始めるソフトウェアテストAdvent Calendar 2015」 の14日目です。 今回の記事は,Chapter6「テスト設計 ~テスト設計をしよう~」です。いつものように読む上で注目して欲しいポイントと補足をします。 ※ご注意:本Advent Calendar はあくまで池田の個人企画です。 ■いきなりテストケースはNG テストのプロセスが十分に普及していない現場ではテスト設計を実施せずにいきなりテストケースを作成する光景をよく見かけます。テストケースが記述された文書からもそう見てとれる事も多いです。 文中,先輩は新人に向けてこう言っています。 「いきなりテストケースを書き始めるのではなく,ちゃんとテスト設計からやらないとダメだよ。いきあたりばったりでテストケースを書いてしまうと,漏れや抜けがが多くなってしまうんだ。テストでも,ちゃんと設計を意識すること。このテスト設計の作業品質でテストケースの品質も決まってくるから,よく考えて取り組むことが重要だよ。」 (引用:マインドマップから始めるソフトウェアテスト p.111) この先輩の...

マインドマップとの出会いなどなど

マインドマップとの出会いなどなど

「マインドマップから始めるソフトウェアテストAdvent Calendar 2015」 の13日目です。 13日目!我ながらよく続いています! ただ,少々息切れしてきましたので,そもそもかつて自分がどのようにマインドマップを使っていたかについて思いだし,一息ついてみることにします。 ※ご注意:本Advent Calendar はあくまで池田の個人企画です。 ■マインドマップと出会い マインドマップに初めて出会ったのは確か学生の頃だったと思います。出会いはもう覚えていませんが,たしか何かの授業で使っている人がいて「落書きしてるや」なんて思った記憶があります。その後しばらく忘れていたのですが,書籍に出会って「あぁそういえばこういうのを見たことあるなぁ」と使ってみることにしたわけです。 ■初めてのマインドマップと躓き 初めてのマインドマップですが,これがなかなか難しかったです。皆誰もが通る道「メインブランチが出てこない」に遭遇するわけです。それでもわかりやすいテーマを選んでいうちになんとか書けるようになってきたのですが,そこでようやく気がつくことになります。 なんとな...

勉強会参加者におすすめしたいACアダプタ用タップ

勉強会参加者におすすめしたいACアダプタ用タップ

筆者は勉強会を開催したり参加したりすることが多いですが,時折困ることがありました。 ノートPCを持ち込んだはいいものの「コンセントやタップの空きがない!」ということです。また,スマホでテザリングしていたらバッテリーがヤバイ!ということも起きます。 そんな困ったことがありましたが,ある物を導入したら一発解決でした。 このタップをACアダプタに接続します。 このタイプですと表に2つ口,裏に1つ口あるので,空きに困ることはなくなりますね。自分で使うのもいいでしょうし,タップの空きがなくて困っている方にそっと差し出すと喜んでもらえるかも知れませんね。 勉強会の能率を上げるためにはこういったハックも活用すると良いでしょう。おすすめですよ~。

MM本 第II部Chapter5「テスト計画 ~テスト計画を検討しよう」についてのあれこれ

MM本 第II部Chapter5「テスト計画 ~テスト計画を検討しよう」についてのあれこれ

「マインドマップから始めるソフトウェアテストAdvent Calendar 2015」 の12日目です。 今回の記事は,テスト計画についてです。 ※ご注意:本Advent Calendar はあくまで池田の個人企画です。 ■テストスケジュール=テスト計画? テスト計画立ててますか?と質問すると「何言ってるんですか,当たり前でしょう!」といって手渡されたのはどう見てもスケジュール表(ガントチャート)でしたことによく遭遇しましたし,現在もそういった現場が多いように感じています。 この章で伝えたいことはひと言です。 スケジュールはスケジュール,計画じゃないよ! ということです。 ■テスト計画とは? Chapter5ではまさにこのような展開から新人君にテストにおける計画とはなんぞやということを解説しています。この計画はソフトウェアテストではIEEE829というデファクトのテンプレートが存在します。829でのテスト計画テンプレートを以下に示します。 ①テスト計画識別番号 ②はじめに(序文) ③テストアイテム ④テストすべき機能 ⑤テストしない機能 ⑥アプ...

国内で実用化されているテスト要求分析技法

国内で実用化されているテスト要求分析技法

「マインドマップから始めるソフトウェアテストAdvent Calendar 2015」 の11日目です。 前回の記事にて,今では実用化されている仕様分析の手法が登場していることを言及しました。今回はそれらについて簡単に紹介したいと思います。 ※ご注意:本Advent Calendar はあくまで池田の個人企画です。 ■IPA発行物におけるテスト要求分析手法 突然テスト要求分析手法という言葉が出てきました,この時点では仕様分析手法と読み替えてください。 先の記事にもあるとおり,2007年当時は仕様分析設計手法は一部のテストのエキスパート以外にはあまり知られていませんでしたが,現在はIPA発行の「高信頼化ソフトウェアのための開発手法ガイドブック-予防と検証の事例を中心に」に掲載されているような以下のような手法があります。 手法名 表現方法 特徴 プロセス NGT ツリー テスト全体をテスト観点で網羅 VSTeP FV表 表形式 目的機能の切り口でV&Vを網羅 HAYST法 ゆもつよメソッド 表形式 機能...

64bit版Firefoxが正式公開(42.0)

64bit版Firefoxが正式公開(42.0)

なんだかんだでメインで利用しているFirefoxですが,気がつけば64bit版の正式版が公開になっていました。42.0で始めて正式版が公開となっていますが,TOPにインストーラーは公開されていないため,このディレクトリから各自でDLする必要があります。なので知らない人も多いのではないかと思います。64bit版に変えたら随分軽くなった印象です。64bit環境にある方は試してみると良いのではと思います。ちなみに,インストール時にインストールディレクトリを変更しておけば32bit版と共存できます。またプロファイルは共用のようなので,特に設定のインポート操作などせずに移行できました。ただし,制限事項としてまだflashくらいしか動かないので,あくまで人柱程度に使うのが良いのではと思います。

MM本 第II部Chapter4「仕様分析 ~仕様を分析しよう」についてのあれこれ

MM本 第II部Chapter4「仕様分析 ~仕様を分析しよう」についてのあれこれ

「マインドマップから始めるソフトウェアテストAdvent Calendar 2015」 の10日目です。 今回はChapetr4「仕様分析 ~仕様を分析しよう」を取り上げます。以前の記事でも敢えて仕様分析という言葉を使っていると解説しました。テスト分析という言葉は初級者には誤解を招きやすいと感じているし,それは今でも余り変わっていないと感じています。このため本記事においても本書に合わせて仕様分析という言葉を使います。ただし,エキスパートの方はテスト分析と置き換えていただいてもよろしいかと思います。 ※ご注意:本Advent Calendar はあくまで池田の個人企画です。 ■仕様分析の方法は様々である この仕様分析ですがテスト設計と並び,未だに定番として定まった方法はないのと思っています。本書執筆当時は仕様分析という考え方がまだまだ知られていませんでしたのでしょうがないところもありますが,現在に至ってもまだまだ研究分野であると感じています。ただし,国内では様々な手法が提案されており,実用化もされています。(次回の記事にて簡単にご紹介します) 本記事はガイドとなる例とし...

スポンサーリンク