news20221022_title

【News】2022年10月2週,3週(ISO/テス友/テスト環境/アジャイル)

皆さん、こんにちは。

ソフトウェアテスト、テスト自動化に関するニュース記事をご紹介していきたいと思います。
今回ご紹介する内容は以下となります。

■記事内リンク

□1.国際標準規格「ISO/IEC/IEEE29119」改訂版対応

□2.「テス友」IT検証技術者認定試験(IVEC)に対応

□3.テスト環境管理

□4.QA テストをアジャイル方法論に統合するには?

□1.国際標準規格「ISO/IEC/IEEE29119」改訂版対応

news20221022_A

https://agest.co.jp/solution/quality_consulting/quality_service/software_test/international_standards/

こちらは、AGEST社が国際標準規格「ISO/IEC/IEEE29119」の改訂に対応した内容となります。
ISOは、一定の年度ごとで改訂が行われます。
従来のISO/IEC/IEEE29119は、2013年版となっており、今回は2021年版の改訂となりました。

AGEST社では、ISO/IEC/IEEE29119の定義内容および2021年改訂の内容が掲載されていました。

◇ISO/IEC/IEEE29119の定義

・Part1:テストにおける概念と擁護
ソフトウェアテストにおける基本概念と規格の利用方法についての説明

・Part2:テストプロセスについて
テストプロセスを「組織のテストプロセス」「テストマネジメントプロセス」「動的テストプロセス」の階層に分けて各プロセスを定義

・Part3:テストドキュメントについて
テストプロセスのアウトプットとなるテストドキュメントのテンプレート

・Part4:テスト技法について
テストケース設計技法のガイドライン

◇ISO/IEC/IEEE29119改訂内容

・従来:ISO/IEC/IEEE29119-2:2013

news20221022_A_01

・改訂:ISO/IEC/IEEE29119-2:2022

news20221022_A_02

(AGEST 出典)

改訂した2021年版では、テスト設計、テストケース仕様書などアウトプットの定義、および新しく「テストモデル」という考え方が採用されているようです。

◇AGESTのテストプロセス

AGEST社では、ISO/IEC/IEEE29119をベースにした標準テストプロセスのテスト支援サービスを組まれているようです。

また、AGESTでは、「ISO/IEC/IEEE29119 ソフトウェアテスト規格の教科書」の高木陽平氏が主体ととなって取り組まれているとのことです。
ソフトウェアテストのISO規格に沿ったテストプロセスとなりますので、標準的なテストプロセスを定めるにはベストなサービスですね。

「ISO/IEC/IEEE29119」の原文は、英語、フランス語のみとなっていますが、以下からアクセスすることができます。

https://www.iso.org/obp/ui/#iso:std:iso-iec-ieee:29119:-1:ed-2:v1:en

ご興味のある方はは、AGEST社のサイトにアクセスされてみてはいかがでしょうか。

TOP

□2.「テス友」IT検証技術者認定試験(IVEC)に対応

news20221022_B

https://prtimes.jp/main/html/rd/p/000000180.000030691.html

こちらは、バルテス社が運営する「テス友」において、IVEC試験対策版がリリースされた内容となります。
従来の「テス友」では、JSTQB Foundation、JCSQE初級の資格試験対策など対応されていました。
今回、10/17からIVEC対策版がリリースされました。

IVEC試験対策では、IVIAが公開しているシラバス内容の学習を目的とした約200種類の問題が公開されているとのことです。

◇テス友について

テス友は、バルテス社が運用しているQbookに会員登録(無料)することで利用することができます。
また、モバイルアプリ向けにも用意されています。

・Web版
https://www.qbook.jp/info-testomo/

・Android版
https://play.google.com/store/apps/details?id=jp.co.vmt.jstqbflapp&hl=ja

・iOS版
https://apps.apple.com/jp/app/id867403516

IVECの直近の資格試験は、2022/11/20(日)となっており、すでに申し込みはできませんが、試験を受けられる方は試験対策の一つとして利用できそうですね。

IVEC試験 2022秋期
https://www.ivia.or.jp/item43/iveca2022

ご興味のある方は、テス友の公式ページにアクセスされてみてはいかがでしょうか。
https://www.qbook.jp/info-testomo/

