300を超えるライブラリの不具合ゼロを目指す品質管理とは
グレープシティは宮城県に本社を構える日本企業である。国内およびアメリカ・中国・韓国・インドなど海外にも拠点を構えながら、エンジニアの開発を支援する高機能ライブラリを開発・販売。その実績は30年以上にも渡る。
まず村上氏は、同社のライブラリに対するテストや品質管理を行う上で、「我々のライブラリの不具合が、お客さまのソフトウェアの不具合に直結してしまう」ことを、非常に重要視しているポイントだと切り出す。
そして、不具合をゼロに近づける取り組みのキーワードとして「シナリオ至上主義」「オートテストとジレンマ」「育成カリキュラムでつくる”知ってる”QAチーム」を挙げた。今回のレポートでは、大きくこの3つの取り組みについて紹介していきたい。
1. シナリオ至上主義
グレープシティが掲げるテストの最重要項目は「シナリオ」である。国内・海外に関わらず、テスト項目を策定する際の大原則は、「Preparing high-level test scenarios（高度なテストシナリオを用意する）」。社内には必ず掲示してあり、新人が入った際にはまずたたき込まれる重要なルールの一つだ。
テストシナリオとは、ブラックボックステスト技法の一つ。機能要件やビジネス要件が満たされているかどうかを確認するためのテスト項目。ユースケースをベースに考える。テストケースはそのテストシナリオを「どのように実施するのか」を詳細なテスト項目にしたものだと、村上氏はわかりやすく説明する。
例えば、同社のグリッドを表示するライブラリ「FlexGrid」に当てはめると、以下のようになる。業務システムの中でも、顧客のデータを管理するためのUIに使われることが多いため、テストシナリオは「業務システムUI（顧客データ管理）」。これをテストケースに落とし込んでいくと、「大規模なデータ結合のテスト」「状況に応じたフィルタリングやソート」「データ更新を行った際の整合性」と考えることができるわけだ。
2. オートテストとジレンマ
グレープシティが提供するライブラリのテスト項目は、1ライブラリあたり10くらいのものから、1000を超えるものまであり様々だが、平均すると1コントロールあたり約300程度の項目数になる。そこで同社では、オートテストを採用しながら日々の品質管理を行っている。
「オートテストでよく使われるツールであるJenkinsを採用し、テスト環境を構築して運用しています。具体的には、QAチームが自動テストスクリプトを作り、BitbucketやTeamCityを経由して、最終的にテスト用アセンブリが実行できるソリューションのかたちになります。それをJenkinsで管理しているテストのエージェントマシーンに送り、テストを実行。テスト完了後はテストレポートが発行されるという流れです」（村上氏）
このオートテストには、実は理想と実際というものがあると村上氏は続ける。オートテストが完璧かと言うと、そうではないのだ。
まず理想的な状況を挙げてみる。
- ぜんぶ自動テスト
- ボタン 1発
- テスト完了！
上記のように、全てが自動テストで賄えるようになっていて、ボタンを押せば全部のテストが走って、テストが終わる。そんなイメージを持つ人が多いだろう。だが、実際には全てを自動化することはなかなか難しい。なぜなら自動化に向かないテストがあるからだ。例えば、以下のようなテストである。
- 特定の条件下のみをテストすればいい
- 複雑な手順を1回だけテスト（繰り返しが発生しないので、スクリプトを組むより手動のほうが早い）
このようにオートテストで全自動を目指そうとすると、効率化からは遠ざかってしまうジレンマが発生するケースもある。こうしたジレンマにグレープシティでは、3段体制のQAで挑んでいる。
「まず、QAリードがテスト項目の作成をします。テスト項目が出来上がったら、手動テストチームのメンバーにアサインを行います。テスト項目をチェックし、自動テストの方が明らかに効率がいいものがあったら、自動テストチームにアサインする体制を組んでいます」（村上氏）
つまり以下の図のように、手動テストで行うべきもの、自動テストで行うべきものを決めて、並行する形でテストを行い、効率よく品質管理を高めているわけである。
何を自動化するかについては、以下のようなプライオリティがルール化されている。
例えば、テストする箇所が製品の基幹部分であれば、プライオリティ1。製品の重要機能、主要なAPIであれば、プライオリティ2、その他の諸機能であればプライオリティ3、レアなユースケース試験は、プライオリティ4となる。
「プライオリティの優先度は、不具合が発生してしまった場合における製品への影響指数で考えています。影響度が大きいプライオリティ1であれば、できるだけ自動化して人的ミスを排除し、確実に毎回のリリースで実行できるように品質管理を行っています」（村上氏）
QAチーム全員が「プログラミング言語基礎」「製品」「テスト手法」を知ってる人になるためのカリキュラム
3. 育成カリキュラムでつくる「知ってる」QAチーム
QAチームの中に、「製品に詳しい人がいるとテストがはかどる、不具合が見つかる」ことはよくある。エンジニアではないけれど、製品を長く使っているので何でも知ってる人がいると頼りになるものだ。だが、ライブラリのテストを考えた場合に、もう少し考えなければならないところがあると村上氏は言う。
ライブラリの品質管理では、UIの操作を通した機能テストに加えて、プログラムして正常に組み込めるかどうか、その確認も一緒に行う必要がある。
「具体的には、APIの入出力が仕様通りか、ライブラリの挙動はベース言語の作法に沿っているかなど。あるいは連動する技術・フレームワーク上などで動かした場合に、しっかり動作しているかについても、QAの中でやっていかなければなりません」（村上氏）
そのため、ライブラリベンダーのQAチームには、ITスキルと製品知識が求められる。同社では、QAチーム全員が「プログラミング言語基礎」「製品」「テスト手法」を知ってる人になるための育成カリキュラムを作り、実践している。
技術に関する育成カリキュラムであれば、プログラム言語の基礎学習、アプリケーション開発・業務システム開発の実践を通じて理解を深めていく。並行して、製品についての理解を深めるために、製品の存在意義やコンセプトの理解、製品機能の理解、開発プロセスなどを学んでもらう。
技術と製品に対する理解が身についたら、最終的にはテストについて深く学んでいく。
「テストの基礎として、世の中にどのようなテストがあるのか。ファンクショナルシンキングという開発者のように製品を考えるメソッドを最初に学んでいただきます。その基礎が固まったら、テストがどういった場面でどのように効率的に働くのか、チーム内でディスカッションしながら理解をさらに深めてもらいます」（村上氏）
実践的な「シナリオ」の活用、手動と自動化の併用で乗り越える大規模テスト、QAチームの人材育成など、さまざまな観点から知見や事例を語ってくれた村上氏。ぜひ、ソフトウェア開発の品質管理に役立ててほしいとメッセージを伝え、セッションをまとめた。
