テストラジオってなんだろう？

書くときはすぐに連チャンで書いてしまう「なそ」です。

お久しぶりです！

さてはて、前回のブログでもちょろっと話をした「テストラジオ」について、今回は話をしようと思います。

テストラジオはひょんなことから始まりましたが、初放送は2017年2月5日です。

twitcasting.tv

私こと「なそ」と東海を中心に活動している「オカウチワニ」さんがソフトウェアテストの話を行うという至極単純ですが、とてもニッチなラジオをツイキャス上で放送しています。現時点でテストラジオは19回目を放送したところです。一覧はこちらです。

twitcasting.tv

ツイキャスのサービス自体はリアルタイムを軸にしていますが、テストラジオは収録したものを編集して、流しています。なので、リアルタイムではありません。コメントには返事できるんですが、番組内では拾うことができないです ToT

初期の段階は録音装置も機材もなく、二人で手探りをしながら放送をしています。

この記事を書くにあたって、第1回とか聞き直してますが楽しいもんですね(笑)

内容に関しては、お互いが興味のある分野について話をすることが多く、特に参加した勉強会の内容を振り返ることが多いです。

そんな中ゲストに来てもらったりまったりのんびりと行っています。

ゲスト出演回

twitcasting.tv

twitcasting.tv

第1回からゲストを呼んでいます。そのあとしばらく間が空いています。

放送は大体1週間に一回土日を中心に行っています。最近は日曜の19時付近に放送し、テスト界隈のサザエさんと化しています(笑)

「オカウチワニ」さんがラジオ内で深掘りや話を広げてくれるため、「なそ」はすごく助けられています。そして、ふんふんと聞いていることがたまにあります。編集中に「オカウチワニ」さんの声だけで良くない？と思った回もあります。その回がこちら！

twitcasting.tv

色々とやっていますが、少しずつ進化しているはずです。

これからも配信していくので、よろしくお願いします！

その中で、テストラジオのパーソナリティのネットワークを活かして宣伝活動を行ったりしています。ここ最近ではJaSST東北やJaSST関西の宣伝を行っています。

そういえば、JaSST関西は6月23日(金)ですね！

JaSSTソフトウェアテストシンポジウム-JaSST'17 Kansai 開催要項

私も行きますが、実に楽しみです。

人工知能とかワクワクします♪

配信方法とかも工夫しているので、その辺も話ができれば良いかなぁ？

聞きたい人いるのかな？(笑)

それでは(*･ω･)ﾉ

WACATE 参加レポート BPPセッションして来た

2017年6月17日〜18日にWACATE 2017 夏が開催されました。

お久しぶりです。なそです。

最近は、「テストラジオ」などの活動でめっきり文章を書いてない。

声の発信をしていると文章は書かないけど、話の進め方とかが重要になってくる。

これって、文字にするか、声にするかの違いなのでどっちにも共通する必要なスキルってことになりますね。

今回はWACATEの参加レポートの中でもとてもニッチです！！ 

さて、WACATEとは、テストエンジニアが集まる年2回のワークショップです。

1泊2日で行われるので、2日間ずっとテストに浸かりながらスキルを高めて行くことができます。

WACATEには、面白い制度があって中の人がセッションをしてくれるのですが、その中の2セッションは、外部の人が行います。

1つはテストで有名な方のセッション。もう一つは前回のWACATEの中から選ばれた1名(ベストポジションペーパー賞)のセッション。

で、私は今回後者の方でセッションを行って来ました。

どうやって、その1名が選ばれるかというと……

「ポジションペーパー」と呼ばれる1枚の紙を参加者が申込時に提出します。参加者が約60名いるので、参加者の投票でその1名を決定します。

ポジションペーパーとは、決意表明や悩み、思っていることなどのWACATEでどうしたいかを記載した紙です。参加者、実行委員の全員が書くので、それが名刺がわりでありお互いを認識するものになります。

そして、前回選ばれた私はBPPセッションを行うことになりました。

前回のWACATEが2016年12月。半年の間に自分が話したいことを中心としたセッションを作成せねばなりません。超悩みました。

