テスターのテストによる開発者のためのテスト

システム業界で思ったことをそのまま言葉にしよう

テストケースのないソフトウェアテストについて考えてみる

どうも、お久しぶりです。

なそです。

 

 追記:文章内で「テストケースのないソフトウェアテスト」=「アドホックテスト」と定義していましたが、JSTQBの用語との乖離があるとの指摘を頂いたので、修正しております。

 

 さてはて、ひさびさの投稿ですが、今回はこの話題について考えてみようと思います。なにかと話題に上がるテストケースのないテストの話ですが、下記の記事でも取り上げています。

tech.nikkeibp.co.jp

 

 この記事では「アドホックテスト」として、話を進めていますので、私もそれに則って、「テストケースのないソフトウェアテストアドホックテスト」としていきます。行きません!!

 この記事では、アドホックテストとしていますが、JSTQBの用語集では、アドホックテストは以下のように定義されています。

 アドホックテスト:非公式に実施するテスト。公式なテストの準備をせず、実績のあるテスト設計技法を用いず、テスト結果も予測せず、毎回、テスト方法が変わる。

 また、他にも、探索的テストがあります。

 探索的テスト:非公式なテスト設計技法の一つ。テストを実施する過程で、テスト担当者かテスト実施情報を活用しなからテスト設計をコントロールし、積極的に質の高い新しいテストケースを設計する。

 

このブログは、ほぼアドホックテストになるので、アドホックテストとして話を進めますが、JSTQBの用語と違うのは、下記の赤字部分です。

  • 非公式に実施するテスト
  • 公式なテストの準備をする場合もある
  • 実績のあるテスト設計技法をもちいない
  • テスト結果を予測する
  • 毎回、テスト方法が変わる

 

 ここで、私がアドホックテストを考えるときは2つのポイントに注目します。それは、「テストする人」と「動機」です。アドホックテストで不具合を見つけたいのはもちろんですが、何かしらの不安があるのでテストすると思います。それぞれ考えてみましょう。

1.  テストする人:どんな人がアドホックテストを行うのでしょう?

  1. とにかくたくさんの業種を問わない人たち
  2. 何度もリリースに立ち会い、いろいろな問題を解決してきた人たち
  3. テスト実施は何度も行なっているが、このシステムは未経験な人たち
  4. 新卒
  5. 上司に言われたからやる人たち
  6. よくわかんないけど、藁にもすがる思いの人たち

 とかとんとんですね。 

 

 もちろん、それぞれで一つではなく、複数のテストする人がいることもありますし、5のようになぜかやることになっているからやるということもあるでしょう。6の人たちは、テストの勉強をしてもらいたいですが、そんな時間がないくらい切羽つまっているかもしれないですね。 また、テストする人たちも様々ですね。テストする人たちをもう少し大きく分類します。それは、アドホックテストの準備がどのくらい必要かということです。

  1. 自立的に考え、アドホックテストを実施できる      → 自立型
  2. なんとなくヒントがあればアドホックテストを実施できる → 補助型
  3. 何をしたら良いかわからないが、指示があれば実施できる → 指示型

 この3パターンに分かれると

 自立型は、期間とシステムと仕様書があれば、アドホックテストを実施できます。補助型には自立型と比べると、ヒントとなるものが必要になります。それがあればアドホックテストを実施できます。指示型は具体的な確認したいことやシステムの使い方があればアドホックテストを実施できるはず。

 もちろん、どのパターンでもフォローは必要になります。

 

 なその経験では、補助型や指示型に思いがままにアドホックテストを実施してもらうと重要度の低い不具合が上がることが多いです。特に画面表示に関する不具合が多い気がしています。

例えば、とある家計簿アプリのアドホックテストをしてもらったときに

  • 家計簿アプリの金額欄に1000兆円入れたら、金額の欄の上2桁が表示されない
  • 金額入力欄に小数点が入力でき、金額が小数点を考慮した計算がされる

  一回の買い物で1000兆円使えるユーザーが家計簿アプリをアプリを使う確率は物凄く低いと思います。(っていうか、何を買えば1000兆円になるんだ!?) また、計算結果にエラーが出るのであれば大問題ですが、この場合であれば入力できるのが間違いという不具合になります。そして、このような問題は他の数値が入力できるところでも同じ問題が出る可能性が高く、不具合が大量生産されます。不具合は上がるに越したことはないかもしれませんが、このような不具合を大量に上げることによって確認で開発者の手を止めるのもまた私にとっては不本意でもあります。

 

 では、補助型や指示型のパターンにはどういう実施をフォローをしていくべきかというと。補助型には、テストで確認してほしいポイントを渡すようにしています。

  これを私が所属するところでは「テスト観点」と呼んでいます。粒度は細かいです。テストケースの一歩手前くらいの記述内容ですね。複数の業種のシステムを構成する要素を抽象化してまとめたものになります。って言っている自分が混乱しそう……。

 例を挙げると、テキストボックスだったら

  • 入力文字種(半角、全角、数値、記号等)が入力できること
  • 入力桁数が入力できること。入力桁数+1が入力できないこと
  • 禁則文字が入力できないこと。Copy&Pasteでも入力できないこと
  • ……

