読者です 読者をやめる 読者になる 読者になる

九州ソフトウェアテスト勉強会の勉強会 Vol.20 ~TDD/BDD実践者のテストアーキテクトに聞け~ kyon_mm氏に聞くQ&A

かなり久しぶりの投稿です。

2016/03/25(金)に行われた 九州ソフトウェアテスト勉強会の勉強会 Vol.20 ~TDD/BDD実践者のテストアーキテクトに聞け~にて@kyon_mmへの質問コーナーを設けました。

最初に講演頂いたスライドはコチラから確認することができます。テストとリファクタリンク?に関する深い方法論※レガシーコード改善勉強会の再演となっています。

参加者に事前アンケートを取って@kyon_mm氏に回答いただきました。 当日はその回答にさらに質問をしたり、助言をいただいたりと非常に濃い時間を過ごすことができました。

質問の内容と@kyon_mm氏の回答を記載します。

Q01: エンジニアがテストコードを書く文化を根付かせることや、テスターがレビュアーとしてテストコードをレビューする文化を根付かせるにはどうすればよいでしょうか?

プレッシャーによってやらせたくする

プレッシャーによってやらせたくするなら、見本を見せたり、バグをたくさん見つけたりして、振り返りとかをうまくつかう。 例えばテストコードをガンガン書いて、それでバグを大量に出すことでエンジニアにプレッシャーをかける。

自律的にやらせたくする

自律的にやらせたくするなら、その人達がどういうものごとを楽しいと思うか観察して、やってほしいことをうまくそれに似せる。

Q02:テストレベルに対するBDDをどのようにおこなうのが良いかがわかりません

A: 各テストレベルつまりあるプロダクトの塊を使いたいユーザーを洗い出して、どのように使いたいかを書く、どんなことにも転用できるかを書く、細かいけど気になりそうなところを書く。それがテストコード(Specification by Example)になっているという感じです。  ここでのユーザーとはエンジニアやテスターや受け入れるお客さまのこと。  例えば、Unitであれば、関数を使うユーザーはエンジニアで、エンジニアはその関数をどのように使いたいか、気になることなどを書いていきます。

それでも考えられない時は、WhyやWhatやGoalを考えるのが苦手なのかもしれません。Impact Mappingとか要求分析とか設計について勉強したらいいかもしれません。

Q03: ソフトウェアメンテナンスを交代した場合のコスト増にテストを活用できる可能性を知りたいので、経験をお聞かせいただければと思っています。

ガイドを作る

ユーザーガイドや開発者ガイドをテストコード付きで記述していくことで、動作させながらどのようなプロダクトなのかを把握できると思います。 ユーザーガイドと開発者ガイドはそれぞれ作るとよいです。 ガイドは、例えばユーザーガイドであれば動画で作るなど、ユーザーにあわせて最適なものを選ぶとよいです。

よく困る仕様をスクリプテッドする

他にも、よく困る仕様などもスクリプテッドしておくとよいです。パッと答えられるので。 大体、聞かれるところは仕様が複雑であったりするので、確認するにも明確になるのでおすすめします。

Q04: TDDやBDD をやっていくためにまず、組織(チーム)として何から手をつけたほうがいいですか。

kyon_mmのような識者にTDDBCを開催してもらう。

何となくやっている人だと、誤解したまま進むことが多いと感じている。 きちんと最初は識者に教えてもらう方がよいです。呼んでください!

Clean Coderに書いてあることを実践することにみんなで挑戦する。

自分たちで出来ることとしては、Clean Coderを挑戦するとよいです。

Q05: VisualStudioのGUIテストをやりたいです。何か参考になる本や方法をご紹介願えないでしょうか?

A:VisualStudio自身のテストでは、前にFriendlyを利用した経験があります。今だと少しは楽になっているはずです。(基本的にはEnvDTEの中身をどうやって読みとくかです。)

Q06: 設計段階からテストを念頭に効率よく仕様に落としていくにはどうすればいいでしょうか?もしくはテストを意識し始めるのはどの段階から意識するのがいいでしょうか?