前回のWACATEでBPPセッションをしてくれた人が凄すぎて自分に同じようなことができるかどうかが全く想像できないのです。

自分の武器や得意なこと、何ができるのかがわからない中で、何か吐き出せるものがあるかと悶々とする日々でした。

4月をすぎても良い内容が浮かばなかったのですが、悶々とする中自分がやりたかったことや夢、困ったこと、やってみたいことが洗い出せて行きました。

そして、4月中旬にプロジェクトが変わってチームリーダーになったことで、今回のテーマ「良いチームを作ろう！！」を思いつきした。

せっかくチームを率いるなら楽しく、成長を感じつつ仕事をしたい。してもらいたいと思ってチーム運営をしていたので、それを吐き出そうと。

悶々としていた気持ちがすっきりすると同時に次は、何をどうやって話そうというところで躓きました。

そういやこういう発表したことないや（笑）

あ、テスコンで発表したけど、チームの内容だったからね。

また悶々とする日々です。

それでも、タイトルを決めて何をしているか、何をしたいか、何を話したいかをメモし続けました。

そして、2週間前の土日？に勢いよくパワーポイントで書きなぐりました。

その枚数、約100枚。

前回の受賞者からのアドバイスは

• 下の方に書くと後ろの人が見えないよ
• フォントが28くらいでも厳しいかも

と教えていただいていたので、枚数を増やして文字を大きくしました。

また、コメント的なことを右上と左下に入れて、本音っぽいことをコメントするようにしてみました。

あとはアニメーションは使いませんでした。当日にアニメーションでトラブルになっても嫌なので使用していません。

何人かにレビューを依頼して言われたのが

• 言いたいことは10個あったら1個か2個の方が良い
• トピックスが4個かあるけど、そのトピックスと内容が一致していない
• 各トピックごとにまとめが欲しい
• 枚数が多い
• 笑いが必要（内容が固すぎる）

色々指摘受けて、言いたいことを減らすと残ったことで深掘りしてページが増えるを2,3回繰り返した結果、100ページにギリギリ届かない枚数となりました。

構成としては

1. オープニング
2. 導入
3. タイトル
4. 実践内容
5. まとめ

としました。

いつものテストラジオのような構成ですね。

タイトルが3分の1くらいにならないと出てこない異色のプレゼンになりました。

この資料の枚数を見た実行委員の良き計らいで5分延長可能な状態になりましたが、25分で話し終わるという駆け足で進み10分くらい質疑応答に使うことができました。

本当にありがとうございましたm(_ _)m

テストラジオも25分くらいだから、その雰囲気で話しちゃったのかな？

緊張するタイプなので、前日は気合いを入れるために「すた丼」を食べて、当日は「テストチョットデキル」Tシャツ(miwa719 の【チョットデキル No.1】Tシャツ ∞ SUZURI（スズリ）)を着て、テストラジオパーカーを羽織り本番に臨みました。

あくまでも、ワークの前座なので楽しんでもらえたらいいなあと思いつつ、こんなリーダーになりたい、私だったらこういうリーダーになりたいとか思っていただければ幸いです。

途中で、飲み忘れていたレッドブル飲んだりして、セッションとしてどうかなぁと思いつつ楽しく話をさせてもらいました。

つぎのベストポジションペーパー賞の発表を楽しみにしつつ、今回も終わろうと思います！

WACATEの内容については、別日に書きます。書く予定です（笑）

 きっと書きます！

それでは(*･ω･)ﾉ

勉強×教育×努力

こんにちは！なそです。

JSTQBからは一旦脱線します。

今回のテーマは「教育」です。 

教え育てることであり、ある人間を望ましい状態にさせるために、心と体の両面に、意図的に働きかけることである。教育を受ける人の知識を増やしたり、技能を身につけさせたり、人間性を養ったりしつつ、その人が持つ能力を引き出そうとすることである。　　　　

wikipedia「教育」より引用

このテーマについて徒然っと書いていきたいと思います。お付き合いいただければ嬉しい限りです。賛否両論あるので、議論してみたいですね。