□3.テスト環境管理

news20221022_C

https://www.softwaretestingnews.co.uk/test-environment-management/

こちらは、「softwaretestingnews.co.uk」に掲載されていた内容となります。
テスト環境管理についてまとめられていましたので、ご紹介したいと思います。

◇はじめに

国際的なエネルギーおよびサービス企業が 1,400 のテスト環境の制御に取り組んだ方法

国際的なエネルギーおよびサービス企業の IT チームは、2,500 万を超える顧客に対して、ビジネスの革新と堅牢なアプリケーションの安定性を継続的に提供する責任を負っています。
彼らは俊敏性と DevOps の効率性を求めて努力していますが、それは非常に困難なエコシステムで行われています。
企業の IT ポートフォリオは非常に複雑で、何千もの可動部分があります。

ソフトウェア プロジェクトには、密結合システム アーキテクチャ、地理的に分散したチーム、カスタマイズされたサードパーティ プロジェクト、および厳しい規制要件が含まれます。
新しいプロジェクトとアプリケーションの包括的なテストには、非常に特殊なテスト環境が必要です。
チームは、非効率性の主な原因として、これらのテスト環境の管理に焦点を合わせました。
毎月、「この変更計画を提供するのに十分なテスト環境がありますか?」という最も基本的な質問にさえ答えるのに苦労していました。

この謙虚な始まりから、彼らはテスト環境を管理するためのさまざまなベスト プラクティスを実装しました。
これは、価値をより迅速に市場に投入するのに役立つだけでなく、アプリケーションの品質により大きな自信を持ってそうしています。
このチームは、コンピューティング DevOps Excellence Award にもノミネートされており、コア レコード システム、何千人ものリモート技術者が使用するフィールド サービス アプリケーション、および何百万人もの顧客向けの Web サイトに DevOps 変換を実装する作業を強調しています。

◇シフトレフトテストの基盤

アプリケーションの規模と重要性を考えると、配信速度のために品質を犠牲にすることはできませんでした。
リリース サイクル タイムの増加は、本番インシデントの削減と共存する必要がありました。
これは、欠陥や機能停止がエンド ユーザーによる新しいツールやサービスの採用を思いとどまらせていたためです。
彼らはエンド ツー エンドのテスト プロセスを分析し、テスト サイクルの後半に欠陥を発見しており、アプリケーションの品質に大きな影響を与えていることに気付きました。

この課題に対処するために、QA チームはシフトレフト テストの基盤を作成したいと考え、各プロジェクトの環境計画に必要な 2 つの重要な要素を概説しました。

・次のテスト環境にコードを渡すために必要なテスト ステージと基準を定義します。
・プロジェクトのキックオフ時にテスト環境のすべての要件を把握して、構成の正確性を確保します。

アプリケーションとコンポーネントのバージョン追跡に加えて、テスト環境の要件にはデータの必要性も含まれる場合があります。
テスト環境を他のプロジェクトや組み込みが必要なサードパーティ コードと共有できる場合です。
キャプチャされると、これらの要件はパイプラインの各ステージで複製されるため、各テスト プラットフォームは目的に適合します。

テスト フェーズに対するガバナンスと構成の安定性の両方を確立することで、コードがより複雑なテスト環境に進むにつれて、複雑なトリアージ シナリオを減らすことができました。プロジェクトの終わりに向けて QA タイムラインが常に圧縮されていたため、これは特に重要でした。


◇多段階テスト戦略

チームは、デリバリー パイプラインの基盤となる多段階テスト戦略を作成しました。

ステージ 1:
機能テスト: 新しいコードの欠陥をデリバリー パイプラインのできるだけ早い段階で分離するために、機能テストはローカライズされた環境で実行され、他のプロジェクトに対するチェックは行われません。

ステージ 2:
回帰テスト: 新しいコードが本番ベースラインに組み込まれます。
テスト チームは初期段階で環境を共有し、相互にテストできます。

ステージ 3:
パフォーマンス テスト: 回帰の問題が解決されると、システム全体のストレス テストと共に、新しいコードのパフォーマンスがストレス テストされます。

ステージ 4:
最終検査です。

ステージ 5:
LIVEに移行します。


◇異種テスト環境の管理