A: 自分たちが今までやってきた中で「全く一緒の部分」「ちょっと違う部分」「初めての部分」を洗い出して、それぞれどう今までと違うのかを書いてみる。  今までやってきたプロダクトと「全く一緒の部分」が多いと思っていても、実際に書いてみると殆どが「ちょっと違う部分」であることに気づくと思います。

精度ではなく、確度をあげる

それらがたいていはリスクなので、それらの見積もり確度をどうやったら早くあげられるか?どうやったらうまくいっているかうまくいっていないかを知れるか?を考える。と、それがだいたいテスト戦略っぽいものになります。

あとは具体化して進めていく感じです。 もちろん、「いつもうまくいっていないこと」とか「今回特に不安なこと」とかがあるなら、それらもあげてください(当り前だと思うんですが)


翌日も、同じく kyon_mm氏に講師をしていただき、日本初のふりかえりのワークショップをおこないました。(何が日本初かは、別途ブログでご紹介・・・できるといいなぁ) 二日間様々な内容の講演やワークショップ、夜もお酒とともに色んな話をしていただきありがとうございました!


次回予告

次回は試される北の大地より @nemorineがいらっしゃいます。 テーマは『探索的テスト』 探索的テストは文献も少なく、勉強もしづらいのですが、圧倒的なスピードでバグを見つける為にはかかせないテストです。 ワークショップを交えての会となりますので、ぜひご参加ください。 https://atnd.org/events/76020

vol.9 テスト設計について学んでみよう @kjstyleppさんをお迎えして

vol.9は@kjstyleppさんをお迎えして、テスト設計コンテストの資料をもとに、テスト設計について学習しました。

 

今回の題材について

私自身、去年と今年とソフトウェアテスト設計コンテスト(以下、テスコン)というものにエントリしています。去年は何の役にも立てず、名ばかりの参加者でした。

 テスコンの難しいところは、題材が普段業務で慣れしんだもの(普段はWEB、エンプラのテストをしています)ではなく、「自動販売機」をテストするというもの。

 ハードウェア構成仕様書ユースケース仕様書からテスト設計を行うのですが、どこから何を手を付けてよいかわからない、成果物を見ると 何となく読める気はしてくるのですが、いざ取り掛かろうとすると、どうしてよいか分からない状態になりました。

 このような悩みを相談したところ、「では去年の成果物を説明して、最初の取り掛かりをワーク形式でやってみようか」と言っていただき、今回の勉強会を行いました。

 

アクティビティ図と状態遷移図

テスト設計の取り掛かりとして、アクティビティ図と状態遷移図を書くというワークを行いました。

 

アクティビティ図

アクティビティ図を書くことにより、ユーザとシステムの振る舞い、流れが分かり、理解しやすくなります。

 ワークでは、全体的なざっくりとした流れを書いてみよう。ということで挑戦しましたが、仕様書に書いてあることを書こうとしてしまい、細かく書きすぎてしまいました。(時間内に終わらず中途半端なまま・・・)

 ワークは@kjstyleppさんも参加し、最後に@kjstyleppさんの書いた図の説明をしていただきました。

 ユーザがする振る舞いを中心に考えると、仕様書に流されることなく書けるようになるのかな?と思いました。とても見やすかったです。

 

状態遷移図

販売ボタンの状態から、状態遷移図を書いてみよう。というワークを行いました。

販売ボタンの状態を洗い出し(これも私は躓いていたのですが・・・)、そこからイベントを繋げました。

状態遷移図は割とスムーズに書けたのですが、それでも1つ抜けがあって、そこに気づくことが最後までできませんでした。

 

ムズカシイと思ったこと

今回のワークを行うにあたり、細かい仕様は考えず、また対象から外して考えたりしたのですが、それでも必要のない仕様を書こうとしてしまったり、手が止まることが多々ありました。

