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

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

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

勉強×教育×努力

こんにちは!なそです。

 

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

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

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

wikipedia「教育」より引用

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

 

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

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

 

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

 

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

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

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

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

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

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

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

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

 

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

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

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

 

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

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

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

 

最後に

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

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

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

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

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

 

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

次回はJSTQBに戻るかな?

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

 

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

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

JSTQB Foundation Leval

こんにちは!なそです。

 

1週間ぶりです。

 

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

 

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

 

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

 

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

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

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

 

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

 

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

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

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

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

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

 

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

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

 

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

 

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

 

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

 

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

 

 

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

Foundation Leval JSTQB

こんにちは!なそです。

 

1週間ぶりです。

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

 

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

 

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

 

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

 

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

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

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

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

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

 

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

 

・経済的な損失

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

・時間の浪費

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

・信頼の失墜

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

・障害や死亡事故

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

 

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

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

 

 

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

 

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

それでは!

 

 

 

 

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

7つの原則 JSTQB Foundation Leval

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

 

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

 

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

 

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

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

 

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

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

 

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

 

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

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

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

 

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

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

 

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

 

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

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

 

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

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

7つの原則 Foundation Leval JSTQB

あれから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つの原則の最後「バグゼロの落とし穴」です。お楽しみに~ノシ

テストってなんだろう?第5回「殺虫剤のパラドックス」

7つの原則 Foundation Leval JSTQB

あれから5か月ぶりになる「なそ」です。

WACATEに参加したり、テストコンテストに参加したり、お仕事がガチで忙しくなったりで時間をうまく作れなかったのが原因です。

定期的な更新を心がけていきたい。来年の目標ですね。

 

今回は7つの原則の5つ目「殺虫剤のパラドックス」です。

同じテストの繰り返しは、範囲外のバグを見つける可能性を低くしてしまいます。

 

ISTQBのシラバスでは「Pesticide paradox(農薬のパラドックス)」です。

Pesticideで調べると農薬がトップに来ます。insecticideが殺虫剤ですね。

 

同じ農薬(テストケース)を使い続けると、対象の害虫や雑草(バグ)を駆除することができますが、農薬に対応した害虫や雑草(バグ)や、別の場所からやってきた害虫や雑草(バグ)は駆除することができないですよね。

農薬が効かない害虫や雑草(バグ)が、今育てている作物(プログラムやシステム)に影響しないかというとそうではないですよね。対象の害虫や雑草(バグ)には対応できましたが、作物(プログラムやシステム)が全滅しました。なんてことになったら目も当てれないです。そこで、一定期間ごとに見直しを行い、改修していくことで改善していきましょうといいことです。

 

農薬の歴史は古く、農薬の起源は慶長 5 年(1600年)ほど関ヶ原の戦いをしていたころに遡るそうです。そこから400年とちょっと改善を加えながら今の農薬ができていると思います。その他には「虫追い」という祈祷を行っていたそうです。(確かに今でもリリース後に祈ることがあるけど。。。)

 

同じテストケースを使うことで、使ったテストケースと同じ動作は保証できます。しかし、それ以外の使い方をして障害が発生したらなんとも言えないですよね。

同じテストケースを使いまわすことが多いのはシナリオテストでしょうか?製品サイクルがあり、なおかつ機能面では大きく変更がないシステムの場合には使い回しは有効ですね。昨今話題の自動テストでのテストケースも同じように使いまわしが多そうです。

 

どこまでカバーできていて、何がカバーできていないのか。これを機に見直してみてはいかがでしょうか?

 

はて?自動テストはスクリプトしかない?聞こえませんねぇ。そのあたりは今後どうするのがいいのか考えてみたいものです。

 

それでは、今回は7つの原則「殺虫剤のパラドックス」でした。

 

テストってなんだろう? 第4回「欠陥の偏在」

7つの原則 Foundation Leval JSTQB

2日連続の「なそ」です。

ちょっと最近品質ってなんだっけ?状態に舞い戻ってきているので、勉強を兼ねてFLの復習を行ってます!

 

さてはて、7つの原則も4つ目「欠陥の偏在」です! とうとう折り返し地点ですね♪

 

これは、皆々様も経験あるのではないでしょうか?

人によって得意・不得意があるようにプログラミングにも癖が出ます。

プロジェクトや組織によっても癖が出ます。要はQCDのどこに重点を置くかという問題なのでは無いでしょうか?

本当は癖など出さずに万人向けのプログラムを書くべきなのでしょう。しかし、膨大なルールやその時のトレンドを反映したプログラムは現に沢山存在するのです!(言い切ってしまってますが、本当にちゃんとしている所もあります)

そういうことで、バグの発現にはある程度予測できます。できることならチケットをいい感じに分類して傾向のメトリクスをとって見るものいいと思います。

 

プロダクトの特性だったり、プログラム固有の問題。はたまた個人の癖だったりします。それは秘伝のタレとなって、誰も触ることができない魔物と化します。「汝ら、リファクタリングを禁ず」とか看板(コメント)が残っているかも知れません。魔窟に住むドラゴンのごとくですね。勇者が現れるまで、そこには立ち入ることができません。。。

 

とまぁ、そんな壮大なものではないです(笑)

 

たいていの場合、過去の実績を元に知見がある人達をアサインして、属人性を持ってプロジェクトを運営したりしますね。過去のチケットから傾向を洗い出すって言うプロジェクトもあるでしょう。

過去に結合テストで失敗したプロジェクトがあれば、そこに重点を置くのも手です。

そうやっていろんな人の知見を得ながら少しずつ成長するべきだと私は思っています。

それが歴史を積み重ねるということで、老舗のSIerにしかできないことだと思ってました。今も思ってます。だからこそ、あの不甲斐なさには心底がっかりしたんです。

案件数で稼ぐ方法もあります。しかし、これにはその人達の知見をまとめにくいという問題もあります。

 

語り継ぐべきことは、過去の栄光ではなく過去の失敗談です。そういうものほど傾向が似ていたりします。でも、恥ずかしくて人に言いにくいんですよね。これ。。。(笑)

 

欠陥はまんべんなくプログラムに入り込むわけではなく、仕様が甘い所、作りが複雑な所に入り込みます。そういった所を開発者とコミュニケーションをとって、品質は問題無いということを宣言できるテストエンジニアに私はなりたい。

 

それでは、今日はこんなところで。