彼らの密結合アーキテクチャは、SAP を中心に構成されています。
非コア アプリケーションには、現場技術者向けのさまざまなリモート サービス (メーターやホーム メーターの検査などの設置) と、家庭および企業の顧客向けの Web サイト アプリが含まれます。

SAP はクラウドに展開された唯一のアプリケーションであり、残りのアプリはオンプレミスの VM とベア メタル インスタンスに配置されています。
本番環境にリリースされたコードは SAP のゴールデン コピーに組み込まれ、それらの変更はすべてのテスト環境にフィードバックされ、常に本番環境に合わせられます。
さらに、Environment Data Services グループは、テスト環境に適切な量のデータベース レコードがあることを保証します。
ベースラインとして、SAP 環境にはデフォルトで 5000 のアカウントがあり、プロジェクトでより多くのデータまたは異なるデータが必要な場合、このチームは適切な量および/またはタイプのレコードを作成します。


◇原価管理

1,400 を超えるテスト環境と約 2,000 のコンポーネントがあるため、コストの抑制は常に懸念事項です。
SAP インスタンスのスピンアップとスピンダウンは、過去の使用率と消費率に基づいています。
この需要ベースの展開モデルは、環境を効率的に共有できるプロジェクト、または不要な料金を回避するためにスピンダウンできる環境を特定することで、費用を節約するのに役立ちます。
クラウドベースの SAP 環境の以前の使用状況レポートを評価することで、クラウド ベンダーから受け取った請求書と照らし合わせて使用​​量を検証し、正しい内部プロジェクトに相互請求することができます。

◇予約と変更リクエストの合理化

Environment Delivery Assurance チームは、毎月 50 件を超えるテスト環境の予約および変更要求を処理します。
スケジュール設定、競合の解決、複雑な構成アイテムとプロジェクト間の依存関係の追跡は、スプレッドシートでは実行できませんでした。
動きの速いテスト チームが、環境が利用可能になるのを待ったり、不適切な構成でテストを実行したりしないようにするために、すべての環境の追跡と管理を統合しました。
Environments Delivery Assurance チームが予約リクエストを受け取ると、利用可能な環境、正しいアプリケーション セット、およびそれぞれの構成を一元的に把握できます。
これらの効率性により時間が節約され、テスト環境の問題を解決しようとするのではなく、アプリケーションのテストに集中することができます。


◇予約と変更リクエストの合理化

Environment Delivery Assurance チームは、毎月 50 件を超えるテスト環境の予約および変更要求を処理します。
スケジュール設定、競合の解決、複雑な構成アイテムとプロジェクト間の依存関係の追跡は、スプレッドシートでは実行できませんでした。
動きの速いテスト チームが、環境が利用可能になるのを待ったり、不適切な構成でテストを実行したりしないようにするために、すべての環境の追跡と管理を統合しました。
Environments Delivery Assurance チームが予約リクエストを受け取ると、利用可能な環境、正しいアプリケーション セット、およびそれぞれの構成を一元的に把握できます。
これらの効率性により時間が節約され、テスト環境の問題を解決しようとするのではなく、アプリケーションのテストに集中することができます。


◇エンドユーザーの旅のテストと…タイムトラベルのためのハードウェアラボ?

確固たるプラクティスが整ったので、彼らはエンド ユーザー ジャーニーをテストするために使用されるハードウェア ラボに注意を向けました。
政府が規制するスマート メーターは、すべてのガスおよび電気の顧客に設置されており、デバイス ファームウェアの品質は、ファームウェアの更新前に顧客の使用シナリオをテストすることによって検証されています。
また、ファームウェア プロジェクトでは研究開発に使用されるデータが生成されるため、新しいバージョンは実際のエンド デバイスでテストする必要があります。

彼らの包括的なテスト スイートは、エンド ユーザー ジャーニー テストのあらゆる顧客シナリオを表しています。
例: ファームウェアが更新された場合、通信ハブは引き続きメーターの読み取り値を受信できますか?
新規顧客は引き続きオンラインで購入できますか?
チームは、将来発生する可能性のあるユーザー ジャーニーを検証するために、「タイム トラベル」シナリオと呼ばれるものも実装しました。

