Prepareコロナ、Afterコロナ、そしてWithコロナに向けて(6)

Ishijima

もし新型コロナ第ニ波がきて工期短縮・・・
それでもプロジェクトのテスト工程をやりきりたい人へ


The author is Tatsuya Kimura.
Global Innovation Headquarters
Business Solution Div Quality Development Group Manager
I joined CO-WELL in September, 2018


もし、新型コロナ第ニ波がきて工期短縮、でもプロジェクトのテスト工程をやりきらなければならない、しかし何をしたらよいかわからない、、、こんな悩み今抱えているならば、これはあなたのための情報です。きっと、この記事をお読みのあなたはテストや品質に対して意識が高く、責任感がある方でしょう。また、お忙しい方でしょう。そこで、結論からお伝えします。それは、、、

テストをしぼること(しかも品質を落とさず、、、)

です。そのための3ステップをお伝えします。

「え、本当に?」「うそくさくない?」そのように感じましたか?もちろん100%これですべて解決できると言うつもりはありません(そんな魔法の方法があれば私が知りたいし、誰にも話さず独占したいです)ただ、23年ぐらいソフトウェアテストを見てきた経験上、この方法は使えるアイデイアだと信じてます。

また、ソフトウェアテストの国際的な資格ISTQB(日本ではJSTQB)にも書かれているのアイディアでもあります。(詳しく知りたい方はJSTQB Foundationのシラバス p.17「1.3 テストの 7 原則」も参考にしてください)では、さっそく始めましょう!



ステップ1不具合情報を集める

結論からお伝えします。不具合情報を集めて下さい。(当たり前過ぎますか?しかし、後ほどご説明する理由で必要な情報です)では、どのように不具合情報を集めればよいのか?ここでは3つの方法をご紹介します。


1. 市場不具合(商用リリース後発見された不具合)情報を集めるこの情報はもっとも大事な情報です。なぜなら、我々はお客さんの問題を解決するためにサービスを提供しているからです。したがって、お客さんから不具合情報、お困りごとは貴重な情報です。

ここで、もし市場不具合がリストにまとめられているならば、とてもラッキーですね。今すぐその情報を使うことができます。

もし、リストにまとめられていないなら、お客さんへヒアリングする必要があるかもしれません。お客さんに聞きづらいなあ、、、と思うかもしれません。しかし、市場不具合、お客さんの反応ほど貴重な情報はないでしょう。時間をかけて集める価値があります。

注意:お客さんから情報を集める場合、一つだけ注意することがあります。それは、その情報が事実かどうかということです。もし、お客さんが善意でいいことを言ってやろう、、、そう考えて情報を提供していたら、残念ながら、その情報はあまり使えないです。


2. 営業やサポート担当者に話をきいて、不具合情報を集める。

もし、営業部隊やサポート部隊がいるならば、彼らから話を聞いて情報を集めることも有効です。営業やサポート部隊は、我々と同じくらい、もしかしたらそれ以上にお客さまの満足向上のために仕事をしているからです。

また、サポートサイトがあれば、そこにはお客さんの問合せ情報、サポートが回答した情報などが書かれていますね。また、最近ではコールセンターを外注化している場合もあります。例えば、月ごとに不具合情報、お客さんの困ったことをまとめてもらうと、あなたは楽ができます。

このように、営業やサポートにはお客様の悩み、不満などが集まりやすいものです。彼らから話を聞いて、情報を集めることも有効な方法ですので、活用を検討しましょう。

注意:ここでも、集める情報を具体的にする必要があります。なぜなら、二次情報だからです。恥ずかしい思いをしないためにも証拠をおさえましょう。


3. 開発時(単体テスト、結合テスト、システムテストなど)の不具合情報を集めるお客さんから情報があつめられない、営業やサポートからも情報を集められないならば、自分たちで情報を集める必要があります。

市場からの情報、営業やサポートからの情報は集めるだけでも時間がかかります。また、市場からのインプットはリリースされない限り手に入りません。解析するために時間が必要です。更に、もし新型コロナが第ニ波が勃発したら、市場からのインプットは期待できません。

そんなときでも、開発時に集めた不具合情報があれば、すぐにその情報を再利用することができるでしょう。

