【News】9月4週のニュース(単体テスト,ソフトウェア品質管理研究会,パフォーマンステスト,セキュリティテスト)

皆さん、こんにちは。
今週もソフトウェアテスト、テスト自動化に関するニュース記事をご紹介していきたいと思います。
今回は国内ニュース2記事、海外ニュース2記事をご紹介回したいと思います。

■記事内リンク

「国内ニュース」
・単体テストとは何か、なぜ必要なのか
・ソフトウェア品質管理研究会 第3回特別講義

「海外ニュース」
・パフォーマンステストを最新化する：より良いアプリのための6つのヒント
・DevSecOpsとハイブリッドクラウド：セキュリティチェックリストの4つの項目

■国内ニュース

□ 単体テストとは何か、なぜ必要なのか

https://monoist.atmarkit.co.jp/mn/articles/2109/21/news001.html
https://monoist.atmarkit.co.jp/mn/articles/2109/22/news001.html

こちらの記事は、「monoist.atmarkit.co.jp」に掲載された内容となっています。
「単体テスト」の必要性について、前半・後半に分けて明記されています。
またこちらは、自動車のシステム、ソフトウェアの観点から記載されており、ISO26262の「機能安全」に関する内容も含まれて掲載されています。

◇前半

前半では、主に以下内容について述べられています。

・「単体テスト」と「機能安全」について

車載系の開発では、ISO26262の「機能安全」の観点を考慮した開発を行う必要があります。
尚、車載系の開発では、単体テスト工程が工数面や開発ワークフローにより、行われないといったケースがあるようです。

・単体テストを行うべき理由

単体ケースを行う理由としては、後工程のテストフェーズで不具合発生を防ぐ、またその際にかかる工数、コストを減らすことできると述べられています。
こちらでは、単体テスト／結合テスト／システムテストといった各フェーズでの1件当たりのバグコストについて述べられていました。

・単体テストの自動化とその自動化を継続的に行うCI（継続的インテグレーション）について

単体テストの自動化については、Googleのソフトウェア開発の例を元に述べられていました。
また、自動化は単体テストだけでなく、回帰テストも自動化し、なるべく手戻りを発生しないCI方式についても述べられています。

◇後半

後半の記事では、最近の開発手法、および単体テスト手法を中心に述べられていました。

・ソフトウェアの品質管理（アジャイル、DevOps開発）

自動車業界では、ウォーターフォール型の開発がまだ一般的なようです。
自動車業界は、今後テスラのような電気自動車が増加し、パーツ数も少なくなるため、開発サイクルも短期的になってくると思います。
上記のような場合も含め、開発（Development）と運用(Operations)の協調が必要なってくると思います。

・単体テスト手法（ブラックボックス、ホワイトボックス、同値分割、境界値分析、カバレッジ）

こちらでは、単体テストというよりは、テスト手法の概要や具体例などが述べられていました。
カバレッジのステートメント、ブランチ、コンディション、MC/DCカバレッジといった内容は、解説図もあり、わかりやすい内容となっていました。

単体テストについてフォーカスされた国内記事で興味深かったので、ご紹介させていただきました。

□ソフトウェア品質管理研究会 第3回特別講義

http://www.juse.or.jp/sqip/workshop/lecture/index.html#kougi3
こちらは、「juse.or.jp」に掲載された内容で、日科技連が運用する「SQiP」に第3回の特別講義が掲載されました。
こちらのサイトでは、JSTQBやJCSQEといった資格試験の申込みの他、ソフトウェアテスト、品質等に関するイベント、セミナーが定期的に掲載されています。
今回は、3回目となる特別講義が10/8(金)に掲載されていましたので、ご紹介したいと思います。

こちらの特別講義は、有料となっていますが、定期的に開催されています。
ご興味のある方は、「SQiP」のページにアクセスしてみてはいかがでしょうか。
http://www.juse.or.jp/sqip/workshop/lecture/index.html

■海外ニュース

□パフォーマンステストを最新化する：より良いアプリのための6つのヒント

https://techbeacon.com/app-dev-testing/modernize-your-performance-testing-6-tips-better-apps

