皆さん、こんにちは。
今週もソフトウェアテスト、テスト自動化に関するニュース記事をご紹介していきたいと思います。
今回は国内、海外ニュース2記事をご紹介回したいと思います。
■記事内リンク
「国内ニュース」
・3月18日(金)開催freee Tech Night × 食べログ
「海外ニュース」
・品質テスト計画を立てる方法
■国内ニュース
□3月18日(金)開催freee Tech Night × 食べログ
https://prtimes.jp/main/html/rd/p/000000836.000006428.html
こちらは、3/18(金)にてfreee株式会社と食べログを運営する株式会社カカクコムがコラボしたイベント内容となります。
freee社は、クラウド会計・人事労務ソフト開発を行われており「会計freee」「人事労務freee」などを展開されている企業です。
free社は「freee Tech Night」を2018年12月以来、3か月に1回を目標として定期的に開催されているようです。
今回は、食べログのカカクコム社とコラボした「〜何度でも食べたい〜テスト自動化導入の必勝レシピ」イベントが開催されます。
◇イベント概要
イベント概要は以下となります。
・イベントタイトル: | freee Tech Night × 食べログ 「〜何度でも食べたい〜テスト自動化導入の必勝レシピ」 |
・開催日時: | 3月18日(金)19:00~21:00(19:40〜21:00はアフタートークイベント) |
・参加費: | 無料 |
・申し込み方法: | https://freee-tech-night.connpass.com/event/241148/ |
・タイムテーブル: | 19:00-19:05 イントロダクション 19:05-19:30 トークタイム 19:30- クロージング/アフタートークイベント参加者は場所移動 19:40-21:00 アフタートークイベント(途中退出自由) |
上記イベントは、Youtubeのライブ配信形式で行われるようです。
また、過去に行われたイベント内容は、Youtubeチャンネル内に掲載されていました。
https://www.youtube.com/channel/UCIfYORSGo_hYtypApyTB-aQ
ご興味のある方は、上記アクセスされてみてはいかがでしょうか。
■海外ニュース
□品質テスト計画を立てる方法
https://www.softwaretestingnews.co.uk/how-to-make-a-quality-test-plan/
こちらは、「softwaretestingnews.co.uk」に掲載されていた内容となります。
品質を考慮したテスト計画に関する内容がまとめられていましたので、ご紹介したいと思います。
◇初めに
各組織内でどのような方法論が採用されているかに関係なく、製品またはサービス全体がどのようにテストおよび提供されるかを詳細に示すテスト計画は、重要な成果物です。
内部アプリケーション、サードパーティアプリケーション、アプリケーション間の統合などのテストがどのように行われるかを概説することが重要です。
組織が従うことを選択する可能性のあるアジャイル手法の例を検討することで、これをさらに拡張できます。
これは、ソフトウェアを開発するための最も一般的な方法であるためです。
この方法論は、誰もが知っているように、ビッグバンの実装を待つのではなく、小さなチャンク(小さな実装)で配信することを可能にします。
洗練されたユーザーストーリーは、アジャイル手法の重要な部分です。
たとえば、スプリントテストなどのテストフェーズに進みましょう。
スコープ/ユーザーストーリーを確認した後、最低限、次のことを定義してみてください。
◇1.必要なテストの種類
・機能および統合テスト
・非機能テスト
・ユーザー受け入れテスト
テストの種類を説明する際には、以下の点を考慮してください。
・テストの範囲
・提供される新機能のテスト方法
・データ要件
◇2.受け入れ基準の明確さ
・テストの受け入れ基準が明確に定義されていることを確認します
・ユーザーストーリーからの受け入れ基準に基づいてテストの受け入れを定義します
・受け入れ基準がユーザーによってレビューされ、合意されていることを確認します
◇3.テスト環境
多くの組織では、環境はさまざまな部門によって構築されています。
したがって、環境要件を明確に定義することが重要です。
要件が明確であることを話し合い、確認するための会議は、常に役立ちます。
・テストを実施するにはどのシステムが必要か?
・テストを実施するにはどのようなデータが必要か?
・サポートが期待されるその他の重要なアクティビティ(バッチ実行、監視、アラートなど)は?
◇サードパーティ製品のテスト
組織でサードパーティベンダー製品を使用している場合は、ベンダーからリリースを入手している可能性があります。
ほとんどの場合、「ベンダースプリント」がどのように機能するかについては何も言えません。
この場合、テスト計画の観点から、最初に計画を定義するために上記の点を参照してください。
受信組織のクライアントとして、受信したリリースが常に期待どおりに機能していることを確認することが非常に重要です。
さまざまな環境にリリースを展開するのに時間と労力を費やしたくないので、リリースが組織にさらに受け入れられるためには、リリースが満たす必要のある方法と基準が必要です。
その後、基本が機能しないことがわかります。
これに対処する1つの方法は、リリースの主要な機能を検証する、迅速に(数時間で)実行できる事前定義されたリグレッションパックがあることを確認することです。
◇リグレッションテスト
私にとって、これはテストの最も重要な側面の1つです。
以前に機能していた「影響を受けていない」機能が実際に機能していることを(検証することによって)確認する必要があります。
機能/ユーザーストーリー/要件は、異なるスプリント間で個別にテストされますが、以前に機能していた機能が引き続き機能するかどうかは保証できません。
したがって、サービスの最小限の主要な柱で検証するリグレッションパックを用意することが非常に重要です。
このようなリグレッションパックを自動化するために投資し、新しいコードがチェックインされるとすぐに、または少なくとも毎日実行されるようにする必要があります。
上記の重要なポイントの定義は、個々のテストフェーズのほとんどに適用できます。
スプリントテストまたはサードパーティベンダーからの個々のリリースのテストを終えたら、次のステップは、コンポーネントを統合し、機能、インターフェイスをエンドツーエンドで検証することです。
◇非機能テストと運用受け入れテスト
「非機能テスト」
多くの場合、主要なコンポーネントが十分に機能的にテストされたらすぐに、機能しない観点から製品またはサービスを検証する必要があります。
非機能テストで実施される一般的なフェーズは次のとおりです。
・性能試験
・負荷テスト
・ストレステスト
・セキュリティテスト
パフォーマンス、負荷、およびストレステストに関する追加の考慮事項は次のとおりです。
・測定が必要なものの明確さ
・時間の経過に伴う負荷パターンが本番環境と同じであることを確認します
・ユーザーパターンの明確な理解
・測定するインフラストラクチャとパフォーマンスモニター
◇運用受け入れテスト
エンドツーエンドのサービスを稼働させる前に、IT本番/実行チームはサービスを「実行」(ファミリアリゼーション)し、障害が発生した場合に対応できることを確認する必要があります。
したがって、監視とアラートをテストし、問題の修正手順が正しいかどうかを検証し、サービスの他のサポートの側面を検証することが重要です。
さらに、多くの場合、このフェーズでは次のことがカバーされます。
・高可用性
・フェイルオーバーとディザスタリカバリ
統合/ユーザーの受け入れ/エンドツーエンドのサービステストを検討する際に、(上記に加えて)いくつかの追加のキーポイントを検討することをお勧めします。
◇さまざまなコンポーネントにわたるデータ要件
・事前に考えないことで多くの時間が無駄になりる
・各システムのデータ要件は何か
・そのデータはどのようにシステム間で同期する必要があるか
・セットアップを検証して、詳細なテストの準備ができていることを確認するにはどうすればよいか
この事前に十分な時間が費やされていることを確認してください。
そうしないと、統合テストが実行されるたびに、労力の浪費、実際のテストの実施の遅れが発生します。
さらに、機能ではなくデータが原因で誤った欠陥が発生する可能性があります。
◇テスト環境とサポート要件
多くの組織では、コードが「より低い環境」から「より高い環境」に移行するにつれて、より厳密な制御が適用されます。
つまり、特定のグループの人々だけが特定のことを行うことが許可されています。
このような場合は、事前にサポートのリクエストがあることを確認してください。
◇毎日の主要な活動の本(マニュアル)を実行する
これはもう1つの強力なアーティファクトです。
誰が、いつ、など、実行する必要のあるすべての主要なアクティビティは、Runbook(マニュアル)で決定できます。
これは、このようなテストフェーズが実行されているときにステータスレポートメカニズムになることもあります。
◇サインオフのテスト
これはプロジェクト提供の非常に重要な部分であるため、事前に定義され合意された基準を持つことは常に役立ちます。
このような基準を定義するために、さまざまな主要な利害関係者と連携することが重要です。
プロジェクトチームにこれらの基準を何度も思い出させることも不可欠です。
組織、プロジェクトのニーズに応じて、常にドキュメント全体を微調整する必要があります。
このに記載されているものはすべて、ガイドとして検討する必要があります。
■最後に
今回は、以上の国内ニュース、海外ニュースを取り上げてみました。
次週も、ソフトウェアテスト、テスト自動化に関するニュースをご紹介したいと思います。
最後まで見て頂き、ありがとうございました。
【この1冊でよくわかる】ソフトウェアテストの教科書詳細はコチラをクリック!