【News】8月2週のニュース(テストアナリストシラバス更新,無料セミナー,自動テスト取組み,継続的テスト,マスキング）

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

■記事内リンク

「国内ニュース」
・JSTQB 「Advanced Level シラバス 日本語版 テストアナリスト v3.1.1 」を公開
・テクバン社、mable社無料セミナー開催

「海外ニュース」
・最初から高度なテスト自動化を組み込む
・継続的テストと自動化の力
・データマスキングの状態：それは不可欠

■国内ニュース

□JSTQB Advanced Level シラバス 日本語版 テストアナリスト v3.1.1 を公開

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

こちらは、JSTQBが8/4に　Advanced Levelシラバス「テストアナリスト ver3.1.1」が公開された内容となります。
最近では、同じタイミングで、Foundation Level Specialistシラバス「モバイルアプリケーションテスト担当者」が新たに公開されました。

【News】8月1週のニュース(JSTQB新シラバス公開,書籍改訂,Webセミナー,機械学習の役割,DevSecOps)

今回のテストアナリストのシラバス更新については、「リリースノート　テストアナリストシラバス」に明記されており、各章において表現の改善等が行われているようです。

シラバスは以下サイトからダウンロードできます。
http://jstqb.jp/syllabus.html#syllabus_advanced_altta

（出典）JSTQB

早速見てみました。
テストアナリストの構成は以下となっていました。

◇テストアナリスト　シラバス構成

1.テストプロセスにおけるテストアナリストのタスク
2.リスクベードテストにおけるテストアナリストのタスク
3.テスト技法
4.ソフトウェア品質特性のテスト
5.レビュー
6.テストツール及び自動化

テストアナリストのシラバスでは、Foundationシラバスで学習した「テスト技法」など、より詳細、特化した内容が明記されていると思います。
「境界値分析」、「デシジョンテーブルテスト」、「状態遷移テスト」他、「クラシフィケーションツリー技法」、Advanced Levelテストマネージャにも表記されています「ペアワイズテストなど詳細に記載されています。

Foundation Levelで学んだテスト技法の他、より詳しく学習したい場合はテストアナリストのシラバスを読むのもいいですね。
私も興味があるので、テストマネージャの資格試験後は、アナリストについても学んでみたいと思います。

テストアナリストについて学習したい方は、この機会にテストアナリストシラバスを読んでみるのは以下かでしょうか。
http://jstqb.jp/syllabus.html#syllabus_advanced_altta

□テクバン社、mable社無料セミナー開催

https://www.techvan.co.jp/event/823web/
こちらの記事は、テクバン社とmable Japan社の合同開催の無料セミナーの情報となります。
こちらのセミナーでは、テスト自動化の導入を検討されている方、テスト自動化は導入してるけど効果が実感できないのに対するヒント、サポートをする内容となっているようです。

無料セミナーの情報は以下となっています。

◇セミナー詳細

セミナーは無料で受けることができ、1時間のボリュームとなっていますので、参加しやすいのではないかと思います。

ご興味のある方は、セミナー詳細ページにアクセスしてみてはいかがでしょうか。

■海外ニュース

□最初から高度なテスト自動化を組み込む

https://www.applause.com/blog/advanced-test-automation-accessibility
こちらの記事は、「applause.com」に掲載されていた内容となります。
テスト自動化に対する取り組み方が掲載されていましたので、ご紹介いたします。

◇効果的なテスト自動化は、コードレベルの調整がすべて

自動化を構築することは困難です。
組織の他のメンバーと協力する際の困難は言うまでもなく、特に高度なテスト自動化のために、スクリプトテストにはある程度の技術的専門知識が必要です。

コードレス自動化も例外ではありません。
コードレス自動化は単純なテストしか自動化できないと考える人もいますが、それは完全には真実ではありません。
高度なテスト自動化スクリプトをサポートする同じ基盤により、コードレス自動化も成功します。

◇包括的自動化の概念

ほとんどのプログラマーは、インクルーシブデザインまたはユニバーサルデザインの概念に精通しています。
この概念では、可能な限り多くの人が使用できる製品を作成します。
この概念は、組織がアクセシブルな製品の作成に努めているため、これまで以上に重要であり、テスト自動化にどのように取り組むべきかについても情報を提供します。

従来、テスト中のソフトウェア開発者（SDET）は、特に複雑なケースでは、コードを使用して自動化をスクリプト化します。ソフトウェアテスターは、これらのテストを維持するどころか、理解するための技術的なノウハウを持っていない可能性があります。
これは、人事異動が発生したり、テスト自動化の規模と範囲がSDETの制御を超えて拡大したりすると、大きな問題を引き起こします。

包括的自動化はこの問題を解決します。
Applause Codeless Automationなどのコードレス自動化製品を使用すると、コードを操作せずに自動テストを作成できます。インターフェイスを操作すると、ACAが技術的な作業を行います。

しかし、コードレス自動化はコードを抽象化しますが、包括的自動化を利用する唯一の方法ではありません。
コードレス自動化が依存するのと同じ識別タグにより、スクリプトによる自動化も容易になります。
それはすべて、テスト自動化をよりスマートで回復力のあるものにすることであり、より複雑ではありません。

◇自動化を促進する方法

最近、テストエンジニアと開発者は、Web（多くの場合Seleniumなどのオープンソースフレームワークを使用）とモバイルアプリ（多くの場合Appium）の両方を検証する必要がありますが、後者はテストの自動化に関して独自の課題をもたらします。

たとえば、Webオートメーションでは、Seleniumはドキュメント全体にアクセスできるため、ページ上の任意の場所で検証する個々の要素を簡単に見つけることができます。

Appiumを介してモバイルアプリケーションを見る場合、表示されているものだけがアドレス可能であり、その上、表示されているアイテムの数は、使用しているデバイスによって異なる場合があります。
この問題だけでは、モバイルデバイスの自動化を構築することは非常に困難です。
たとえば、要素がページの下部にあり、ユーザーがスクロールすると上部に移動する可能性があります。
これにより、テストスクリプトに不整合が生じる可能性があります。

さらに悪いことに、不適切にコーディングされた要素は、アクセシビリティの範囲にギャップを残し、重要性が増している領域です。

このため、コードに組み込まれた詳細を含む包括的な自動化に向けてアプリを適切に調整することが重要です。
テスト自動化コードがSelenium、Cucumber、Appium、または他の言語で記述されているかどうかにかかわらず、自動化が要素を見つけるのに役立つこれらの要素を含めます。

・ID

すべての要素には一意の識別子があり、Androidの場合はresource-id、iOSの場合はnameと呼ばれます。
テスト自動化は、一貫性を保つために、ページ上の位置ではなく、これらのIDに基づいて動作する必要があります。
IDには、親IDと子IDを含めて、テスト対象の領域をさらに分類および指定できます。
これらの一意の識別子は、自動化が機能したり、アサーションを追加したりできる安定したアンカーを提供します。
ユーザーがアプリやページを操作しても変化しません。

・コンテンツの説明

Androidの場合はcontent-desc、iOSの場合はaccessibility-idと呼ばれるこの記述子は、要素の目的を説明します。
コンテンツの説明は、プログラマーがUI要素を区別するのに役立ちますが、これらの説明をスクリーンリーダーに中継することに依存している障害を持つ人々には特に役立ちます。

上記は自動化の標準的な方法になりつつあります。
実際、一部のIDEは開発者にこれらの要素属性を含めるように促しますが、それは当たり前になる必要があります。
壊れない機能的で高度なテスト自動化を実装する場合、これらのIDはオプションではありません。

◇高度なテスト自動化の限界

コードレス自動化は、高度なテスト自動化ケースの多くをスクリプトテストとして処理できますが、自動機能テストソリューションなど、自動化の専門知識に頼るのが理にかなっている場合もあります。一部のテストは、コードレス自動化の制限のためではなく、テスト自動化全体の制限のために、手動で実行する方が適切です。

テスト自動化で外部データと画面上のデータを組み合わせるのは非常に困難です。
これは、今日のすべてのアプリで一般的な外部API呼び出しで機能します。
たとえば、GoogleやFacebookを介してログインを自動的に検証することは困難です。

これは、各アプリの動作が、インストールされているかどうかや実行されているOSなどのさまざまな要因によって完全に異なり、更新によっていつでも変更される可能性があるためです。
2つのシステムの同期は、あらゆるタイプの自動化で最も困難な問題の1つです。

◇高度なテスト自動化による多くの可能性

開発組織にとって、技術的負債を返済するための新機能の開発にブレーキをかけることは容易ではありません。

技術的負債はユーザーを登録したり興奮させたりすることはありませんが、それは必要な努力です。
技術的負債を返済しないと、パフォーマンスが必然的に低下します。
そのため、優れたテクノロジーイノベーターの多くは定期的にそれを削減することを約束しています。
包括的自動化を通じて高度なテスト自動化を実現することは、長期的に組織に利益をもたらすためにコアコンピテンシーの進捗を一時停止する必要があるこれらの領域の1つです。

私は最初からこの仕事を計画している会社で働いてきました、
そして私はこれらの目標を達成するために進歩を一時停止したくない会社で働いてきました。
私の経験では、それはそれほど難しいことではなく、リスクは比較的小さいです。
この取り組みを成功させる最善の方法は、高度なテスト自動化の計画と戦略をSDLCに直接組み込むことです。
これは1回限りの作業ではありません。
アプリ要素を適切に識別し、それらの周りの自動化を改善することは絶え間ない努力です。

テスト自動化の取組みに対する内容がまとめられていましたので、ご紹介させて頂きました。

□継続的テストと自動化の力

https://www.cpomagazine.com/cyber-security/continuous-testing-and-the-power-of-automation/

こちらは、「cpomagazine.com」というサイトに掲載されていた内容となります。
継続的テスト「CT」、継続的テストの自動化、侵入テストについてまとめられていましたので、ご紹介したいと思います。

◇継続的テストとは何ですか？なぜそれが重要なのですか？

継続的テスト（CT）は、開発の全段階を通じてさまざまな問題を発見して直面するソフトウェアテスト方法です。
CI / CDパイプラインCTは、開発者と製品マネージャーがソフトウェア開発ライフサイクル（SDLC）の初期段階および後期段階で潜在的に有害なバグを見つけて修正するのに役立ちます。

CTは、自動化された各テストで一貫性のある洞察に満ちたフィードバックを提供し、コードエラーが実際にリリースされるのを防ぎ、ビジネスリスクの範囲を強化し、郊外のユーザーエクスペリエンスを通じて満足する顧客を保証します。

それでも、CTの最も価値のある機能は、自動テスト機能です。
配信パイプラインの一部として、CTはリリース目標を達成するために、徹底的なテストを頻繁かつ早期に完了します。
最も注目すべきは、他のテストタイプとは異なり、CTは必ずしも大規模なスタッフを必要としないことです。
これは、テクノロジーのフロントエンドとバックエンドでエンドツーエンドの自動テストを使用しているためです。
同様に、自動化により、手動で時間のかかるテストを実行するコストが削減されます。
また、内部チームに過度のストレスをかけることなく、配信を迅速に追跡できます。

CTを活用すると、アプリケーションの状態とセッション終了時のクラッシュの頻度で測定される、より安定したユーザーエクスペリエンスが得られます。
CTはまた、サイロ化されたチームを分解し、部門の枠を超えたコラボレーションを活性化し、壊れたアプリをより迅速に修正することで、製品の品質とパフォーマンスに対する認識を高めると同時に、全体的なビジネス指標を改善します。

同様に、CTから提供されるフィードバックと実用的なデータにより、利害関係者は情報に基づいた即時の意思決定を行うことができます。
継続的テストは、自動化された機能テストだけではありません。
CTの鍵は、機能が本番環境に対応していることを証明するために必要なすべてのタイプのテストが含まれていることです。

◇継続的な侵入テスト

CTの見落とされがちな側面の1つは、セキュリティチェックの可能性です。
これは、脆弱性管理戦略が不十分な多くの企業によって例示されています 。

ほとんどの企業は、従来のウォーターフォール方式または過大な負担をかけられたチームに依存して、労働集約的で不正確になりがちな時代遅れの分析アプローチを実行しています。
継続的な侵入テストの自動化された能力を利用することにより、企業はもはや従業員の貴重な時間を無駄にする必要がなくなります。

継続的な侵入テストは、CTの一部として、コードの脆弱性、暗号化の脆弱性、さらにはSQLインジェクションの欠陥の存在などの脆弱性についてネットワークを調査するサイバー攻撃をシミュレートできるセキュリティチェックです。

ビジネスのネットワークと脅威の状況の両方で変化は避けられないため、侵入テストは継続的に行う必要があります。
リモートの従業員、管理および監視されていないIoTデバイス、および脅威アクターの進化し続ける戦略は、組織にとってすでに複雑な環境を複雑にするために機能します。

CTがコードエラーの頻度を減らすのと同じように、継続的な侵入テストはシステムの見落とされた開口部を減らします。
セキュリティチームが脅威にどのように対応するかを企業が確認し、現実的なシナリオに対して練習できるようにします。

ユーザーエクスペリエンスがすべてです。
消費者は、ソフトウェアアプリケーションやその他のデジタル製品を使用するときにエラーのないエクスペリエンスを期待しています。

ソフトウェア開発パイプラインにCTを導入することで、企業はより迅速な配信、より高い資格、より優れたセキュリティを実現し、最終的にはエンドユーザーエクスペリエンスを向上させることができます。

継続的なテスト、侵入テストについてまとめられていましたので、ご紹介させていただきました。

□データマスキングの状態：それは不可欠

https://techbeacon.com/security/state-data-masking-its-essential-so-get-it-right

こちらの記事は、「techbeacon.com」に掲載されていた内容となります。
ソフトウェアテスト、テスト自動化とはケイロが異なりますが、興味深い内容でしたので、ご紹介したいと思います。

◇初めに

2017年、パッチが適用されていないサーバーを介したEquifaxの侵害により、1億4,300万人を超える米国市民の機密データが公開されました。
これは、全成人アメリカ人の半数以上を占め、社会保障番号などの情報を公開しています。

この違反により、7億ドルの罰金が科せられ、事実上の国民識別番号としてのSSNの将来について多くの議論が交わされ、企業は情報を使用可能な方法で保護する方法を再評価しました。

1つの解決策であるデータマスキング（機密データが許可されていないユーザーに表示されないようにする手法）は、それ以来、普及し、進化してきました。
データマスキングは、機密データの単純な置き換えから、企業が攻撃者から情報を保護しながらデータの有用性の多くを維持できるようにする動的マスキングおよびトークン化技術へと変化しました。

データマスキングは、正しく実行され、適切なデータセキュリティポリシーと組み合わせることで、保護されたデータを引き続き機能させることができます。

◇1.データマスキングは多くの分野をカバーする

データマスキングという用語の対象となるテクノロジー は拡大しています。
もともと、データマスキングとは、機密データを隠すことを指すことがよくありました。
たとえば、電話番号の代わりに「（000）000-0000」を送信します。
データマスキングには、機能的な匿名化と仮名機能も含まれるようになり、機密データ値のトークンが生成されます。
このトークンは、元に戻すことはできませんが、一部の分析機能を使用できます。
データマスキングは、フォーマット保存暗号化（FPE）やステートレストークン化などの手法を利用します。

これらの手法は、データのサイズが少なくとも2桁大きくなり、計算の複雑さが爆発する可能性がある準同型暗号化などの計算集約型の手法とは異なり、実用的です。

◇2.すべてのデータマスキングが同じというわけではない

静的データマスキングは、通常のユーザーにレコードを配信するために使用されるマスクされたデータを持つ2番目のデータベースを使用しますが、特権ユーザーは引き続き元のデータにアクセスできます。動的データマスキングは、データの有用性の一部を維持できるさまざまな手法を使用して、要求されたときにプログラムでデータを変更します。
クレジットカード番号の代わりにトークンを使用することもできます。
これにより、1回限りの取引が可能になり、アカウント情報の漏洩を防ぐことができます。

そのような技術は強力な機能を提供しますが、それらは普遍的ではありません。
多くのデータベース製品はデータマスキング機能を提供しますが、これらの機能により、データの文字通りの「マスキング」によって情報を隠すことができます。
他の動的データマスキングでは、機械学習アルゴリズムを使用して、配信時にデータを変更しますが、トレーニングが不十分な場合、最終的な結果に影響を与える可能性があります。

◇3.優れたデータマスキングは現在の規制を満たす必要がある

データマスキングの最終的な目標は、侵害が発生したときに通知する必要がないようにすることです。
欧州データ保護委員会は、2021年のデータ侵害通知に関する例に関するガイドラインで、暗号化されたデータを紛失または漏洩したものの、データへのアクセスを維持している企業は、顧客に侵害を通知する必要がないことを確認しました。

ただし、このような法的保護を利用するには、企業は適切な措置を講じ、適切なテクノロジーを使用していることを確認する必要があります。

◇4.データを引き続き使用できることを確認する必要があります

最後に、企業は、マスクされたデータが引き続きユーザーのニーズに対応できるようにする必要があります。
データマスキングテクノロジに満足していない従業員は、テクノロジを駆使してエンドランを実行しようとする可能性があります。
マスクされたデータは、実際のデータと同じ結果をもたらす必要があり、マスキングの結果として偏ったり歪んだりしてはなりません。

◇最後に

企業は、データに対してより厳しい姿勢を取り始める必要があります。
データを使用できない場合は、データを削除します。
しかし、他のすべての場合において、データをマスキングすることは、企業が最悪の侵害から逃れるのに役立ちます。

データマスキングについて、まとめられており、興味深い内容でしたので、ご紹介させていただきました。

■最後に

今回は、国内ニュース2記事、海外ニュース3記事を取り上げてみました。
次週も、ソフトウェアテスト、テスト自動化に関するニュースをご紹介したいと思います。
(次週は、資格試験がありますので、日曜日に投稿致します。）

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

ソフトウェアテスト自動化の教科書　〜現場の失敗から学ぶ設計プロセス

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

アナリストが教える　リサーチの教科書―――自分でできる情報収集・分析の基本

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