皆さん、こんにちは。
今週もソフトウェアテスト、テスト自動化に関するニュース記事をご紹介していきたいと思います。
今回は国内ニュース3記事、海外ニュース2記事をご紹介回したいと思います。
■記事内リンク
「国内ニュース」
・ソフトウェアテスト資格試験対策eラーニングに新コース期間限定無料公開中～
・バルテス社／テストサービスの4つの分野でNo.1を取得
・デジタルハーツ社／ISTQB「Global Partner」認定を取得
「海外ニュース」
・継続的改善の指標：6つのソフトウェアチームからの教訓
・自動化されたUIテストを管理および維持する方法
■国内ニュース
□ソフトウェアテスト資格試験対策eラーニングに新コース期間限定無料公開中～
https://prtimes.jp/main/html/rd/p/000000096.000030691.html
こちらは、バルテス社が「JSTQB® 認定テスト技術者資格 Advanced Level」テストマネージャ試験対策eラーニングの提供が開始された内容となります。
JSTQB ALテストマネージャーの資格試験は、8/21に開催予定となっており、そちらの資格試験に向けてのeラーニングコンテンツとなっているようです。
バルテス社が運営するQbookに会員登録することで、上記JSTQB Advance Level試験 eラーニング対策講座の第一章が無料で受けれれるようです。
第一章となると「テストプロセス」部分が確認できますね。
また、Qbookサイトには、Advance Levelテストマネージャの他、Foundation Levelの試験対策講座が用意されていました。
https://www.c-streaming.net/v5/e-learning/user/product_list.php?&kaisha_id=toLiLY9tkkM%3D&s=9L2RlloSRh8%3D
◇お試しコース！JSTQBFL対策
・料金：0円
・申込期間：2021/08/31
・Foundation Levelの第一章の一部コンテンツが無料のサンプル版
◇JSTQB Foundation Level試験対策講座
・料金：9,800円
・申込期限：2021/08/14
・Foundation Level試験対策コース
◇JATQB Advanced Levelテストマネージャ試験対策講座
・料金：29,800円
・申込期限：2021/8/14
・Advanced Levelテストマネージャ試験対策講座コース
※Qbook会員登録で、第一章の「テストプロセス」部分が無料
私はQbookに登録しているので、ALの第一章「テストプロセス」内容を見て、購入するか決めたいと思います。
8月のJSTQB AL、FLの資格試験を受ける方は、Qbookサイトにアクセスしてみてはいかがでしょうか。
https://www.qbook.jp/event/20210730_1216.html
□バルテス社／テストサービスの4つの分野でNo.1を取得
https://prtimes.jp/main/html/rd/p/000000093.000030691.html
こちらの内容は、1つ目の記事と同じバルテス社が日本マーケティングリサーチ機構による調査において、
・IT関係者が推奨するソフトウェアテスト検証会社 No.1
・IT関係者が推奨するセキュリティ診断 No.1
・IT関係者が推奨するIT技術セミナー No.1
・IT技術者におすすめのソフトウェアテスト資格勉強アプリNo.1
の4項目を受賞した内容となります。
バルテス社は、株式上場後、ソフトウェアテストの検証業務の他、セミナー、資格対策のコンテンツなど様々な分野で活動されており、今回の各1位獲得は納得の結果ですね。
また、ソフトウェアテスト資格試験のアプリ、コンテンツにおいても、今回のQbookのeラーニングの他、「テス友」が用意されています。
・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
今後もバルテス社では様々な活動が期待できそうですね。
当ブログでは、今後も、バルテス社のセミナーの他、様々な情報をご紹介していきたいと思います。
□デジタルハーツ社／ISTQB「Global Partner」認定を取得
https://www.sanspo.com/geino/news/20210728/prl21072811510093-n1.html
こちらの内容は、第三者検証会社のデジタルハーツ社がISTQBの「Global Partner」認定を取得した内容となります。
今回の記事で私も初めて知ったのですが、「Global Partner」はISTQBのパートナープログラムにおいて最上位認定となるようです。
「Global Partner」を取得している企業は、世界的に見ても9社のみとのことです。
以前の記事で、東京都内にあるコウェル社が「Global Partner」認定されたことをご紹介させて頂きました。
【News】10月3週のニュース（コウェル社ISTQB Globalパートナー,バルテス社Expo出展,QAAリリース 他）
デジタルハーツ社は、全国に約8,000名のテスターが在籍されており、ISTQB資格保有者が368名を突破されており、業界トップレベルの人員規模となったようです。
その他、子会社のデジタルハーツがISTQBの「Platinum Partner」、また、同じく子会社のエイネット社及びDIGITAL HEARTS （Shanghai） Co.Ltd.が「Gold Partner」の認定を取得されたとのことです。
上記経緯により、ISTQBパートナープログラムの最上位となる「Global Partner」の基準を満たし、「Global Partner」の認定を取得されたようです。
第三者検証会社のテスト業務を行われているスタッフ規模は、デジタルハーツ社が群を抜いて多いようですね。
今後もデジタルハーツ社は、様々な活動をされていくと思いますので、当ブログでも可能な限りご紹介していきたいと思います。
■海外ニュース
□継続的改善の指標：6つのソフトウェアチームからの教訓
https://techbeacon.com/app-dev-testing/continuous-improvement-metrics-lessons-6-software-teams
こちらの記事は、「techbeacon.com」に掲載された内容となります。
チーム、組織内で継続的な改善を作成する方法に関するアドバイスの共有、経験、改善フレームワークなどについてまとめられていましたので、ご紹介したいと思います。
◇SPACE Framework：開発者の生産性を予測するための良い方法
SPACE Frameworkは現在、業界で新しい流れを作っているエンジニアリング・メトリクスプログラムです。
ニコールフォースグレン、マーガレットアンストーリー、チャンドラマディラ、トーマスツィンマーマン、ブライアンフック、ジェナバトラーによって開発されたこのフレームワークは、開発者の活動を定義、測定、予測することで、より安全で高速なソフトウェア配信につながるという考えに基づいています。
SPACEは、この方法論はまだ初期の段階ですが、Netflix、GitHubなどはすでに開発チーム内で実装しています。
SPACE方法論の鍵は、生産性と満足度が本質的に関連していることを理解することであり、これは他の方法論にも反映されていることがわかります。
◇DevOps Research and Assessmentモデル：SPACEの前身
DevOpsチームの研究と評価SPACE枠組みを先行（DORA）モデルは、あなたがソフトウェア配信のパフォーマンスを測定し、業界の残りの部分にそれを比較することができます。
モデルを開発する際、DORAチームは、パフォーマンスの4つの主要な指標を特定しました。
展開頻度、変更の平均リードタイム、変更の失敗率、および回復までの時間です。
どのメトリクスプログラムでも、覚えておくべき最も重要なことは、各データポイントとメトリクスが組織に固有であることです。
◇データと指標を使用し、燃え尽き症候群を回避する
SPACEやDORAなどのエンジニアリングメトリクスプログラムは、組織のパフォーマンスと改善点についての基本的な理解を提供するだけでなく、最も重要なこととして、開発チームに目標と目的の出発点を提供します。
各メトリックは、ソフトウェア配信ライフサイクルに固有のものになります。
メンタルヘルスを無視してはならないため、メトリックを使用して、開発者が過労にならないようにすることもできます。
Honeycomb.ioのメジャーによると、「デフォルトでは、私たちは自分たちが作ったものを気にするので、人々は自分たちが作ったものに責任があると感じています。」しかし、時間の経過とともに、開発者を営業時間外に仕事に引き戻すと、蓄積して燃え尽き症候群につながる可能性があり、メトリックとデータが各タスクに費やされる時間に不可欠になり、最も重要なものに優先順位が付けられます。
メトリクスプログラムの実装が成功するということは、メトリクスに基づいて人々を評価するのではなく、彼らがそれらを認識していることを確認することも意味します。
◇データは継続的改善のコアとなり得るか？
エンジニアリングメトリクスプログラムは、管理チームだけでなく、開発チームにとっても重要です。
データは、管理者が組織全体のパフォーマンスと進捗状況を追跡するのに役立ちます。
また、エンジニアが重要なタスクに集中し、努力すべき指標に導くこともできます。
エンジニアの幸福は最も重要です。
成功するエンジニアリングメトリクスプログラムでは、エンジニアの作業負荷、中断間の平均時間などが考慮されます。
したがって、エンジニアの義務に注意し、仕事中の時間を保護し、仕事から切り離します。
こちらの記事では、継続的改善として、難しい内容でしたが、「SPACE Framework」「DORAモデル」というワードだけでも知っておいた方が良いと思い取り上げてみました。
このようなフレームワーク、枠組みについては、別途情報を整理して学習していきたいと思います。
□自動化されたUIテストを管理および維持する方法
https://searchsoftwarequality.techtarget.com/tip/How-to-manage-and-maintain-automated-UI-tests
こちらの記事は、「searchsoftwarequality.techtarget.com」に掲載されていた内容となります。
UIテストの自動化、管理・維持に関してまとめられていましたので、ご紹介したいと思います。
◇自動化されたUIテストを維持するのが難しい理由
アサーション/検証の問題に加えて、UIテストではすべてのコンポーネントをエンドツーエンドで組み合わせる必要があります。
単体テストでは同じファイルにコード行が必要になる場合がありますが、UIテストでは、ソースコード、ライブラリ、データベース、API、ネットワーク、ブラウザー、およびクライアントコンピューターが必要です。
UIテストでは、チームがネットワークを介して接続された少なくとも2つの独立したシステム（テストサーバーと、別のコンピュータープログラムによって制御されるクライアントサーバーなど）をセットアップする必要があります。
◇自動化されたUIテストのデバッグ
自動化されたUIテストが失敗した場合、そしておそらくある時点で失敗した場合、チームメンバーはテストを再実行して、それが真の失敗であったかどうか、またはコードが機能しなかったためにコードの変更によって失敗が発生したかどうかを確認する必要があります。
チームは、自動UIテストの最初の実行を、真のテストではなく、自動変更検出のように扱う必要があります。
テストチームは、UIテストの失敗に関連するコストのかかるループを回避する必要があります。
たとえば、自動化されたUIテストが失敗した場合、テスターは答えを見つけることを期待して次の手順を実行することになります。
・設定
・テスト
・失敗を確認する
・再実行
・デバッグ
・テスト（またはコード）を修正する
・セットアップに戻る
ただし、単体テストにはこのような問題はありません。
ユニットテストは、信頼性に劇的なプラスの効果をもたらす可能性があります。
2000年代初頭、マイクコーンは、リサクリスピンなどの他の専門家とともに、チームがユニットテストに重点を移すことを提案しました。コーンが提案したモデルは、テスト自動化ピラミッドでした。
ピラミッドは、Seleniumが存在する前に定義されていたことに注意してください。
当時のツールは、Windowsデスクトップクライアントアプリケーション（Win32と呼ばれることもあります）に基づいており、比較的扱いにくいものでした。
今日、物事は少し変わっています。
ほとんどのチームにはある程度の単体テストカバレッジがあり、GUIツールはこれらのニーズにはるかに適しています。
ただし、テストの自動化は依然として懸念事項であり、テストのメンテナンスには引き続き注意が必要です。
◇メンテナンスコストを削減する技術的な方法
メンテナンスコストを削減する1つの方法は、テスト容易性を追加することです。
たとえば、コード要素には、テキストが別の言語に翻訳されている場合でも、変更されない名前付きIDが必要です。
さらに、ソフトウェア自体は、コマンドラインレベルで公開されたセットアップおよびティアダウンルーチンを持つことができます。
コマンドラインレベルでデータ入力およびセットアップルーチンを書き込むと、すべてのテストセットアップをテストファイルから1〜2秒でロードできます。
テスト自体を介してデータを入力する代わりに、冗長で重複するテストが作成されます。
これらのテストは、作成にコストがかかり、実行に時間がかかり、デバッグが困難です。
テスターは、エンドツーエンドで繰り返しテストするために、適切なバージョンのコードを使用して独自のステージング環境を作成し、データを入力できます。
おそらく、既知のテストデータを含む標準ファイルをインポートします。
または、チームは、ユーザー、ページ、グループ、権限など、テストされないものを取得して、APIまたはコマンドライン関数で駆動できるようにすることができます。
他のセットアップが自動化されると、テスト自動化設計が機能します。
アイデアとして、テストを小さな機能に分割することです。
データベースへのDOMは、一度に1つのことだけをテストする非常に小さなテストを含むQAアプローチです。
その結果、これらのテストはより高速に実行され、必要なデバッグが少なくなります。
マイクロ機能テストが失敗するのに30秒かかる場合、デバッグを行い、誰かにコードを修正してもらい、サイクルを再実行するのに10分しかかからない可能性があります。
テストは、並列またはランダムな順序で実行できるように、相互依存関係があってはなりません。
チームは、ログイン、検索、タグ付け、ページの作成（タイトル、添付ファイルの本文）などの一般的なコマンドを使用してテストコマンドライブラリを構築することもできます。
ログインに必要なインタラクションが変更された場合、ライブラリは50ではなく1ページで変更する必要があります。
この手順は、ブラウザをゆっくりと実行しますが、コードライブラリのように機能するため、セットアップコードとは異なります。
一連の機能です。
ここで、user-IDなどの変数が渡されます。
◇メンテナンスコストを削減するためのプロセストリック
GUIテスト自動化の保守性を向上させるための強力なトリックは、それを開発段階に引き込むことです。
チームは、自動テストが実行されるまで、ストーリーを不完全なものとして扱う必要があります。
自動化されたテストは、動作するソフトウェアの視覚的なデモンストレーションになります。
これがないと、変更を加える必要のあるテスターは、常にストーリーの修正作業（すでに「完了」）および「現在の作業」と競合します。
プログラマーが他のストーリーを壊すような変更を加える場合、テストは継続的インテグレーションの下で実行する必要があります。
これは、壊れる変更をコミットまでさかのぼります。
変更により他の場所でリグレッションが発生するため、機能のテストに合格するだけでは不十分であることに注意してください。
この機能は、アプリケーション全体の既存のテストスイートと統合されるまで完了せず、すべてのテストに合格し続けます。
これらの変更により、テストメンテナンスが開発に取り入れられ、プログラマーにタスクが与えられます。
将来的には他の誰かにタスクが与えられることはありません。
このシフトにより、テストが中断したときにプログラマーに余分な作業が発生しますが、より良いテストを作成したり、邪魔にならない変更を加えたりする方法を見つけるインセンティブがプログラマーに提供されます。
◇自動UIテストを変更する方法
これらの変更はすべて、「ストーリー」と呼ばれることもある機能レベルから始まります。
開発者とテスターは、プログラマーがコードを書く前に、どのテストが実行されるかについての共通の理解を作成するために協力する必要があります。
そうすることで、機能の要件としてテスト容易性の重要な要素を追加し、それらの要件を発見プロセスにします。ここでは、開発者、テスター、さらには製品の所有者が協力して、製品を構築するための最良の手段を見つけ出すことができます。
チームが健全性テストまたはスモークテストを作成した後、新しい機能に一致するテストをピボットして開発することは一般的に理にかなっています。
結局のところ、これらの新しいソフトウェア機能は、物事を壊すような変更を加える可能性が最も高いです。
チームが事前にテストIDを十分に知っていて、例が明確である場合、製品コードが存在する前にテスターがテストを作成することが可能です。
その後、プログラマーはテストを満たすためのコードを記述し、必要に応じてテストを変更できます。
テストに合格すると、コードを視覚的に示すことができ、機能を人間が探索できるようになります。
これを達成できるチームはほとんどなく、達成したくないチームもありますが、これは、より保守性の高いコードにつながる種類の共同作業の良い例です。
最後に、時期尚早の自動化を回避することについて言及する必要があります。
UIが根本的に変更されている場合は、ユーザーフローをキャプチャしながら、UIの自動化をほとんど行わずに、後でテストを作成することをお勧めします。
それにはもう1つのオプションがあります。
それは、ビジネスロジックをUIから分離することです。
◇ビジネスロジックをUIから切り離す
そのピラミッドには、中間層、統合層、またはより一般的にはAPI層と呼ばれる層があります。
データベースにアクセスし、Webブラウザーよりもはるかに高速に戻り、可動部分が少なくなります。
たとえば、保険アプリケーションでは、GUIテストでシステムを調べて、単純な呼び出しで正しい結果が返されることを確認する必要がある場合があります。
ツールは、UIのいくつかのエラー状態をテストする場合もあります。
ただし、これら2つの簡単な例以外では、ソフトウェアには割引とコストの組み合わせが数十または数百ある可能性があります。
低レベルシステムがすべてのフラグを正確に受信し、正しい答えを送信することが明らかになったら、計算エンジンだけを分離してテストすると便利です。
これらの数十、数百、またはおそらく数千のテストは、それぞれ10秒ではなく、それぞれ10分の1秒で実行できます。
ビジネスルールの視覚的な例として、テストをスプレッドシートのようなものとして表現できる場合があります。
これにより、APIテストは、ビジネスユーザーが自分のビジネスルールの生きたドキュメントとして理解できるものになります。
以上UIテストの管理、維持に関して詳しくまとめられており、自動化テストの取組む際に有益な内容であると思いましたので、ご紹介させていただきました。
■最後に
今回は、国内ニュース3記事、海外ニュース2記事を取り上げてみました。
次週も、ソフトウェアテスト、テスト自動化に関するニュースをご紹介したいと思います。
最後まで見て頂き、ありがとうございました。
［改訂版］演習で学ぶソフトウェアテスト 特訓150問――JSTQB認定テスト技術者資格 Foundation Level対応
詳細はコチラをクリック！
短期間で〝よい習慣〟が身につき、人生が思い通りになる！ 超習慣術
