皆さん、こんにちは。
今週もソフトウェアテスト、テスト自動化に関するニュース記事をご紹介していきたいと思います。
今回は国内、海外ニュース３記事をご紹介回したいと思います。
■記事内リンク
「国内ニュース」
・ソフトウェアテスト効率化カオスマップの公開
・JaSST’22 Tokyo 3/10～3/11開催
「海外ニュース」
・ユビキタスソフトウェアの欠陥を処理する方法
■国内ニュース
□ソフトウェアテスト効率化カオスマップ
https://www.valtes.co.jp/news/2022/202202223401
こちらは、バルテス社から「ソフトウェアテスト効率化カオスマップ」が公開された内容となります。
カオスマップの情報は、上記公式サイトからダウンロードリンクがあり、そちらからダウンロードすることが可能です。
カオスマップでは、主にテストベンダー、テスト自動化ツール、テスト管理ツール、バグトラックシステム、品質教育、資格といったカテゴリごとにまとめられています。
◇テストベンダー
テストベンダーでは、主に第三者検証会社の企業が掲載されています。
バルテス社をはじめ、VERISERVE、SHIFT、DIGITAL HEARTSなど、株式上場上企業も掲載されています。
◇テスト自動化ツール
テスト自動化ツールでは、T-DASH、mabl、Katalon、Autifyなど主要なSaaSモデルの自動化ツールの他、Selenium、等のオープンソースも掲載されています。
◇テスト管理ツール
SHIFT社のCATの他、様々なテスト管理ツールが掲載されています。
私は、CAT以外は初めて見るツールが多かったので、別途調査してみたいと思います。
◇バグトラッキングシステム
backlog、Redmine、Jira等掲載されていました。
こちらは、バグトラックというよりも、タスク管理の方がしっくりくる方もいると思います。
◇品質教育
こちらでは、品質、テストに関するオンライン教育を実施しているサービスが掲載されていました。
QbookはJSTQB資格取得対策の他、ISO/IEC/IEEE29119規格の書籍なども取り扱っていますね。
そのほかですと、FUJITSU、HITACH、SHIFT社の教育機関など掲載されています。
◇資格
JSTQBをはじめ、IVEC（IT検証技術者認定試験）、JCSQE（ソフトウェア品質技術者資格認定）が掲載されていました。
他にもQC検定等が当てはまりそうです。
個人的には、CI/CDツール、Devopsといったツールも掲載いただければと思いました。
Jenkins、Azure DevOpsなどのツールの掲載があれば、それらの情報も調べてみたいと思いました。
今回のカオスマップでは、ソフトウェア業界の規模拡大、ソフトウェアテストの売り上げは過去１０年ほどで急成長していますが、テスト事業における上場企業の業界占有率が１％と低かったりしています。
今後、ソフトウェアテスト市場の活性化の一環として、カオスマップの情報公開をされたとのことです。
ご興味のある方は、以下バルテス社のカオスマップページにアクセスしてみてはいかがでしょうか。
https://www.valtes.co.jp/news/2022/202202223401
□JaSST’22 Tokyo 3/10～3/11開催
http://jasst.jp/symposium/jasst22tokyo/outline.html
こちらは、JaSST’22 Tokyoが3/10(木）、3/11(金）に開催となる内容になります。
JaSSTは、NPO法人ASTERが運営するソフトウェアシンポジウムとなります。
今回で、19回目の開催となるようです。
今回の講演の概要を拝見したところ、目玉は3/10(木）1日目のA1）基調講演だと思いました。
こちらは「Competing with Unicorns」の題で、Spotifyの元エンジニアのJonathan Rasmusson氏が登壇されます。
ハイテク企業、ユニコーン企業のテストを中心とした文化作り、育成などについての内容となっているようです。
JaSST’22の参加方法、タイムテーブルは以下となります。
| ・JaSST’22 TOKYO参加方法： | http://jasst.jp/symposium/jasst22tokyo/query.html |
| ・タイムテーブル 3/10： | A0) オープニングセッション A1）基調講演「Competing with Unicorns」 B2）C2）D2）ランチテクノロジーセッション「テストベンダーが必要な理由をメーカーの担当者に聞いてみた」 A3）論文セッション 事例発表 B3）一般公募セッション 自動テスト C3）企画セッション ゲームのテスト F3）チュートリアル1：JSTQB AL テストマネージャ チュートリアル A4) B4）C4）D4）E4）テクノロジーセッション A5）企画セッション ＱＡとプロダクトマネジメント B5）一般公募セッション ゲームの品質管理 C5）企画セッション テスト設計 F5）チュートリアル2：AI & AIのテスト チュートリアル |
| ・タイムテーブル 3/11： | A6）企画セッション 品質保証 C6）一般公募セッション ゲームデバッグ F6）公募ワークショップ ソフトウェアレビュー A7) B7）C7）D7）ランチテクノロジーセッション A8）企画セッション ソフトウェアエンジニアリング B8）企画セッション 一人QAパネル C8）企画セッション テストエンジニア育成パネル F8）ワークショップ：初心者向けセッション B9）C9）D9）E9）テクノロジーセッション A10）招待講演 A11) クロージングセッション |
2日とも、朝から夕方まで、様々なセッションが用意されていて、タイトルを見るだけでとても興味がそそられます。
お時間が取れる方、ご興味のある方は、以下JaSSTの公式ページにアクセスしてみてはいかがでしょうか。
http://jasst.jp/symposium/jasst22tokyo/timetable.html
■海外ニュース
□ユビキタスソフトウェアの欠陥を処理する方法
https://techbeacon.com/security/how-handle-flaws-ubiquitous-software
こちらはtechbeacon.comに掲載されていた内容です。
ユビキタス（偏在する）ソフトウェアの欠陥を処理する方法として題し、先日脆弱性として話題になった「Log4j」等を例に記載されていましたのでご紹介したいと思います。
◇初めに
Log4jの脆弱性が12月初旬に発生したとき、企業はスクランブルをかけて、Java用のロギングライブラリを使用しているアプリケーションと製品を特定しました。
これらはすべて、企業が使用するソフトウェアコンポーネントをより適切に処理する必要があることを思い出させるものです。
Log4jのフットプリントは膨大であることがわかりました。
たとえば、IBMは、脆弱性の影響を受ける80を超えるクラウドサービスと450の製品を文書化しました。
Amazonは、AWS Secrets Manager、AWS Lambda、AWS Simple Storage Server（S3）などの機密性の高いアプリケーションを含む40を超えるクラウドサービスにパッチをロールアウトしました。
今日のソフトウェアの広大な依存関係ツリーは、特定のライブラリとコンポーネント（主にオープンソースプロジェクトとして公開されている）が非常に大きな影響を与える理由の1つです。
実際、2021年の平均的なソフトウェアアプリケーションは、2019年に298～ 500を超えるオープンソースコンポーネントに依存していました。
上位4つのエコシステム（Java、JavaScript、Python、.NET）では、現在300万のアクティブなプロジェクトが3700万のバージョンをサポートしています。
米国政府はソフトウェア部品表（SBOM）に関するポリシーを改善するためのイニシアチブに着手し、Open Source Security Foundation（OpenSSF）などの取り組みは重要なインフラストラクチャを特定しようとしていますが、企業は自社のソフトウェアコンポーネントの使用を管理する必要があります。
方法は次のとおりです。
◇所持している・利用しているものを改めて理解する
開発者が使用しているソフトウェアライブラリとコンポーネントがわからない場合、脆弱なコンポーネントを見つけることは不可能です。
依存関係は多くの脆弱性を隠す傾向があり、サイバー犯罪者や国民国家の攻撃者による攻撃にさらされているため、間接的な依存関係を可視化することは非常に重要です。
すべての企業は、組織全体のSBOMを生成して、依存しているオープンソースプロジェクト、使用している各プロジェクトのバージョン数、および将来の脆弱性の最小化に最も影響を与える可能性のある手順についての洞察を得る必要があります。
◇パッチの適用回数をなるべく減らす
企業は開発者を自由に保つことでイノベーションをサポートする必要がありますが、コンポーネントバージョンの量を増やすことで、複雑さと脆弱性が課題となります。
さらに、企業は、セキュリティの問題を修正するためにメンテナがコードベースを迅速に更新しないコンポーネントを放棄する必要があります。
2021年の平均更新時間（MTTU）は28日と推定され、2018年にオープンソースコンポーネントを更新するのにかかった158日よりも大幅に改善されました。
ただし、ソフトウェアの修正は依存関係のチェーンを上に移動する必要があるため、依存関係が深いとパッチ適用が遅れる可能性があるため、企業は平均よりもパフォーマンスの高いプロジェクトを探す必要があります。
たとえば、Googleによると、Log4jの依存関係の平均的な深さは5層です。
つまり、企業の開発者が独自のアプリケーションを更新する前に、5つのプロジェクトにパッチを適用する必要があります。
◇頻繁な脅威モデリングを使用して、サプライチェーンの弱点を理解する
依存関係の混乱などの新しい攻撃ベクトルを使用して、ソフトウェアエコシステムを利用し、企業アプリケーションを危険にさらすことができます。
業界と各組織は、脅威がどこから来るのかを確実に理解するために、バリューストリーム全体をモデル化する必要があります。
◇コーポレートウォレットを開く
最後に、組織は、ソフトウェアを使用するプロジェクトをサポートする必要があります。
2014年、Heartbleedの脆弱性は、脆弱なソフトウェアであるOpenSSLがインターネット上の暗号化の多くを支えていたため、Webサーバーとアプリケーションに重大な問題を引き起こしました。
当時、OpenSSLプロジェクトは 年間わずか2,000ドルの寄付を受け取り 、プロジェクトを維持するために1人のフルタイムプログラマーとわずかなパートタイマーチームがいました。
企業がソフトウェアコンポーネントを使用するプログラマーをサポートしない限り、オープンソースソフトウェアの品質と開発プロセスは不均一なままです。
■最後に
今回は、以上の国内ニュース、海外ニュースを取り上げてみました。
次週も、ソフトウェアテスト、テスト自動化に関するニュースをご紹介したいと思います。
最後まで見て頂き、ありがとうございました。
ソフトウェアテスト自動化の教科書 〜現場の失敗から学ぶ設計プロセス
OWASP ZAPとGitHub Actionsで自動化する脆弱性診断 
詳細はコチラをクリック！
