Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
不具合起票時に心がけて欲しいこと
ta9mi3
June 18, 2022
Technology
0
73
不具合起票時に心がけて欲しいこと
不具合票のクオリティアップを目的としたドキュメントです。
自社のプロジェクトメンバーを想定して作成しましたので、やや分かりづらいところがあるかもしれませんが、ご参考になれば幸いです。
ta9mi3
June 18, 2022
Tweet
Share
More Decks by ta9mi3
See All by ta9mi3
ソフトウェアテスト入門/Introduction to software testing
takulee
0
250
Other Decks in Technology
See All in Technology
DeepDive into Modern Development with AWS
mokocm
1
360
大声で伝えたい!定時に帰る方法
sbtechnight
0
260
サイバー攻撃を想定したクラウドネイティブセキュリティガイドラインとCNAPP及びSecurity Observabilityの未来
sakon310
4
480
テクニカルライティングの検定を受けてみた話 / "My Story About Taking the Technical Writing Exam
line_developers
PRO
1
230
8日で作るオレオレRISC-V CPU
matsud224
1
180
Reactコンポーネントにおけるテスト手法の選択肢
sakito
5
2k
漫画で使えそうな背景画像をblenderを使って作ってみた!
nokonoko1203
1
340
セキュアなTerraformの使い方 ~ 機密情報をコードに含めず環境構築するにはどうしたらいいの?
harukasakihara
9
1.6k
Power Automate for desktopで 配信環境を改善してみた話
akiika
0
340
AWS環境のセキュリティどうやってチェックしてる?
cmusudakeisuke
1
410
塩漬けにしているMySQL 8.0.xxをバージョンアップしたくなる、ここ数年でのMySQL 8.0の改善点 / MySQL Update 202208
yoshiakiyamasaki
1
750
セキュリティ・キャンプ全国大会2022 企業紹介イベント/seccamp2022-nikkei
nikkei_engineer_recruiting
0
150
Featured
See All Featured
How To Stay Up To Date on Web Technology
chriscoyier
780
250k
Making the Leap to Tech Lead
cromwellryan
113
7.4k
Documentation Writing (for coders)
carmenintech
48
2.6k
How STYLIGHT went responsive
nonsquared
85
4k
10 Git Anti Patterns You Should be Aware of
lemiorhan
638
53k
Large-scale JavaScript Application Architecture
addyosmani
499
110k
Testing 201, or: Great Expectations
jmmastey
21
5.5k
Streamline your AJAX requests with AmplifyJS and jQuery
dougneiner
127
8.5k
Art, The Web, and Tiny UX
lynnandtonic
280
18k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
498
130k
How to name files
jennybc
41
63k
Designing for humans not robots
tammielis
242
24k
Transcript
不具合起票時に 心がけて欲しいこと 2022/06/18 たくり~
自己紹介 名前:たくり~ twitter: @ta9mi3 ブログ:https://ta9mi3.hatenablog.com/ 技術経歴:プログラム、DB、ネットワーク テストエンジニア 基本的には何でも屋です。
目次 1. 不具合起票までの流れ 2. 起票しました! 3. 周辺確認が必要な理由 4. 不具合票に必要な情報って? 5.
周辺確認について 6. 周辺確認のコツ 7. おまけ
注意事項 本ドキュメントに記載されていることは、 あくまで一例です。 会社やプロジェクト毎に起票ルールは 異なると思いますので、詳しくはそちらに 従ってください。
1. 不具合起票までの流れ 怪しい動作 を発見 本当に 不具合? 問題なし 不具合 起票 N
Y 起票の前に、本当に不具合なのか どうか確認してください。 ・仕様書を調べる ・テスト手順書を作成した人に 問い合わせる など。 間違って起票してしまうと、自分だけ でなく、開発者の時間も無駄になっ てしまいます。 もちろん、既に起票されていないか、 制限事項ではないかという確認も 必要です。
2. 起票しました! 不具合を見つけました! よし! 起票だ!! ボタンを押したらアプリが落ちました。 修正をお願いします。 ・・・・・・ 上記の例は極端ですが、不具合票には発生した不具合に関する情報を 詳細に書きましょう。また、「こういう場合も発生する」「こういう場合は
発生しない」などの周辺情報も記載することが大切です テストチーム 開発者
3. 周辺確認が必要な理由 テストは開発が終わってからの実施となるため、上の図のように、テス ト実行時には開発者は次の開発に取り掛かっていることが多いです。 そのため、新規の開発で頭がいっぱいになり、前回の事は細かく覚えて いないことが多いし、時間的な余裕もありません。 不具合に関する詳細が存在すると、開発者も不具合の原因にあたりを 付けやすくなるため、より早く・確実に修正を行えるようになります。 このような情報提供も、私たちテスト側の重要な仕事の一つです。 Sprint
1 開発 Sprint 2 Sprint 3 設計 テスト テスト 設計 テスト 設計 テスト 開発およびテストの工程(例)
4.不具合票に必要な情報って? 件名、発生日時、環境、手順、不具合事象、期待結果などなど。 以下の項目は特に詳細に記載してください。 •環境 端末の機種、OSバージョン、通話機能に関する不具合であれば電話番号、 使用したアカウント情報、使用したアプリの名前およびバージョン など。 ※環境が異なることにより開発側で不具合を再現させられないことが往々にして 発生しますので、不具合が発生した環境についてもできるだけ記載しましょう。 •手順
できるだけ詳細に、誰でも再現させられるようにすることを念頭に。 基本的に1操作につき1行です。 •不具合事象 起きたこと。周辺確認結果(※次ページ参照) エラーメッセージが表示されたのであれば、「エラーメッセージが表示される」 だけでなく、「◦◦というエラーメッセージが表示される」というように、 実際に表示された内容も記載します。 ※可能であれば、スクリーンショットや動画などのエビデンスも添付します
5.周辺確認について (1/2) 「こういう場合も発生する」「こういう場合は発生しない」などの情報を、 周辺確認として不具合票に記載しておきましょう。不具合に載せたい 周辺確認としては、例えば以下のようなものがあります。 •必ず記載したい情報 ・不具合が発生する端末が限定されているかどうか ※他の端末でも発生するのか。メーカーによる違いはあるか。 ・OSバージョンが限定されているかどうか ※Android
11や12、iOS 14やiOS 15など、OSのメジャーバージョンが 変わると不具合が発生することがよくあります。 ・不具合が発生後に操作が行えるのか。行えるとしたらどんな結果に なるのか。 •通信系の不具合であれば ・ネットワークの種類(LTEやWi-Fi)を切り替えたらどうか ・環境が変わっても発生するのか。 ※拠点Aでも拠点Bでも発生するのか、とか。 ・他の通信系アプリや、対向とするキャリアを変えたらどうなのか。
5.周辺確認について (2/2) •その他 ・別のアカウントでも発生するのか ・商用版のアプリでも発生するのか。 ※既存機能でクラッシュや操作ができなくなるなどの クリティカル系の不具合である場合、開発版だけでなく 現在ユーザーが使用しているバージョンでの確認は 必須となります。
6.周辺確認のコツ 周辺確認のコツはただ一つです。 「こういう操作をしたらどうなるのかな?」 「このような環境ならどうだろう?」 限られた試験期間内で調査まで行うのは負担ではありますが、 不具合報告の質が自分自身だけでなく、テストチーム、ひいては会社や テスト業界の地位向上につながっていきますので、がんばりましょう。
7.おまけ おまけとして、不具合を見つけるコツを載せておきます。 好奇心を持つ(周辺確認と同じ) 試験手順に記載されたこと以外も、少しだけ試してみる 例えば、入力の順番を変えてみるとか、軽く連打してみるとか ユーザー目線に立つ 視認性が悪い、レスポンスが悪い、使い勝手が悪い など 違和感を大切にする 試験手順にかかれていない箇所でも、少しでも違和感を感じるところが
あれば、それは不具合かもしれません
以上です。 閲覧、ありがとうございました。