とかですね。もちろんシステムの表示部分だけではなく、見えないところのテスト観点もあります。 

  このテスト観点という言葉、色んな人によって考え方が違っていて曖昧な言葉でもあるので、私のテスト観点と読者のテスト観点が違うものになるかもしれません。

 テスト観点に興味のある方はぜひ、テスト観点を語る夕べにご参加ください! 一緒に語らいましょう♪ 次は2018年5月29日(火)です。語る夕べの雰囲気をお知らせしますね

togetter.com

togetter.com

 

 指示型には、自立型の人と一緒にテストを体験してもらうのが良いと考えます。(その人が何も知らない状態でシステムを触ることで見えてくる課題があるとも思いますが、それはアドホックテストで確認することではなく、ユーザビリティテストで計画した上で実施するのが望ましいです。望ましいんですよ!!)
 一緒にテストやってもらうといろんなことが起こるんです。テスト設計等の話でペアテストをやってもらったときのことをまとめてますので、よかったら参考にしてください。

devtest.hatenablog.com

 

 補助型や指示型の人を参画させると余計な工数が取られてしまい、十分なアドホックテストができないと思う方もいらっしゃいますが、後続を育てる意味でも参画させる必要があると思います。(この辺も語りだすと止まらなさそうで本筋から外れるのであまり語りません)

 

次に動機について考えていきましょう。

2.  動機:なぜ、アドホックテストを行うのでしょう?

  1. アドホックテスト以外のテストでは詳細な手順を記載するが、記載しきれない仕様の不具合を見つけたい?
  2. 仕様に書かれたテストは十分だが、人の感覚や経験に基づく不具合を見つけたいから?
  3. 過去の不具合を参考にテストをしたいが、過去の不具合が資料として残っておらず経験者にも診断してもらいたいから?
  4. テストした環境とリリースする環境の不一致があり、不一致部分の不具合を見つけたいから?
  5. テストケースを作る工数がなく、なんでも良いから不具合を見つけたい?
  6. 気が進まないが、上司からやれと言われたから?
  7. なんかやればよいことがあるらしいから?

 何をしたいのかはプロジェクトによって異なりますが、 それが定まっていないプロジェクトもありそうですね。何をしたいのかはしっかりと定めて不具合を狙いに行きたいです。

 仕様書から作っただけのテストケースでは、当たり前品質の確認しかできないかもしれない。魅力的品質も含めて考えた場合、それはテストケースにも現れてくる。何を魅力的品質とするのかは組織やチーム、個人によって異なるので、ここではあまり触れない(というか触れたくない((((;゚Д゚))))ガクガクブルブル)

 1は仕様書を中心にテストしていく確認作業に近いですね。2はフローやデータのつながりを考えながら実施したほうが良さそうです。3は経験者や第三者検証に依頼したほうがよいです。4は以前やったテストを使いまわしても良さそうですね。5はそう思っているなら今すぐテストケースを書くための努力をしてくださいToT 6や7はアドホックテストで何がしたいのかをもう一度熟考してもらいたいです。何かしらの不安点があってこそのテストなので。会社に決めているからと言っても無駄な工数を使うためではなく、一番最初にはなにかの課題をクリアしたかったはずです。

 

 で、こういうことを言っていると、「あ、じゃ、アドホックテストだけでよくない?」とか言う人がいるんですけど、ドキッとしたそこのあなた!その考え方は危険です。どうしてもアドホックテストだと、テストケースを使用したテストに比べて情報が残りにくいということがあります。残りにくいのは品質の測定のための情報です。この情報がないと次に繋がる一歩に繋げることができません。なぜかというと、どうしても直近のよかったことや困ったことはよく覚えているのに、数週間前や数ヶ月前の記憶は曖昧、もしくは忘却されてしまうからです。不具合として残る情報以外が闇に葬られてしまいます。

 なその所属するテストチームは2週間単位で振り返りをしていますが、それでも直近数日の話が振り返りに上がることが多いですという経験則もありますし、皆さんはどうでしょうか?(チームの話は語り出すと止まらないので、別途記事にしたいと思います)

 

 最後に第三者検証会社にいるとどうしても思った以上に品質が悪いという状況になってから参画することが多いです。「予定したテストを行ったが……」その状態から入ったときはアドホックテストを行うことが大半です。しかし、最初はアドホックテストを行い、並行でテスト設計を行ったうえでアドホックテストの比率を落としていく等の対策はもちろん行っています。ゼロにはならないんですけどね。

 アドホックテストだけではなく、テスト設計をしたテストを行うことでお互いの良いところを掛け合わせて品質を高めていけます。アドホックテストと言う名前のテストを設けたからと品質が高まるわけではなく、それで何がしたいかどんな人をアサインできるかとかまで考えないともったいない工数になってしまいますねということで今回は締めさせてもらいます!

 

