2018年6月28日木曜日

[ソフトウェア品質技術]リリース後に発見されるバグのバグ分析について

プロジェクトのテストフェーズで、開発中のバグが検出されることがあります。それらのバグは、発生原因や再発防止策をバグ分析として実施することが一般的だと思います。

ところが、リリース後に検出されたバグのバグ分析については、プログラマーがあまり意識してやっていないと感じることがあります。これらのバグについても、きちんと分析しないと、次回のプロジェクトのリリース後に同じようなバグを含めた状態でリリースされ、品質を下げるリスクがあります。

バグが発生した直接的な原因を見つける

たとえば、「コーディングミス、仕様理解ミス・・・〇△×処理のif文で□△〇をチェックしていなかった」みたいな原因分析をしたりします。
 →プログラマーはここに注力して、バグ修正に必死で取り組みます。 

本来、検出されるべきだったフェーズはどこか?

発生したバグは、本来、前回のプロジェクトのどの工程で発見されるべきだったかを考える必要があります。
 →プログラマーはここに注力しません。

再発防止策は?

同じようなバグを出さないためには、どのフェーズでどんなことをすればよいか?
 →プログラマーは、当然、ここにも注力しません。

では、なんでやらないのでしょうか?

発生しているバグを修正して、バグ修正確認テストの実施して、修正パッチを早くリリースすることが一番大事だと考えているからだと思います。(推測)

2018年1月24日水曜日

World of Tanks 紳士と悪魔 [WoT]

オンラインゲームで思うこと

オンラインゲームでは、コミュニケーションと思いやりがとても大事。
最低限のマナーを持つようにしたいですね。
  • 助けてもらったら”Thank you”
  • 味方を撃ったら”Sorry”
  • お願いするときは”Please”
経験値やダメージ稼ぎだとどうしても味方を出し抜こうと悪魔的な衝動にかられるけど、味方がトップガンとか取れそうなときは、キルを譲ってあげる心の余裕が欲しいですね。
あとは、味方に期待してもダメなときなダメと諦めること。これが難しい。

言葉が通じないと、容易に悪いパターンの状態に陥るのでご注意を!
みんなでプレイしていることを忘れずに・・・

ゲームで熱くなったときは、これを観ましょう(笑)
Quickybabyさんも年々大人になっている気がします。

紳士:望ましいと思われる

"World of Tanks || Being the Good Guy... - YouTube"



悪魔:望ましくないと思われる

"Indien Panzer EPIC RAGE [RAGEBABY] Thats a must watch :DDDD - YouTube"

2017年12月19日火曜日

QAは製品マニュアルのテストをすべきか?(ドキュメンテーションテスト)[ソフトウェアテスト技術][TC]

我が家のサザナミインコ(2017年6月25日)
皆さん、年末でお忙しいと思いますが、私は咳がとまらず腹筋が痛くて上のインコさんみたいに縮こまっております。

さて、製品ドキュメントの品質は、ライターや仕様を考えたエンジニアに任せておけばよいのでは?と思う人も多いかと思いますが、今回は、QAの製品ドキュメントのテスト(ドキュメンテーションテスト)について考えてみました。※

ソフトウェアの機能が期待どおりに動くことは、当たり前品質の部類ですが、マニュアルの記載動作がソフトウェアの動作と等しく書かれていることも同じように当たり前品質です。

私が働いている日系のエンタープライズ系ソフトウェア業界では、基本機能だけでなく、詳細動作も正しく動くこと、UI周りのリソース文字列やドキュメントの手順の記載も正しい書かれていることが当たり前となっています。とりあえず、目的が達成できていれば満足というユーザーは少ないのが現状かと思います。

前提

テクニカルライターやテストエンジニアのような役割が明確に設定されていない開発組織では、基本的に開発者がソフトウェアに付随するドキュメントを制作することが一般的だと思います。また、制作を外注に出している会社も多くあるでしょう。大規模な組織では、組織内包型のテクニカルライターやQAを持ち、ライターが原稿を書き、その後で開発チームやサポートチームが査読する形をとる場合もあると思います。

ここでは、次のような前提で考えています。
  • 製品ドキュメントは、テクニカルライターが仕様書や実際に動いているものを試しながら書きます
  • ドキュメンテーションテストの目的は、製品に付随されているヘルプやマニュアルの内容が正しく書かれてあり、正しく動作・表示されることを確認すること


    QAもドキュメントのテストをしよう

    QAが、次の理由からドキュメンテーションテストをすべきと考えました。
    • マニュアルも製品の一部である
    • QAは、製品の仕様や手順を詳しく知っている存在である
    • 目につく間違いはちょっとしたことでも品質を下げやすい


      ●マニュアルも製品の一部である

      QAは、製品の品質に対して責任を持つプロフェッショナルです。製品の中には、当然、ソフトウェアに付随するドキュメントも含まれます。また、コンテキストベースのヘルプシステムでは、ソフトウェアの動作に応じてテキストを表示するような仕組みも実装されています。


      ●QAは、製品の仕様や手順を詳しく知っている存在である

      テストケースを作成するには、テスト対象のソフトウェアの動作や手順に熟知しているはずなので、マニュアルの説明や手順が正しいかどうかをチェックするには適任です。


      ●目につく間違いはちょっとしたことでも品質を下げやすい

      ちょっとしたことでも、目につく間違いに対してユーザー(特にシステム運用や管理者の人)は非常にセンシティブです。そういったみっともないものをいつまでも放置したり気が付かなかったりするメーカーは、信頼できないと考える人も多いのでは無いでしょうか?

      メーカー側としても、簡単な記載漏れや記載誤りで低品質と評価されることは避けたいところです。


      具体的にどんな観点でテストをするの?

      QAが具体的にどんなテストを実施しているかは、以前書いた記事「ドキュメンテーションテスト(製品マニュアルのテスト)の観点」を更新しましたので、こちらを読んでみてください。