こちらの記事は、「techbeacon.com」に掲載されていた内容となります。
パフォーマンステストにフォーカスされた内容となっていましたので、ご紹介したいと思います。

◇1.最新のパフォーマンステストは負荷テストを超えています

負荷の自動化を作成し、負荷シナリオを実行し、システムを負荷でスラミング（衝突、衝撃圧力を受ける）することにより、システムのパフォーマンスをテストすることは、組織がパフォーマンステストを採用する必要があるときに通常行うことです。

この慣行により、パフォーマンステスト と負荷テスト は互換性のある用語として誤って見なされてきました。
パフォーマンステストの専門家でさえ、これらを切り替えることがよくあります。
これは、負荷の自動化と負荷テストのみを実行することで、パフォーマンスをテストするという古くからの伝統を永続させます。

パフォーマンステストには、全体として実行する必要のある無数のプラクティスとアクションが含まれます。
負荷テストにはその場所がありますが、最初に、以下で説明する他のタスクを実行する必要があります。

◇2.パフォーマンスについて早めに考える

パフォーマンステストへの従来のアプローチは、パフォーマンス保証に対応していません。
これは、最高のパフォーマンスを確保するために実行する必要のあるすべての可能なタスクを意味します。

良好なパフォーマンスを保証するための最良のプロセスでは、コードの最初の行を記述する前でもタスクを実行する必要があります。
これらのタスクの一部は、パイプライン、監視、インストルメンテーションなど、環境内にメカニズムを作成します。

インフラストラクチャだけでなく、要件の収集段階からエピック、機能、タスクの構築までのすべてのパフォーマンスへの影響を含め、パフォーマンスについて早期に検討してください。
パフォーマンスに関して実装するすべてのものは、何かを完了としてマークする前に合格しなければならないメトリックを定義する必要があります。

チームは、単一スレッドでの応答時間、同時応答、データベース接続/読み取りの数、消費される最大帯域幅などの測定値を定義する必要があります。このパフォーマンスに重点を置くことで、開発者を含むチームは、ソフトウェアの作成前、作成中、作成後にパフォーマンスのエチケットを念頭に置くことができます。

◇3.あなたの開発者はあなたの最初の防衛線です

現代の慣行は、開発者が提供するもののルールを実装することを提案しています。
1つの可能性は、アプリケーションコード内にテレメトリ、インストルメンテーション、単体テスト、およびタイマーを実装し、パフォーマンス測定値を保存することです。
これらのアクションは、開発段階でもパフォーマンスの問題をトリガー、検出、測定するのに役立ち、コードをチェックインする前であっても、問題の特定と報告を容易にします。

◇4.すべてを測定して観察する

開発者がコードを書くとすぐに、チームはパフォーマンス測定を行う必要があります。
これは本番環境まで継続する必要があります。

これらの測定値を取得することは、アプリケーションとそのコンポーネントのパフォーマンスを測定する方法がないことが多かった古い手法からの大幅な変更です。
通常、ソフトウェアがテスト環境または実稼働段階に到達するまで、メカニズムは導入されていませんでした。
場合によっては、本番環境にメトリックすらありませんでした。

それでも、コード内のパフォーマンスメトリックは十分ではありません。
チームは、これらをアプリケーションパフォーマンス管理（APM）システムで補完する必要があります。
古いアプリケーションパフォーマンス監視システムの進化形であるこれらのシステムは、パフォーマンスしきい値を監視および管理するための軽量エージェントと無数の新機能を提供します。

チームは、アプリケーションがソフトウェアライフサイクルで通過するすべての環境にAPMエージェントとインストルメンテーションを実装する必要があります。
コードが開発環境からステージング、テスト、ブランチなどに渡されると、チームはパフォーマンスメトリックと未解決の偏差を継続的に監視および測定できるようになります。

◇5.テストの自動化を作成するときに開発者を関与させる

もう1つの時代遅れの慣習は、コードを本番環境にリリースする直前に、テストのプロセスを自動化しようとすることです。
この問題は、一般にパフォーマンスの自動化とテストの自動化の両方に影響します。
従来、パフォーマンステスターとQAチームは、コード、関数、フロントエンドをリバースエンジニアリングして、そのようなコードのテストを自動化する必要があり、すべてのタスクに大きな影響を与えていました。