それでは、今回はテストケースのないソフトウェアテストについてお送りしました!

 

 

参考資料
JSTQBの用語集「ソフトウェアテスト標準用語集」

http://jstqb.jp/dl/JSTQB-glossary.V2.3.J01.pdf

 
 

アジャイルの勉強について、なそのおすすめのアジャイル本

今年もよろしくお願いします!なそです。

 

今週のテストラジオで、アジャイルの勉強方法を話したところ、ワニさんからおすすめ本をまとめて欲しいとリクエストいただいたので、まとめてみます!

ssl.twitcasting.tv

アジャイルの話をするときは、なそは相手の前提条件を元におすすめの本を用意します。大体は上から順番になります。 

という訳で、簡単な説明とともに紹介していきますm(_ _)m

 

アジャイル初心者の方へ

 SCRUM BOOT CAMPです。

この本はなんと!作中に漫画が書かれており、各章の進行は漫画ベースで進みます。

スクラム(アジャイルの一つ)の進め方を知って前提をつくれるおすすめの本です。文章は読まなくても良いので、まずは漫画を読んでみてください。その後に文章を含めてもう一回読むと内容を理解しやすいと思います。

 

 アジャイルのプロジェクトの流れを知っている人へ

 アジャイルでやっている各作業について知りたい方にはこちらをおすすめします。

上記の本で流れを知った上でこの本を読むと単品で読むより吸収率がよくなると思います。文章も軽く読みやすいです。この本の作者は「初めての自動テスト」を書いたJanathan Rasmussonさんです。本の中の絵が可愛いです。

 

ここから役割によって変わっていきます。「アジャイルサムライ」を読み終わった後にそれぞれきになる分野から読むと良いです。

 

 アジャイルの中でテストを専門にしたい人へ

高いですが、アジャイルの中でテストを進めていく話が記載されています。量も多いですが、得られる知識は多義にわたるので、しっかり読んでみてください。自動テストのことも書かれていて、「初めての自動テスト」とかぶる部分がありますが、アジャイル×テストを知るにはこれ以上良い本はありません。 

 

 アジャイルの中でメンバーを育てたいしたい人へ

 チームの中でメンバーを育てたりコーチングについて書かれています。

教育に興味ある方はぜひ!実践したら効果が高いものも書かれているので、何処かのタイミングでは読んでおいた方が良い本です。「作者の言葉」というコラムが多く、学びも多いです!

  

アジャイルの中で自動テストをやりたい人へ

 アジャイルだけに特化した訳ではないですが、自動テストってなに?を知るためにはこれは最強の本です! 上記に記載しましたが、「アジャイルサムライ」の作者が一緒でどちらか読んだことある人はぜひとも読んでみてください。

さらに自動テストを知りたい人へ

 初めての自動テストを読んだ後におすすめなのが、システムテスト自動化標準ガイドです。より実践的な内容です。

 

アジャイルの中で小さく作ってチームを分けていきたい人へ

マイクロサービスが書かれている本になります。安定のオライリーさんですね。

本編中では触れていなかったですが、これも知っているとチームの分け方とかを考えるいい知識になります。

 

アジャイルを学んでいくことでおすすめの本を紹介でした。

それでは、なそがお送りしました!

料理を開発に例えて、テストについて考えてみる

※この記事は「ソフトウェアテスト Advent Calendar」12月25日の記事です。

qiita.com

 

 家の壁に貼るホワイトボードを導入したなそです。好きなだけ書けるのはとても楽しいです。AdventCalenderの書くことをいろいろマインドマップで考えて今回はソフトウェア開発がよく例えられる料理の話を考えてみたいと思います!

 何かに規模の小さなものに例えることで、大きなソフトウェア開発の全体を理解が進むと思っています。

