ソフトウェア開発者がテスト技術の資格「JSTQB」のテキストを読んで感じたこと

テスト技術についての資格である「JSTQB認定テスト技術者資格」のテキストを読んだ。読もうと思った理由は後述するが、ソフトウェア開発についての考えに別の光を当ててくれるいい体験になった。

ソフトウェアテスト教科書 JSTQB Foundation 第3版

なぜテストを学ぼうと思ったのか

僕は開発者、プログラマという自己認識をしており、現在の業務の中心はソースコードを書くことだ。また、普段勉強している事柄も、コードの書き方やプログラミング言語についてのものが中心になっている。

しかしながら、今回、テストの勉強をざっとでいいのでしておくべきだと思い立ち、冒頭に掲げた書籍を手に取った。その理由は以下の通りである。

• 現職にはテスト専門の部隊がおらず、開発チームがテストまで行うため、テストの技法を知る必要がある。
• プロジェクトを通じてどのように品質を高めていくを織り込んだ計画を作成する必要があり、テスト計画の考え方を知りたい。
• テスト経験のないメンバーが漏れの多いテスト項目書を作成していたため、共通の理解の基盤が必要と考えた。

上記は、現在のプロジェクトというコンテキストに依存する理由であるが、一般論としても、ソフトウェア開発者として、品質に関わる重要な営みであるテストを学ぶ意味はあると思う。どれだけスピーディに開発をしても、品質が悪くテストで差し戻されるようであれば、結局リードタイムは長くなってしまう。製造業的な言い方をすれば、「歩どまりの悪い」開発となってしまう。

『SHIROBAKO』で井口さんが、「リテイクが見えればいい原画が見える、悪い原画もわかる。」と言っているのと同じで、テストにおいてどのような観点でソフトウェアが見られるかを知っておくことは開発者にとって意味のあることだろう。そのような言説にもちょうど先日接する機会があり、いいタイミングだと思って学ぶことにした。

最近言ってる人居ないから言うと
後の工程のことを考えて作業できないなら半人前
後の工程で一番効果が高い事をするためには後の工程のことを十分に理解してなきゃできない
コード書く事もテストを理解してなきゃいいコード書けないし本当にやりたい事するなら好きなことだけやってたってダメ https://t.co/rASrR2dHq3

— お料理エンジニアわかめ (@namawakame) 2019年2月27日

以下、本を一冊読んで感じたことを述べていく。

制約の中でテストをするということ

この書籍の冒頭の方で、「テストの7原則」というものが挙げられている*1。

• 原則1：テストは「欠陥がある」ことしか示せない
• 原則2：全数テストは不可能
• 原則3：初期テスト
• 原則4：欠陥の偏在
• 原則5：殺虫剤のパラドックス
• 原則6：テストは条件次第
• 原則7：「バグゼロ」の落とし穴

このうち、ハッとさせられたのは、原則2の「全数テストは不可能」である。これは、「ソフトウェアに入力する可能性のある、すべてのパターンをテストする」*2ことが不可能であると主張するものであり、当たり前といえば当たり前の、何ら衝撃を受けるようなものではない。

僕がこの原則に強い印象を受けたのは、この原則に端を発して、書籍全体を貫いているテストというものへの考え方が、自分のテストに対するイメージとは異なるものだったからだ。僕のテストに対するイメージは、バグを無くすためにしらみつぶしで実施するものというものだった。もちろん、全数テストを行うものだ、というまでの極端なイメージではなかったが、決められた件数を実施するまでひたすらやる退屈なものというイメージがあった。

しかしながら、この書籍では、時間やコストの観点から、どのようにテストを効率的に設計・実施するかという観点から書かれている記述が非常に多かった。どのようなテストを実施するのかについても、テストの目的、対象となるソフトウェアの種類に応じて合理的なものを選択するという姿勢が一貫している。「全数テストは不可能」という原則には、テストがそもそも限られた資源の中で実施されるものであり、「制約の中でどのようにテストを行うか」こそがテスト技術の本質なのだということが表現されているように感じた。現実を見据えることなくしてテストを考えることはできないのだ。

「品質」の多様性とOOP

テストは品質と深い関係を有している。僕も、品質という言葉を普段口にすることもあるが、実際のところ「品質」が何を指しているのかは深く考えたことがなかった。「バグがある」や「パフォーマンスが悪い」というのが品質の悪い例であることはわかるから、コードを書く際も左の2点については考えることは多いが、この書籍を読むことで、考慮すべき品質が思っていた以上に多様であることがわかった。

それを教えてくれるのは、書籍中で紹介されているISO/IEC 9126の品質モデルである。これは、非機能テストを実施する際に参照することのできるモデルとして紹介されているものであり、以下のように整理されている*3。

品質特性	品質副特性
機能性	合目的性・正確性・相互運用性・セキュリティ・適合性
信頼性	成熟性・障害許容性・回復性・適合性
使用性	理解性・習得性・運用性・魅力性・適合性
効率性	時間効率性・資源効率性・適合性
保守性	解析性・変更性・安定性・試験性・適合性
移植性	環境適応性・設置性・共存性・置換性・適合性

これを見たときに、「自分は今まで品質というものの一部しか見られていなかった」という思いを持つとともに、ここしばらく興味を持って勉強している事柄の意義を再確認できた気がした。「興味を持って勉強している事柄」というのは、オブジェクト指向のことである。

