Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
不具合起票時に心がけて欲しいこと
Search
ta9mi3
June 18, 2022
Technology
0
720
不具合起票時に心がけて欲しいこと
不具合票のクオリティアップを目的としたドキュメントです。
自社のプロジェクトメンバーを想定して作成しましたので、やや分かりづらいところがあるかもしれませんが、ご参考になれば幸いです。
ta9mi3
June 18, 2022
Tweet
Share
More Decks by ta9mi3
See All by ta9mi3
ソフトウェアテスト入門/Introduction to software testing
takulee
0
450
Other Decks in Technology
See All in Technology
エラーとアクセシビリティ
schktjm
1
1.3k
サラリーマンの小遣いで作るtoCサービス - Cloudflare Workersでスケールする開発戦略
shinaps
2
440
現場で効くClaude Code ─ 最新動向と企業導入
takaakikakei
1
240
会社紹介資料 / Sansan Company Profile
sansan33
PRO
6
380k
Firestore → Spanner 移行 を成功させた段階的移行プロセス
athug
1
480
なぜテストマネージャの視点が 必要なのか? 〜 一歩先へ進むために 〜
moritamasami
0
220
Autonomous Database - Dedicated 技術詳細 / adb-d_technical_detail_jp
oracle4engineer
PRO
4
10k
ガチな登山用デバイスからこんにちは
halka
1
240
Platform開発が先行する Platform Engineeringの違和感
kintotechdev
4
570
2つのフロントエンドと状態管理
mixi_engineers
PRO
3
110
RSCの時代にReactとフレームワークの境界を探る
uhyo
10
3.4k
これでもう迷わない!Jetpack Composeの書き方実践ガイド
zozotech
PRO
0
490
Featured
See All Featured
Faster Mobile Websites
deanohume
309
31k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
How to Think Like a Performance Engineer
csswizardry
26
1.9k
Designing for Performance
lara
610
69k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
A designer walks into a library…
pauljervisheath
207
24k
Done Done
chrislema
185
16k
The Cult of Friendly URLs
andyhume
79
6.6k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
840
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
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.おまけ おまけとして、不具合を見つけるコツを載せておきます。 好奇心を持つ(周辺確認と同じ) 試験手順に記載されたこと以外も、少しだけ試してみる 例えば、入力の順番を変えてみるとか、軽く連打してみるとか ユーザー目線に立つ 視認性が悪い、レスポンスが悪い、使い勝手が悪い など 違和感を大切にする 試験手順にかかれていない箇所でも、少しでも違和感を感じるところが
あれば、それは不具合かもしれません
以上です。 閲覧、ありがとうございました。