f:id:DevTest:20171224225521j:plain

 

きっかけ

 さて、そもそもなぜこの話をするかというと、ソフトウェア開発におけるテストフェーズが料理における「味見」に当たるのが納得できていないということがきっかけです。ツィッターでは「味見」でした。「お毒見」とかもありました。

 

やっぱり味見がテストなのか?

 料理と開発の工程を比べてみましょう。今回は夕食を作る場合を想定して開発に照らし合わせています。

工程(料理:開発)

  1. 食べたいもの:要求
  2. 作れるもの:要件
  3. 作るもの:設計
  4. 調理:製造
  5. 味見?:テスト
  6. 盛り付け:リリース
  7. 片付け:運用

 こういう風に考えてみると確かに味見が該当します。そして、この味見はお惣菜(OSS)やコンビニ弁当(外部サービス)を買ってきたときには必要ないので、確かに味見がテストフェーズと言っても過言ではないでしょう。お惣菜をそのまま食べる場合は味見の必要がないですが(食べたらそれはつまみ食い)、ひと手間加えた場合、味見が必要になりますね。

 

QCD(料理:開発)

  1. おいしさ?:品質
  2. 夕食に使えるお金:予算
  3. 夕食の時間:納期

 次はQCDを考えた場合、Qに当たる部分が人によって意見が分かれるような気がします。おいしさ度外視(言い過ぎ)で栄養のバランス、カロリー重視、手を汚さずに食べれる等々私が思いつく限りでも複数あるので、もっとありそうですね。予算、納期に関してはそんなに意見が分かれない気がします。

 そもそもQが一つだけだとは限らないでしょう。複数の要素があるので、料理における品質特性(おいしさ、栄養のバランス、カロリー、彩り、温度等)を定義するべきでしょう。当然いま5つですが、ここに該当しないものもあるでしょう。家庭の夕食に厳格な栄養のバランスを求めていると予算と納期が大変なことになりますが、「1日30品目食べましょう」などはQCDを考える上で良いバランスに感じます。

 

結論? 

 料理におけるテストフェーズは「料理における品質特性」+「家庭の伝統」を加味して家族が健康であることが担保できるような活動全般を指すのではないでしょうか?

 その中の手法の一つが「味見」であるということです。味見は属人性を含んだテストにおける探索的テストですね。栄養のバランスとかカロリーは素材をカウントするので、テストケースで確認できるかもしれません。

 

余談1 食べたいものがしっかり言えないと・・・

 「今晩何食べたい?」とよく母親に聞かれたことがあり、何でもいいと答えていたのですが、よくよく考えると要求で「良しなに作ってくれ」といって丸投げしていたということですね。よくこのプロジェクトが失敗しなかったと改めて母親に感謝してますm(__)m

 しかし、食べたいものが出てくる確率は低いことは確かでした。一緒に暮らしている母親でさえこうなるので、大人数がかかわるソフトウェアの開発では「ほしいもの」が完成することはまずないでしょう。「ほしいもの」を要求できなかったことでトラブルになった例はいくつもあります。この辺は有名ですね。京都市の場合は現在内容の確認中なので、何とも言えませんが可能性があると示唆されています。

 

itpro.nikkeibp.co.jp

itpro.nikkeibp.co.jp

 

余談2 一汁三菜ってさ・・・

 ご飯の基本は一汁三菜って、教えてもらいましたが、

  1. ご飯
  2. 汁物
  3. 主菜
  4. 副菜1
  5. 副菜2

 ざっと見ただけでも、サブシステムが5つもあります。これを決められた予算と納期でしかも品質を担保しながらと考えると、無理な気がします・・・。っていうか普段料理する私も毎日は無理です。(せいぜい一汁一菜。茶色い・・・)

f:id:DevTest:20171225011518j:plain

 しかもこれらを考えながら、季節の食材や素材の数を横串で見ながら考えないといけないという。主婦はプロジェクトマネージャに向いているのではないかと本気で考えてます。

 

余談3 作るもの・・・

 料理のレシピは、材料と手順が書かれています。レシピがなかったら属人性を持った家庭の味になります。レシピ化することで人に教える、次に作る時にも同じ料理がつくれたりしますね。

「ぎゅーんとやって、スパッとひゅんとしてぐつぐつするとできるよ」じゃ伝わるものも伝わりませんよね。似たような話をテストラジオでも話をしています。