テスト設計のセンスの一つは、そこの取捨選択のうまさ、粒度やレベルを決めて、そのことを忠実に守る事ができること。かな。と思いました。

 

今回の勉強会は、少人数ながら、13~17時、19~21時と6時間に及ぶ長時間勉強会を開催することができました(夜は想定外だったのですが・・・)

6時間でもテスコンの最初の一歩が踏めたかな?というところで、本当に全部を完走しようと思うととてつもなく大変だとあらためて感じました。

 

おしまいに

今回の開催にあたり、東京からわざわざお越しいただいた@kjstyleppさん本当にありがとうございました。

 また、開催にあたり、ASTERの協力と、会場提供をしていただいたFusic、連休中にも関わらず参加いただいた方がいてこそ開催できました。ありがとうございます。

 

@kjstyleppさんとは、JaSST東京やWACATEなどで会う機会はあるのですが、中々ゆっくりとお話する時間が取れないので、今回は色々と話せてよかったです。

また、九州のメンバーとも話せたことが、九州メンバーの刺激になったのではないかと思います。何か分からないことがあったときに、きちんと答えられるって素晴らしいです。

本当に開催できてよかったです。ありがとうございました。

vol8.バグチケットから見る分析方法 @radioeyesをお招きして

6月の勉強会です。

今回は@radioeyesを講師にお招きして、バグチケットの分析についての勉強をしました。

 

Togetterにもまとめています。

http://togetter.com/li/684977

 

今回のテーマについて

私個人の問題なのですが、バグチケットをBTSで管理しているので、チケット駆動は上手く回っています。

ただ、そのバグチケットは終了してしまうと、何にも使われていない状態でした。

バグの分析というものがあるということを知って、このバグチケットも何か分析することにより有効活用ができるのではないか?と今回のテーマにしました。

 

バグチケットの分析

今回は題材として、私が実際にバグチケット発行したものをデータとしてお渡しし、分析していただきました。

使用するものはExcelのピボットテーブルです。

以下の手順を行っていました。

 

 

1.データ整理

  • 1チケット1バグ
  • バグが起こった箇所と原因のカラムを追加
  • 起票日時を起票日だけのカラムを追加

2.ピボットテーブルを作成

 

バグが起こった箇所を縦軸、横軸に原因を並べると、どこにどんなバグが多かったか一目瞭然であったり、起票日を積み上げ?ることで、プロジェクトの過渡期を判断することができる

 

バグチケットを解析して出来ること

次回のテスト戦略の材料になる

場合によっては人で分析することもある(私個人的にはこの分析は反対です。プロダクトに問題があって、人で判断すべきじゃないと思っています。)

 

バグチケットはテスターと開発者を繋ぐコミュニケーションツール

 最後は座談会のようになりました。みなさんあげたバグチケットを対応してもらうことや、バグの情報を得るのに苦労していたようです。

 開発とテスターの距離があったり、組織の距離や知識差があったりすると難しいようです。私自身は同じチームとして開発者とやりとりを円滑にできている方だと思っていますので、少し例とお話をさせていただきました。

 

 バグのチケット分析は、開発者にとって嫌われる存在にも成りかねないそうです。

そこで、伝える側もハートフルさや、伝えるための努力、対応してもらえるための努力は必要だよね。と仰っていました。

バグチケットは、開発者を攻撃するためのものではなく、テスターと開発者のやりとりにつかう大切なコミュニケーションツールだと思います。

今回の勉強会で、バグチケット自体の価値があがったり、コミュニケーションが円滑に進めば嬉しいです。

vol7.同値分割って何だろう? 西康晴氏をお招きして

5月開催でした。今頃アップ。。。

 

vol.7は東京より @YasuharuNishi さんをお招きして「同値分割ってなんだろう」について講習していただきました。

 

テーマの選定について

今回お呼びするにあたり、テーマを何にしよう?と考えていたんですが、たまたま?Twitterで「同値分割って奥深いよね」ということが流れていました。

同値分割について

