検索キーワード: 「ソフトウェアテスト」


【QA】不具合を発見した時

ソフトウェアやその機能についてテストを行った場合、何かしらの不具合を発見することがあります。実施者は発見した不具合が市場への流出するのを防ぐ最初の防衛ラインとなります。では実際に不具合を発見した場合、実施者はどう不具合報告をすればよいか。※開発チーム所属するQA担当であることを想定した内容となります。プロジェクトによって不具合を報告する際のルールは様々なため、この限りではないことを留意してください。

初心者

テスト自動化

テスト自動化とは、人の手によって行われるソフトウェアテストの全体あるいは一部を自動化することを意味します。そもそもソフトウェアテストは、不具合を見つけることが目的です。そのため、テストを繰り返し行うことも増えています。テスト自動化によって、テストにかかる人的負担を減らし、将来的なコストの削減が期待できます。テストといっても、その中にはさまざまなプロセスが含まれます。ソフトウェアテスト技術者資格認定組織である「ISTQB(国際ソフトウェアテスト資格認定委員会)/JSTQB(日本ソフトウェアテスト技術者資格認定組織)」の定義によると、テストプロセスは以下の5つの要素で構成されています。テストプロセス ・テスト計画作業とコントロール ・テストの分析と設計 ・テストの実装と実行 ・終了基準の評価とレポート ・終了作業

テスト(運用・保守・サポート)

ITインフラの基礎【初心者向】

ネットワークとは、複数のコンピュータを通信回線で接続し、データのやり取りを行えるようにしたもので、正確にはコンピュータネットワークと呼ばれます。当初は、管理者が特定のコンピュータ同士を接続しただけのもの(=プライベートネットワーク)でしたが、段々とプライベートなネットワーク同士を接続するようになり、世界中のネットワークが接続されたインターネットとなりました。

初心者

【ソフトウェアテスト】状態遷移テスト

何かの操作を行うと何かのアクションを実行して実行後の状態になり、実行後の状態からさらに次の操作を行うとまたアクションを返すといったように、ソフトウェアに限らず何かしらの機能を持つものは、機能を使う前と機能を使った後でそれぞれ状態が変わります。状態が仕様想定どおりに遷移しているかどうかを確認する技法として、状態遷移テストがあります。

テスト(運用・保守・サポート)

【ソフトウェアテスト】欠陥分析手法について

「【ソフトウェアテスト】不具合報告のインシデントレポートについて」記事で記載したとおり、インシデントはチケット作成して報告されたのち、内容を分析して対応をし、作成から完了に至るまで管理します。そうして蓄積されたインシデントレポートは、報告対応されたそのレポート自体が、以降で類似の現象を検出した際の資料として用いられる面もありますが、内容を分析することで、今後の開発品質向上を目指すための判断材料として活用することができます。いずれのインシデントレポートも、何かしら問題があったから作成されているものであり、問題点は解決した時点で完了とはせずに、内容を振り返って同じ轍を踏まないように以降の活動を随時改善していくことが肝要です。近年のアジャイル化が進んでいるプロジェクトなどの場合は、直近の開発内容に対するインシデントレポート単体を都度分析するような時間も設けられずに次々進んでいくことがありますが、プロジェクト全体としてインシデントレポートを統合管理し、アジャイル開発の各プロジェクト進行とは別途で機会を設けて、振り返りと共に不具合分析を行うことは、高品質な開発を目指す上で必要な活動です。ソフトウェア開発現場の現状として、プロジェクト形式もインシデントレポート形式もさまざまある状況なので、欠陥分析の手法もこれが絶対という唯一のものではなく、状況や期間などに合わせて必要な手法でアプローチをすべきです。統計的内容に基づく分析、インシデントごとの要因に基づく分析、その両面からの分析など、どのような面からアプローチするかによって用いる手法もさまざまあります。

テスト(運用・保守・サポート)

【ソフトウェアテスト】レビューについて

ソフトウェアテスト領域には、動作させることを前提とした対象をテストする動的テストと、動作させることを前提としていない対象をテストする静的テストがあります。単体テストや結合テストなど、作成したものを動作させてテストをするのが動的テストですが、静的テストは動作させる対象がなくてもテストが実施できます。静的テスト活動の種類としてレビューがありますが、開発活動の中で作成された製品やシステム自体以外のものは、レビュー対象としてテストすることが可能です。