twitcasting.tv

 

あとがき

 

 余談のほうが長くなった気がしますが、ノルマ(テストラジオの広告)も達成したのでこのくらいにします!

料理の作業工程とソフトウェア開発の工程は例えとして優秀です。誰でも料理をしたことがあるので想像しやすいはず・・・。この例えは今後も使っていきたいと思います。

 

それでは、なそがお送りしました!

WACATE 2017 冬 ~すべてがTになる~ 参加レポート

どうも!なそです!!

 

ワカテーズハイという症状をご存知でしょうか?

WACATE2017 冬 ~すべてがTになる~ 開催概要 - WACATE (ソフトウェアテストワークショップ)

1泊2日で開催されるワークショップです。

ソフトウェアテストに関わる人たちが60名くらい集まる異色と言えば異色です。

そこでは2日間ずっとテストの話をし続けます。

その状態に慣れ、月曜日に会社に来ると周りよりもテンションが高くなっているのが「ワカテーズハイ」と呼ばれるハイテンション状態です!

 

テストラジオも今回のWACATEに触れてます。さらっと。

ssl.twitcasting.tv

 

通常のセッションは、他の人に解説を任せて私はよりニッチな分科会をレポートします!

素晴らしく綺麗にまとめてくださっている人からリンクOKをもらったので、通常セッションを見たい方は、こちらをごらんください!!

yoshikiito.net

yoshikiito.net

 

WACATEは参加型ワークショップです。

参加者の自主性がかなり尊重されるワークショップでは、他では珍しい時間があります。

それは「夜の分科会」です。

語りたいテーマをぶら下げたオーナーの元に集まり、議論をするという形式です。ここにはWACATEの実行委員はあまり関与してません。オーナーを中心に議論をファシリテートしながら、意見をぶつけ合うのが分科会です。みんなで考える会です。

分科会のオーナーになるには、WACATE申込時に分科会のオーナーになりますと宣言するだけです!簡単!!

 

WACATEより引用

ディナーセッションが終わった後はその勢いのまま自分が語りたいテーマごとにグループにわかれ、フランクに議論をしていただきます。
恥ずかしがりやの方も人見知りの方も、遠慮なさらずテストについて思い切り語りあいましょう。
テーマはWACATEの参加申し込み時に募集しておりますので、語りたいテーマがある方はぜひテーマオーナーとして立候補していただければと思います!

普段からの悩みや他のエンジニアに考えを聞きたいことなどを大胆に、かつ真剣に語ってみてください。きっと応えてくれる同士が見つかるはずです。

是非、想いのたけをぶつけてください!

 

参加者による分科会のため、WACATE毎にテーマが異なります。

その時に興味があることについて話をするので、その場限りになります。

そして、今回のテーマは5つでした。

  • テストの妥当性
  • 納得の提案
  • BPPセッションの続き
  • QAの立場
  • テストの自動化についてなんでも答えます

そして、私は今回「テストの妥当性」のオーナーでした。

さて、今回なんだかんだで3回目のオーナーになりましたが、どうやってテーマを決めているかというとその時のトレンドを分科会のテーマにしています。

過去の分科会では、「教育」がテーマになってます。

今回とは別なテーマにしました。

テーマを決めた理由は、「テストの妥当性」について悩んでいる人がいたから。

そして、そのことに私自身が興味を持ったからですテーマにしました。

みんなどうやって折り合いをつけながら、テストしているのかなと。

 

分科会が始まると、気になるテーマごとに集まり議論スタートします。

今回はお悩み相談に近かったので、本人のヒアリングからスタートです。

 

ここでオーナーが注意しないと行けないことは大きく3つ

  1. 喋りすぎる人を止める
  2. 発言しない人に発言を促す
  3. タイムキーピング(時間は100分)

オーナーが最初の火をつけると周りから発言が出てきて、程よく火が大きくなります。

そうして、想像以上に思っていること、普段疑問に思っていること、疑問に思っていなかったけど人の意見を聞いて疑問に思ったことなどなど周りからいっぱい出てきます。

火がだんだんと大きくなってきた頃には、よく喋る人と全く喋らない人の2層に分かれます。この辺でオーナーがファシリテートしていきます。

が、今回はよく喋る人が喋らない人に発言を促してくれたおかげで、オーナーやることなくなりました。

それでも、議論を進めながらなので、届かないところもあります。

そこをフォローすれば良いだけなのです。

 

