皆さん、こんにちは。
今週もソフトウェアテスト、テスト自動化に関するニュース記事をご紹介していきたいと思います。
今回は国内、海外ニュース4記事をご紹介回したいと思います。
■記事内リンク
・JSTQB Foundation Level Specialist シラバス 性能テスト担当者 日本語翻訳公開
・Mabl自動アクセシビリティテストの追加
・5つの要素を比較検討しソフトウェアテストモデルを選択する
・ソフトウェア工学の13のテストタイプ
■国内ニュース
□JSTQB Foundation Level Specialist シラバス 性能テスト担当者 日本語翻訳公開
https://prtimes.jp/main/html/rd/p/000000016.000054604.html
こちらは、「JSTQB認定テスト技術者資格」のサイトページにて、「Foundation Level Specialist シラバス 性能テスト担当者」の日本語翻訳版が公開された内容となります。
JSTQBでは、今回のように近年、シラバスの更新がありました。
これも時代の流れにより、ソフトウェアテストの在り方なども変化してきているのではないかと思います。
◇「Foundation Level Specialist シラバス 性能テスト担当者」シラバスについて
「Foundation Level Specialist シラバス 性能テスト担当者（以下性能テスト）」のシラバスは、以下リンクからアクセス、ダウンロードが可能となっています。
https://jstqb.jp/dl/JSTQB-SyllabusFoundation-PTSpecialist_Version2018.J01.pdf
私は早速、このシラバスをダウンロードし、概要確認してみました。
・改訂履歴
改訂履歴を確認すると、ISTQBの「性能テスト」シラバスは、2018年5月にβ公開され、2018年12月に正式リリースされており、海外でも比較的新しいシラバスとなります。
日本語翻訳版は、2022年4月16日にリリースされています。
・シラバス構成
シラバスの構成としては、68ページとあり、ボリュームがあります。
構成としては以下となっていました。
0.イントロダクション
1.基本的な概念（学習時間：60分）
2.性能測定の基礎（学習時間：55分）
3.ソフトウェアライフサイクルにおける性能テスト（学習時間：195分）
4.性能テストのタスク（学習時間：475分）
5.ツール（学習時間：90分）
6.参考文献
第3項、第4項が本シラバスのコア部分で、結構な時間を確保して学習に臨む、または繰り返し読み返して理解する必要がありそうですね。
私はGW中にでも一通り目を通してみたいと思います。
ご興味ある方は、「JSTQB認定テスト技術者資格」のサイトページにて、「性能テスト」シラバスを参照されてみてはいかがでしょうか。
https://jstqb.jp/syllabus.html#syllabus_foundation_specialist_performance
■海外ニュース
□Mabl自動アクセシビリティテストの追加
こちらは「prnewswire.com」にて掲載された内容となります。
ローコードテスト自動化で有名な「Mabl」に「アクセシビリティテスト」の追加機能が発表されたとのことで、ご紹介したいと思います。
（アクセシビリティテスト：ユーザーがソフトウェアを操作できない、ユーザーがソフトウェアを理解できないなどをテスト）
◇アクセシビリティテストの追加について
2022年4月27日、ボストンにあるインテリジェントテスト自動化のSaaSリーダーであるmablは、品質エンジニアリングのための統合プラットフォームの最新の拡張機能として、自動アクセシビリティテストの追加を発表しました。
現在ベータ版の新機能により、ソフトウェアチームは、エンドツーエンドのテスト作業の一環として、エンドユーザーに影響を与える前に、開発の早い段階でアクセシビリティの問題を自動的に特定して解決できます。
アクセシビリティは、あらゆる規模の組織にとって急速に高まっている懸念事項です。
特に、消費者の好みがデジタルファーストのエクスペリエンスに移行し、最新の政府規制がコンプライアンス違反に強い影響を及ぼしているためです。
ソフトウェアアプリケーションは絶えず変化していますが、機能品質の評価が開発パイプラインに組み込まれている間、アクセシビリティチェックはほとんど頻繁でない監査に追いやられています。
ほとんどのチームはアクセシビリティを事後対応的に管理しており、顧客が影響を受け、組織のブランドを傷つけ、信頼を損ない、訴訟に直面するリスクがはるかに高い本番環境で問題が発見された後にのみ問題を軽減します。
mablを使用すると、品質エンジニアリングチームは、自動化されたアクセシビリティチェックを配信パイプラインに簡単に組み込むことができます。アクセシビリティテストで人気のあるエンジンであるaxe-coreを搭載したアクセシビリティチェックは、ウェブ、メール、PDF、モバイルウェブテスト向けのmablのローコードテスト自動化ソリューションに完全に統合されています。
実用的なレポートを備えたアクセシビリティテストを開発パイプラインに組み込むことで、ソフトウェアチームがWebコンテンツアクセシビリティガイドライン（WCAG）（バージョン2.0および2.1）への準拠を継続的に検証することがこれまでになく簡単になります。
「アクセシビリティは品質の重要な領域であり、すべての企業、特に一般向けのアプリケーションやWebサイトを使用している企業に影響を与える倫理的な懸念事項です」とmablの共同創設者であるDanBelcher氏は述べています。
「Mablは現在、品質チームが顧客に到達するずっと前にアクセシビリティの問題を積極的に軽減する方法を先導することを可能にし、ユーザーエクスペリエンスを向上させ、コストのかかる欠陥を回避します。」とも述べています。
自動アクセシビリティテストベータ版は、 14日間の無料トライアルに登録しているユーザーを含むすべてのmablユーザーが利用できるようになりました。
品質チームは、ローコードインテリジェントテスト自動化の力を利用して、データ駆動型テストを採用し、品質エンジニアリングをDevOpsパイプラインに統合し、製品品質の幅広い領域にプラスの影響を与えて、誰もが楽しいデジタル体験を楽しめるようにします。
◇mablについて
https://www.mabl.com/
mablは、インテリジェントなローコードテスト自動化のエンタープライズSaaSリーダーであり、高速ソフトウェアチームが自動化されたエンドツーエンドテストを開発ライフサイクル全体に組み込むことを可能にします。
mablのお客様は、信頼性の高いブラウザー、API、およびモバイルWebテストを簡単に作成、実行、および保守できる統合プラットフォームの恩恵を受け、高品質でビジネスに不可欠なアプリケーションをより迅速に提供できます。
そのため、 Charles Schwab 、jetBlue、Dollar Shave Club、Stack Overflowなどの顧客中心のブランドは、顧客が要求するデジタルエクスペリエンスを作成するためにmablに依存しています。
尚、今回のアクセシビリティテストの追加リリースについては、mablの日本ページにおいても、アナウンスされていました。
https://www.mabl.com/jp/introducing-low-code-accessibility-testing-with-mabl
mablを利用されている方、またmablを導入検討されている方は、上記アクセシビリティテストの内容についても、確認されてみれはいかがでしょうか。
□5つの要素を比較検討しソフトウェアテストモデルを選択する
こちらは、「techtarget.com」に掲載された内容となります。
プロジェクトにソフトウェアテストモデルを選出する5つの要素について、比較検討する旨の内容が紹介されており、とても興味深かったため、ご紹介したいと思います。
◇初めに
ソフトウェアQAを使用すると、適切なテストモデルが保険証券として機能します。
これにより、組織は、ソフトウェア製品の最高の見返りに対するコストと価値の適切なトレードオフを見つけることができます。
しかし、正しい テストモデルを構成するものは何ですか？
チームが自分の好みのソフトウェアテストモデルを見つける方法、それが組織とその開発スタイルにどのように適合するか、そしてどのアプローチが利用可能かを調べてみましょう。
◇テストと価値に影響を与える要因
ソフトウェアテストのモデルとアプローチについて話し合うとき、チームはまず、製品に最大の価値を提供するものを決定する必要があります。
考慮すべき重要な要素は次のとおりです。
・フィードバック速度
・フィードバック精度
・機能レベルのテスト
・回帰アプローチ
・回帰エラーの量
次に、チームはスクラム、ウォーターフォール、かんばん、およびその他のソフトウェアテストモデルについて話し合い、適切な一致を見つけることができます。
たとえば、スクラムをフォローしているチームについて考えてみましょう。
チームには、スプリントの終わり近くにビルドを受け取るテスターがいて、2日間の回帰バーンダウンを実行します。
2週間のスプリントタイムラインで、チームは最後に2つの「回帰テスト」サイクルを予約します。
これは4日、つまりスプリント時間全体の20％になります。
チームがその4日目にバグを発見した場合、それはスプリント全体が遅れることを意味します。
同時に、プログラマーはおそらく、ただ座ってバグを待つだけでなく、別のブランチで次のスプリントに取り組んでいます。
バグ修正は両方のブランチにマージする必要があり、それらが導入するリグレッションバグは少なくとも2週間は検出されません。
テスターは、バグを書き留め、再現方法を誰かに説明、バグかどうかを議論、修正する必要があるかどうかを議論、プログラマーがバグを拾い上げるのを待って、最終的にバグの問題を解決しようとする必要があります。
時間と費用がかかるようですね。
ここで、上記のシナリオを、一緒に作業している開発者とテスターのペアがバグを見つけたシナリオと比較してみましょう。
テスターは、誰がバグを導入したかを正確に把握しており、すぐに問題に対処できます。
この2番目の例では、テストのタイムラインが大幅に短縮され、不完全なバグ修正や別の回帰バグが作成される可能性が低くなります。
このアプローチでは、無駄な時間が大幅に短縮され、修正が不完全になったり、別の回帰バグが発生したりする可能性が大幅に低くなります。
開発チームは、Jiraなどのツールを使用してデータを分析し、時間枠を短縮する方法を学ぶことができます。
チームがこのデータを入手すると、組織に適したソフトウェアテストモデルを見つけるのがはるかに簡単になります。
◇さまざまなソフトウェアテストモデルの経済的利益
・例による仕様（SBE）
このソフトウェアテストモデルは、プロセスの最後にバグを書き直してバグを修正しようとする開発チームを悩ませているプロジェクトの終わりの議論とやり直しを制限することを目的としています。
たとえば、チームは、新しいストーリーを作成するのにかかる時間に基づいてリワークにかかる時間を見積もり、プロセスに関与する人の数を掛けてから、スプリントごとのストーリーの数を掛けることができます。
控えめに言うと、これらの議論の50％だけがこの推定によって妨げられると仮定します。
同様に、チームは指定に費やした余分な時間を見積もることもできます。
この単純な計算は、週に5人時間で実際に20を節約できることを示しています。
これは、SBEの値が、このスプリント中に引数と書き換えで節約された時間だけであることを示しています。ソフトウェアが何をすべきかについてのドキュメントを参照するチームは、その価値が指数関数的に増加することに気付くかもしれません。
・継続的デリバリー
ソフトウェアコンポーネントが分離されて いて、個別に展開でき、サブシステムAに展開しても、サブシステムBに問題が発生しない場合、チームは回帰テストの実行を完全に停止し、完了時にすべての機能を展開できます。
これらの展開可能なターゲット（DT）のテスト戦略は、フィードバック速度、フィードバックの精度、機能レベルのテスト、回帰アプローチ、および回帰エラーの量に大きく依存します。
たとえば、APIテストツールは、書き込みと実行が比較的高速です。
自動化されたAPIテスト 一種の契約のように機能します-この入力とデータベースの条件を考えると、この出力を期待してください。
デプロイの前に、APIプログラマーは簡単なクイックチェックを実行して、変更がこれらの期待される結果のいずれかを「壊した」かどうかを確認できます。
一方、GUIテストツールは遅くて壊れやすい場合があります。
継続的デリバリーの場合、小さなコンポーネントをデプロイする前に、人間がインターフェースを実行する方が理にかなっている場合があります。
ただし、コンポーネントがそれほど小さくなく、大量のセットアップが必要で、多数のブラウザとモバイルデバイスの組み合わせで実行する必要がある場合は、テストツールを使用すると時間を節約できます。
・ウォーターフォール
Waterfallでのテストには1つの大きな利点があります。
それは、 1回だけ実行する必要があるフェーズです。
他のすべてのソフトウェアテストモデルでは、テストは繰り返し実行するアクティビティです。
スプリントビルドリクエストが遅いスクラムチームの例を参照すると、回帰テストは2週間ごとに実行する必要があります。
継続的デリバリーを試みる多くのチームは、コミットがバージョン管理にプッシュされるたびに、GUIを含むすべてをテストしようとします。
ウォーターフォールでは、回帰注入率が高い場合、最初のリリースのテストは安価です。
開発者が回帰テストを行わない時間が長いほど、未知の欠陥が発生します。
最初のビルドで100個の欠陥がある10個ごとに7個の新しいバグを作成するチームは、最終的に1回のテスト修正サイクルを実行することはありません。
11個のバグを出荷する前に7回実行します。
ウォーターフォールテストを使用したソフトウェア開発は、リリースが1つしかない場合、またはソフトウェアがそれほど頻繁に変更されない一連の小さなモジュールで構成されている場合に機能する可能性があります。
たとえば、機械学習のバッチアプリケーションやデータサイエンス部門を行う企業は、このスタイルの開発、テスト、データの収集、およびコードを捨てるなどです。
・かんばん
小さなソフトウェアの変更とバグ修正を伴うチケットに取り組む内部IT部門は、テストにウォーターフォールスタイルのアプローチを採用する可能性があります。
つまり、バグを観察して修正し、修正をテストして展開します。
これは、変更によってリグレッションバグが発生しない場合や、システムが分離されている場合に特に効果的です。
たとえば、IT部門が、財務、人事、営業など、100の異なるアプリケーション開発を個別にサポートしている場合です。
□ソフトウェア工学の13のテストタイプ
こちらは「securityboulevard.com」に掲載されていた内容となります。
ソフトウェアテストのテストレベル、テストタイプについてまとめられていましたので、ご紹介したいと思います。
◇ソフトウェアテストとは何ですか？
ソフトウェアテストは、ソフトウェア開発ライフサイクルの重要な部分です。
これには、リアルタイムのユースケースに展開されたときにソフトウェアが正常に機能することを保証するために機能するさまざまなアクティビティが含まれます。
初期の頃は、社内のソフトウェア開発者は自分たちが作成したコードを手動でテストしていました。
これには時間がかかり、効果がありませんでした。ソフトウェアが本番環境に移行する前に、開発者が欠陥をキャプチャすることはめったにありませんでした。
時が経つにつれて、ソフトウェア開発に厳格な品質基準を適用するための専門部門が誕生し、最終的には、ソフトウェアテストがすべての成功するアプリケーション開発イニシアチブの重要な柱になりました。
◇ソフトウェアエンジニアリングにおける上位13種類のテストは何ですか？
基本的なソフトウェアテストアクティビティは当初、企業の品質要件を処理していましたが、時間の経過とともに、いくつかのタイプのテストアクティビティがソフトウェアエンジニアリングアクティビティの主流コンポーネントになりました。
今日のデジタルに精通した市場条件に対応するアプリケーションを構築する際に、すべての企業が注意しなければならないソフトウェアエンジニアリングの上位13種類のテストを調べてみましょう。
1.ユニットテスト
単体テストは、コードまたは機能ユニットの個々のスニペットの品質を保証する最も重要なタイプのテストの1つです。
モジュラーソフトウェアユニットが適切に機能することを検証します。
これは、さまざまなコンポーネントまたはユニットが時間の経過とともに連携して完全なアプリケーションを形成するときに、アプリケーションの復元力と変化への適応を示します。
2.統合テスト
統合テストは、さまざまなモジュールまたはユニットが統合されたときにどのように機能するかを調べるプロセスです。
ソフトウェアスイート全体のより広範なニーズをサポートします。
統合テストは、統合システムの実行可能性をチェックします。また、実際の運用シナリオを活用して、さまざまなモジュールが摩擦なく連携できるようにします。
3.システムテスト
システムテストは、統合テストの包括的なものです。
モジュールまたはユニットで構成されるシステム全体が連携して動作するかどうかを検証します。
また、モジュールまたはユニットが意図したとおりに連携して動作しているかどうかもチェックします。
4.互換性テスト
互換性テスト戦略は、アプリケーションの品質に最も大きく貢献するものの1つです。
さまざまな環境でのソフトウェアのパフォーマンスを評価します。
環境の主な例には、携帯電話のさまざまな画面サイズとOS構成、コンピューターとモバイルデバイス上のさまざまなブラウザー、クラウド、オンプレミスホスティングの互換性などがあります。
5.回帰テスト
機能または変更がリリースされると、回帰テストにより、アプリケーションの通常の機能に影響がないことが確認されます。
つまり、変更がソフトウェアアプリケーションまたはそのモジュラーコンポーネントに影響を与えるかどうかをチェックします。
最新の開発シナリオでは、回帰テストはさまざまなツールを使用して自動化されています。
このプロセスでは、手動テストの必要はありません。
6.健全性テスト
テストは簡単な作業ではありません。
アプリケーションが比較的大きい場合の開発作業と同様に、テストサイクルには時間と労力がかかります。
健全性テストは、特定のアプリケーションが大規模なテスト作業の準備ができているかどうかを通知する保証のレイヤーを作成します。
新しいソフトウェアまたはそのバージョンまたはコンポーネントが、主要なテスト活動を検討するのに十分に機能しているかどうかをチェックします。
これにより、開発者は健全性テストから洞察を得て、アプリケーションを主要なテストサイクルに渡す前に、アプリケーションのパフォーマンスを向上させるため、長いテストサイクルを排除できます。
7.スモークテスト
スモークテストは、継続的デリバリーモデルで実行されるソフトウェアプロジェクトに活用されます。
開発段階から新しいビルドの準備ができたら、スモークテストでビルドの安定性をテストし、大きな欠陥が本番環境に忍び込む可能性を排除します。開発チームは、修正を行うために同じことについて通知されます。
8.検収試験
受け入れテストは、エンドユーザーがソフトウェアを受け入れるかどうかを決定する重要なテスト戦略です。
要するに、受け入れテストは、エンドユーザーがソフトウェアをどのように使用するかとしてのユーザビリティをチェックすることによってソフトウェアを検証します。
9.エンドツーエンドのテスト
エンドツーエンドのテストにより、すべての運用シナリオでアプリケーションのワークフローを着実かつ合理的に進行させることができます。
アプリケーションまたはその機能の最初から、エンドツーエンドのテストでは、アプリケーションがどのように進行するか、および各機能またはソフトウェア全体の割り当てられた目的を完了するために適切なナビゲーションの旅をするかどうかを観察します。
10.機能テスト
機能テストは、ソフトウェアが機能に関して意図したとおりに機能するかどうかを検証します。
11.セキュリティテスト
これにより、セキュリティ上の脅威から保護する保護層が確保されます。
さらに、アプリケーションが本番環境に移行する前に、脆弱性を特定するのにも役立ちます。
12.負荷テスト
負荷テストでは、複数のエンドユーザーが同時に使用する場合のアプリケーションの動作をチェックします。
13.パフォーマンステスト
特定のワークロードに対するアプリケーションのスケーラビリティ、運用速度、リソース使用率、および安定性をチェックします。
◇まとめ
企業はどのようにしてすべてのタイプのテストから最大の利益を活用できますか？
企業は、利用可能な膨大な数のオプションから適切なテスト方法とアプローチのセットを選択することに混乱を感じています。
これは、私たちの専門家が違いを生み出すのを助けることができる場所です。
最先端のテスト自動化プラットフォームを介したさまざまなタイプのテストと自動化でのベストプラクティスの採用を通じて、ソフトウェア開発の野心が最高レベルの品質を保証できる方法を探ります。
■最後に
今回は、以上の国内ニュース、海外ニュースを取り上げてみました。
次週も、ソフトウェアテスト、テスト自動化に関するニュースをご紹介したいと思います。
最後まで見て頂き、ありがとうございました。
JSTQB Foundation 第4版 シラバス2018対応
詳細はコチラをクリック！
【この1冊でよくわかる】ソフトウェアテストの教科書
詳細はコチラをクリック！
