皆さん、こんにちは。
今週もソフトウェアテスト、テスト自動化に関するニュース記事をご紹介していきたいと思います。
今回は国内、海外ニュース３記事をご紹介回したいと思います。
■記事内リンク
「国内ニュース」
・mabl×テクバン共催ウェビナー
・単体テストを書く文化を作るまでの取り組み
「海外ニュース」
・コンプライアンステストまたはコンフォーマンステストの違いは何？
■国内ニュース
□mabl×テクバン共催ウェビナー
https://prtimes.jp/main/html/rd/p/000000096.000031612.html
こちらは、mabl Japanとテクバン社が共催する無料ウェビナー「ひとつ上を目指すテスト自動化」についてです。
Mabl Japanは、mobl Incが提供するクラウド型テスト自動化サービス「mabl(メイブル）」を日本で販売を行っている企業で、テクバン社はシステムやソフトウェアの第三者検証サービスを行っている企業です。
今回のセミナーでは、テスト自動化ツール「mabl」を使い、ノーコード・ローコードによる自動テストの実施方法や、課題の解決方法をデモ形式で紹介されるようです。
◇ウェビナーの概要
ウェビナーの概要は以下となります。
| ・開催日程： | 2022年2月22日（火）19:00～20:30 |
| ・参加費用： | 無料 |
| ・イベントURL： | https://connpass.com/event/234147/ |
| ・タイムテーブル： | 19:00 -19:10/オープニング 19:10-20:25/ひとつ上を目指すテスト自動化ウェビナー 20:25-20-30/クロージング |
ご興味のある方は、上記URLにアクセスしてみてはいかがでしょうか。
□単体テストを書く文化を作るまでの取り組み
https://speakerdeck.com/whisaiyo/developers-boost2021
こちらは「Developers Boost 2021（2021/12/11)」に開催されたイベントにて、人事システム「COMPANY」を開発しているWorks Human Intelligenceの寺尾 拓氏が講演れた「脱レガシープロダクトに向けて開発環境にCIを整理し単体テストを布教した話/develop…」の内容となります。
◇初めに
寺尾氏は、大規模プロジェクトの脱レガシー試みた内容となります。
大規模プロジェクトでは、20年間保守・数百万行規模のソースコード、計40ー50人（＋オフショア）がソースコードを編集を行っている規模とのこと。
大規模プロジェクトでは、主に以下の問題が取り上げられました。
・ソースコードが大規模かつ依存関係が複雑
・ビルドやサーバー起動等に時間がかかる
・テスト自動化が難しく手動テストに頼らざるを得ない
◇Step1の行動/結果
【行動/取り組み】
・1.開発をたのしくし、脱レガシーを取り組む
「モノリス分割」
モジュールごとに、担当する開発チームが明確となっており、各チームが独立化していることが望ましい
「モノリス分割のアプローチ」
リファクタリング（システムのふるまいを変えずに内部構造を変える）を行う。
しかし、レガシープロダクトのリファクタリングは様々なリスクがあり、困難である。
（例）
・テスト工数が確保できない
・影響範囲が大きすぎる
・チーム間で合意しないといけない
2.リファクタリングの第一歩
プロダクトコードに「単体テスト」を整備する
（モダンな開発環境を整える）
・開発者全員が共通設定のIDEを利用する
・IDEファイルを編集の旅にフォーマッタやLinterを実行する
・コードレビュー時に各種チェック（CI）を実行する
ビルド/フォーマッタ/Linter/単体テスト
（快適な開発環境）
・IDEのセットアップを自動化されている
・自動化チェックがすぐに終わる
・自動化チェックの誤検知が少ない
・自動チェックが失敗したときに原因がすぐにわかる
【結果】
1年かけてモダンで快適な開発環境の整備ができたが、脱レガシーは、できなかった
単体テストは、なかなか増えなかった。
（原因/分析）
「Junit」の実行結果をデータベースに入力し、Metabaseで可視化してみえてきたのは、テストを描いていたのは一部の部署のみだった。
・単体テストの書き方がわからない。
・習得する時間もないから、手動テストで対応した。
◇Step2の行動/結果
【行動/取り組み】
いきなりレガシーコードに単体テストを描くのはハードルが高い
まずは今後追加される新規コードにテストを書いてもらう
（Junit dojoの導入)
・オンラインハンズオン形式の研修コンテンツを導入
・1回30-60分、10ー20名ごとに実施（合計40名）
（Junit dojo導入後）
・単体テストについて、興味を持つ開発者が増えた
・Junit dojoの導入後、単体テストを書く開発者が増えた
【結果】
新規コードに関しては単体テストはかけるが、レガシーコードに対して単体テストが書けない
◇Step3の行動/結果
【行動/取り組み】
(Junit dojo改良実践）
・次は、レガシーコードに単体テストを書くための実践的なスキルを習得
・実践的な内容（実プロジェクトを模した研修用レガシーコード）で単体テストを書く
【結果】
開発チームに以下変化が起きた
・dojo参加者が講師役となって、Junit dojo再放送が行われた
・単体テストの勉強会が各チームで開催されるようになった
・単体テストを書きやすくするために共通モックが整備
・単体テストの環境が各プロダクトに整備
・単体テストを書く定期的な活動（JUnit部）が発足
↓
研修1年後、脱レガシーの取り組みが進んだ！
現在も脱レガシーの取り組みは、継続されているとのことです。
https://speakerdeck.com/whisaiyo/developers-boost2021
単体テストを導入してみたいという方は、上記ドキュメント資料を参照してみてはいかがでしょうか。
■海外ニュース
□コンプライアンステストまたはコンフォーマンステストの違いは何？
https://www.impactqa.com/blog/compliance-testing-or-conformance-testing-whats-the-difference/
こちらは、「impactqa.com」に掲載された内容となります。
「コンプライアンステスト」「コンフォーマンステスト（適合性テスト）」と聞きなれない内容が掲載されており、とても興味深いものでしたので、ご紹介したいと思います。
◇コンプライアンステストとコンプライアンステスト
・コンプライアンステスト
コンプライアンステストは、製品が適用される規則や規制に準拠していることを確認することを目的としています。
・適合性テスト
適合性テストははるかに広い表現ですが、このソフトウェアテスト手順には、IEE、W3C、またはETSIで指定された標準とルールに準拠したシステムが含まれます。
検査プロセスは主にコンプライアンステストに利用され、レビュープロセスの結果は将来の参照のために完全に文書化する必要があります。
適合性テストは、システムがテスト中に特定の規格の特定の基準を満たしていることを確認する方法を確立します。
ご想像のとおり、この2つにはいくつかの重複があります。
コンプライアンス基準では、法律または規制への準拠が必要になる場合があります。
逆に、許容可能な要件を満たすには、業界標準への準拠が必要になる場合があります。
◇ソフトウェアテストでのコンプライアンステストの使用
企業にとって、インターネットはかつては少し荒れた西部であり、法規制の順守は、金融やヘルスケアなどの厳しく規制された業界で働く組織にとってのみ問題でした。
ただし、世界中を巻き込むデータプライバシー規制の洪水によって示されるように、法律はテクノロジーに追いついています。
たとえば、ヨーロッパの一般データ保護規則（GDPR）や米国のカリフォルニア州消費者プライバシー法（CCPA）などです。
会社のソフトウェア、システム、またはデータが何らかの規則や規制の対象である場合は、コンプライアンステストを実行して、すべての要件を満たしていることを確認する必要があります。
コンプライアンステストは通常、規制スペシャリストのチーム（できれば特定のセクター）がシステム、手順、およびセキュリティ管理を検査してコンプライアンスを確認する実践監査です。
コンプライアンステスターが問題を発見した場合、それらを修正する方法について具体的な推奨事項を作成し、その後、すべての問題が修正されたことを確認するためのフォローアップテストを行います。
コンプライアンステストは通常、テスト対象の特定の法規制の専門家で構成されるサードパーティ機関によって実施されます。
大企業の場合、この目的のために社内チームを維持する場合があります。
コンプライアンステスト は、法律で義務付けられている監査と同じではありませんが、監査の準備に非常に役立つ自主的なセルフチェックです。
コンプライアンステストは、担当者がより詳細なトレーニングを必要とするか、セキュリティ管理が不十分であるか、管理手順がより正確であるかなど、コンプライアンスプログラムの弱点を特定するのに役立ちます。
これにより、監査人がコンプライアンスの懸念を発見する前に、それらに対処して修正することができます。
◇ソフトウェアテストでの適合性テストの使用
一方、適合性テストは、法令順守要件と交差する場合と交差しない場合がある特定の業界、技術、または契約上の基準を順守することに関係しています。
適合性テストは、多くの場合、ソフトウェアとシステムの機能、および特定のベンチマークを満たしているかどうかに関係しています。
適合性テストは、次の3つのタイプに分類されます。
・負荷テスト
・ストレステスト
・ボリュームテスト
コンプライアンステストは、ソフトウェアとシステムの品質と互換性を保証するために必須（コンプライアンス監査と同様）または選択的である場合があります。
いずれの場合も、適合性テストは、消費者、法律、および業界のすべての要件を満たす高品質の完成品を提供するのに役立ちます。
◇まとめ
以上の内容により、適合性テストとコンプライアンステストの明確なアイデアが得られることを願っています。
グリッチ（障害）のないソフトウェアを提供するには、適切なコンプライアンステストパートナーを選択することが重要です。
■最後に
今回は、以上の国内ニュース、海外ニュースを取り上げてみました。
次週も、ソフトウェアテスト、テスト自動化に関するニュースをご紹介したいと思います。
最後まで見て頂き、ありがとうございました。