注意:ここでも集める情報を具体的にする必要があります。なぜなら、開発のバイアス、バグじゃないよね?がかかるからです。このバイアスを取り除くためにも、不具合情報をあつめる「切り口」をあらかじめ決めておくことは有効です。



ステップ2 分析する

ここも結論からお伝えします。パレート図を作り分析します。

実は、この方法は日本で昔から使われています。ソフトウェア会社ではあまり馴染みがないかもしれません。しかし、恐らくハードウェアなどを扱っている会社ではよく使われている方法でしょうか。また、パレート分析は品質管理でよく使われるQC7つの道具の一つです。パレート図は次の3ステップになります。

2-1 機能別に不具合を多い順にヒストグラムを作成する
2-2 不具合数の累積で折れ線グラフを作成する
2-3 パレート図で分析する

なお、エクセルがあれば簡単にパレート図を作成することができます(パレート図の作成方法について詳しいことが知りたいならば、QC7つの道具についてかかれた書籍を参考にするとよいでしょう)

注意:パレート図を作成するとき、不具合数をカウントするときの粒度を工夫する必要があるかもしれません。というのも、分ける粒度が大きすぎると分析しづらいからです。では、どれくらいの粒度がよいのか?ここはやりながら工夫することをオススメします(答えをお伝えできず、ごめんなさい)

弊社の事例
ここで弊社で作成したパレート図の事例を1つご紹介します。これはとある継続案件のパレート図です。

弊社では不具合情報をRedmineで管理しています。その不具合リストを取得して作成しました。不具合分布は前バージョンのシステムテストで報告された不具合情報をパレート図にしたものです。一方コーディングエラー分布は、不具合を生み出した原因のパレート図です。



ソフトウェアテスト

ステップ3 テストする

最後のステップです。結論からいいえば、不具合が潜みそうなところをテストします。

ステップ1で不具合情報を集めました。ステップ2で分析しました。分析の結果、不具合が多く出ている機能、そうではない機能があることがわかりました。この分析で得られた情報をつかいテストします。ここでは2つの方法をご紹介します。

1. 弱点を重点的にテストする
分析結果に基づき弱点をテストします。ここで弱点とは何でしょうか?冒頭でお伝えしたとおり、これまでご紹介した方法は、ソフトウェアテストの7原則の一つ「欠陥(不具合)は偏在する」がベースです。

事例でご紹介したパレート図の通り、欠陥(不具合)が偏在していることがわかります。つまり、そこにプログラムの弱点があるということ。だから、その弱点をさらにつっつくことで、更に不具合を叩き出すということです。

ここで、「すでにテストで不具合を出した機能だからもう不具合はないのでは?」もしあなたがそう思ったならば、残念、間違いです。不具合をだした機能には更に不具合が潜んでいる確率は高いのです。

なぜか?不具合は最終的に人間のあやまった考えや足らない考えからきているからです。だから、不具合をだした機能や弱点を更にテストすることで不具合を見つけることができるというわけです(例えが悪いかもしれませんが、ゴキブリを1匹見つけたら10匹いるはずという考えです。日本人にはわかるかな・・・13年ぐらい前、台湾人にこの話したのですが、キョトンとしてました・・・)

しぼることで見逃しがあるかも?そのように感じたかもしれませんが、正しくしぼることで品質を落とすことなくしぼることができるわけです。

2. エラー推測テストを実施するこの方法も使える方法です。パレート図で得られた情報を見ながら、自分へ問いかけてください。そして、お思いついたことをテストしてみてください。

「ほかは?(プログラムが間違いやすいところはどこか?)」

エラー推測は、よくあるソフトウェアテストの不具合を知っておくと、見つけやすい場合もあります。よくあるソフトウェアテストの不具合はソフトウェアテストの名著「基本から学ぶソフトウェアテストの付録「よくあるソフトウェア不具合」にまとめられています。ちょっと古いですが参考になるでしょう。



テストを賢くしぼる方法

かけあしで、テスト工程をやりきる方法を、3ステップをご紹介しました。テストをしぼること、かしこくしぼる方法やアイディアをお伝えしました。もちろん、工期短縮などと言ったことが起きないことを望みます。あなたが苦境に立つことはのぞみません。しかし、万一そのようなことがきたとしても、プロとして何かひねりださなければならない可能性があります。そのとき、なにかのヒントにでもなれば、うれしいです。

Behind your success

ps
開発・テストの事例はこちら

pagetop