テスト(運用・保守・サポート)

【ソフトウェアテスト】QC7つ道具と新QC7つ道具 ②

QC7つ道具は、主に生産現場における各種数値を元に品質やリスクなどを分析して、品質管理を進める手法でしたが、品質管理に関わる問題は定量的分析のみでは対応しきれないようなものもあります。「【ソフトウェアテスト】欠陥分析手法について」記事でも触れているとおり、統計的分析は定量的解析手法で対応可能ですが、問題の要因に対してアプローチしようと考えた場合に、あらゆる要因が数値化できるのであれば定量的分析手法を用いれば解決できますが、数値化が困難であったり、集計して数値化して分析すると考えた場合に非常に手間がかかるような要-因に対しては、定性的な分析手法が必要になります。また、生産活動そのもののみではなく、プロジェクト全体の管理もQC活動、品質管理活動で対応すべき事象です。プロジェクト進行における問題点の可視化や共有に際して、数値データではない文字データや言語データでの集計管理をして、そうした定性的データを共通化された手法を用いて分析することにより、どのような生産現場でどのようなスキルの人が品質管理対応をする想定になったとしても、ある程度容易に対応できるように作成された手法のなかでも代表的な7つの手法が、新QC7つ道具(N7)として分類されています。英語ではNew Quality Control – 7 Tools等と呼ばれます。

テスト(運用・保守・サポート)

【ソフトウェアテスト】ソフトウェア開発とテスト活動について②

「【ソフトウェアテスト】テストレベルについて ①」記事に記載のとおり、開発ライフサイクルモデルには形式や期間によってさまざまなモデルがあり、テストを実施するタイミングもモデルによってさまざまです。先に挙げた開発工程の例である要件定義→設計→開発→テスト→リリース/保守を一連の流れとする開発ライフサイクルも、このフローを開発期間の流れとして実施するのはあくまでウォーターフォール型モデルのようなシーケンシャルな開発ライフサイクルであり、イテレーティブ開発モデルやインクリメンタル開発モデルでは、各工程とテストが同時に進行したり、無駄をなくすことを目的としてあえて一部工程を省くこともあります。V字モデルは各工程とテストが同時進行する例です。要件定義の段階で要件定義に対するテストを実施、システム設計の時点で設計された内容に対してテストを実施といったかたちで、開発完了後にようやくテストではなく、常に工程の早期段階でテストを実施します。開発完了後のテストで不具合が検出されると工程の手戻りが発生してしまい、工数に無駄が生じますが、早期にテストを実施することにより、上流工程の段階で不具合や懸念を可能な限り取り去って開発作業の手戻りを少なくし、無駄な工数の増加を防いだり、最終的な品質の向上を目指すことができます。このようにV字モデルの左側で行う開発活動に対して早期にテストを実施して効率的な開発活動を目指す手法をシフトレフトと呼びます。イテレーティブ開発モデルやインクリメンタル開発モデルとなると、さらに各工程とテストが早期段階で実施されていきます。全体的な流れをより細かく迅速に行い、それを細かく繰り返していくサイクルが、現在のソフトウェア開発形式の主流になってきています。

テスト(運用・保守・サポート)

【DOM】基本のまとめ | 初心者向け

HTMLの標準オブジェクトモデルおよび、プログラミングインターフェイスであるDOMについてまとめました。DOMは、Webアプリケーション制作にかかせない知識となっています。ぜひ最後までお読みください!

製造・コーディング(PG/フロントエンド)

【初心者用】AWS基礎③

AWSの基礎レベルの知識を身につけるために、範囲に沿って学んでいきましょう。前回は、クラウドの概念、セキュリティのAWSの責任共有モデルについて学習してきました。続きからはじめていきたいと思います。

その他(インフラ)

【C# WPF】WPFを理解したいC#初心者の話【基礎知識編2】

C# WPFについて学んでいく過程を備忘録として残して置きたいと思います。

製造・コーディング(PG/フロントエンド)

サーブレットJSPを学ぼう#5

サーブレットJSPを学びます。

製造・コーディング(PG/フロントエンド)

関連タグ

カテゴリ別人気記事

もっと見る
テレワーク関連人気記事

週間人気記事

もっと見る