私が初めて同値分割という言葉を知ったのは 秋山浩一さんの

 

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

 

 

だったのですが、第一章にでてくる技法ということで、誰もが聞けばわかるものじゃないの?すごくシンプルで簡単なものだと思っていました。

それが奥深いということが何なのかが分かりませんでした。

そこで、「そもそも同値分割が何かきちんと理解していないのでは?」ということを
@mkoszkさんと@akiyamaさんを中心にTwitterで教えていただきました。

@mkoszkさんと@akiyamaさん、一つ一つ丁寧に教えてくださり、本当にありがとうございます。

Twitterでの様子はtogetterにまとめています。

http://togetter.com/li/661230

 

会場の様子

今回もLINE FUKUOKAさん(PLAY ART FUKUOKAさん)に場所をお借りしました。
いつもありがとうございます。

今回の参加者は約30名。会場にぎっしりと人が参加されています。

いつも勉強会をしている場所に あの にしさんがいらっしゃっるということが凄いことだなぁと思いました。

 

以下の項目で進みました

  • テストの目的
  • 簡単な同値分割の問題
  • ちょっともやっとする同値分割の問題
  • 同値分割の難しいところの話

※実況は togetterの後半をご覧ください・・・

 

感想

にしさんマジ凄い

 2時間半という限られた時間で、テストについて~同値分割からテスト設計の大事さを教えていただきました。
簡単な例題から、数多くの情報をわかりやすく説明いただけて、本当に勉強になりました。

今回私個人の収穫としては、何となく自分で理解していた部分について、他の人にこれからは正しく伝えられるところが出来たのではないかと思います。

資料には乗っていないような実例を紹介してもらえたり、ちょっとした「あるある」は実感できるのでよかったです。

これからの勉強会の課題ですが、技法でもTipsでも、まず「なんで、これを勉強すべきか」という実際の問題を事前に提示するのって大事だなぁとあらためて思いました。
今から勉強するのに、とりあえずこの本やる。というのと、こういう問題があるのを解決の一つとして勉強する のでは身の入り方が違うよな。と思いました。


個人的な想いなのですが、今まで何度か にしさんのパネルセッションや講演を拝聴したのですがいつもとても「わくわく」させてもらえるんです。
今回も序盤から 本当に楽しくてわくわくできて、構想から半年くらいでお呼びすることができてよかったな。と感じました。

同じように思ってくれた参加者の方が一人でもいてくれたらうれしいです。
そして、私も微力ながら そう思ってもらえるような勉強会を開催できたらいいなと思います。

 

九州ソフトウェアテスト勉強会vol.4〜別館:グループわけって難しい〜

もう数ヶ月前の出来事ですが、vol.4が終わった夜のTwitterでの出来事があったので、簡単にまとめ。

 

境界値分析はテスト技法かテストタイプか 

 

 

回帰テストと出荷前テスト


 

  

ソフトウェアテスト勉強会vol4 ~@gen519 PRESENTS ソフトウェアテスト最初の一歩 ~

2014年2月の勉強会vol.4です。

(ブログの公開がすっかり遅れてしまいました。。。ごめんなさい)

 

今回は@gen519さんをオンラインゲストにお迎えして

