So-net無料ブログ作成

第4回Java研修OB・OG懇親会を開催します [プログラミング言語Java教育]

2年振りにJava研修OB・OG懇親会を開催します。過去の3回の開催記事は以下の通りです。
第4回は、参加資格をJava研修の修了生に限定せず、Go研修の修了生、および現在開講している第25期のJava研修受講生を含めます。

【開催日】 
  7月22日(土)

【場所】
  カフェテリア River South (東京都江東区大島)

【時間】
  • 第1部 15:00〜17:00 技術セッション
  • 第2部 17:00〜18:00 懇親会
【参加資格】
技術セッションでは、「Node.js 日本ユーザーグループ」の会長である古川陽介氏(Java研修第8期修了生)によるNode.jsの紹介を含め、修了生が活躍している企業のサービスや技術の紹介を行ってもらいます(古川さんの最新のインタビュー記事はこちら)。

懇親会は、同じ場所で引き続きビュッフェ形式で開催します。

参加を希望される修了生は、私宛にメールで問い合わせください。登録サイトの情報および詳しい案内を送ります。

ソフトウェア開発組織が持つべきカルチャー(17) [ソフトウェア開発組織が持つべきカルチャー]

コードカバレッジを品質基準としない

API設計の基礎」の3.8節「コードカバレッジと防御的プログラミング」では、次のように述べています。
テストコードによるコードカバレッジは、そのソフトウェアの品質を担保しません。コードカバレッジが100%だから、品質が高いとは限りません。バグがあるコードでも、テストでコードカバレッジを100%にすることはできます。
ある機能を持つモジュールを開発する場合、そのモジュールのAPI設計が重要になります。APIの仕様には機能や使い方はもちろんのこと、不正なパラメータの場合の振る舞いが記述されていなければなりません(参考:「API設計の基礎」)。

そして、テストコードとしては、その仕様を検査するテストを書くことになります。①適切なAPI仕様、②それに基づく適切なテスト、そして実装です。実装がテストに合格したら、コードカバレッジを計測するわけです。コードカバレッジでは、コードの実行割合ではなく、実際に実行されたコードがどの行で、どの行が実行されていないかを見る必要があります。もし、実行されていないコードがあれば、その理由を考えます。テストが不足しているのであればテストを追加しますし、不必要なコードを書いていればコードを削除するかもしれません。あるいは、防御的プログラミングのために実行されないコードなら、そのままにしておくかもしれません。

このような開発では、①の「適切なAPI仕様」が記述されているかが、まずは重要です。私自身は、多くのAPIのレビューをしてきましたが、適切にAPIを定義できないエンジニアが多いです。ソフトウェアの経験年数が浅いためにできない人もいれば、ソフトウェアの経験年数が長くてもできない人もいます。この①ができていなければ、コードカバレッジは無意味です。残念ながら①の品質を静的に解析できるツールはありません。経験を積んだスキルの高いエンジニアにレビューしてもらうしかないのです。

②の「適切なテスト」では、仕様通りであるかに加えて、入力パラメータの組み合わせが網羅されているかも重要です。不正なパラメータの検査、境界値分析、同値分割などを適切に取り入れる必要があります。①がきちんとされてない場合、②のテストは正常なケースだけだったり、テスト範囲が狭かったりします。不適切なテストを実行した結果のコードカバレッジも、再び無意味です。したがって、ソフトウェアエンジニアは、テスト設計に関する技法もきちんと学ぶ必要があります。

コードカバレッジの数値が、ソフトウェアの品質を担保するわけではありません。しかし、①と②は静的に測定するのが困難なので、コードカバレッジの数値を単体テストの品質基準にしてしまっているソフトウェア開発組織が多くあるのではないでしょうか。たとえば、80パーセント以上のコードカバレッジをもって単体テストを完了とするとかです。そして、その数値だけが一人歩きを始めます。つまり、開発者や組織が、その数値をクリアするという視点だけで活動してしまうのです。極端な場合には、ソースコードを解析して、高いコードカバレッジとなるテストコードを生成する有償ツールを使って目標値を達成することまで行われたりします(もちろん、品質は向上しません)。結果として、①の「適切なAPI」を定義できなくて、②の「適切なテスト」を設計できないソフトウェアエンジニアを大量生産してしまいます。

残念ながら、コードカバレッジの数値目標を長年追っているようなソフトウェア開発組織では、①や②をきちんと行えるソフトウェアエンジニアが少なく、あるいはいなかったりして、①や②をきちんとレビューするという品質向上の活動ができなくなったりしています。