テスト ~面倒だけど大切なこと~

こんにちは。株式会社フィックスポイントのよしだです。

今回は、社内のQA活動の一環として行っているテスト講座についてご紹介します。

講師はエンジニアの @aysuzuki さんが担当しており、演習も取り入れながら全4回で開催しています。

なぜテストが必要なのか?という基本から、実際のテストの進め方、フィックスポイントでのテストについてなど、具体的にお話ししていきます!

はじめに

本題に入る前に、近年のソフトウェアの立ち位置について触れておきます。

ご認識ある方もいらっしゃると思いますが、ソフトウェアはより重要性を増してきています。

電車やバスといった交通系インフラから、金融や医療に至るまで、私たちの生活に関わる多くのものがソフトウェアで制御されています。

しかもそれらは年々複雑になり、規模も大きくなっています。

複雑なソフトウェアによって社会は便利になりましたが、反対にソフトウェアがきちんと動く状態を作り上げるハードルは高くなる一方です。

f:id:aqui_jasmine:20220201125056p:plain

そのため、テストの重要度もあがっています。
作って終わりではダメなのです。

なぜテストをするのか?

前項で述べた前提について、十分理解している方は多いかと思います。

しかし、それでもテストは面倒に感じてしまいませんか?
ダメ出しはするのも、されるのも辛いという印象があるかもしれません。

それではその "ダメ出し" という認識を変えましょう。

そもそも、テストとは「対象のソフトウェアが、その時々でどのようにふるまうかを理解・確認し、関係者と共有するために行う活動」です。

つまり、ダメ出しを行うためにするものではないのです。

理解した結果と実際に確認した動作が異なれば、それはいわゆる「バグ」ですし、目的に適っていない動作をすれば、それは「使いにくさ」と呼ばれるものです。

ただ、それらは発見されるだけではほとんど意味がありません。
発見された脆弱性や予期せぬ動作を、関係者が対処・修正されて初めて意味を成すものなのです。
この時点でテスト=ダメ出しではないことが分かりますね。

もちろん、バグを減らすことは重要です。
しかし、バグがないことはどうやっても証明できないため、「バグをなくすこと」を目的にしてしまうと、延々とテスト沼から抜け出せなくなってしまいます。

f:id:aqui_jasmine:20220201153544p:plain

そのため、「ソフトがどのように動いているのかを理解し、それが期待値とどのくらい近いのか確認・共有する」ことを目的として活動するのが大切です。

そしてテストをしっかりこなした結果、開発は障害で夜起こされることもなく、営業は自信を持ってサービスをお客様に紹介でき、お客様は使いやすく、みんなが幸せな世界になるという訳です。
こんなソフトウェアを目指したいですよね😊

ちなみに、テストをしないとどのようなことが起きるでしょうか。

まず前提としては、何事も早期発見が大事だということです。
その上で、リリース後にバグ等が見つかった場合、様々なものが失われることは想像に難くないですよね。

  • 時間:原因レポートやお客様への謝罪、報告(開発だけでなく営業/経営層の時間も奪われる)
  • 金銭:サービス解約や損害賠償
  • 信用:会社としての信用を失う可能性                         など

特に信用は取り戻すのが大変なため、とても大きな損失になってしまいます。
このようなことを避けるためにも、日頃からテストという活動を通して、品質を維持することが重要になるのです。

テストは計画的に!

さて、実際にテストをする際に必要なのが、テスト計画です。

どの種別のテストをどのレベルでどのくらいやるのか、の計画をたてましょう。

具体的には、自分のテストしたい対象にあったテストを考えます。

例えば、自分だけが使うツールであれば、バグが発生しても自身が困るのみで、自身で直せばいいだけですので、綿密なテストは不要です。
しかし、車であれば多くの人命に関わり、万が一リコールとなれば巨額の損害が発生します。これを防ぐにはきちんと網羅されたテストが必要になるでしょう。

つまり、どんなテストをいつまでにどれくらいやるか、それを考えるのがテスト計画です。

テスト計画に必要な項目は、以下の通りです。

  • テスト対象
    テスト対象が何のために作られたのかを考えます。
    それを元に、テスト対象に必要な品質を明確にします。

  • テストの範囲
    テスト対象となる機能の範囲を明確にしておきます。
    特に連携システムがある場合は要注意です。
    担当範囲を明確にしておきましょう。

  • テスト設計/戦略
    目的を達成するためにどんなテストをどのくらいするのか考えます。(単体・機能・性能・セキュリティなど)
    ツールの選定なども行います。

  • 終了基準
    どうなったらテストを終わっていいのか決めておきましょう。
    基準はピンポイントではなく「許せる範囲」がどの程度か決めておくのがよいです。(スケジュールの都合で早期終了しないといけなくなった場合、どこまで許せるのか決めておくとなあなあにならずに済みます。)

  • スケジュール
    何人でどのくらいの期間やるのかを決めておきましょう。

f:id:aqui_jasmine:20220201153458p:plain

計画についても、もし立てなかった場合の恐ろしい状況について記載します。

  • バグが見つかるかどうかは運任せ
    狙いやあたりがあってテストするわけではないため、バグが見つかるかどうかは分からないです。
  • いつどんな操作を確認したか不明
    再現できないバグは往々にして闇に葬られてしまうためです。
  • 時間が来たらそこで終了
    「テストした」と言われてもそれが十分なのか不十分なのか誰にも判断できません。

このような状況を避けるためにも、きちんと計画を立て、考えた結果についても逐一残しておきましょう。

フィックスポイントでのテスト

最後に、当社フィックスポイントでのテスト方法についてご紹介します!

当社では、QA担当者と開発者が協力してテストを行っています。

各製品にQA担当が付き、製品の品質を管理できるよう活動するイメージです😊

製品テストについては、開発がコードベースの単体と基本的な結合確認をします。
QA担当は、その製品が顧客の問題を解決するのか、製品の真の価値を発揮できる状態なのか(重い・遅い・すぐ落ちる・分かりにくい、などがないか)をメインで見ます。

さらに、開発スピードをできるだけ落とさずにテストができるような工夫もしています。
例えば、自動テストを企画したり、テストだけでなく仕様レビューに参加したりすることで、開発チームと情報共有・役割分担を密にできるよう活動しています。

f:id:aqui_jasmine:20220201162822p:plain

最後に

今回は、テスト講座についてご紹介しました。

改めてテストや計画の重要性に気付けたのではないでしょうか。

フィックスポイントでのQA活動にも興味を持っていただけたら幸いです!




株式会社フィックスポイントでは、一緒に働いてくれるメンバーを募集しています!

詳細は、こちらをご覧ください。