さて、まずは私の持論としては「できない人は絶対にいない」ということを最初に伝えておきます。会社で「こいつ使えねぇなぁ」っていうのを聞くと、その組織の教育に対する姿勢を疑います。

しかし、費用対効果を考えなければ社会人ではないでしょう。諦めるという選択肢が存在することは私も認識しています。これは本当に苦渋の選択で、自分の力不足を本当に恨みます。

　私はできない人は絶対にいないといいますが、その人のレベルから要求するレベルに上がってもらうのは並大抵の努力ではありません。一緒に努力する必要があります。教育方針の決定は、その人の人生を左右する事になります。途中で「あ、ごめん。教育方針間違えたわ」なんて絶対に言えません。今回は教育者目線（上司から部下）で話を展開します。（いつか逆の目線で書きたい）

そして、教育対象の人は下記の4タイプに別れると思っています。

1. 進みたい方向が決まっていて、会社の方向と一致している。
2. 進みたい方向が決まっているが、会社の方向と一致していない。
3. 進みたい方向は決まっていないが、会社の方向は許容できない。
4. 進みたい方向が決まっていなくて、成り行きに任せている。

１.進みたい方向が決まっていて、会社の方向と一致している。

　面談時にこんな人に出会ったときに私達が考えないといけないのは、本当に認識がズレていないかと思わなければ行けません。こういう人は会社の方向を理解し、合わせてくれている可能性を十分に含みます。そして、理解が早いのでサクサクと面談が進むので楽です。しかし、本心を聞き出すことを忘れないでください。

ある日、辞表を突然出されるということが起こるかもしれません Σ(ﾟДﾟ)

2.進みたい方向が決まっているが、会社の方向と一致していない。

　これは結構難しい問題にぶち当たったと思ってください。簡単な例では、新人がこれに当たることが多いと思います。夢を持って入社するわけですので、事前に聞いていた状況と現状のギャップに悩むことは当然といえます。こういう人は「急がば回れ」という事を理解して貰う必要があります。ホップ・ステップ・ジャンプです。基本になる知識や経験がなければ次に進むことができず、最後の大きなジャンプをすることができません。

自分の現状の場所と最終的に居たい場所を描き、どういう道で進むかを複数示してあげてください。モチベーションが高いので、進むべき道をしっかりと作ったときの成長は早いと思います。

3.進みたい方向は決まっていないが、会社の方向は許容できない。

　なんて、めんどくさい事になっているんだか、どうしてこんな人がいるのかあなたは自分の心に聞いてください。この状態は5年目以上の人に多く、会社の現実に夢砕かれてもういいやって投げやりになっている可能性が高いです。相手も人間なので考える事ができます。なにが不満か全力で聞き出してください。教育はその後です。枯れかかっている心に優しく水と肥料を与える気持ちで接してください。こういう言い方をすると腫れ物を扱うように接する人も居ますが、それは違います。その人の心にぶつかるので、あなたも本心でぶつかってください。少しずつ新人の頃の気持ちを思い出し進みたい方向を思い出すかもしれません。そこで会社の方向が許容できない部分も出てくるでしょう。あなたのすることはその人の間違っている所をしっかりと論理的に指摘して気がついてもらう事です。そして、会社がおかしい場合はそれを改善するアクションをとるべきです。

　これを読んでいる人はそんなことできるわけないだろうと思うかもしれませんが、この改善のアクションは誰のためでしょう？会社のため、ひいてはあなたのためです。「情けは人のためらならず」です。きちんとググって意味調べてくださいねｗ

4.進みたい方向が決まっていなくて、成り行きに任せている。

　一番の困ったさんですが、3に近い感じがします。こういう人は「自分で考えてくれないんだよな」って言う印象が着きやすいです。なぜ自分で考えないんでしょうか？本当に考えてないんでしょうか？普段の業務中にあなたが頭ごなしに否定していませんか？

　そんなことないよ。と思った人にはもう一度聞きます。「頭ごなしに否定していませんか？」無意識のうちにその人を追い込んでいませんか？一度周りの同僚にその人と自分の関係性をどう見えるか聞いて振り返ってください。たいていの場合、相手の意見を潰し、自分の意見を押し付けています。すぐに素晴らしい考え方が身につくわけじゃありません。しかし、繰り返すことで脳は確実に進化します。それを忘れないでください。あなただって生まれたときから言葉を発したわけじゃないでしょうｗ