テスト初心者のためのワークショップをしていただきました(∩´∀`)∩

@gen519さんはvol.1からオンラインゲストとして手を挙げてくださっていたのですが、中々調整が上手く行かず・・・(すみませんっっ)今回やっと実現しました!

 

今回のスライドはコチラ↓

http://www.slideshare.net/kunioyamamoto519/ss-31073077

 

今回のワークショップは鈴木三紀夫さんが以前開催したワークショップのアレンジ版ということです。

東京で行った内容を福岡でも出来るってステキです!

今回はSkypeなどを使ってオンラインでワークショップを行っていただきました。

 

当日の様子はコチラにトゥギャっております(私だけのTweetで申し訳ないですが) 

 

今回の勉強会の目的

 ”テスト”の話をしても会話がかみ合わない!という悩みを解決しよう

 

自己紹介

各グループで自己紹介と この勉強会にきた「目的」や「持ち帰りたいもの」を発表しました。

 

テストって思いつくものをあげてみよう 

個人ワークでは「テスト」にはどういったものがあるか、思いつくだけポストイットに書き出しました。

 

各チームで どのグループになるかわけてみよう

各チームで、書いたポストイットを展開し、どのグループに属するかをまとめました。

同じテストをあげていたり、全く知らないものがあったり、忘れているものがあったりと、結構数多く項目がでました。

印象としては、みんな結構いろんなテストの名前知っているし、どういうテストか聞くと、大体「あー、そういうテストあるあるー」とわかるようなものが多かったと思いました。

 

発表しよう 

じゃんけんで順番を決め、各チームによる発表を行いました。

各チーム、アピールポイントも発表し、他のチームにない点や、項目数の多さなどをアピールしていました。

発表後、やまもとさんによる総評をいただきました。

 

講座を聞いているのと、いざチームでやってみると、中々仕分けるのは難しいと思いましたし、実際間違っていたり、いまだに悩んでしまう項目も結構ありました。

 

今回のワークショップで、「あるある」をたくさん聞けたと思います

(テスト技法を聞いたときに「おお!こんな方法が!」と目から鱗だったのに、実際使いこなせないままだったり・・・)

また、言葉の意味を正しく理解する大事さをあらためて感じました。

貴重なお時間をいただき、@gen519さん 本当にありがとうございました。

 

 

 

勉強会を終えての番外編(Twitterより)

分類するのって難しいなーというTweetからのお話が展開されました。

 

境界値テストや組み合わせテストを「テストタイプ」って言っちゃう所がある?!

 私は、テスト技法の勉強を初めてしたときに「ドリル本」で勉強したので、

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

 

 この本に載っていたものは「テスト技法」なんだ!という覚え方をしていました。

ですので、当然「境界値分析」や「組み合わせテスト」は「テスト技法」だと思っていました。

しかし、テストベースによっては、「テストタイプ」としたくなるときがあるとのことでした(・・・ここから理解できていません)

 

テストタイプは「目的」で、テスト技法は「その目的に対するモデル化」と考えたらいいよ。というアドバイスをいただきました。

(モデル化・・・となると敷居が高く感じてしまうのは モデル化の苦手意識からでしょうか?難しいです。ただ違いのイメージはできました)

 

回帰テストはテストアプローチ? 

上記の話題で「テストアプローチ」という言葉から、次の質問があがりました。

ちなみに、今回の勉強会には「テストアプローチ」という言葉は出てきません。

鈴木三紀夫さんがこのワークショップを開催するときに「初心者向け」ということでグループに入れなかったそうです。

 

回帰テストは「テストフェーズ」とするのがいいのではないかという結論になりました。(デグレ防止のアプローチでは?という声も)

この辺は私の不勉強で全くついていけず・・・ただ、その会話の中で「出荷前テスト」は回帰テストの言いかえだろ。という言葉でびっくりしました。

私の中の「出荷前テスト」は「受け入れテストのためのテスト」という位置づけで、「回帰テスト」は何かプログラムに修正が入ったために、影響がないかを確かめるテスト と理解していたので、同じテストケースを2回以上使うもの=回帰テスト

だと思っていました(説明が下手ですみません。。。)

 

ただ、これは粒度が違うだけで、システムテストなどで以前パスしたテストをもう一度やるという回帰テストなんだよ。

という説明をしていただいて、納得し、勉強になりました。

中々、シラバスや本を読んだだけでは理解したつもりになっているだけで、きちんと理解できていないな。と再認識できました。

 

強化テストは回帰テスト

では、強化テストは回帰テストなのか?

強化テストは探索的テストなのでは?という話が出ました。

それに対し、探索的テストは「テスト技法」なので、強化テストの時に「探索的テスト」という技法を使うことが多いのでは?(強化テストは回帰テストというテストフェーズにあたるのでよいのでは?)ということで落ち着いていました。

 

やはり、テストフェーズやアプローチ、、、グループ分けは難しいです。

ただ、ここの仕分けが出来るようになると、言葉の理解が早いだろうな。と思いました。

 

ソフトウェアテスト勉強会vol3 ~WARAI 福岡サテライト~

みなさん。こんにちは!

はやくもvol3になってしまいました!月1開催だと、次の回までが早い!

 

今回の勉強会は復習会を予定していたのですが、WARAI(関西ソフトウェアテスト勉強会)と日時が重なっていることを発見!

内容も何かとっても面白そう!ソフトウェアテストを勉強しようと思っている人にぴったりっぽい内容!

ということで、主催者の@NoriyukiMizunoにお願いして、SkypeGoogle+ ハングアウトを使ってサテライト会場として開催しました!

 

資料はコチラ

 

なぜテストは必要なの?から、テスト技法の説明までグループワークもありの大充実の3時間半でした。

本当にありがとうございました(*´ω`*)

 

