もくじ テストマップとは テストマップの目的・必要性 テストの全体像が分かるようにするため どの機能とどの観点の組み合わせを重点的にテストすべきかを明確にするため テストマップの書き方 まとめ 1．テストマップとは テストマップとは、テスト設計仕様書でまとめた、機能一覧と観点一覧を組み合わせて表にしたものです。 ただし、単に組み合わせるだけではなく、各組み合わせに対してテストの重要度を定めていく必要があります。 ※機能一覧、観点一覧については、「テスト設計仕様書」をご参照ください。 テスト設計仕様書では、テスト計画書で定義されたテスト対象機能と観点を細分化することで、テスト対象となる機能と観点を明確にしました。 テストマップでは、この細分化した機能と観点を組み合わせることで、各機能に対してどのような観点のテストをどのぐらい重点的に行うのかを定義していきます。 2．テストマップの目的・必要性
テスト設計仕様書は、テスト基本設計プロセスのoutput（成果物）として位置付けられています。 テスト設計仕様書の主な目的は、主に下記の2点です。 どの部分をテストするのか どのような内容のテストをするのか そのテスト対象の全体を見据え、上記を明確化し、テストの指針や骨格を定めることにあります。 本記事では、テスト設計仕様書の各項目と使い方、作成時の注意点について解説していきます。 もくじ テスト設計仕様書とは テスト設計仕様書の各項目 テストの目的と背景、重要テスト項目 テスト設計のプロセス定義 テストアプローチ テスト環境・使用機材 テストアプローチ作成の流れ テスト対象機能(要素)一覧 テスト観点一覧 重要度の決定 テスト設計仕様書 作成時の注意点 テスト設計仕様書はテスト設計工程全体の品質を左右する 誰が見ても分かりやすい記述、分類を心がける テスト設計仕様書の使い方 ステークホル
「テスト計画」とは、テストの設計、実装、実施、管理といった、テストのすべての指針を定めるものです。「テスト計画書」とは、これらをまとめたドキュメントのことを指します。 テストの成功・失敗は、テスト計画で決まると言っても過言ではありません。テスト計画が適切に策定できれば、テストプロジェクトは円滑に遂行される可能性が高まります。 本記事では、Qbookで公開している「テスト計画書」のテンプレートに沿った形で、計画書の作成方法について説明しています。 無料でダウンロードしていただけるテンプレートは、ISO/IEC/IEEE 29119（以下、29119規格）に対応しており、29119規格に準拠させる場合、必須項目を入力していくことで規格に適合したテスト計画書が完成させることができます。 ぜひ、実務での計画立案にご活用ください。 もくじ テスト計画書とは 「QUINTEE テスト計画プロセス（29
効率的なHAZOPの進め方 HAZOPは安全なシステムを設計する際におこなうとよい分析手法です。 11の魔法の言葉（guide word)があります。 <この項は書きかけです。順次追記します。> This article is not completed. I will add some words in order. 魔法の言葉(guide word) 無逆他大小類部早遅前後 大小類部が空間を 早遅前後が時間を 大小早遅が量を 類部前後が質を 大が上限を（類早前） 小が下限を（部遅後） HAZOPの利点 物にも事にも適用できる。 システムの状態を検査するプログラムを作成するのに、いろいろ役立つ道具です。 一人作業 最初に１人で作業します。 責任を持って作業 利用者視点は設計能力が高くなくても担当可（設計者との差が分る） 誘導語と図（設計図・外観等）を見てありえない事を「外れ」に列記 想定
こんにちは！SmartHR 品質保証部所属の ark265 、gonkm です。 SmartHR全体のプロダクトを横断的に品質保証業務を行なうチームに所属してます。 今回はQAエンジニアが知識0から始めたセキュリティ分野に挑戦した2年間の取り組みを振り返りつつ記事にしました。 QAエンジニアがセキュリティ分野へチャレンジする時の参考になれば嬉しいです。 なぜQAエンジニアがセキュリティ分野に挑戦しようと思ったのか QAエンジニアが脆弱性診断を実施した理由と訪れた変化にも書いている内容に補足してお話します。 元々(今も)、脆弱性の発見は年に数回行なう外部のセキュリティベンダーによる脆弱性診断で行なっていました。 しかし、機能テストのようにセキュリティもより早いサイクルでプロダクトチームへ脆弱性などをフィードバックする仕組みを作り上げることができれば、より堅牢性の高いプロダクト開発ひいてはプロ
こんにちは！マネーフォワードのHR領域でQAエンジニアをしている森田です。 光陰矢のごとし。最初のQA組織立ち上げ奮闘記を公開してから、10ヶ月も経っていました。 今回は、入社1年という節目を利用して、何ができたのか、どのくらい貢献できているのかを振り返ります。 1人目QAとして頑張っている方、これから頑張る方、マネーフォワードでのエンジニア生活を知りたい方、どうぞ奮闘記をお楽しみ下さい。 2020年12月にQA組織ができ、2021年2月に入社note『マネーフォワード QA組織の歴史を紐解くと、様々なチームの形があった』より2020年12月にHRプロダクトのQAグループが新設され、私は2021年2月に部署1人目QAとしてジョインしました。 HR以外の雰囲気も気になる方は、こちらの記事もご覧ください。👇 この1年でできたことと貢献度◎：想定以上 ◯：概ね想定通り QAの社内外での認知 ◎
海外旅行予約アプリ『NEWT（ニュート）』は、2022年4月5日にコアローンチしました。私が入社したのは4月1日、プロダクトをリリースするわずか数日前のことでした。当時を思い返すと、まさに”カオス（祭り）”で、どのチームもお客さまへ『NEWT（ニュート）』を届けるためにリリースに向けたラストスパートを駆け抜けている印象でした。ですが同時に、コアローンチはゴールではなくあくまでスタートであり、リリース後いかに安定し、継続的により良いプロダクトをお客さまに届けられるかについて考えるべきだろうと私は冷静でした。 入社当時の令和トラベルには、リリースプロセスやテストプロセス、branch管理や課題管理方法などが明確には存在せず無秩序で、個々人の裁量とコミュニケーションによってあらゆる問題を解決していました。それはそれですごいことですが、プロダクトをリリースした後は、ある程度のルールやプロセスを設け
今まで、IPO（Initial Public Offering）前準備（東証グロース市場：2022年4月3日までの東証マザーズ市場）シリーズ期の「スタートアップ」・「ベンチャー」数社のQA組織立ち上げに関わってきました。 SaaSビジネスであったためARRの数値や毎月のMRRの数値も気になり、Churn MRRも。 そもそも、どのような経緯でQA組織を立ち上げることになったのか？ スタートアップやベンチャーでは、1つ目としてEXIT（IPOもしくはバイアウト）まで持っていくこと。 （VC：Venture CapitalやCVC：Corporate Venture Capitalからの資金調達だと特にリターンが大事になる）なので、IPOもしくはバイアウトまで持っていくプロセスの1つが事業としての品質プロセスです。 （資金調達ラウンドが「シリーズA」以降から「シリーズC」までは特に） 2つ目と
MagicPodミートアップの発表スライドです。 https://trident-qa.connpass.com/event/278843/
ソフトウェア設計を行う場合、必ずエラーや障害などの用語が飛び交うことがあるが認識がずれていることが多いので、以下に簡単にまとめてみた。 ソフトウェアの非正常を表す概念 ソフトウェアのエラーや障害などの非正常を表す概念の定義をいくつかピックアップしてみた。 JIS X 0014:1999の定義 出典: ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版) 誤差・誤り(error) 計算，観測もしくは測定された値または状態と，真の，指定されたもしくは理論的に正しい値または状態との間の相違。 障害(fault) 要求された機能を遂行する機能単位の能力の，縮退または喪失を引き起こす，異常な状態。 故障(failure) 要求された機能を遂行する，機能単位の能力がなくなること。 JIS X 0014では、意図しない結果を引き起こす人間の行為は、「間違い、人的過誤(mistake,
LINEが定期的に開催する技術者向けミートアップ「LINE Developer Meetup」。71回目となる今回は「QA - 開発プロセス全般における品質向上」をテーマに開催しました。そこで開発3センター サービスQA室の鈴木里惇氏が出前館プロジェクトにおけるLINE QAチームの取り組みについて紹介しました。 出前館プロジェクトにおけるLINE QAチームの取り組み 鈴木里惇氏（以下、鈴木）：さっそくトークを始めたいと思います。今日は『出前館プロジェクトにおけるLINE QAチームの取り組み』という話をします。 まず簡単に自己紹介です。LINEの開発3センターサービスQA室に所属している鈴木里惇と言います。所属はQA1チームとQA4チームという2つのチームで、マネージャーをしています。 それぞれのチームの役割としては、QA1チームがLINEファミリーサービスを担当していて、QA4チーム
iCARE Developer Meetupは、月次で開催している株式会社iCAREが主催するエンジニア向けのLT勉強会です。 本ミートアップのアーカイブや切り抜き動画もアップしますのでチャンネル登録もよろしくお願いします！ ---------------------------------------------------------------------------- 22回目の今回は、 QA(Quality Assurance)についてです！ 今回は『開発者自身によるQAが開く未来』と題してQAE(quality assurance engineering)をテーマに行います。 弊社iCAREでも開発チームの一部としてQAEチームを起ち上げるべく調査や採用活動などの準備をしてきましたがなかなかに苦戦しており、ようやく入り口に立てたかな？というところです。 ご登壇いただく
はじめに 品質管理部の河野です。先日、 ソフトウェアテストシンポジウム 2021 東京 の企画セッションで「仕様整理のためのテスト設計入門」というタイトルで発表してきましたので、本ブログでは発表に至った経緯や発表の感想などを報告いたします。 発表の経緯 まず、タイトルを見た方は、仕様を整理するためにテスト設計を使うのか？ と考えられたと思いますが、その通りでテスト設計はテストケースを設計する行為なのですが、実はテストケースを設計する過程で仕様を整理していることが多いです。ということで、テスト設計のための技術である、テスト設計技法を理解しながら、演習を交えて仕様の整理を実感できるような構成でチュートリアル形式で90分の発表を行いました。 それで、このようなテーマを思いついたきっかけは、私が以前作成したテスト設計の入門のテキストを近くの開発者の方に「開発者向けにやったら需要ありますか？」と質問
こんにちは。エンジニアリンググループ クオリティアシュアランス（QA）の窪田です。あっという間に時間が過ぎてしまっていることに焦りを感じています。今年度から採用にも関わらせていただいており、様々な施策を実施中です。今回は、ひょんなことから採用のためのペルソナを作成し、社内展開したところ、ポジティブな声が多く上がったため、ペルソナ作成の過程とその結果の例をご紹介したいと思います。 背景 採用ペルソナ 組織目標の明確化 必要な人材の明確化 ペルソナの作成 名前 年齢 プロフィール 課題 達成したいこと 感情 代替手段 利用メディア スキル 関係者内でのすり合わせ QAペルソナの例 感想 We're hiring! 背景 今年度からデザイングループのGLに就任した古結から、デザイングループの紹介がありました。その中で知り合いにデザイナーがいたら紹介して欲しいといった話もあり、 資料 に、採用ペル
日本のソフトウェア企業のテスト・テスト自動化に関する資料をまとめています
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