というわけで、議論がいい感じに進みました。

 

 議論を進めていく中で、今回のお悩みは「テストの妥当性」「テストケースの妥当性」の2面があり、それぞれを切り分けて考えていく中で、取れる立場や状況。立ち回り方。失敗例。と教科書的な回答が出てこない!! そこがとても面白い。

 

その中で、

  • テストの妥当性では「テストケースによるテスト」と「探索的テスト」が必要
  • テストケースの妥当性では「どこまでテストするべきか」を検討する必要

って話になったはず・・・(メモとか取ってないので思い出しながら書いてる。間違ったらフォローして!!)

 

 テストケースだけのテストでは、カバーできる範囲が限られています。だからこそテストレベルを分けてテストすることでそれらをカバーする必要があります。

 また、テストケースによるテストだけではカバーできないので、探索的テストを実施する必要がある。それもモンキーテストではなく画面の規模等で時間を割り振るタイムボックスの探索的テストとかをオススメしていました。

画面の規模等の話は何話したかを覚えていますが、ちょっとここでは割愛します。

 

 いきなり「探索的テスト」をやりましょうでは、難しいのでまずはテストケースのテストを実施して、バグの傾向を掴む必要があります。(7原則の4:欠陥の偏在)その傾向に則って探索的テストを実施するのが理想ではと分科会メンバーでは落ち着きました。

 そのためのメトリクスや情報を集めるのも重要です。的な話をして翌日のメトリクスのセッションにぶん投げた記憶があります。(ページ下部にリンクを貼っておきましたのでご覧ください。私も何やるかわかっていなかったので目的の情報が集まってなかったらごめんなさい。連絡くだされば一緒に悩みます(うぉい笑))

 

 次にテストケースの妥当性では、どこまでテストすべきかは担当者やユーザー側にヒアリングを行い、その水準を満たすのをゴールに実施していくべきという話になりました。どこまでもテストケースは増やすことができます。(7原則の2:全数テストは不可)

 その中で取捨選別を行うのは我らテストエンジニアでは決め切れません。経営判断やPMの意向等々が必要になります。100点の基準がわからないのであれば、決めるしかないです。その決め方は私たちから動いて決めてもらう。一緒に決めていく必要があります。

 また、必要なケースを洗い出すためにはたくさんのテストケースをやるのではなく、効率の良いテストケースを用意する必要があります。テスト技法を使って効率を求める必要があります。ここは翌日の「直交表に触れてみよう(仮)」にぶん投げました。
(この仮はいつ取れるんだろう?これも下に貼っておきます)

 他にもテスト技法があるので、ここは頑張って勉強してもらいましょう!!

 

 オススメの本はこれ!

ただし、いきなり深く読もうとすると深淵を覗くことになるので(失礼なやつ笑)無理のない範囲で学習を進めるのが吉♪

 

という感じの100分を終え、どうだったんだろうな?

どこかで話を聞けたら嬉しいですね。

 

そんな分科会を開催しました。周りの人がどんな分科会をしたのか興味あるなぁ。

分科会のオーナーは、気になるテーマの話ができて、みんなの意見をまとめる練習がここではできます。

答えを持っている必要はないです。ニッチ過ぎても多少は大丈夫!!

飛び込んでみると世界が変わると思いますよ♪

 

実は、WACATEにはさらに分科会がありまして、深夜の分科会があります。

 地方から来た人たちと話をする機会がないので、その集まりっぽくなりますがここでは、全国の猛者たちが暑すぎる議論を繰り広げたりします。お悩み相談もしてくれます。進路だったり、業務の悩みだったり。

(まぁ、夜の分科会の時点で0時近いので、そこから先は自己責任です笑 ただし、濃厚なテスト談話を聞けます。今回の深夜の分科会はワークショップがもう一個開催されていました) 

 

ちなみに私はというと

ssl.twitcasting.tv

ssl.twitcasting.tv

いる人捕まえて、ラジオ放送をしていました。

 

そんな感じで夜が更けていきます。

なかなか夜の分科会のオーナーになった話というブログは見ないので、これをきっかけに分科会のオーナーが増えてくれると嬉しい限りです!

 

WACATEはレポートを書いてみんなでワイワイするのも一つのアウトプットになります。ワカテーズハイのうちにブログを書いて見ましょう!!

 

それでは、なそがお送りしました♪

 

 WACATE セッションの資料はこちら

www.slideshare.net

www.slideshare.net

テストデータの人名を「ああああ」とかにしてませんか?簡単にデータを作成してみませんか?

※この記事は「ソフトウェアテストの小ネタ Advent Calendar」12月4日の記事です。

qiita.com

  

