CodeZine(コードジン)

特集ページ一覧

開発者の仕事を増やさずにバグを減らす、かしこいテスト戦略とは?【デブサミ2021】

【18-B-4】ソフトウェア品質を高める開発者テスト

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2021/05/19 11:00

目次

2割の部分に8割以上のバグが潜んでいる

 しかし、単体テストやリファクタリングを増やすといっても、それだけでは作業量が増えてしまうのではないだろうか。

 「ソフトウェア品質の論文を読む限り、全体の2割の部分に8割のバグが潜んでいることが明確になってきています。このなかで、1番バグが潜んでいるところは、よく変更されるところ。2番目は長いファイル。3番は複雑度の高いところです。論文によって2番と3番は入れ替わることがありますが、1番は変わりません。このとき、ファイル単位で単体テスト計画を立てるのが基本です。

 皆さんが上流品質を担保するために単体テストを書くとしたら、よく変更されるファイルのテストを書けば、かなり品質が上がるはずなんですね。ぼくがコンサルやっている限りでも、ほとんどそこからバグが出ます」

2割の部分にバグが潜んでいることは明確になっていて、その1番が、良く変更されるところ

2割の部分にバグが潜んでいることは明確になっていて、その1番が、よく変更されるところ

 では、よく変更されるファイルは、どのように見つければ良いのだろうか。

 「直近でファイルが変更されているというのは、HotSpot値で計算できます。計算式は、検索するとすぐに出てきます。HotSpot値が高くて、複雑度の高いファイルはリファクタリングして、複雑度が低いファイルはコードを再考しましょう、という感じです」

 また、サイズの大きい長いファイルと複雑度の高いコードでも、この手法の効果は高いと説明する。

 「リファクタリングには、いろいろな手法があります。マーティン・ファウラーの本に、いろいろ載っていますし、デザインパターンを見れば、こういうふうに機能分割すればいいと書いてあります。長いファイルには、大きなクラスがよく書いてありますが、ビッグクラスというのはバグの温床なんです。その大きいクラスを二つに分けるだけでバグが減ったりします。

 さらにいうと、複雑度の高いコードって、単体テストがすごく書きにくいんですよね。たとえば、if文のなかにelseがあって、elseのなかにswitch文があるといった場合に、自分の頭のなかで分岐網羅をどのようにやったらいいのか、考えなければならないので。でも、クラスのなかにif文とelse文ひとつくらいだったら、じゃあ4つ書けばいいみたいなことになって、単体テストがすごく書きやすくなります」

アジャイル開発のなかで速さと品質を担保するテスト自動化の考え方

 とはいえ昨今主流になりつつある、アジャイルやスクラムの開発サイクルのなかで、どのようにテストに取り組めばいいのだろか。

 「ウォーターフォールでは、長い開発プロセスのなかで品質を確認するフェーズがありますが、アジャイルやスクラムの時代には、1・2週間のイテレーションやデイリーで品質を担保したいという希望があると思います。そういう短いライフサイクルのなかでテストするには、基本的に自動化する必要があります」

 そして、あまりきつい言い方をしたくはないんですがと前置きしながら、次のような例を説明した。

 「アジャイル開発をやっていても、システム開発の最後の段階で、協力会社にお願いして、システムテストとして1か月いじってもらいましたという組織も無きにしもあらずです。ぼく個人としては、基本的にはデイリーで出荷できるような品質まで上げるというのが、アジャイルなりスクラムなりの品質担保の方法だと理解しています。

 また、UIのところを、ただ単になぞって、自動化しているというケースも多々あります。手動でやっていたテストを自動化するのは、非常に意義のあることです。ただ、もうワンステップ上にいくためには、テストの網羅率で品質を担保したり、チェックインごとにハイスピードで自動テストを実行したりすることも重要だと思います。

 テストに関しても、ただ単に開発者がテストやればいいや、単体テストをやればいいやっていうんじゃなくて、本当はテスト戦略を立てて、スクラムの1・2週間のイテレーションのなかに、機能テストから非機能テストから単体テストからシステムテストまで、入れなきゃいけないんです」

 そして、単体テストの優位性やMVC(Model View Controller)の分離といった考え方などを説明した。さらに、テストスピードを考える例として、次の図を示した。

自動テストのスピードの考え方

自動テストのスピードの考え方

 「この図は、ぼくが日頃から使っている例を表しています。プルリクエストしたら、CircleCIを使って、3分でユニットテストする。Circle CIは、Unitテストを並列化するのは、すごく楽なんですね。その後で、コードの複雑度や網羅率を計測して、すぐにダッシュボードに表示しています。システムテストに関しては、1時間おきくらいに1日8回流せばいいよね、といった具合に、大きい枠のなかでテストを考えています」

 そして、次のように語って講演をしめくくった。

 「ただ、このような内容をいきなり全部やるのでは、大きなステップになってしまいます。今日聞いた内容をやってみようと思った人は、たとえば新規の関数だけでも単体テストを書いて、CI/CDフレームワークに入れてみるといいと思います。

 それから品質分析もやってみて、自分たちがどういうふうにバグを出しているのか調べて。この長いファイルからバグが出ているから、ここの品質を担保してみるみたいなところから、次のステップを考えるのもいいのかなと思います」



  • LINEで送る
  • このエントリーをはてなブックマークに追加

バックナンバー

連載:【デブサミ2021】セッションレポート

もっと読む

著者プロフィール

  • 可知 豊(カチ ユタカ)

    フリーランスのテクニカルライター 興味の対象はオープンソースの日常利用、ライセンス、プログラミング学習など。 著書「知る、読む、使う! オープンソースライセンス」。 https://www.catch.jp

あなたにオススメ

All contents copyright © 2005-2022 Shoeisha Co., Ltd. All rights reserved. ver.1.5