#品質の「見える」化

１．品質の見える化を学ぶメリット

　　現在の開発現場ではほとんどが品質を上げるためにきちんと管理されていますが
　　品質なんてどうでもいいから早く業務を終わらせようという考えの人がチームに
　　いるとすると、気の緩みで大ごとになりかねません。

　　そしてテストケース作成時の考え方としても品質を考えながら限られた時間の中で
　　作業することが求められます。
　　一方で品質管理や品質ってどんなものなのかを教えてから開発現場に新人エンジニアを
　　送る会社は多くはありません。
　　そんな品質ってどんなものかふわっとしているままいざ本番って怖くないでしょうか。

　　「君自分の会社でそんなこと教えてもらえなかったの？」と新人さんが言われてしまうのが
　　もったいないと思います。

　　一番のメリットはやはり実際の開発現場での考え方が身につくこと、
　　より品質を考えたテストケースの作成ができるようになることです。

２．本当に大丈夫??

　　本格的な開発現場において品質向上に取り組む場合、以前私が違う記事にて紹介した４段階での
　　大まかな評価ではおおざっぱすぎて正確な評価とは言えません。

　　いくらテストケースをたくさん作ったとしても「これですべてのバグを潰せているのか？
　　いや、まだまだテストしつくしていないのでは？」という不安から逃れられないのです。

　　品質について安心するために必要なこと

　　プログラムやクラスの使われ方には全部でどれだけのパターンがあって、テストで試したのは
　　そのうち何パターンか？(＝カバー率)

　　目に見えずに把握しにくい「品質」というものを、何となく高い/低いという表現で議論するのではなく、
　　数値として「見える化」することによって品質の根拠を数字などで表すことができると便利ですね。

　　このように品質に限らず、開発に関する把握しにくい様々な事柄を、主に数値の指標として
　　「見える化」したものを、メトリクスと呼びます。

　　テストによるカバー率もテストカバレッジまたは網羅率と呼ばれるメトリクスの一つです。

２．コードのカバレッジ

　　理想としてはカバー率(要件仕様に対するカバー率)を算出したうえで１００％を目指すことが
　　望ましいのは確かです。

　　しかし実際の開発現場では機械的に計測することが難しいためこの方法はあまり用いられません。

　　その代わりによく用いられるのがコードカバレッジと呼ばれるもので、代表的なものとして
　　命令網羅率と分岐網羅率が知られています。

カバレッジの数え方

命令網羅率の数え方

　　①ソースコードの中の命令文をすべて数える
　　②テストケースを実行した場合に通る命令文を数える
　　③②の数を①の数で割る

分岐網羅率の数え方

　　①フローチャートの中の分岐記号だけに注目する
　　②すべての分岐記号について、流れ出ている各経路の隣に矢印を書く
　　③テストを実行した際に通過した経路の矢印に丸を付ける
　　④③により丸で囲まれた矢印の数を②で書いたすべての矢印の数で割る

４．本課題を学んでみて

　　＜筆者の所感＞

　　品質管理の大切さや、それを考えながら作業することなどは実際の現場に行くと親切に教えてくれる
　　人がいたり、一方でそんなこと知ってて常識でしょという人もいると思います。

　　自分が開発現場で実際にもっと品質が向上できるようなテスト仕様書を書いたりするために
　　今回の課題は必要だったなと感じます。

　　フローチャートなど処理的な設計書や基本設計書を作成する際にもこの資料に書いてあることは
　　応用が利くので実践してみようと考えています。

以上、間違っている知識などございましたらご指摘いただけると幸いです。