ソフトウェアビットが封印されている、コンパイルされている、またはアクセスできないために、テスターがプロセスを自動化できない場合が複数ありました。
そのような場合、ソフトウェアは完全にテストされないままになるか、テスターは手動でテストする必要があります。

これを回避するには、コードを作成する開発者は、 使用されるテスト自動化の性質を考慮し、それらの自動化からコードを簡単にトリガーできるようにする必要があります。
呼び出しメソッドを実装し、テストバックドア、テスト指向API、および自動テストを可能にする任意のメカニズムを作成できます。

これらのメカニズムには複数の利点があります。
一方では、一般的なQAおよび負荷を含むパフォーマンス測定に必要なテスト自動化を作成する方が簡単です。
一方、これは、チームがこれらのテストと検証を継続的で自動化されたプロセスに統合するのに役立ち、コードを本番環境に移行させるためのフラグとしてそれらの結果を受け取ります。

◇6.スケジュール、実行、測定、検証、繰り返し

従来の慣例では、テストの専門家は、パフォーマンステストを、起動前に1回、または変更があった場合は最大で毎年実行される単一の負荷テストと同じように考えていました。
しかし、最近では、ソリューションが頻繁に変更されることが予想されます。
パフォーマンステストの結果は、新しいコードを含めた瞬間、またはスプリントのリリース後に廃止され、1回限りのパフォーマンステストは役に立たない方法になります。

上記のベストプラクティスに従うと、チームはソフトウェア開発ライフサイクルのすべてのステップでパフォーマンスを効率的かつ継続的に測定し、すべてのパフォーマンスの自動化としきい値を任意のプラットフォームに統合する機能を向上させます。

テストは軽量で高度に自動化できるため、チームはテストをスケジュールしたり、コードチェックイン、スケジュールされたジョブ、または外部イベントによってトリガーされるように構成したりできます。
自動化がトリガーされると、チームはパフォーマンス測定値を継続的に受信し、新しいコードを自動的に停止したり、本番環境に到達させたりするしきい値を実装できます。

最後に、自動化は本番環境でも繰り返し可能であり、アラートのしきい値とともに、アプリケーションの任意の層と環境でテストを実行できます。
チームがこれらのしきい値をすべて実装すると、通知と修正トリガーが可能になります。
このようにして、常にすべてを監視する必要がなく、問題のない測定で過負荷になることを回避できます。

◇負荷を超えて考える

パフォーマンステストと保証に関する同じ古い慣行に従うことは、非生産的であるか、アプリケーションに害を及ぼす可能性さえあるため、自動化された負荷テストだけに焦点を移してください。
パフォーマンスのニーズとリスクについて早めに考えてください。
パフォーマンスを可能にするタスクに開発者を参加させます。

コード内のあらゆる場所およびあらゆる環境でパフォーマンスを測定します。
ソリューションを簡単に自動化できます。
また、自動化を常にトリガーし、変更が発生するたびにトリガーできるようにします。

パフォーマンステストについてまとめられており、興味深い内容でしたので、ご紹介させていただきました。

□DevSecOpsとハイブリッドクラウド：セキュリティチェックリストの4つの項目

https://techbeacon.com/security/devsecops-hybrid-cloud-4-items-your-security-checklist

こちらも「techbeacon.com」に掲載されていた内容となります。
DevOpsでのセキュリティチェックに関してまとめられていましたので、ご紹介したいと思います。

◇1.セキュリティをデータに拡張します—どこにいても

多くの点において、今日のセキュリティに関する推奨事項は20年以上前と同じです。
多層防御を実践し、人、プロセス、およびテクノロジに対応するセキュリティへの階層型アプローチを採用します。

機密性、整合性、可用性のCIAトライアドを適用できますが、モデルは、データがオンプレミス、パブリッククラウド、エッジのいずれにあるかに関係なく、データが存在する場所に拡張する必要があります。
具体的には、誰がデータにアクセスできるか、データが信頼でき、変更されていないかどうか、必要なときにデータに適切にアクセスできるかどうかを確認します。