最後に

言いたいことを言いましたが、もう一つ言いたいことがあります。

社会人なんだから仕事のプロになる努力をしようよ！！

たまになんでそんなに勉強するの？って言われますが、私は勉強会に参加するのも、社外の人と情報交換するのも、本を呼んで勉強するのも「今の仕事に自信がないから」です。他の人より持っている情報が多い部分もあるでしょうが、周りの人はもっとすごいです。毎日の業務を仕切るので必死なら、少しでも簡単になる工夫をしようよ！！

と思ってます。他の人に丸投げとか片っ端から断るのもいいですが、今のプロジェクトが終わったときにあなたは必要とされる人であり続けることが出来ますか？っていう話です。

自分に価値をつけて行く努力はするべきではないかと思います。

今回は「教育？」についてでした。

次回はJSTQBに戻るかな？

それとも、とある勉強会で話題に上がった話を纏めるかもしれません。

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

ソフトウェアの欠陥ってなんだろう？

こんにちは！なそです。

1週間ぶりです。

12月は寒い日が続くと思ってましたが、どちらかというと11月の方が寒かった気がする今日この頃です。しかし、油断すると崩れそうなので、皆さんも体調を崩さないように気をつけてくださいね。

さて、前回に引き続き、JSTQBを読み進めて行きましょう。

ところで、「ソフトウェアの欠陥」って何を示すんでしょうか？ ひとえに欠陥といっても、自分の思った通りに動かない。エラーが発生する。設計書通りに動かない……等々とあると思います。その原因をよく考えないと修正時に間違った方向に行ってしまう可能性もあります。

それに自分がどういう欠陥を発見したのかを説明するときにうまく説明できますか？一括りに障害やバグ(以降「障害」に統一します)という言葉で片付けてしまうこともあると思います。

しかし、その障害がどういった要因によるものかを分類することも必要です。

その「ソフトウェアの欠陥」の分類はJSTQBでは以下で定義しています。

• エラー
• フォールト　
• 故障

エラーは「間違った結果を生み出す人間の行為」3×2と入力した時に5と結果が返されると、これは欠陥ですね。掛け算と足し算を間違えている可能性大です。この間違えた行為がエラーです。

フォールトは「要求された機能をコンポーネントまたはシステムに果たせなくする、コンポーネントまたはシステムの中の不備」先ほどの例で言うならば、3×2と入力した時に5と結果が返されるという事象がフォールトです。

故障は「コンポーネントやシステムが、期待した機能、サービス、結果を提供できないこと」

3×2と入力した時に5と結果が返されるということはシステムとして、計算をするという機能を提供できなくなります。この事象が故障です。

これはプログラムのエラーでもそうですが、ハードウェアを含めています。カラオケに行って、マイクが全て使えない状態になっていたら、サービスが提供できません。これも故障ですよね。

そして、それらの管理はインシデントと言い、意味は「発生した事象の中で、調査が必要なもの」となっています。

ただし、インシデント ≠ 故障ということだけ覚えたおいてください。テスターのオペミスということもあります。実は×だと思ったんだけど＋を押していた。マイクの電源を入れ忘れた。マイクの充電が切れていたとか考えつくので、発見した事象を調査してもらい、故障かどうかを確認していくためにインシデントを発行します。

最近だとチケットという名前で浸透していると思います。ひと昔（今もやってると思いますが）エクセルでインシデントを管理していた時の分かりにくさったらありゃしません。個票と一覧表を用意して、それぞれの同期は手動なんて時代もありましたね。そう考えるとシステム化しただけで当時からやりたいことは変わってないですね（笑）

さて、インシデントにどういう情報があれば良いか等JSTQBでも定義されています。今から説明し始めるとさらに長くなってしまうので、今回はここで終わろうと思います。

今回は「ソフトウェアの欠陥」について考えてみました！

次回は「インシデントってどうすれば良いの？」と考えてみましょう♪

テストってなんだろう？「ソフトウェアシステムの状況」ってなに？

