皆さん、こんにちは。
今週もソフトウェアテスト、テスト自動化に関するニュース記事をご紹介していきたいと思います。
今回は国内ニュース2記事、海外ニュース2記事をご紹介回したいと思います。
■記事内リンク
「国内ニュース」
・オーティファイ社 株式会社ITI品質保証サポート開始
・ソフトウェア品質保証の新しいアプローチ「シフトレフト」
「海外ニュース」
・ソフトウェアテストサイクルをスピードアップする5つの重要なヒント
・AIベースのヘルスケアドメインでのソフトウェアテストの課題
■国内ニュース
□オーティファイ社 株式会社ITI品質保証サポート開始
https://prtimes.jp/main/html/rd/p/000000023.000049466.html
こちらは、株式会社ITIの品質サポートととして、オーティファイ社のE2Eテスト自動化「Autify」が導入され活用された内容となります。
Autifyの導入により、ITI社の受託開発での品質管理、コスト削減につながったとのことです。
◇受託開発での課題
ITI社では、自社サービスの他、企業からの受託開発も行い、5,000件にも上るとのこと。
この受託開発では、主に以下が取り上げられていました。
・品質保証のための時間や人員が確保できない
・10年以上続いており、レガシーコードのためテスト自動化が困難
◇Autify導入での効果
ノーコードでテスト自動化が行えるAutifyを採用したことで、以下が可能となり、品質保証レベルが向上したとのことです。
・深夜～早朝にかけて毎日テストを実施し、安定稼働を目視確認が可能となった
・機能追加によるデグレ―ションチェックが網羅的にテストできるようになった
Autifyの導入記事については、過去DeNA社、セールスフォース社など取り上げさせて頂きました。
webコンテンツを対象に幅広く導入され活躍されていますが、今後はモバイルアプリでも対象になってくると思います。
βテストの受付をされていますので、モバイルアプリケーションに関する導入例も今後ありそうですね。
Autifyについてご興味のある方は以下公式サイトにアクセスしてみてはいかがでしょうか。
https://autify.com/ja
□ソフトウェア品質保証の新しいアプローチ「シフトレフト」
https://japan.zdnet.com/article/35175521/
こちらの記事は、「シフトレフト」に関する内容がまとめられていましたのでご紹介いたします。
◇初めに
CI/CD（継続的インテグレーション／継続的デリバリー）パイプラインをコードが通過する際のテストには、「シフトレフト」の考え方が組み込まれており、DevOpsをはじめとする新しい開発手法が、品質保証の方法論にも影響していることが分かります。
◇従来の品質テストの手法ではクラウドのスピードについていけない
今日のアプリはエンドツーエンドで開発・運用されています。
製品ライフサイクルの早い段階でテストを実施して潜在的なバグを見付けることが時間とコストを削減し、結果的にお客さまの満足度を高めます。
さらに、エンドツーエンドのAPI（Application Programming Interface）テストやブラウザーテストがCI/CDパイプラインに組み込まれ、テストと品質保証の範囲が拡大していることも近年の傾向と言えます。
さまざまなブラウザー上でコードがどのように動作するか、また、重要なデータソースとどのように相互作用するかの品質テストがプロセスの初期段階で実施されるようになったことで、ユニットテストやセキュリティテストなどのプロセスにシフトレフトが反映され、品質保証全体に対する新たな考え方が生まれました。
手作業による従来のテスト手法は、アジャイル開発のワークフローに対応したものではなく、コードを本番環境にデプロイする前に個別にテストを行う、従来のウォーターフォール開発をサポートするものでした。
特定の品質保証チームが本番直前に全てのテストを担当するとクラウド環境での開発スピードを妨げることになり、アジャイル開発においては最適なアプローチとは言えません。
このような理由からテストは、開発プロセスの初期段階へとシフトレフトされ、各エンジニアリングチームによって手動で行われています。
◇クラウドネイティブな開発によりテストはCI/CDパイプラインにシフト
アジャイル開発の一環としてCI/CDが活用され、コードが常にデプロイ可能な状態に置かれるようになりました。
コードがCI/CDパイプラインを通過する時、開発者は早い段階でバグを確実に把握したいと考えますし、そのために、より早期に、より頻繁にテストが行われるようになりました。
特に、CIプロセスの構築を通してエンドツーエンドのテストを行うことの必要性が高まっています。
例えばAPIテストでは、HTTPリクエストとAPIコールをリンクすることで、エンドツーエンドのワークフローを検証することができ、また、世界中の異なる拠点からシステムの全レイヤーを検証することができます。
一方、ブラウザーテストでは、重要なトランザクションにおけるユーザーの視点を捉え、ユーザーインターフェース（UI）の変更がウェブアプリケーションに与える影響を把握することができます。
開発ライフサイクルの早い段階でバグを修正する方が、バグが複雑化して影響範囲が大きくなってから修正するよりはるかにコストが少ないため、この2つのテストをCI/CDパイプラインに移行することで、時間とコストを削減することができるのです。
◇メトリクス、トレース、ログの可視化がテストの価値を高める
このように、CIパイプラインでブラウザーやAPIのテストを実行することは有益です。
特に、これらのテストをフロントエンドとバックエンド、アプリケーションとインフラストラクチャーなど、あらゆるスタックのデータと関連付けることができれば効果はさらに高まります。
失敗したテストを検出することで、本番環境に移行する前に不良コードをロールバックすることができ、また、相関性のあるスタックのデータを使用することで、開発段階に検出できなかった問題をトラブルシューティングして修正することができます。
品質の維持が開発サイクルの全てのプロセスに関連するようになり、あらゆるスタックのデータを利用するという、品質保証の新しいアプローチが生まれます。
◇高い品質を維持するには、部門を超えた協力が必要
このような品質保証アプローチの変化は、ブラウザーテストやAPIテストをシフトレフトさせるという方法論の変化にとどまらず、エンジニアリングチーム間の協力体制を根本的に変えるものです。
本番に入る前にコードがテストされ、コードを本番環境で実行するようになった後もしっかりとモニタリングされます。
テストにはスタック全体のデータが使用され、さまざまな部門のチームが責任を持ってテストを行います。
このような品質保証の新しいアプローチにより、問題がより早く、場合によってはコードが開発中であっても解決され、全く問題が発生しなくなるという好循環が生まれます。
リグレッションが減ればダウンタイムも減り、お客さまに喜んでいただけるだけでなく、エンジニアが新製品の開発に専念できるようになるため、さらに顧客価値が高まるという好循環が生まれます。
こうして実現される信頼性と顧客体験の底上げが、ユーザーに価値をもたらす新たなイノベーションを可能にします。
シフトレフトに関して、わかりやすく、まとめられており、興味深い内容でしたので、ご紹介させていただきました。
■海外ニュース
□ソフトウェアテストサイクルをスピードアップする5つの重要なヒント
https://www.eweek.com/enterprise-apps/how-to-speed-up-your-software-testing-cycle-5-key-tips/
こちらは、「eweek.com」に掲載されていた内容となります。
◇ヒント1:テストスイートは10分で完了
理想的には、ソフトウェア開発者は1週間に40時間コードを記述して配信しますが、会議や通常の中断により、実際の開発は1週間に30時間未満になることがよくあります。
1つの原因：開発者は待機に時間がかかりすぎます。
コードを作成したら、レビューされるのを待ちます。
コードがデプロイされるのを待ちます。次に、機能および品質保証のテスト結果を待ちます。
最後に、検証と統合テストを待ちます。
コードを本番環境に移行するには時間がかかりすぎます。
開発者は、コーディングプロセスの各ステップの間に1日以上待つことがあります。
コードの変更に関するフィードバックを受け取る前に「わずか」1〜2時間遅れた場合でも、生産性は大幅に低下します。
待っている間、開発者は手間のかからないバグ修正を任されるかもしれません。
この「コンテキスト切り替え」にはコストがかかり、分析的な問題解決に必要な集中的で創造的な焦点が中断されます。
その心の枠組みに入るには、時間とエネルギーが必要です。
多くの人にとって、コンテキストスイッチングは、生産的な精神状態を妨害し、モチベーションを低下させます。
◇ヒント2:テストスイートの実行時間を90%短縮することは可能
多くの人は、テストスイートの実行時間を最大90％短縮することが非常に実現可能であることを知って驚いています。
アプリケーションアーキテクチャの分野はクラウドコンピューティング、マイクロサービス、コンテナ化のパラダイムに移行しましたが、テストは段階的に進化していません。
テストは、ソフトウェア開発ライフサイクルの中で最も過小評価されている（または無視されている）部分の1つです。
ほとんどのテストスイートは、テストテクノロジーが進歩したため、不必要に、昨年のモノリスのように構築されています。
テストスイートはマルチスレッドにすることができますが、多くの場合そうではありません。
コードの変更に関連するテストのみを選択的に実行できますが、多くの場合、スイート全体が任意に実行されます。
インテリジェンス、アクセラレーション、レポート用に設計できますが、そうなることはめったにありません。
テストに対する最新のソフトウェアアプローチは、最新のテスト結果につながる可能性があります。
リファクタリングと管理に何年もかかることはありません。
実際、それほど複雑ではありません。
◇ヒント3:エンタープライズレベルのテストアクセラレーションを1つのスプリントで実装可能
大企業の力を活用するのは難しい場合があります。
優先順位の異なる複数の部門を囲い込むことは簡単なことではありません。
プロジェクトは必然的に当初の見積もりよりも時間がかかり、費用もかかります。
なぜこれが起こるのですか？
大規模な実装では、動作の変更、インフラストラクチャの構築、ツールの更新などが必要になるためです。
開発チームは、ワークフローに変更を加えない最新のツールを活用し、同じコマンド、コミットプロセス、およびテスト手順を使用できるようにする必要があります。
変更されるのは、テストスイートが完了するのを待つ時間です。
最良のシナリオでは、テストの準備には、依存関係リストに単一のgemまたはパッケージを追加するだけで済みます。
◇ヒント4:テストを高速化することで、開発者の生産性、満足度、及びオンボードを維持する
開発者の役割はこれまで以上に重要であり、需要があります。
CompTIAによる2020年12月の求人レポートによる と、開発者の仕事は、市場に出回っている391,000の新しい技術職のうち62,900（16％）を占めています。
開発者が実際に開発できない場合、開発者は自分の仕事に対するモチベーションと熱意を失います。
フィードバックと忙しい仕事を待つことは欲求不満を生み出します。
それは彼らが別の仕事を探し始めるときです。
逆に、開発者がコードの作成に費やす時間が長いほど、開発者はコードを楽しんで、保持期間が長くなります。
生産性を高め、仕事を楽しみ、やる気を感じるツールを持っている開発者をつかむのははるかに簡単です。
◇ヒント5:テストアクセラレーションは開発者の生産性を次の飛躍に導くことができる
過去20年間で、開発者の生産性は、マイクロサービスアーキテクチャ、コンテナ化、クラウドインフラストラクチャ、サーバーレスによって向上しました。
これを変更することが可能になり、多くの組織では、毎週数千ドルを節約できます。
インフラストラクチャ、コーディングパラダイム、およびスケーリングが最新化されたので、開発者がコード作成で直面する障害に対処するときが来ました。
テストアクセラレーションは、開発者の生産性を大幅に向上させることができます。
企業は、開発プロセスの現状を調査する必要があります。
テストスイートはほんの数分で完了し、開発者はコンテキストスイッチを強制されるべきではなく、コードの配信時間はより速くなるはずだと信じている人にとって、それがどのように達成できるかを示すことができます。
ソフトウェアテストのサイクルスピードアップを図るヒントがまとめられていましたので、ご紹介させていただきました。
□AIベースのヘルスケアドメインでのソフトウェアテストの課題
https://www.softwaretestingnews.co.uk/software-testing-challenges-on-ai-based-healthcare-domains/
こちらは、softwaretestingnews.co.ukに掲載されていた内容となります。
ヘルスケア分野のAIに関するソフトウェアテストについて、まとめられており、日本ではあまり目にしない内容でしたので、ご紹介したいと思います。
◇バックグラウンド
世界中の医療機関は、AIベースの医療システムとドメインを世界中で歓迎しています。
それにもかかわらず、医療機関はまだAIの可能性を認識していません。
しかし、非常に多くの製品やシステムが、臨床診療や臨床システムでAIアルゴリズムを使用し始めています。次のセクションでは、ヘルスケアにおけるAIの概要を説明します。
◇ヘルスケアにおける人口知能の成長する可能性
ますます多くの文献が、X線写真、癌、その他の長期的な健康状態の解釈など、医療におけるAIのさまざまなアプリケーションを実証しています。
・電子カルテ（EHR）から収集された膨大な量のデータの分析は、臨床的に関連する情報を抽出し、診断評価を行うこと（Escobaretal。l2016）
・集中治療に移行するためのリアルタイムのリスクスコアを提供することを約束します。
（Liangetal。l2016）
・院内死亡率、再入院リスク、長期滞在および退院診断の予測
（Rajkumar etal。l 、2019）
・急性腎障害を含む将来の悪化の予測
（Tomaševetal。l、2019）
・人工呼吸器の離脱や敗血症の管理などの意思決定戦略の改善、観察データからの治療方針の学習。
（Prasadetal。l2019）
AIは、ヘルスケアの成果を急速に改善する大きな可能性を秘めています。
AIツールとソフトウェアは、より個人主義的で患者中心のアプローチで医療提供の未来を形作ります。
◇AIとMLでのソフトウェアテスト
機械学習とAIアルゴリズムの開発の中核となる要素は、テストです。
これをソフトウェアテストの単体テストと比較することができます。
AI / MLエンジニアは、AIアルゴリズムを開発し、トレーニングデータが、データを過剰適合または過適合することなく、適切な一般化でデータを正確に分類または回帰するのに十分な仕事をすることを確認します。
エンジニアは、ソフトウェアテストのテストデータのようないくつかの検証手法も使用します。
AIベースのソフトウェアは、アルゴリズムとデータを一緒に使用して、ハイパーパラメータ構成データと関連するメタデータを考慮に入れます。
これらは主に連携して結果を表示します。
アルゴリズムの検証フェーズで間違ったパラメーターが取得された場合、探している結果に影響を与える可能性があります。
より正確な結果を得るには、エンジニアはアルゴリズム自体を再検討し、ハイパーパラメータを変更し、おそらくより良いトレーニングデータを使用してモデルを再構築する必要があります。
これは、テスターがシステムの動作を理解するために行っていたシステムテストと比較される場合があります。
対照的に、Alのエンジニアは、アルゴリズムの動作を理解するためにかなりの作業を行うことができます。
アルゴリズムとモデルがうまく機能する場合があります。
ただし、それを現実の世界に展開すると、多くのエラーが発生する可能性があります。
それでも、トレーニングフェーズで行うはずだったすべてのことを実行しました。
私たちのモデルは期待に応えて合格しましたが、モデルが運用可能になったときの「推論」フェーズでは合格していません。
これは、本番環境のモデルを処理するためにQAアプローチが必要であることを意味します。
◇AI-MLベースのヘルスケアドメインでのソフトウェアテストアプローチ
標準のヘルスケアドメインテストは、安全性、コンプライアンス、他のエンティティとの相互依存性などの要素を使用してヘルスケアアプリケーションをテストするプロセスです。
テスターは、ヘルスケアアプリケーションの品質、信頼性、パフォーマンス、安全性、および効率をその場所で確認します。
ソフトウェアは受け入れられたとおりに動作します。
現在のAIベースのツールとソフトウェアには、Alのエンジニアがすでに行っているアルゴリズムと論理テストが付属しています。
ただし、テスターにとって難しい部分は、ソフトウェアとシステム内でアルゴリズムがどのように動作するかをテストすることです。
QAチームは、ヘルスケアシステム、アルゴリズム、およびこれらの両方がどのように連携するかなどに関するドメイン知識とバックグラウンドを持っている必要があります。
AIベースのヘルスケアソリューションをテストするには、特定のオーダーメイドのシナリオとヘルスケアシステムのニーズごとに調整された戦略的アプローチが必要です。
ほとんどのヘルスケアアルゴリズムは非常に複雑で、ソフトウェアテスターの予測は困難です。
アルゴリズムはトレーニングとテストセットを経て、人間の行動に関連するいくつかの意味のあるデータを作成します。
データセットが不十分または不完全であるか、データの品質が低いと、ソリューションに偏りが生じる可能性があります。
システムは、同じものを見るように過度に訓練されているか、正確な判断を下すのに十分な訓練を受けていません。
テスターがAIベースの医療システムをテストしているときに直面するもう1つの課題は、システムのテストに必要なデータの量です。
制限されたデータ項目に近づくことは、システムの統計的保証を提供しません。
これは、テスターがどのようなスキルを持っているべきか、そしてテスターがその複雑さのレベルのこれらのシステムとどのように相互作用するべきかについて、テスターにとって別の課題への門戸を開きます。
◇AI-MLベースのヘルスケアドメインに必要なスキルとアプローチは？
前に説明したように、アルゴリズムの作成とトレーニングは、いくつかのテスト要素を使用した手動および自動のプロセスです。
主にテスターは、複雑さに関連する問題のほとんどを解決するために、境界テストとデュアルコーディングを使用しています。
テスターはある程度のデータ知識を持っている必要があり、アルゴリズムに精通していることが不可欠なスキルです。
場合によっては、使用するアルゴリズム、データ量、またはソリューションの複雑さ、これらのシステムのテストは、ソリューション自体と同じくらい複雑になる可能性があります。
テスターからの広範な技術およびデータサイエンスの専門知識が必要であるため、AIテスターの仕事は手動または自動化テスターとは異なります。
ただし、テストプロセスへのアジャイルアプローチと学際的アプローチは、テスターがアルゴリズムとその機能についてより深く理解するのに役立ちます。
結論として、AIベースのヘルスケア製品は日々成長するでしょう。
テスターとして、私たちは最も複雑なアルゴリズムとロジックの1つをテストする準備ができている必要があり、命を救い、人々を保護する可能性があります。
以上、ヘルスケア分野のAIに関し、ソフトウェアテストの課題についての記事をご紹介させていただきました。
■最後に
今回は、国内ニュース2記事、海外ニュース2記事を取り上げてみました。
次週も、ソフトウェアテスト、テスト自動化に関するニュースをご紹介したいと思います。
最後まで見て頂き、ありがとうございました。
ソフトウェアテスト自動化の教科書 〜現場の失敗から学ぶ設計プロセス
教養としてのAI講義 ビジネスパーソンも知っておくべき「人工知能」の基礎知識