クラウドデータ保護は、クラウドイメージからクラウドホストやクラウドプラットフォームまで、各レイヤーで適用する必要があります。具体的には、この階層化されたデータ保護には次のものが含まれている必要があります。

・画像のスキャン、署名、およびブループリント
・ホストの強化
・プラットフォームの委任慣行

◇2.ソフトウェアサプライチェーンのセキュリティ戦略を決定する

今日の環境では、単一の企業のセキュリティは、ソフトウェアサプライチェーンのセキュリティに依存しています。
特に、クラウドに移行するワークロードの増加と、アプリケーションパイプラインとライフサイクルでより強力な開発者がいます。

残念ながら、エラーの余地は十分にあります。
コードを最初から作成している開発者はほとんどいません。
オープンソースの台頭に伴い、開発者はインターネットから直接リポジトリからコードをダウンロードし、それを組織独自のソフトウェアサプライチェーンに持ち込んでいます。

インターネットからダウンロードされたコードの多くは、精査、テスト、またはキュレートされていません。
たとえば、数年前、暗号通貨をマイニングするように設計された17個の汚染されたDockerコンテナが、発見される前にDockerHubから500万回ダウンロードされました。

オープンソースには多くの利点があります。
実際、それはデジタルトランスフォーメーションの原動力となっています。
ただし、組織は、オープンソースソフトウェアを安全に消費するための安全対策を講じる必要があります。
それは大変な仕事であり、すべての企業がそれに取り組むためのリソースを持っているわけではありません。

◇3. DevSecOps：早い段階でセキュリティとコンプライアンスを統合し、大規模に実行する

組織がより多くのワークロードをクラウドに移動するにつれて、セキュリティはDevSecOpsモデルにさらに依存します。
ほとんどの企業にとって、これは、サイロ化されたチームを使用してすべてを手動で行うことから、コードベースおよびAPIベースのすべてに進化することを意味します。

DevSecOpsの進化には、テクノロジーの変化だけでなく、文化の変化も必要です。
これは確かに小さな偉業ではありませんが、DevSecOpsを最大限に活用することで、組織はセキュリティをアプリケーションのライフサイクルに完全に統合できます。

DevSecOpsの高度な段階では、コンテナーやKubernetesなどのクラウドテクノロジーをセキュリティイネーブラーと見なすことができ、組織が構成管理、パッチ管理、コンプライアンス、ガバナンスなどのプロセスを改善し、さらには異なるチーム間の相互コラボレーションを可能にして改善するのに役立ちます。

◇4.スタッフに必要なツールを教育し、装備する

自動化とポリシー主導のプロセスはセキュリティの鍵ですが、保護に関しては、依然として人々が成功要因です。
従業員とパートナーが継続的に教育を受け、適切な意思決定を行うために必要なツールを備えていることを確認するのは組織の責任です。企業がとることができるアプローチは次のとおりです。

・正式な（および継続的な）セキュリティ教育および認定プログラムを実装する。
・アプリ開発でセキュリティロールを確立する。
・クロストレーニングとクロスコラボレーションの文化を確立する。
・セキュリティツールとリソースをチェックする。
・組織全体に一貫した自動化戦略を実装する。

以上、セキュリティチェックリストの4つの項目についてご紹介いたしました。

セキュリティに関する内容は、正直敷居が高く、理解するのが難しく、時間がかかりますが、一つ一つ学んでいくことが大切と思いますので、私自身、概要レベルからでも覚えていきたいと考えています。

■最後に

今回は、国内ニュース2記事、海外ニュース2記事を取り上げてみました。
次週も、ソフトウェアテスト、テスト自動化に関するニュースをご紹介したいと思います。

最後まで見て頂き、ありがとうございました。

【この1冊でよくわかる】ソフトウェアテストの教科書　［増補改訂 第２版］

詳細はコチラをクリック！

マンガでわかるソフトウェアテスト入門 テスターちゃん Vol.1

詳細はコチラをクリック！