皆さん、こんにちは。
今週もソフトウェアテスト、テスト自動化に関するニュース記事をご紹介していきたいと思います。
今回は国内、海外ニュース2記事をご紹介回したいと思います。
■記事内リンク
「国内ニュース」
・無料共催セミナー『QCD(品質・コスト・進捗)向上のテクニック』
「海外ニュース」
・回帰テストは再テストではありません
■国内ニュース
□無料共催セミナー『QCD(品質・コスト・進捗)向上のテクニック』
https://prtimes.jp/main/html/rd/p/000000128.000030691.html
こちらは、バルテス社が翌年2022年1月26に、無料Webセミナー「やっぱり基本のQCD向上に立ち戻ろう”セミナー ～品質・テスト戦略、プロジェクト管理、設計力向上～」が開催される内容となります。
こちらのセミナーでは、バルテス社とシステムインテグレータ社が共同でのWebセミナーとなるようです。
◇セミナー概要
| ・タイトル： | 「やっぱり基本のQCD向上に立ち戻ろう」セミナー ～品質・テスト戦略、プロジェクト管理、設計力向上～ |
| ・日時： | 2022年1月26日（水）10:00～12:00（Webセミナー） |
| ・定員： | 500名※（先着順） |
| ・詳細リンク： | https://www.qbook.jp/event/20211222_1285.html |
| ・タイムスケジュール： | 10:00～10:30 セッション1 QCDを達成するための品質・テスト戦略 10:30～11:00 設計力が成功のカギを握る！良い設計書を書くためのコツ 11:10～11:40 セッション3 プロジェクトを成功に導くためのQCD統合管理とは？ 11:40～12:00 セッション4 質疑応答 |
QCD、設計書、管理に関する内容のWebセミナーのようです。
午前の2時間で開催されるとのことですので、ご興味のある方は、上記詳細ページにアクセスしてみてはいかがでしょうか。
■海外ニュース
□回帰テストは再テストではありません
https://www.accelq.com/blog/regression-testing-is-not-retesting-know-the-difference/
こちらは「accelq.com」に掲載されていた内容となります。
回帰テスト、再テストについて細かく述べられておりましたので、ご紹介したいと思います。
◇初めに
エラー、バグ、誤謬はすべてソフトウェア配信プロセスの一部です。
これらの非効率性の存在が、最終的にリリースの改善への道を開きます。
ただし、これは、適切なテスト計画が実施されている場合にのみ可能です。
ただし、「健全なテスト計画」という用語は、特定のシナリオとアプリケーションの最良のテスト手法に関する個別の議論を促進します。
これは、テスト駆動型のアプローチである必要がありますか？
負荷駆動型のシナリオ？
そして、再テストはどうですか？
たとえば、再テストとは、以前に実行した回帰テストを手動で再実行して、それがまだ機能するかどうかを確認することです。
対照的に、回帰テストでは、新しい機能が既存のコンポーネントや機能を壊さないことを確認します。
残念ながら、定期的な回帰テストを実行する場合、それらが再テストと同じものであると思い込んでしまうのは簡単です。
どちらもテストプロセス全体に大きく貢献しますが、実装、アプリケーション、および実行は異なります。
では、これら2つの用語をもう混同しないようにしましょう。
◇回帰テストとは何ですか？
回帰テストは、プログラムコードとデータファイルを分析し、関連するテストを実行して、アプリケーションまたはソフトウェアに加えられた変更が既存の機能を壊さないことを確認するプロセスです。
これは、ソフトウェアテストにおける重要なプラクティスです。
回帰テストの主な目標は、新しい機能がアプリケーションに導入されたときに不要な回帰をブロックすることにより、ユーザーと開発者のバグのない環境を維持することです。
そのため、開発の初期段階でバグが見つからなかった場合でも、特に重要な新機能を追加した後は、回帰テストを定期的に実行する必要があります。
◇再テストとは何ですか？
回帰テストとは異なり、再テストは、開発、テスト、およびリリースされた特定の機能が期待どおりに機能しているかどうかをテストするために行われます。
これは通常、コードまたはソフトウェアに大幅な変更が加えられた後に実行されます。
再テストを実行するときの目標は、既知のバグが再出現したかどうか、または新しいバグが出現したかどうかを判断することです。
◇回帰テストはいつ行われますか？
新しい機能が実装された後、アップグレードまたはパッチがインストールされた後、新しいリリースを展開する前など、さまざまなケースで回帰テストの適用が必要になります。
最も一般的なタイプの回帰テストは、次のように要約できます。
・新機能の実装
このような場合、回帰テストは、新機能に必要なすべてのコードの仮定に対処します。
それでも正しく機能します。
・更新とパッチの適用
インストールの前または後に回帰テストを実行して、変更が既存のソフトウェアと互換性があることを確認できます。
同様に、新しいリリースをデプロイした後に回帰テストを実行して、意図しない結果が同じものに関連付けられていないことを確認できます。
◇再テストはいつ行われますか？
最も一般的なタイプの再テストケースは、次のように要約できます。
ソフトウェアにバグがある場合、レポートに問題がある場合、または他の問題が再発した場合は、これらの問題が発生しないことを確認するために再テストが行われます。
ビジネスロジックの変更–レポートの番号が変更されたか、データベーステーブルに新しいフィールドが追加されたか、または全体的な機能に影響を与えるその他の注目すべき変更が行われた可能性があります。
◇回帰と再テスト–違いの概要
| 回帰試験 | 再テスト | |
| オートメーション | 自動回帰テストのアプローチは実行可能 | 動機は既存の領域を修正することであるため、メソッドを自動化することは不必要 |
| 関与 | 更新、アップグレード、パッチなど、回帰テストは永続的な監視プロセスである必要がある。 | 再テストは最初にバグを特定することに依存するため、再テストは各テストサイクルで採用される場合と採用されない場合がある。 |
| タイプ | 修正、選択、プログレッシブ、部分、ユニット、再テストなどすべてで適用可 | タイプはないが、必要に応じて |
| 欠陥の検証 | NA | 再テストプロセスの一部 |
| 適用性 | 合格したテストケース | 失敗したテストケースの修正。 |
| 優先度 | 低（並列テスト中に例外が表面化） | 高い |
| 正確さ | テストケースを事前に決定するために、一貫性を確保するために各方法論を同じアプローチで実装することはできない。 | テスト戦略は以前の調査結果に基づいて変更されることが多いため、繰り返される可能性はほとんどない。 |
◇まとめ
回帰テストは再テストよりも複雑であり、このタイプのテストを続行することの利点はかなりのものです。
ただし、プロセスの徹底性が大幅に拡張されているため、再テストと回帰テストの組み合わせが長期的に役立つことは否定できません。
その観点から、それらの間の選択は存在しません。
どちらも機能が重複しており、テストプロセス自体が独自のアイデンティティを提供します。
これも誤解されるべきではありません。
■最後に
今回は、国内ニュース2記事を取り上げてみました。
次週は、年末年始となるため、お休みいたします。
最後まで見て頂き、ありがとうございました。
