#1. 「テスターちゃん」について
初心者(新人)向けに描かれたソフトウェアテストの漫画になります
たまたまJSTQBについて調べていた時に見付けたブログの記事がきっかけで読むようになりました
JSTQBを取るメリット5選

今でも更新がある度にチェックしたり、書籍版を読み返したりしたり、とテスト関連の資料として活用しています

#3. 最初に
最初の記事を書いた時は書籍版の「テスターちゃん Vol.1」が発売される直前だったため同人誌版を参考にした旨を書きましたが、現在は書籍版がリリースされています
そのため、今後は同人誌版のみならず書籍版も使用して記事を書いていこうと思っています

#4. テスト実行について
##4.1 テストについて
テストケースとはテストする項目のこと
基本的に

・仕様の確認
・異常系の確認

が書いてある

Excelやスプレッドシートを使う現場が多いが、テスト管理ツールを使うところもある

テストの基本＝テストの実行

##4.2 テストケースの中身

・前提条件
・入力値(因子)
・Steps(手順)
・期待結果(期待値)
※但し現場によって書き方がさまざまなので、基本的に現場に沿う形で

同じ機能でも対象画面が異なったりする場合もあるので、前提条件に気を付ける

期待値通りだからPass
これも現場ごとによって違う
自分の場合は

・OK
・NG
・BL
・N/A

など

テストケースの時も報連相はしっかりと！
自分の担当範囲が終わったら報告する⇒次の仕事があったりする

多分これのことだろうが一番やっちゃダメ！！

本音

（´-`）.｡oO（とは言え、個人的には設計者の書き方が伝わり難いというのが原因な気もする… なので、判断に迷うテストケースの設計は完全にOUTだと思う ※投稿者は早く設計者以上のスキルを身に付けたいので心したい所存である

そのため、テストケースは第三者が再現出来る、客観的に判断出来るように書くのがBEST！！
⇒実行者によって結果が変わっちゃうのが一番の問題
新人でもプロやベテランでも同じバグが出せるような差が出ないはっきりしたケースが良い
φ(.. )ﾒﾓﾒﾓ
絶対忘れないでおこう

#5. バグ票の書き方
##5.1 バグ票って何？
※現場によって言い方は異なる
今の現場では“チケット”と言うのがメジャー
どんなバグがあったか関係者に伝えるもの
⇒バグの修正までの流れも記録される

##5.2 バグ票の鉄則

バグの情報が相手に明確に伝わるように

具体的に書くこと

###バグの内容が明確に相手に伝わるように書く

①環境
バグが出た時の環境のこと
テストしているブラウザ・スマホの情報など
　⇒他の人も同じ状態で作業や確認をしているとは限らない
　　環境を抜かすと「再現するしない」のやり取りが増えてしまう

②再現手順
他の人も再現出来るように手順を書く
基本は1ステップ1行動
　⇒行動を詰め込むと勘違いの元になる

慣れた人ほど雑になり易い場所なので、書き終わった後、誰でも再現出来るかを考えて見直してみること

③現状(実際の結果)
どんなバグが発生しているか
調べてわかったことも書いておくと、開発の人の調査の手助けになる
　⇒ただし、自分の推測を書くことは×
　　起きている事実を書く

④期待結果
どう動作して欲しいか

情報を分けて相手に伝わるように書くことが大切

・バグの優先度の設定
　優先度はプロジェクトによって決まっているから確認しておく

・画面キャプチャを使おう
　画像や動画があると、それを見るだけで伝わり易い
　※会社で使っていいツールが決まっている場合もあるので、要確認