Advent Calender 初投稿のなそです。

今回のお題は小ネタということで、知っていたら楽かもしれないテストデータを便利に作れるサイトを紹介したいと思います。

 

皆さんはテストデータで人の名前使うときにどうしてますか?

「テスト太郎」や「ああああ」とか使ってませんか?私は以前まで使ってました。

あとはドラマやアニメの登場人物を使ったり、自分の名前使ったり色々使っていたんですが一人二人ならさくっとできます。大量のデータになった時や住所や電話番号と入力項目が増えていくと毎回その場で作るのは難しくなります。

 

疑似個人情報データ生成サービス

 

氏名や住所だけでなくメールアドレスや誕生日などのデータを作ることができます。

また、年齢比や男女比、居住の地区など細かく生成データを指定することでテストするアプリの対象ユーザーに合わせることができます。

 

ただ、問題としてはリアルすぎて本物だと思われる可能性があります(;ω;)

使用の際はその点だけご注意ください。

 

バグがあったときに、XXさんで障害出てますとか言いやすいです。

 

10件〜5000件のデータが作成できます。

いっぺんにデータを作成してくれるので、大量のデータを対象にしたテストデータも作りやすいです。

 

 ぜひ、利用して素敵なソフトウェアテストライフをお過ごしください!

木テクにて突撃LTをさせてもらいました!!

こんにちは、なそです。

 

季節は一気に冬になり、体調はいかがでしょうか?

 

さて、ちょっと前ですが、下記でLTをさせてもらった話をします!

mokuteku.connpass.com

 

申し込んだのは10月25日(水)の前日でした。

直前に対応いただきありがとうございましたm(__)m

話の内容は「テスト観点」についてです。

私が伝えたかったのは、テスト観点一覧表をつくりましょうではなくテスト観点とは何者かということを再認識してもらいたかったということです。私自身がという再認識をするところがめっさ強いです。

 

=私のイメージ=

テスト観点=テストするための観点。この辺にバグが居そうだなと思える「勘」だとおもっています。

(このテーマで話をしようと思った時に、テスト観点とは何者だということでJSTQBの用語集を見ましたが、テスト観点はなかったです)

 

よくあるのがそれを一覧化して、みんなで共有できればバグは漏れない!と。

でもよく考えてほしいのです。「勘」なので、何かしらの経験、知見、知識が必要になってきます。その一覧は失敗リストでもあるのである。

過去の失敗をリスト化したものをテスト中にバグが出たとしたら、その前の工程で対策できていないと過去の経験が活かされていないということに。

 

そのため、テスト観点はテストする人たちのみのものではないということだと私は思っています。プロダクトマネージャやプロジェクトマネージャ、開発者、テストエンジニアのみんなで共有できれば、早い段階から問題解決できて良い製品を作れるはず!!上流の工程からバグを作りこまない作業ができる!

 

では、すぐにテスト観点一覧を作るべきかというとそうではないのです。

作る前にチームの中で話をするべきです。特に最近入った人とベテランが対話すべきです。先ほども言った通りで「勘」なので、ベテランが持つ直観の場合もあります。まずはチーム内で共有することが重要です!

まずはドキュメント化しようぜ!って流れは私は好きじゃないです。

∵ドキュメントにすることでかかる時間ってすごい膨大なものだからです。

このテスト観点を一覧にするだけで作成コスト、メンテナンスコスト、内容の把握、使い方の説明、改善作業、等々・・・

誰がやるんでしょうね。重要性とコストを天秤にかけないままに実行に移すとそれこそとん挫します。1回作ればそれでOKってものでもないので、改善をしていかないといけないです。もし途中でできなくなるなら、それって結局やったことをどぶに捨ててるんですよね。もったいないですよね。

 

じゃ、どうしましょうって話になります。

テーマを決めた飲み会とか座談会とかを実施してみたらどうでしょうか?

その中で出てきた話をみんなで共有して、整理して、みんなの中の合言葉にする。

合言葉にすれば忘れにくいので、改善されてそれが起こらなくなったらそれは文化になったということなので、次の問題や課題が発生しているはずです。忘れる、漏れる、抜けるとかが問題になってくるのであれば、一覧化して共有していく。

みんなで整理しながら育てていく。そんな感じで現場がうまく回り始めればよいなぁと思っています。

speakerdeck.com

すでにテスト観点をお持ちの場合は、一度整理してみるといいです。

これ毎回テストするけど、まったく障害を出さない場合は「殺虫剤のパラドックス」化している可能性が高いです。

 