例:
法人顧客の契約に変更があった場合でも、請求は正確ですか?
新しいファームウェアは顧客の喪失をサポートしますか?
システム負荷の変化が予想される場合、来年の支払い方法の変更を実行するにはどのくらいの時間がかかりますか?

IT チームは、ハードウェア ラボのスマート メーターと並んで、社内ディスプレイ、通信ハブ、電気メーター、ガス メーター、ファームウェアなど、1200 を超えるアーティファクトを管理して、テスト目的で追跡、割り当て、およびスケジュールを設定します。
現在、構成メタデータは一元化されており、すべてのラボ コンポーネントを正確かつタイムリーにプロビジョニングするための統合ビューを管理者に提供しています。
さらに、ハードウェア ラボでも、IT リリースで利用できるのと同じ監査証跡と変更履歴を利用できます。


◇高品質のコードをより早く提供

1,400 の複雑なテスト環境と大規模なエンド ユーザー ハードウェア ラボの制御に取り組むことは、簡単な仕事ではありませんでした。
適切なプロセスとツールを導入することで、環境管理チームはセンター オブ エクセレンスとなり、組織と効率のモデルとなっています。
さらに、正しく構成されたテスト環境を予定どおりに提供することに自信を持っているため、毎日より高品質のコードをリリースできます。

□4.QA テストをアジャイル方法論に統合するには?

news20221022_D

How To Integrate QA Testing In Agile Methodology?

こちらは、「impactqa.com」に掲載されていた内容となります。
QAのテストをアジャイルに統合する内容が掲載されており、興味深かったのでご紹介致します。

◇はじめに

ソフトウェア業界は、高品質の製品で繁栄しています。そして、すべての成功した製品の背後には、製品がテストを受けない限り休むことのないチームがあります。
品質保証チームは、信頼できる製品でビジネスの信頼性を高める責任があります。
ただし、開発後に製品をテストすると、発売が遅れる可能性があります。
したがって、市場投入までの時間を短縮するには、俊敏性が重要です。

87% の企業が、ソフトウェア ソリューションのテストにアジャイル手法を採用しています。
SLDC (ソフトウェア開発ライフサイクル) の開始時からアジャイル手法を実装することで、企業はバグをしっかりと把握できるため、コードのクリーニングがより効率的になります。
アジャイル方法論がテスト結果を向上させる理由と、QA をアジャイル方法論に統合する方法については、読み続けてください。


◇アジャイル方法論を採用する理由

長い間、開発者とテスターはサイロで作業していました。
その結果、QA チームは、開発者が製品の構築を完了してから作業を開始する必要がありました。
実績はありますが、この方法には重大なリスクが伴います。

テスト チームがバグを特定した場合、開発チームはコードを作り直す必要がありました。
つまり、一方のチームが作業を開始できるのは、もう一方のチームが作業を終えたときだけです。
そのため、プロジェクトのタイムラインが伸びました。
チームは、いつ製品が発売される可能性があるかについて永遠に不確かでした。
では、アジャイル手法はどのように状況を変えてきたのでしょうか? 主な利点の一部を以下に示します。

チームはサイロで作業しなくなりました。
代わりに、彼らは問題や挫折について社内でコミュニケーションを取り、共通の目標に向かって取り組みます。
開発者とテスターが緊密に連携することで、バグはより迅速に解決されます。
したがって、このアプローチにより、製品を遅滞なく発売できます。
製品の発売前にバグが特定されるため、企業は品質の問題について心配する必要がありません。
ただし、ソフトウェア テスト会社は、QA でアジャイル手法を実装するためのベスト プラクティスと手順に精通している必要があります。


◇アジャイル方法論でQAを実装するには?

・プロセスを決定する
チームがアジャイル手法を採用すると、テストと開発が同時に行われます。
開発プロセスは小さなイテレーションに分割されます。
各イテレーションの最後にビルドが送信されると、QA チームが作業を開始します。
QA をアジャイル方法論に統合するための最初のステップは、反復を特定し、ギャップを特定し、テスト ケースを実行することです。
ステージが定義されると、開発チームとテスト チームが協力してソフトウェア ソリューションを構築します。

プロセスを定義するとき、企業はビルドとフィードバックが開発チームとテスト チームの間でシームレスに移動することを確認する必要があります。
これにより、2 つのチームがビルドをできるだけ早く完成させ、結果を向上させることができます。

