皆さん、こんにちは。
今週もソフトウェアテスト、テスト自動化に関するニュース記事をご紹介していきたいと思います。
今回は国内、海外ニュース3記事をご紹介回したいと思います。
■記事内リンク
・QUINTEE テスト計画プロセス（プロセス定義書, テスト計画テンプレート）公開
・従業員に権限を与えることで、セキュリティをダイナミクスに変える
・継続的なパフォーマンステストの11のベストプラクティス
■国内ニュース
□QUINTEE テスト計画プロセス（プロセス定義書, テスト計画テンプレート）公開
https://www.qbook.jp/download/1346.html
こちらは、バルテス社が運営するQbookにおいて、ISO/IEC/IEEE 29119の「QUINTEEテスト計画プロセス（プロセス定義書、テスト計画テンプレート）」が公開になった内容となります。
「テスト計画」は、テスト設計、実装、実施、管理といったテスト工程のすべての指針を定めるものです。
「プロセス定義」は、各工程のプロセスに対して、どのような作業を行い、どのような成果物を生成するのかをまとめています。
実務でも利用できる「テスト計画」のドキュメントであると思います。
本ドキュメントは、Qbookのページのダウンロードリンクから個人情報を入力後、ダウンロードすることができます。
私も早速ダウンロードしてみました。
ドキュメントは2部構成となっています。
・QUINTEE-Q-002-01_プロセス定義書_テスト計画プロセス.pdf
・QUINTEE-T-001-01_テンプレート／テスト計画書_1.docx
docxのテスト計画書は、ISO/IEC/IEEE 29119に沿った内容となっており、規格内に必須となっている項目が網羅されいて、標準的な内容にまとまっています。
テスト計画書を一から作って対応すると、それなりに工数もかかります。
私は、今回のテンプレートは、テスト計画書を作成するうえで、作業効率、またISO/IEC/IEEE 29119の内容を理解することにもつながるので、有益なドキュメントであると考えます。
ご興味のある方は、以下ページにアクセスし、「テスト計画プロセス」のドキュメントをダウンロードされてみてはいかがでしょうか。
https://www.qbook.jp/download/1346.html
■海外ニュース
□従業員に権限を与えることで、セキュリティをダイナミクスに変える
https://techbeacon.com/security/empowering-employees-can-change-security-dynamic
こちらは、「techbeacon.com」に掲載されていた内容となります。
個人的に、情報セキュリティに関する海外の情報が気になり、面白そうな内容でしたので、ご紹介したいと思います。
◇初めに
情報セキュリティの専門家は長い間、エンドユーザーをサイバーセキュリティチェーンの中で最も弱いリンクと見なしてきましたが、それは変わりつつあります。
セキュリティの最も脆弱な点として、人間が機械よりも多くのエラーを犯すという単純な事実から生じています。
さらに、必須のトレーニングとベストプラクティスの継続的なリマインダーにもかかわらず、一部のユーザーが間違ったことを行うと想定することがよくあります。
しかし、テクノロジーが進化し、サービスとしてのソフトウェアアプリケーションが現代の作業環境で一般的になるにつれて、多くの組織でエンドユーザーは弱点ではなく強みになりました。
これがどのように起こったかを見てみましょう。
◇バランスの取れたサイバーセキュリティ文化
継続的な認識プロセスを通じてユーザーを関与させることによって、強力なセキュリティ文化を構築する組織は、強固な障壁を作成します。
ユーザーは、セキュリティを所有できるように、アプリケーションに伴うリスクを可視化するツールを提供する必要があります。
従業員にセキュリティツールを提供することで、彼らは傍観者ではなく、積極的な防御メンバーになります。
彼らは、問題の解決、脆弱性の特定、または異常な動作の共有に関与するようになり、組織のセキュリティ体制を改善します。
目標は、従業員が使用するアプリケーションについて意思決定できるようにすることです。
彼らは使用するアプリのビジネスコンテキストと、これらのアプリが彼らの仕事をより良くするのをどのように助けることができるかを知っているので、それは理にかなっています。
従業員を関与させることにより、組織はコラボレーションを改善し、セキュリティを合理化します。
従業員は、忙しくて人員が不足しているセキュリティチームに追加のサポートを提供するのに役立ちます。
◇セキュリティチームが主導権を握る
これは、エンドユーザーが情報セキュリティチームを完全に置き換えることができるということではありません。
セキュリティチームは、余分な手を歓迎しながら、SaaSセキュリティの完全な可視性と制御を維持する必要があります。
この2つは連携して機能し、組織全体の一般的なセキュリティ負荷のバランスをとる必要があります。
セキュリティリーダーは決定的なリーダーシップの役割を果たすことができ、従業員は目と耳の役割を果たすことができます。
ビジネスリーダーは、セキュリティプロセスに従業員をもっと関与させることを、セキュリティチームにとって冗長であると見なすべきではありません。
セキュリティリーダーは、組織の全体的なセキュリティの制御を失うため、この文化の変化を見るべきではありません。
これは、セキュリティプロセスの進化です。
組織が直面している脅威は増え続けています。
より多くのSaaSアプリケーションは、ビジネスをより効率的にし、ネットワークの攻撃対象領域を増やし続けます。
コミュニケーションツールがプロジェクト管理プラットフォームとリンクすることは珍しくありません。
プロジェクト管理プラットフォームは、計時アプリケーションや顧客リソース管理ソリューションとペアになっています。
この相互接続性により、ハッカーにとって多くのエントリポイントが作成されます。
中に入ると、ハッカーはこれらのネットワークを使用して、必要なデータやリソースに移動できます。
◇世界が進化するにつれて準備する
組織は、従業員が仕事をするためにSaaSツールに依存するようになりました。
これらのツールは生産性の向上に役立ちますが、企業の攻撃対象領域も増加させます。
リモートワークがより一般的になり、今日の企業文化に浸透するにつれて、これらのアプリケーションを保護する必要性は高まるばかりです。
セキュリティチームは、これらのツールとそれらを使用する人々を可視化する必要があります。
これは、従業員に力を与えることが真の価値を提供できる場所です。
従業員はリスクを理解する必要がありますが、異常な行動を特定する能力も備えている必要があります。
これらの従業員がサイバー脅威との戦いで同盟を結ぶことを可能にすることは、無制限の価値を提供することができます。
課題は、トレーニングや追加の責任に煩わされることなく、潜在的な攻撃を特定するために従業員が強化されていると感じる方法で従業員と関わりを持つ方法を見つけることです。
最初の努力をするだけで、成功の雪玉効果を生み出すことができます。
◇変化する未来
脅威の状況が変化するにつれて、情報セキュリティリーダーが従業員のトレーニングにどのように取り組むべきかが変化します。
従来、セキュリティチームは、単純なミスや不注意なミスをしないように求める従業員のトレーニングを推進してきました。
しかし、従業員に適切なSaaSセキュリティツールを提供することで、セキュリティチームは同僚を手ごわい防御力に変えることができます。
この追加の責任は、従業員をセキュリティ担当者にすることではありません。彼らには独自の役割があります。
それは、従業員が会社のセキュリティとパフォーマンスに投資できるようにすることです。
間違いを犯さないことを望んでいる人よりも、資産である方が良いです。
多くの従業員がこの挑戦を心に留めます。
□継続的なパフォーマンステストの11のベストプラクティス
https://www.qamentor.com/11-best-practices-for-continuous-performance-testing/
こちらは、「qamentor.com」に掲載されていた内容となります。
「qamentor.com」は、海外のテストベンダーです。
海外のパフォーマンステストについて知れると思いますので、有益な情報と思いますのでご紹介したいと思います。
尚、国内では先月、JSTQBにおいて性能テストのシラバスが公開されました。
性能テスト、パフォーマンスに関することは、今後のソフトウェアにおいて、重要なポイントになってくると考えられます。
性能テストに関する情報は、国内に限らず、海外の情報もキャッチアップし、習得していきたいと思います。
◇初めに
一流の製品を開発するには、開発チームが継続的なパフォーマンステストを実行する必要があります。
これを使用すると、主要な機能バグだけでなく、検出が困難な負荷処理やパフォーマンスのバグもすばやく特定できるためです。
継続的なパフォーマンステストを実装する準備ができている場合は、次の11のベストプラクティスを知っておくと役立ちます。
◇11のベストプラクティス
1.パフォーマンスSLA(サービス品質保証)に焦点を当てる：
テストの目的でアプリケーションにコードを導入しても、コードがバラバラになったり、SLAを下回ったりしてはなりません。
これが意味するのは、パフォーマンスSLAをすべての反復の受け入れテストとして使用する必要があるということです。
したがって、このような場合のパフォーマンスの問題はアプリケーションの特定の部分に限定されるため、コード全体のごく一部にのみ影響する反復に加えられた変更は許容されます。
ただし、アプリケーション全体をカバーする一般的なSLAの場合、制約を壊すことなく「完了」の名目上の定義を満たしているかどうかを確認するために、反復ごとに調査される制約のより広範なリストを追加する必要があります。
2.テスト駆動アプローチを採用する：
プロジェクト全体を有利に開始するには、製品機能とテストスクリプトを同時に作成する必要があります。
これにより、ソフトウェアに変更が加えられた場合に、テスターがテストスクリプトを再作成または改訂する必要がなくなります。
3.開発者とテスターは緊密に連携する：
テスターは開発者と緊密に連携して、現在コーディングされているソフトウェアまたはアプリケーションが最終的にどのようにテストされるかを理解する必要があります。
開発者はプロジェクトに取り組むときにテスターのように考える必要がありますが、テスターはスクラムのような会議に参加することで開発タスクについて最新の状態を保つ必要があります。
この緊密なコラボレーションにより、スムーズで継続的なテストプロセスが保証されます。
4.ストーリー/シナリオベースのテストケースの開発：
従来の開発モデルとは異なり、最新の開発プロセスでは、ユーザーが詳細な仕様を利用できないことがよくあります。
このような場合、厳密な一連のケースに基づいてテストを考案するのではなく、ストーリーベースまたはシナリオベースのテストを作成する必要があります。
このようなテストを使用すると、テスターは、本質的に文書化されていない可能性のある幅広いテストをカバーできます。
5.動的環境での動的テストの使用：
これまでは、単独のテストスクリプトを使用して複数のコンピューティングシナリオをテストできました。
ただし、今日の急速に変化する環境では、テストも動的である必要があります。
そのため、すべての仮想ハードウェア、コンピューティングアセット、およびアプリケーションがソフトウェアとして表される、コードアプローチとしてのインフラストラクチャが普及しています。
満たす必要のある現時点での要件に基づいて、それに応じてプログラムすることができます。
したがって、会社のITスタッフはスクリプトを開発し、スクリプトはテストを実行するために必要な仮想環境を作成および構成します。
6.テスト自動化の使用の増加：
ほとんどの場合、自動化はまだ単体テストの初期段階に限定されています。
ただし、特に後の段階では、展開プロセス全体を通して適用する必要があります。
これを実現するための最善の方法は、個別のソフトウェアサービス/コンポーネントにカプセル化できるテストスクリプトを作成することです。
このスクリプトは、さまざまな状況で必要が生じたときに、比較的不可知論的なスタイルで使用できます。
7.アプリケーションパフォーマンス監視ツールの使用の増加：
APMツールは、今日のいくつかのテストプロセスの重要なコンポーネントとして使用されています。右シフトのパフォーマンス監視を継続するには、このようなツールをますます使用する必要があります。
8.ビルドサーバーを使用して定期的なテストを開始する：
ビルドごとに、定期的なテストの中でパフォーマンステストを機能させる必要があります。
これは、ビルドサーバーを介してテストを開始し、ビルドツール内で生成されたテスト結果を含めることで実現できます。
このようにして、ビルドを開始した人は結果を確認し、そのビルドで行われた変更を知ることができます。
これは、発生するパフォーマンスの問題（ある場合）を修正することを意味します。
9.CI、スプリント後、およびナイトリービルドのテストの適切な計画：
ナイトリービルド、CI（継続的インテグレーション）ビルド、およびスプリント後のビルドのテストは大幅に異なる可能性があります。
また、スプリント中に行われたすべての変更に対して、1日に行われた単独の変更との違いが生じる可能性があります。
したがって、このようなビルドのパフォーマンステストは小規模で開始し、利用可能な内部負荷を使用する必要があります。
たとえば、内部負荷ジェネレーターによって生成されるアプリケーションの一般的な負荷を使用することで、最も一般的なシナリオをカバーする小さなパフォーマンステストを最速で実行できます。
CIビルドのテストは、ビルドで行われた変更がシステムにどのように影響したかを確認できるように、迅速に実行する必要があります。
CIを開始した開発者は、これらの結果をできるだけ早く確認して、正しい方法で活用されるようにする必要があります。
10.テスト資産の転用：
これは、継続的なパフォーマンステストの領域でより高い効率をもたらすのに役立ちます。
たとえば、最近の多くの企業はAIを使用して運用システムのログを調べ、最も呼び出されるユーザーパスに接続されているURLを特定しています。
次のステップでは、この識別を活用する自動化を使用して、これらのパスにテストの優先順位を付けます。
いくつかの企業は、展開パイプラインの後の段階で、テストターゲットに対して機能資産を転用しています。これらの企業は、自動化によって得られた最新の技術、知識、専門知識を活用することで、テストのオーバーヘッドを削減し、効率の向上への道を開いています。
11.モッキングを選択する：
コンポーネントのテストにモッキングを使用することで、コンポーネントを個別にチェックできます。
このようにして、継続的デリバリーを容易にする高品質のテストを保証できます。
◇まとめ
パフォーマンステストを行っていない場合は、すぐに開始してください。
覚えておいてください
基本的なパフォーマンステストを継続的に実行すると、大きなメリットをもたらすことができます。
■最後に
今回は、以上の国内ニュース、海外ニュースを取り上げてみました。
次週も、ソフトウェアテスト、テスト自動化に関するニュースをご紹介したいと思います。
最後まで見て頂き、ありがとうございました。
【Amazon.co.jp 限定】ISO/IEC/IEEE 29119 ソフトウェアテスト規格の教科書
ソフトウェア品質を高める開発者テスト 改訂版 アジャイル時代の実践的・効率的でスムーズなテストのやり方
