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
460
不具合起票時に心がけて欲しいこと
不具合票のクオリティアップを目的としたドキュメントです。
自社のプロジェクトメンバーを想定して作成しましたので、やや分かりづらいところがあるかもしれませんが、ご参考になれば幸いです。
ta9mi3
June 18, 2022
Tweet
Share
More Decks by ta9mi3
See All by ta9mi3
ソフトウェアテスト入門/Introduction to software testing
takulee
0
320
Other Decks in Technology
See All in Technology
**強い**エンジニアのなり方 - フィードバックサイクルを勝ち取る / grow one day each day
soudai
60
17k
コードを書く隙間を見つけて生きていく技術/Findy 思考の現在地
fujiwara3
24
4.8k
転移学習とドメイン適応の基礎
kmatsui
2
570
【SORACOM UG】SIM Deep Dive セキュアエレメント編
soracom
PRO
0
240
日本におけるデータエンジニアリングのこれまでとこれから
foursue
9
1.9k
Data and AI Governance: Existing Challenges and Emerging Trends
scotthsieh825
0
140
[2024年3月版] Databricksのシステムアーキテクチャ
databricksjapan
7
1.9k
OpenTelemetry を使ったトレースエグザンプラーの活用 / otel-trace-exemplar
k6s4i53rx
2
630
[PlatformCon 24] Platform Orchestrators: The Missing Middle of Internal Developer Platforms?
danielbryantuk
0
170
4年前、あるじゃん老害エンジニアLT合戦に登壇、米国西海岸コンピュータ歴史博物館体験記の続編
toshi_atsumi
0
190
疲弊しない!AWSセキュリティ統制の考え方 #devio_osakaday1
masahirokawahara
6
5.8k
o11y入門_外形監視を利用したWebアプリケーションへの最適なモニタリング_TechBrew
k5k
2
100
Featured
See All Featured
How GitHub Uses GitHub to Build GitHub
holman
468
290k
The Power of CSS Pseudo Elements
geoffreycrofte
58
5k
Designing with Data
zakiwarfel
95
4.8k
Put a Button on it: Removing Barriers to Going Fast.
kastner
58
3k
Fontdeck: Realign not Redesign
paulrobertlloyd
75
4.9k
Rebuilding a faster, lazier Slack
samanthasiow
72
8.2k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
240
1.2M
Web Components: a chance to create the future
zenorocha
304
41k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
124
32k
StorybookのUI Testing Handbookを読んだ
zakiyama
10
4.6k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
13
1.5k
A designer walks into a library…
pauljervisheath
199
23k
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.おまけ おまけとして、不具合を見つけるコツを載せておきます。 好奇心を持つ(周辺確認と同じ) 試験手順に記載されたこと以外も、少しだけ試してみる 例えば、入力の順番を変えてみるとか、軽く連打してみるとか ユーザー目線に立つ 視認性が悪い、レスポンスが悪い、使い勝手が悪い など 違和感を大切にする 試験手順にかかれていない箇所でも、少しでも違和感を感じるところが
あれば、それは不具合かもしれません
以上です。 閲覧、ありがとうございました。