オブジェクト指向は、拡張性や保守性を持ったソフトウェアを開発するための技術、考え方だと思っている。オブジェクト指向と品質の関係については、オブジェクト指向の泰斗であるバートランド・メイヤーの言葉を引いておきたい。鈍器大著『オブジェクト指向入門』の第1章は「ソフトウェアの品質」であり、以下のような端的な言明で説き起こされている。

工学の目的は品質である。したがって、ソフトウェア工学は、品質の高いソフトウェアの生産を意味する。本書ではソフトウェア製品の品質を飛躍的に高める可能性を持った一連の技法を紹介する。*4

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

メイヤーは、ソフトウェアの品質の「外的品質要因」と「内的品質要因」のうち、オブジェクト指向の技法が内的品質要因を実現するとした上で、あくまで後者は前者の達成のための手段であると述べる。これは忘れてはならない事柄だと思う。拡張性や保守性というのは、後々の開発者にとって問題になるものであり、直接的に顧客に価値をもたらすものではない。それ自体が価値なのではないという意味では、アジャイルもこれに似ており、ややもするとソフトウェア開発者の自己満足の対象となりかねないという危惧を持っている。

上の表に保守性や移植性というものが挙がっていることを、自己満足の免罪符に使うつもりはない。品質特性に含まれているということは、いつでもこれらが重要であるということを意味しない。どのような品質特性を重んじるべきかは、対象となるソフトウェアの性格によって異なるからだ。自分にとって「品質モデル」が啓発的だったのは、普段自分が「開発者」として興味を持っている事柄と、（今までは「開発」ではない営みとして見がちであった）テストで扱われている事柄が地続きであることを確認できたからである。

後工程を考えて開発するということ

当たり前のことではあるが、テストをする際には、要件がわかっていることが重要である。要件を窺い知るための資料は、書籍では「テストベース」という言葉で指示されている。外部のソフトウェアテスト会社にテストを依頼したところ、「仕様がないからテストできません、うちは設計する会社じゃないんですよ」と言われたという笑い話を耳にしたことがあるが、有効なテストを実施するためにはこのテストベースの充実が不可欠である。

テストベースの分析はテスト設計のための重要な作業であるわけだが、書籍では、実際のプロジェクトにおいてはこのテストベースが十分に揃っていない場合が多いから、収集と分析にかかるオーバーヘッドを考慮に入れて計画せよ、と指摘されている*5。ドキュメントが揃っていないと、テストにおいても遅延を引き起こすことになるというわけだ。

これは、現在のプロジェクトにおいても実体験していることであるが、仕様が開発者の頭の中だけにあるような状態では、テスト実施は覚束ない。「テストで見つかればいいや」と考えずに、品質を意識してコードを書くのは当然なされるべきことであるが、「どのような資料があればテストしやすいだろうか」と考えて適切な資料を残すということも重要なのである。後工程のことを考えて開発をするというのは、コードを書くことだけではないのだ。

SHIROBAKO第8話の瀬川さんの言葉「きっと、もう少ししたら、安原さんも普通にできるようになることなんだよ。自分の後の工程のことを考えて書くなんてことは。でも、今はまだわからない、わからないからできない。ちょっとの違いなんだけどねぇ。」だ。

— こまど (@ky_yk_d) 2019年3月1日

おわりに：開発者がテストを学ぶということ

以前のブログ記事で、『エクストリームプログラミング』の一節を紹介した。以下に再び引用する。

ky-yk-d.hatenablog.com

品質部門を別に設置すれば、エンジニアリングにおける品質の重要性が、マーケティングや営業における品質と同等だというメッセージを送ることになる。エンジニアリングで品質に責任を持つ人がいなくなる。すべては他の誰かの責任だ。開発組織のなかにQA部門を設置したとしても、エンジニアリングと品質保証が別々の並行した活動であるというメッセージを送ることになる。品質とエンジニアリングを組織的に分離すれば、品質部門の仕事は建設的なものではなく、懲罰的なものとなってしまう。*6

現在属している会社にも、独立した「品質部門」が存在しており、プロダクトの品質を改善するためのマニュアルやドキュメントのフォーマットを「開発部門」に提供したり、レビューに入ったりしている。自分も「開発部門」の一角に属する身であるわけだが、他の「開発部門」の諸先輩に話を聞いてみると、「品質部門」の取り組みに対して懐疑的な声も聞こえてくる。だからこそ、『エクストリームプログラミング』の上の記述を読んだときは笑ってしまった。

今回、JSTQBのテキストを読んでみて、テストという営みがソフトウェア開発プロジェクトの「テスト工程」以外の部分にも深く関わっているものだということを確認することができた。上では書かなかったが、開発者とのコミュニケーションの重要性や、プロセス全体においてテストチームがボトルネックとならないようにする配慮、テストに関わるリスクに対する考え方など、テストという分野が視野に収めるべき事柄は非常に広い。これは、専門職としてのテスト技術者の重要性を語るものであると同時に、「視野に収められる側」である開発者もまたテストを学ばねばならないということも意味しているのだろう。

エクストリームプログラミング

*1:27頁以下。

*2:28頁。

*3:108頁。

*4:バートランド・メイヤー『オブジェクト指向入門 第2版 原則・コンセプト』2頁。

*5:40頁。

*6:ケント・ベック『エクストリームプログラミング』128頁。