この話の後に、テストのスーパーヒーロー達による会が開催されることになりました。

connpass.com

興味があればぜひ参加してみてください。
(ってすでに募集オーバーしているΣ(・ω・ノ)ノ!!)

 

それでは、少しでも現場を改善して1分でも早く帰りたい「なそ」がお送りしましたm(__)m

転職を振り返ってみる

こんばんは、なそです。

 

Twitterのタイムラインが転職、仕事辞めたいであふれかえっていたので、自分の時を思い出してみることにしました。

 

【転職迷い時期】

 もともと北海道でSIerでほぼベンダーとしてシステム開発をしていたので、一気通貫の仕事が多かったです。そのため、顧客とかかわることができる要件定義から保守運用まで担当できたのはとても仕事をする上での土台を作ることができていました。

 しかし、その中でどうしても開発の終盤からリリースまで荒れることが多く、いろんな人に迷惑をかけることがありました。

 このころから勉強会に参加するようになり、いろんな方から社外の状況を聞くようになっていきます。それと合わせてプロジェクトマネージャーの勉強に加えて、開発プロセスの勉強も進め始めました。

 

【転職決断】

 前職で炎上案件の渦中におり、うまいことマネジメントができない。開発も進まない。顧客との調整もしっくりこないという状況でした。(PMは別にいたんですが、ここでもうまいことコミュニケーションが取れていなかった気がします)

 PMとは別の案件でもチームを組んだことがあったのですが、顧客への価値提供の部分でぶつかることが多く、ここでも同じことを発生させてしまいました。

 そうこうしているうちに実践している開発プロセスに疑問を持つようになり、ほかの会社はどうやっているのか気になり始めました。また、品質の指針であるテスト計画書がコピペ製作だったため、品質に対しても気になり始めました。

 そんな中、ふとした気の迷いから登録した転職サイトから一通のスカウトが届きました。それが今の会社です。上記で気になっていた「品質」「検証」「いろいろな会社」というキーワードがヒットし、ダメ元で受けてみることに。

 

【転職まで】

 ダメ元で受けるといっても、いろいろとヒットする項目があったため数社から選ぶことはせずに1社受けてダメだったら、もうしばらく会社を続けることにしました。
(性格上、ふらふらと決めかねるくらいの時は実務も転職活動も何も身も入らないので)

 エントリーからすぐに1次面接のメールが届き、東京本社を希望していたためSkypeで面談となりました。(一人しかいない部屋の中でスーツを着て椅子に座っているのはシュールでした)

 その日は前歴、転職の理由、ちょっとした雑談をして終わりました。最初は緊張していましたが、話を進めていく中で緊張も程よく解けました。

 そのままあれよあれよと決まり、無事に転職することができました。意思決定の速さには本当に感謝しています。9月下旬から10月中旬くらいのスピード決定でした。

 

【転職後】

 さて、念願かなって品質を勉強できるとのことで、いろいろと飛び込ませてもらいました。そのおかげで今、悩みながらもテストを仕事にしてよかったと思えています。

 

なんだかんだでサクッと決まりましたが、いろんな人と話をしていくなかで感じたのは「転職の理由」が大きいのではないかと思いました。

私が自問自答したのは、3点だった気がします。

  • 会社の事業に共感できるか?
  • 業務の内容は理解できるか?
  • その業務を通じて何をしたいか?

 会社の事業に共感できて、業務内容が理解できて、得たいものが定義できなければ、ミスマッチが起きますので。。。相手もこの3点がミスマッチだと落としてくれるので、自分に合わなかったんだと納得もできます。

(多少の思い込みが入っても大丈夫だし、ぼんやりしててもいいと思います。そして、会社の全部を知るのは不可能です。漠然とでもよいのでここで働きたい。こういうことをしたいとイメージできるかどうかが鍵な気がします)

そして、これがしっかりしていると周りの人に止められることはないと思います。

(転職した人周りにいなかったし、誰にも相談しませんでした(笑) 社内では特に誰にも言ってません。一番仲が良かった先輩すら転職が決まった後に報告しました)

まぁ、ノリと勢いで転職しましたが、こうして言葉にしてみると何も考えずには転職はしていませんね(笑)
(スピード決定だったのですが、転職は3か月くらい待ってもらいました。わがままを聞いていただきありがとうございます)

 

自分はこうして東京で働くことになり、いろんな人出会うことができました。

転職や今の業務で悩んでいる人の少しでも助けになれば幸いです。

 

それでは、ノリと勢いを大切にする「なそ」がお送りしました♪