3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

過去の自分に教えたい、ソフトウェア品質の心得を投稿しよう by QualityForwardAdvent Calendar 2024

Day 23

尊敬する上司に教えてもらった、「ゼロトラスト思考」でつくるテスト仕様書。

Posted at

「品質を上げるため、テストに時間がかかるのは仕方のないことです。一度、時間を気にせず、テスト仕様書を "ゼロトラスト思考" で作成してみてください。」


これは、私がとあるアプリケーション開発の案件で、尊敬する上司から言われた一言です。この言葉が、この体験が、私のテストに対する心構えを根本から変え、以降のアプリ品質を飛躍的に上げるきっかけになりました。


私はテストを舐めていた

正直に言うと、私はテスト仕様書の作成がヘタクソでした。ヘタクソというのはあまり正確でないかもしれません。今では「態度」だったのかもと思います。テストに対して舐めた態度でいるために、たびたび必要なテスト項目が抜けてしまっていました。

テストが抜けてしまう原因はいろいろありますが、一番多いのはこのパターンです。

「内部的にやっていることは同じだから、全部のパターンを網羅しなくてもいいや。」

こう考えてしまうのです。ですので "ただの面倒臭がり" という、もっともっと根本的で、根の深い問題だったのしれません。


例えば、次のような選択項目のテストを作成するとします。
(例の画像は、Outlookのスケジュール設定。)


こういう機能のテスト「土曜日にチェックをつけて保存ボタンをクリック ⇒ その値がデータベースに登録されればよい。」みたいな確認をするとき、土曜日だけうまくいけば他の曜日は確認してくても大丈夫だろうと安易に考えてしまいます。

だってやってることは同じだからです。登録されるデータが違うだけで、いちいち全部確認する必要はないし、時間の無駄だと思ってしまっていました。


もちろんこれは間違いで、月曜日から日曜日の各パターンを確認すべきです。

内部のロジックは同じだとしても、データベースに保存される内容は違うからです。ほかにも、複数件のパターンも網羅したいところですよね。全件指定パターンも欲しいです。


特に自分が開発者自身であるときは、「どの操作をしても、引数をこの関数にブチ込むだけだから同じ同じ。」ということが分かってしまっています。そうすると、その感覚のままテスト仕様書を作成し、パターンを抜かしてしまいました。

意図的に抜いてしまうこともあれば、意図せずに抜けてしまうこともあります。そのたびに、上司から「このパターンはなんでいらないの?」と聞かれ、「ぁ、ぁう内部の処理が同じなので、必要ないと思って…」と言葉を詰まらせてしまうのです。

言葉が詰まってしまう理由も簡単です。「面倒なテストを少なくしたかった。」というサボりたい想い───ようするに後ろめたさがあるからです。


上司はそれを見抜いていました。

そのたびに、私はこう言われたものです。

「俺がお客さんやったら怒ってるかな。手を抜きたいのが透けて見える。」


もちろん、指摘を受けたあとの私は、テスト項目が抜けないように気を付けていました。サボりたいという想いを健全に消し、できるだけパターンは網羅しようと、テスト仕様書の作成しました。

しかし、その想いむなしく、どうしても項目が抜けてしまいます。

気を付けていても。なぜか抜けてしまいますし、指摘されてから「ハッ!」っとしてしまうのです。


そんな指摘が連続で続いたある日、いまの上司がテスト項目を作成するときの「心構え」を教えてくれました。それが、冒頭でもお伝えした「テスト仕様書は "ゼロトラスト思考" で作成せよ!」です。


テストにおける "ゼロトラスト思考" とは

ゼロトラストとは、セキュリティ考え方で、すべての通信やアクセスを一切信頼せず、常に監視し、情報セキュリティを徹底するという考え方です。

簡単に言うと、「決して信頼せず、常に検証せよ」(Never trust, Always verify)を基本理念とし、社内外を問わず、あらゆる通信の安全性を検証することで情報資産を脅威から守る手法です。


では、この「決して信頼せず、常に検証せよ」という考え方をテスト項目の作成に当てはめるとどうなるでしょうか?


  • 全ての入力は疑う:
    ユーザーからの入力は全てが疑わしいものと考え、必ず検証します。どんな入力も、不正や予期せぬ動作を引き起こす可能性があると認識することで、より堅牢なシステムを構築できます。

  • 全てのコンポーネントは疑う:
    システム内の各コンポーネント(モジュール、サービス、関数など)が常に正しく機能するとは限らないと考え、独立してテストを行います。すべてが連携する中で、どこかに弱点があるかもしれないという視点が重要です。

  • 全ての出力は疑う:
    システムからの出力もまた、期待通りの結果を返すかどうかを疑い、必ず検証します。結果が正しいかどうかを確認することで、思わぬバグや誤動作を防ぐことができます。

  • 自分の開発を信用しない:
    自分が書いたコードでも、バグや予期せぬ動作が含まれている可能性があると考え、徹底的にテストを行います。

  • 「やったはずだ」を信用しない:
    「やったはず」「確認したはず」といった仮定は危険です。必ず実際に確認作業を行い、仮定に頼らないようにします。

  • ドキュメンテーションを疑う:
    ドキュメンテーションが常に最新かつ正確であるとは限りません。文書に頼りすぎず、実際の動作を確かめることが必要です。

これが「決して信頼せず、必ず確認せよ」というゼロトラスト思考です。


ひどく極端だと思ったひともいるかもしれません。

「そんなん時間かかり過ぎるし無駄やん(笑)」と。

あるいは「テスト仕様書ってそういうのじゃないやんwww、設計書通りの開発になっているか確認するためのもので、設計書ベースで作成するもんやんwww」でしょうか。

「テストって、何のためにするか知ってる?」みたいなヤジも聞こえてきそうです。


しかし、私はこの教えを受けてから、テスト項目を一つ一つ疑い、細かい部分までチェックするようになりました。結果として、テスト仕様書の品質も向上し、お客様からのフィードバックもポジティブなものが増えたのです。

似たようなことは過去何回も言われていましたが、なかなか改善しませんでした。これは心構えのため、変えることが難しかったのだと思います。理解はしていてもできないという、あの感覚です。

きっと「ゼロトラスト」というキーワードをもらわない限り、ずーっとピンとこず、改善しなかっただろうな、と思っています。そういう理由もあり、皆さんにも「ゼロトラスト思考」というキーワードを共有したかったのです。


私はいまでも、「ゼロトラスト」の考え方をテスト項目の作成に取り入れることで、システムの安全性を高め、未知の脆弱性やバグからシステムを守ることが可能になると信じています。


時間はかかるが効果は絶大

ゼロトラストのアプローチを取り入れたことで、アプリケーションの品質は確実に向上ました。その代わり、私は「テストの人」と言われるようになってしまいました。

これが評価されているのか、揶揄されているのかは皆さんの想像におまかせします。


ですが、どちらなのかは明白です───


このアプローチには時間がかかります。「アプリケーションの品質が向上しました、めでたしめでたし。」では終わる話ではありません。残念ながら現場にそんな工数はありません。

テスト仕様書を作成するにも、実際にテストを行うにも、コストは決して小さくありません。「工数を節約するために、全部のパターンをチェックしなくてもいいか…」と考えたくなることもあるでしょう。


ですので、この話はあくまで「心構え」の話で、じっさいにはこれまでのテスト仕様書をほんの少しだけよくするものになる人が多いと思います。


以上です。

3
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?