・ユーザーを知る
ソフトウェア ソリューションのエンド ユーザーは誰ですか? ターゲット市場を定義し、そのペルソナを特定し、イメージを構築し、ユース ケースをテストすることが不可欠です。
事前に決められたターゲット グループに対してテストを計画することは、焦点を絞ったアプローチの開発に役立ちます。

・リスクを分析する
企業は、新しい方法論で QA チームを立ち上げる際に、いくつかのリスクに直面する可能性があります。
したがって、リスクを特定し、それらを分析して軽減することが重要です。

たとえば、チームの最終目標は、バグのない製品を作成することです。
ただし、徹底的な QA チェックにもかかわらず、1 つまたは複数のバグが見過ごされる場合があります。
その結果、チームは考えられるさまざまなバグを理解し、評価する必要があります。
この理解は、目に見えないバグのリスクを軽減するのに役立ちます。
さらに、開発中の問題を回避するのにも役立ちます。

結局のところ、QA チームの仕事はアプリケーションの起動で終わりではありません。
彼らは、より良いエクスペリエンスのために、問題の解決とバグのパッチ適用に引き続き取り組んでいきます。

・テストを自動化する
チームが自動化を正しい方法論と統合して、テストの品質を向上させれば、助けになるでしょう。
手動のツールや手法が必要なテストもいくつかありますが、自動化できるテストもいくつかあります。
回帰テストは、QA の中で最も退屈で時間のかかる側面です。
チームメンバーがソフトウェアのテストに多くの時間を費やさないようにするために、特定の反復が自動化されていると助かります。
テスト ケースを生成するツールを使用して、チームは最も重要なテストに集中できます。

テスト自動化 ソリューションは、バグの特定と解決を加速するのに役立ちます。
ユーザーがテストを再現できない変数やケースが多すぎる場合は、手動テストを選択する必要があります。

・初期のテストの勝利
説明したように、SLDC の開始時に QA を実装することは、必須事項の 1 つです。
アジャイル テストの会社またはプロバイダーは、開発者がプロ​​ジェクトの最初のフェーズにコミットしたらすぐに作業を開始する必要があります。これにより、バグがすぐに削除されます。
チームが小規模な反復をテストすると、コードのクリーニングと品質の維持が容易になります。

ただし、早期にテストすることが唯一の解決策ではありません。
テストはできるだけ頻繁に行う必要があります。開発者が 2 つのビルドをコミットした場合、テスト チームは相互関係をテストしてスムーズな結果を保証します。
この機敏性により、新しい機能が導入されるとすぐにテストできます。
問題を解決し、リスクを軽減することで、時間とお金を節約することさえできます。

・ソリッドホワイトボックステスト方法
QA をアジャイル手法と統合する場合は、テスト チームが潜在的な問題と結果を把握していることを確認してください。
計画は、彼らがリスクを判断し、解決策を容易に認識するのに役立ちます。
たとえば、彼らは判断を曇らせる可能性のある問題を予測し、さまざまなテスト シナリオと潜在的な結果を認識していたでしょう。
したがって、オープンで知識豊富な心でテストを行うと、エラーを特定して解決するのに役立ちます。

アジャイル手法の実装の背後にある考え方は、すべての部門が緊密に連携できるようにすることです。
ホワイト ボックス テストはエラー状態を予測し、チームがさまざまなシナリオを特定するのに役立つため、企業はホワイト ボックス テストを選択する必要があります。

・まとめ
従来の方法論からアジャイルへの移行だけが変革を保証するものではありません。
企業は考え方を変え、変化を実装するための明確なアプローチを採用し、より合理化する必要があります。
したがって、専門のアジャイル テスト会社と提携して、 QA をテスト プロセスに統合することが不可欠です。

これらは、統合を段階的に管理するのに役立ちます。

□最後に

今回は、以上のニュースを取り上げてみました。
次週も、ソフトウェアテスト、テスト自動化に関するニュースをご紹介したいと思います。
最後まで見て頂き、ありがとうございました。

この記事が気に入ったら
いいね ! しよう

Twitter で
news20221022_title
最新情報をチェックしよう!