以下、個人的な所感と反省点です。

 所感

●テストはなぜ必要なの?という、みんなが思っているであろう点を品質モデルや狩野モデルを使って説明されていたので、すごく納得できた。

”品質”とか”ISO”とかと”テスト””なんで大事?”みたいなことが 繋がった瞬間でした。

●このキャラクターは”ハッピー〇ーン”モチーフ!!

●キャラクターを使うことで、理解も早いし、覚えてもらいやすいんだなぁと思いました(こっちでも「あのハッ〇ーターンのところでさー」みたいな会話が成立しちゃってたし)

 去年から、イラスト(頭で思ってるイメージを絵で伝えたい)描けるようになりたいと思っていたのが、より一層強くなりました。

●関西レベル高い!

 参加者の声を聴いたわけではないので、みずのりさんのレベルが高いなぁと再認識したのですが、やはりレベル高いなぁと思いました。

 ●マインドマップ凄い!

 参加者も「おお!俺もやってみよ!」と言わせたマインドマップ!最近みずのりさんのマインドマップをいくつか拝見する機会があったのですが、綺麗!そして作成がむちゃくちゃ早い!

 おそらく普段から活用されていて作り慣れている&頭の整理ができる、そのターンがすっごい速いんだろうな。と改めて思いました。

(他にもたくさんあると思いますが)みずのりさんの頭の整理の速さマジ凄いです。

 マインドマップの回もいれねば。の前に、私も使いこなせるようにせねば。

●参加者の中には「難しい」と感じた方もそこそこ多かったようです。(私もその一人ですが、以前よりは理解は進んでいる気はしています)でも、半年後とかに再度この資料を見返すと 理解できる部分がどんどん増えてくるようないいものではないかと思いました。

 早く、この資料ぜーんぶ完璧に理解できる!ってなるように頑張ります!

 

反省点

●サテライトというものに参加したこともなかったまま、開催してしまっていたので、雰囲気作りができなかったのは課題かなぁと。

 こっちでフォロー?話すと聞き漏らすし、かといって、ずっと聴き続けるのも集中力が続かないというか。。

 普段Skypeミーティングしているときは、そんなことないので、やはり多数参加者形式の場合のオンラインでうまくいく手段?が別にある気がします。

 たぶん、まずは音響設備かなという感じ。。ノートPCの出力には限界がありました。。Skypeミーティングするときはヘッドフォンかイヤフォンなので。

 

●せっかくワークショップの時間があったのに、最後の問題以外をうまく誘導できなくて出来なかったこと。実際に手を動かすのが一番理解が早いというのは、参加者もみんな分かっていたので、これは私の力不足だと思いました。

 ワークショップだけでも、次回以降の勉強会でもう一度やってみたいです。

 

おわりに

 

重ね重ねになりますが、快くサテライト許可していただいたみずのりさん、本当にありがとうございました!

 

さて、次のvol.4は2014年2月12日(水)予定です♪