こんにちは！なそです。

1週間ぶりです。

先週は水曜日が祝日だったのに、体調を崩してしまいドタバタな一週間でした。

12月目前で寒い日が続くので皆さんも体調を崩さないように気をつけてくださいね。

さて、前回で「7つの原則」を説明終わったので、次に進んでみましょう。

今回からはJSTQBのシラバスに沿って解説をしていきましょう。なぜ「7つの原則」から始めたかというと、ちょっとかっこいいじゃないですか（笑）かっこいいのもありますが、この原則は何を説明するときにも前提として影響を及ぼします。

今回は「1.1テストの必要性」の「1.1.1ソフトウェアシステムの状況」についてです。

ソフトウェアシステムと世界はもはや切り離す事ができないくらいに融合しています。

銀行や自動車、食品、生産現場でシステムを使用しています。業務中にパソコンを使わない事が今まで以上になくなっていくでしょう。最近はさらにIoTの成長は著しく、生活により浸透していくでしょう。

システムが不都合な動きをすることで社会に影響を与えます。大きく分けて4つあります。

• 経済的な損失
• 時間の浪費
• 信頼の失墜
• 損害や死亡事故

どれも想像つくと思いますが、ひとつずつ見ていきましょう。

・経済的な損失

昨今のシステムはリアルタイムで動く事が多いです。そのためトラブルで発生したシステムで止まる時間は取引が停止または減少するので、その影響は経済的な損失につながります。

・時間の浪費

経済的な損失はそのまま時間という損失を発生させます。システムを修正する時間は、時間の浪費という形で現れます。

・信頼の失墜

品質の低下は信用の失墜という形で現れます。これは製品の競争力の低下につながり、会社のブランドイメージを低下していきます。これはソフトウェアシステムだけではなく、どの業界でも同じだと思います。

・障害や死亡事故

 車を例に話をしましょう。車に自動運転や緊急停止など少し前よりも機能が追加されはじめています。車の大部分をソフトウェアシステムが制御ようになりました。そのソフトウェアが不都合な動作をすると事故が発生する可能性があります。最悪乗客が死亡することもあるでしょう。

しかしながら、ソフトウェアの欠陥は全て取り除くことができません。(7つの原則を参照)

テストを行う際は様々な状況を想定して、ソフトウェアの動作をテストしていく必要があります。現状ではこれをやれば正解というテストはありません。無数に広がるテストから状況に応じたテストを選び抜く必要があります。そのお手伝いができれば嬉しい限りです。

今回は 「1.1テストの必要性」の「1.1.1ソフトウェアシステムの状況」について説明しました。社会に浸透したソフトウェアシステムはどかまで成長するのでしょうね。

 さて、次回は「1.1.2 ソフトウェアの欠陥の原因」です。

それでは！

テストってなんだろう？第7回「バグゼロの落とし穴」

あれから5日。「なそ」です。

定期的な更新を心がけ1週間くらいのサイクルで更新を目指してます。

とりあえず3回目。これで三日坊主になれる。続けることに意義がありますね。

7つの原則も最後。今回は「バグゼロの落とし穴」です。

簡単に説明すると、全部テストしたからって安心しないでねって言うことです。

ここでバグゼロって無理だよって説明してたくせに何を言い出すんだと思ったあなた！

鋭いですね。ここは原則6「テストは条件次第」を使って絞り込んだ状態のテストをすべて確認が終わった状態だと思ってください。

当然すべてのテストが一回で確認終わると思いません。障害として報告され、修正されることがあります。その中で修正した結果、報告したAは修正できたけど、Bが新たに発生しているということがありますよね。いわゆるデグレート、デグレですね。他のテストで確認できればよいのですが、仕様外のものは見つけにくいですね。Aの修正結果で動作が重くなったり、セキュリティに穴を開けてしまったりとなり、他の障害になっては目も当てられません。Aを直したけど、今までできたCができなくなるっていうものありますね。

そうなるとお客さんからのクレームにつながります。結果的に自分達の信用を傷つけてしまうということがあります。

