こんにちは。てぃろです。
最近新しいプロジェクトでアプリの品質向上を担当してます。つまりアプリの品質が悪いわけです…。具体的に言うとテスト工程で障害の検出数が非常に多かったので品質を強化したい！というわけです。
調べてみたところ、障害が多発した原因はテストがしっかりできていないからだと思われます。
では、なぜテストがしっかりできていないと言えたのか？それを少し深堀して考えた上で解決策として押さえたい考え方をご紹介したいと思います。
テストとは、期待通りに動作することを確認すること
原因分析する前に、ソフトウェアの品質を高めるために行うテストの本質を考えたいと思います。
ソフトウェアテストの定義はWikipediaにはこうあります。
ソフトウェアテスト (software testing) は、コンピュータのプログラムから仕様にない振舞または欠陥（バグ）を見つけ出す作業のことである。
wikipedia
私はこの言い方は本質を捉えていないと思います。
私の定義は”ソフトウェアテストはソフトウェアが期待通りに動作することを確認すること”です。
言い方だけの問題とも言えますが、私が強調したいのは、テストにはそもそも設計上こう動いてほしいと期待する動作を定義する必要があるということです。
つまりテストを実践するには、次の4つの要素が不可欠なのです。
- 設計書（期待する動作の定義）
- プロダクションコード（テスト対象）
- テストケース（期待する動作を確認するための操作方法と確認ポイント）
- テストコード（テストのために必要なコード）
図でいうとこんなインプット/アウトプットの関係になっています。
つまり、設計書をはじめにつくって、それをもとにプロダクションコード（製品コード）を書く。続いて設計書をもとに作ったテストケースとプロダクションコードからテストコードを作る。
こうして初めてテストが実行可能になります。すべての成果物のもとは設計書であり、設計書が期待する動作を定義しているものなのです。
言い直すと、テストとは設計通りにプロダクションコードが動くことを確かめること、です。
当たり前ですよね。
品質が悪い原因は、正しい設計がよくわからないから
もとの話に戻ります。
そもそも”テストがしっかりできていない”という言葉は抽象的なので、もう少し具体的にしてみます。
- 設計書が作られていない
- テストケースが作られていない
- テストに対するエビデンスがあったりなかったりする
障害が多発して忙しくなると、設計書やテストケースを作るのが疎かになるのはよくあることです。テストケースが適当になるとエビデンスも適当になります。
しかしこれらを疎かにするからより障害が多発してもっと忙しくなってもっと疎かになって…という悪循環になってしまうので、一刻も早くこの悪循環から抜け出す必要があります。
上記の３つの事象は先ほどの図の通り、前後関係があります。
- 設計書が修正されていない（設計が正しくない）
- 設計が正しくないから、テストケースが作れない
- テストケースが作られないから、エビデンスは何を取得すればいいかわからない
ということで、根本原因は設計書を作らないことです。つまり、何が正しい設計なのかわからないから現場からするとテストのやり方がよくわからなくなってしまうのです。
設計書は適度に。確認ポイントは明確に。
じゃあ設計書をめっちゃしっかり書こう！
というのは、現実的ではありません。そもそも品質の悪い炎上寸前のプロジェクトです。設計書を書く余裕がないからこうなっているのです。
だからといって、テストの元になる設計書を諦めてはいけません。必要なのはIPAの定義でいう基本設計レベルの設計書を整備することです。ここで書き方のポイントがあります。
設計書は、各機能がどんな背景のもとどんなことができるのか、を書くだけでOKです。
できること = 期待する動作、というわけです。
では、これでテストできるかというとそんなこともありません。テストをやりはじめると気づきます。
何をもってテストをOKとするのか、がわからない！
そこで必要なのが、確認ポイントです。
期待する動作の中にも、こうであるべきという具体的なポイントがいくらかあるはずです。それを私は確認ポイントと呼んでいます。例えば、以下のようなものがあげられます。
- ポップアップ中の背景は半透明である
- 文言はXXXである
- ログが〇〇〇と出力されている
これらは本来詳細設計から起こすことができるものです。しかし今回詳細設計書はありません。そのため詳細を設計した本人 = 開発者がテストでOKとなるべきポイントとして確認ポイントを書くべきなのです。
それを第三者がいろんなケースで打鍵して問題ないことを確認していく。これが正しいテストです。
まとめ：押さえておきたいのは、確認ポイントを書くこと
炎上寸前のプロジェクトでいかにソフトウェアテストを実践するか、という話をしてきました。
テストを進める上で押さえておきたいポイントは、確認ポイントを書くことです。
それ以外にも大事なポイントを箇条書きでまとめます。
- テストは期待する動作を定義する必要がある
- 期待する動作は、設計書として書く
- 設計は、どんな背景のもとどんなことができるのかを書くこと
- 確認ポイントは、開発者が責任をもって具体的に書く
炎上寸前のプロジェクトでは、これを少しずつやっていくことが大事です。いきなり鎮火はできないので、徐々に消化していくように少しずつ設計書を整備し少しずつ品質を高めていくことを心がけましょう。
最後に注意点です。
設計書に関しては、会社やプロジェクトごとの書き方もあるので本記事でもあまり具体的なことには言及できていませんが、各機能がどんな背景のもとどんなことができるのかを書く必要があるということだけ気を付けてもらえればいいと思います。