しかし、決められたテストはすべてパスしているという矛盾。修正を行う際は、Aができるだけではなく他の機能に影響しないかという視点でものを見ていく必要があります。

ちょっとめんどくさいと思いますが、これも重要な作業になるでしょう。

そういう意味では、リリース前のテストを決めておくべきでしょう。機能テストとシナリオテストを用意しておけば大丈夫でしょう。そして、できることなら自動化できていると作業が楽になるでしょう（毎度、ほぼおなじテストになるはずので手動でやるよりも断然効率がよいです）

でも、自動化したらOKというわけでなく、原則5の「殺虫剤のパラドックス」に注意してくださいね！

バグゼロと言うのは原則6の「テストは条件次第」で、テストする部分を絞り込んでいます。絶対的に原則2の「全数テストは不可能」がありますので、バグゼロなんてありえないんですよね。原則1の「テストは「欠陥がある」ことしか示せない」ですので、漏れていたら残念ですが見つけられないですね。

なんか原則の復習もできたのでいい感じですね。

それでは、今回は原則7の「バグゼロの落とし穴」でした。

次回からJSTQBの違うものを見ていきましょう。

テストってなんだろう？第6回「テストは条件次第」

あれから1週間。「なそ」です。

定期的な更新を心掛け、1週間というサイクルで再び投稿できたことを人類にとっては小さな投稿だが、「なそ」にとっては大きな投稿です。

だいたい2回目までは続くんです。三日坊主にすらなりきれない残念状態の「なそ」ですが、今回はやるぞー！

というわけで、残すところ7つの原則も2つ。今回は6つ目の「テストは条件次第」です。もう少し具体的に言えば、「前提条件としてプロジェクトが何を優先するか次第で、テストが異なる」ということです。

その答えはすべてのものが有限であるからです。例えばですが、QCDをメインに考えるとわかりやすいでしょうか？　QCDはQuality(品質)、Cost(資金)、Delivery(納期)の3つですね。これも語り始めると時間がかかるので、スルーさせてもらいます。いつか書きたいものです。

Quality(品質)を優先すると、Cost(資金)、Delivery(納期)は大きくなります。

ここでステータスであるQuality(品質)を前回にしなければいけないのは、主に人の命を預かるシステムになります。医療をはじめとするシステムですね。Quality(品質)を優先するので、細部まで見て安全性を高めるのでCost(資金)は高くなり、Delivery(納期)は遅くなります。開発サイクルは長くなる傾向にあるといっても過言ではないでしょう。

では、Delivery(納期)が優先されるのはどういった場合でしょう？これはスマホアプリが該当します。多少のQuality(品質)を落としても早く出すことで市場を押さえることができます。またネットにつながる利点を活かして更新頻度を高め、少しずつQuality(品質)を高めていくことができますが、基本的にDelivery(納期)が優先されると思います。そうなるとテストできる範囲が狭くなるので、当然Quality(品質)は下がります。

しかし、Delivery(納期)が早くなる ≠ Cost(資金)が安いは同義ではないです。メンバーの生産性が高い場合結果的に安くなることはありますが、大人数で開発を行う場合、Cost(資金)は高くなるでしょう。

最後にCost(資金)を優先する場合は、そもそもテストするかなって感じがしないでもないですが、スモールスタートを行うことが多いです。機能の全部を開発せずに一部だけ開発して使ってみて少しずつ機能拡張していく。そうすると少ない機能を少しずつテストしていくので、先の2つの条件とはまた違ったテストが必要になると思います。

って、QCDメインで話が進んでるじゃないですか……

たとえにQCDを出した時点でこうなりますよね。いつかじゃなくて今日書くことになるとは！

「前提条件としてプロジェクトが何を優先するか次第で、テストが異なる」ということがわかっていただけたでしょうか？

最後に全部大事という強者な上司に出くわしたときはプロジェクトの失敗を覚悟して大いにぶつかっていくべきだと持論を述べておきます。(最終的には火を噴くはずなので、失敗覚悟でやると大いなる経験をすることができます)

今回は7つの原則の「テストは条件次第」でした。

次回は7つの原則の最後「バグゼロの落とし穴」です。お楽しみに～ノシ