バグを発見した際に考える範囲
最近、バグを見つけた際に考える範囲は人によって異なるなーと気づきました。
どういう違いがあっただろう、と考えると色々浮かんできたので、自分の経験から発散してみます。
考える範囲
- 「テストの判定基準を満たしていないこと」のみを確認
- バグが発生する条件や環境があることを確認
問題が複雑な場合、1.から
・バグ報告→原因が分からず→再現調査
・バグ発見→以降再現せず→条件を変えて再現確認
など繰り返す内に、判定基準以外にも目をむき始めます。
また、報告前に発生条件を特定できるかどうかは力量や状況によって違います。そういう人はあれこれ操作して、バグの原因となる条件に目星を付けてからバグチケットを作成しているように見えます。 - 過去にも同様のバグがないか確認
バグが確定したとしても、
・今回の開発 / 修正が影響して生まれたバグ
・既存のバグ
か切り分けます。
また、既存バグであれば過去のテストを振り返り、
・テストケースがない→網羅漏れ
・テストケースはあるのに期待結果が違う→テスト設計ミス
・正しいテストケースがあり、実行済み→実行ミスによる見逃し
など、どのテストに原因があって、防げたかどうかを確認します。 - バグの原因を考える
仕様検討不足か設計時の検討漏れ、など作る過程でどこが原因だったかを考えます。 - バグを見つけたテストが妥当だったかを確認
単体テストからシステムテスト、システムテストの中でも色々な種類があり、それぞれ目的が異なるので、目的に沿って検出できたか確認します。
もしNoなら、どこで見つかるべきだったかを確認し、そのテストへFBします。
考える範囲を広げること
毎回これら全てを考えるべきだとは思いませんし、特定に時間をかけすぎることが妥当かどうかもチームによって異なるかと思います。
個人的には色々な考えを巡らせることにはメリットがあると考えます。
- 修正確認の質を高める
当たり前ですが、バグは修正されたことを確認するまでが大事です。
バグ検出時点で原因などに考えを巡らせることで、修正方針に対して意見を伝えることができたり、修正確認の質が高まります。 - バグの原因やテスト実行・環境構築のトラブル特定が早くなる
毎回踏み込んで考えることで、製品のロジックや構造への理解が深まり、新たなバグを見つけた際も再現手順や条件の手札が多くなります。
また、車載製品の評価の時に多かったのですが、なかなかテスト実行や環境が上手く組めず、機材も多いので手順or環境or製品のどこに原因があるか特定が難しいことがありました。こういった時に手札がないと絞り込むことができません。 - 楽しくなる
これが一番メリットだと思いますが、詳しくなると考える幅が広がり楽しいです。
考える範囲を広げるには
バグチケットの入力必須項目を決めると考える範囲の最低限の統一ができると考えられます。
毎回チケット起票者に提供してほしい情報を検討して入力必須にすることで、一定標準化できると思います。
最後に
途中、バグ分析の話になった気もしますが、ふわっとしていたことを書き出しました。
まだ考える余地がありそうなので、適宜更新しようと思います。
APIテストを教えてもらったので振り返る
社内のQAメンバーにバックエンド（Apex）のAPIテストを教えてもらいました。
（ありがとうございました！）
大まかな流れについて振り返りたいと思います。
また、APIテストの前後処理にjavascriptやJavaが使われていたのですが、そこについては自力ではできなかったので、どういった内容だったのか調べながら理解します。
使ったツール
サーバーへの負荷試験やパフォーマンスの測定に使われるツールです。
準備
①ツール
- Javaをインストール
- ApacheJMeterをインストール
- 今回のテストで使うブランチをローカルへ落とす
- JMeter用のディレクトリを作り、jmxファイルを作成
- JMeterを起動し、jmxファイルを開く
②API仕様書の確認
実装のために、以下を調べます。
- テストの対象となるAPIのパスを確認
- HTTPリクエストとレスポンスに使われるパラメータを確認
リクエストのパラメータ
APIに対して投げるリクエストはJMeterでjsonフォーマットで書くので、入力が必要な項目を確認します。今回は最低限の確認のため、任意項目については検討しませんでした。
レスポンスのパラメータ
APIテストの成功/失敗の判定に使うアサーション（Response Assertion）をどのパラメータにするか検討します。
実装
- サンプラーを作成
Body Dataにリクエストをjson形式で書きます。
内容はAPIのpathと準備で検討したparamです。 - PreProcessorで前処理を作成
リクエストで使うパラメータの値を予め指定したい時などに作成します。
今回はリクエストに日付を指定したかったので、javascriptで月や日を取得し、次の処理（サンプラー）で使うためにvars.put()で変数を定義しました。 - PostProcessorで後処理を作成
レスポンスのパラメータを次のテストで使いたい時などに作成します。
今回はレスポンスをパース（*1）してからvars.put()で変数を定義しました。
また、今回はレスポンスに複数のデータがあり、一つのみ使いたかったので、配列で最初のデータのみ取得するようにしました。 - Response Assertionを作成
レスポンスデータをアサーションする設定です。
今回はレスポンスのjsonファイルに設定した文字列が含まれているかどうかを検証する設定にしました。 - Beanshell Assertionを作成
テスト実行後にBeanshellでアサーション処理をします。ここはJavaで書かれています。
Jenkinsでの定期実行で失敗した際に出るエラー文を見やすい形にする処理をしています。 - Config Elementを設定
今回は以下の3つを設定しました。すべてを理解はできていないのですが、調べたことを書きます。
HTTP Request Defaults
HTTPリクエストに対して設定されるデフォルトの構成です。
HTTP Header Manager
HTTPヘッダー情報を設定します。
BeanShell Post Processor
JMeterはレスポンス情報のデフォルトの文字エンコードが「ISO-8859-1」になっているため、BeanShell Post Processorで文字コードを変更し、文字化けを防ぎます。
参考：
【Apache JMeter】レスポンス情報が文字化けする場合の対応方法の紹介 – fumidzuki
学んだこと
テストのピラミッドがよく理解できる
UI Test, Integration Test, Unit Testの順に上から並んでおり、ピラミッドの上位を拡充する方がコストがかかるため、下位のUnit Testを拡充する方がコストメリットがあることを示した図です。
今まではUI Testのみ自動化経験がありました。今回のようにIntegration Testを実際に作ってみることで、上位のテストを色々なパターンに対して作るよりも、下位のテストを充実させる方がメンテナンスにかかる時間の減少や費用対効果があると肌感で理解することができました。
最後に
APIテストを実際に作ってみて、自分の守備範囲が広がった気がします。
少しですがJenkinsも触ったりできて良かったです。
また、JavaScriptも使われており、E2E自動テストでも使える言語なので、コードを書けるようになって自動テストでの選択肢を増やせるようになりたいなと思いました。
*1 パース（parse）
ある書式で記述されたデータをプログラムで使えるデータ構造の集合体に変換すること。
今回だとJson.parseを使い、Jsonで記述された文字列をJavascriptのJsonオブジェクトに変換しました。
事前条件とテスト観点について整理する
テスト観点について何気なく調べていたところ、こちらで議論されているのを見つけました。
テスト観点と実装実施時要検討事項 - Togetter
丁度自分が悩んでいたことに少し関係があり、自分なりに整理します。
また、引用先の議論で自分の今の力量では今回理解できそうでできなかったところも多々あるので、今時点で自分が腑に落ちたところだけ書きます。
事前条件とテスト観点について
経験上、そして今回議論されているようにテスト手順書の「事前条件」に書くもの（書いてしまうもの）の意図は、大きく分けると以下の2つがあります。
引用先の議論で使われている言葉を用いて、下のように表現します。
・テスト観点（テストケースの意図を満たすもの）
・実装実施時要検討事項 ※1
-テストケースの実施に必要な事前準備（テストケースの意図を満たすものではない）
もしその事前条件がテストケースの意図を満たすために必要なら、それは事前条件ではなくテストケースそのものに含まれるべきで、それはテスト観点（やテスト値）のはずです。ただ他のテスト観点と違うのは、何らかのトリガによって事前に実行されている可能性が高いということです。
逆に、その事前条件がテストケースの意図を満たすために必要無ければ、それは単なる事前条件であり、テスト観点ではありません。
参照：
テスト観点と実装実施時要検討事項 - Togetter
棲み分けないことで起こったこと
タイムリーな話として、自分がテスト設計していないテスト手順書を実施した時、頭でこの区別がはっきりできていない事による弊害を感じました。
具体的には、あるケースの中に明確に特定の環境や値が記載されておらず、実施者によって任意で選択されるものがある場合、任意の一つの値を選択するだけでなく「別の値だとどうなるだろう？漏れがないだろうか。」と深読みしすぎて考えを広げてしまいました。参照先でも似たようなことが記載されています。
しかし一般的なテストでは、テスト観点と実装実施時要検討事項を厳密に峻別しません。それによってテスト観点の漏れを防ぐ側面もあるからです。そのため、実装実施時要検討事項なのに境界値を選んだり網羅しようとしたりします。したがって混同してしまいます。
まさに「漏れがあるかも」というモチベーションで考えを広げましたが、振り返るとケースに書かれていない観点やその期待値にばかり気を取られていたと思います。
とはいえ、設計者のテスト観点漏れを拾える場面でもあるので一概に悪い行為ではなさそうです。
棲み分けないために起きること
以下で引用した図は実装時実施時要検討事項の棲み分けの議論で出た図です。
こちらに続くスレッドに書かれているように、もし棲み分けされていれば、「保証しないことが明確になる」のはテストとして確かにメリットだと思いました。
ありがとうございます。既に@YasuharuNishi さんに大事なところを説明いただいたので、私の出る幕はないのですが、説明用に作った図を置いておきます。
— Toshiyuki Manabe (@ToshiManaPlus1) 2021年12月22日
「実装実施時要検討事項」について、@nihonbuson さんは「B,C」を指しており、私は「C」のみを指している、と考えていました。 pic.twitter.com/roSxfcj5og
これから実施したいこと
テスト実装や実施時に、テストケースの記述を書いたり見た時に「実施時要検討事項（C）」のように見えるものが本当に（C）なのか、テスト設計で漏れていた観点（B）の可能性がないかを検討したい。
今年始めて良かった習慣や考え方
初めまして！Teamspirit EXのQAとして2021年9月に入社した三木です。
普段ブログを書くことはなく、中学生の頃に流行っていた「ホムペ」以来です。
懐かしいですが、当時を思い出すと恥ずかしすぎて辛いです...
話は変わり、少しだけ今年を振り返ると
2回の引越し・結婚・転職...と、初めての経験が盛り沢山の充実した1年でした。
とはいえ、しっかり疲れたので年末はのんびり過ごそうと思います。。
さて、今回は個人的に新しく取り入れて良かった習慣や考え方について書いてみます。
この記事は チームスピリット Advent Calendar 2021 の17日目です。
始めて何が良かったのか
何が良かったかというと、
頭がスッキリして、以前より疲れやストレスが少なくなったことです。
自分の性格上あれこれ考えすぎることが多く、
選択肢が複数あったり、答えのない仕事だと長時間考えてしまいます。
ぼーっと考えるのは好きなので最初は問題なかったのですが、
今年のようにプライベートも忙しいタイミングで好き勝手やってると奥さんにも怒られ余裕がなくなってきました。
頭を楽に＋シンプルに考えれるように
本を読んだり、試してみて良かったことを3つ紹介します。
始めて良かった習慣
周知の事実ですが、睡眠はとても大事です。
最近は少なくとも寝る1時間前からスマホやPCを見ない、のがオススメです。
ブルーライトの影響はもちろん、見ているコンテンツが面白い/怖い、など
刺激的な内容だと脳が興奮してしまいます。
この文脈で、一見問題なさそうな読書も内容によっては
睡眠の質を下げることもあるみたいです。
その他にも「シャワーやお風呂に入る時間と寝る時間」も体温の関係で
睡眠の質に影響があったり、「腹式呼吸」もリラックスできてオススメです。
調べてみると想像以上に自分の習慣が睡眠の質を下げていることに気づきました。
良い睡眠しか勝たんのです。みなさんも今一度見直してみてはいかがでしょうか。
2. 考えを寝かせる
考えを発散させて、絞り込んでいるとまた発散し始めて...ストレスですね。
冷静になると、無理に長い時間悩んで解決したことはほとんど無いことに気づきます。
なので「煮詰まり始めているのにまだ考えようとしている」時こそ
今は良い答えは出ない、と思い切って考えることをやめました。
また、複雑なことを考える時は、以下のように事前に準備や心構えをしておくと
頭が一杯になる場面が減ったように感じます。
・余裕をもつ為に、なるべく早く考え始める。（また発散するかもしれないので）
・まずできるだけ発散し切ることに専念し、その日は無理に絞り込まない。
・次の日の朝や時間を置いてスッキリした頭でもう一度見てみる。
例えば、QAの仕事で「テスト観点出し」は考えを発散させる作業ですが、
同時に「テストにどの観点を使うか」と絞り込もうとすると、
発散と収束がそれぞれ中途半端になり、発散⇄収束の行き来が多くなってしまいます。
また、「ある程度出せたかな？」と思っても、時間が経つと「あれはどうだろう？」と新しい考えが出てきたりします。
ある程度 発散と収束は独立して実施したり、一気に完成させようとせずに
寝かせてから再度見直すのを前提に考えると楽になりました。
割り込みがあると元々の作業は中断し、新しい仕事に取り掛かりますが
今度は中断した作業を再開する時に「思い出す作業と時間」が発生します。
こうしたタスクスイッチングの繰り返しは効率が下がるだけでなく、
脳を傷つけてしまう恐れもあり、長期的にパフォーマンスが落ちる原因になります。
当時、頭が疲れ切っていたので以下のようなこと意識すると負担が減り、
割り込みがあっても着実に仕事が進んでいる感じがして精神的に良かったです。
・一つの作業を連続して集中できる時間を確保する
・時に進みが悪い時は一定時間割り込みがない環境に身を置く
・他の作業に入るときは、思い出す時間を減らせるような準備をしてからにする
今は以前のような割り込みはないのですが、
油断すると不要な中断を自らしてしまう恐れもあるので
無駄に頭を切り替えないように注意したいです。
本題とは逸れますが、今年はよくナイトシアターを見に映画館へ足を運びました。
大画面の迫力はもちろん、余韻に浸りながら駅に向かう時間もとても好きです。
ある俳優の方が「映画館で映画を見るメリット」について、
「家だとスマホや他のことに囚われて、逆に1本集中して見切る方が難しくないか。映画館だとスマホは出さないのが当たり前で当たり前のように作品に没頭できる」（みたいなこと）をおっしゃっていました。
確かに色々なものが「手軽に」、「どこでも」、「ながら」でできるようになり便利になりました。
反面、「1つに集中すること」が以前より難しくなっているんだなぁと気づきました。
映画館で映画を観た後、とても満足して幸せな気分になりますが、それは内容の面白さだけでなく、他のことを忘れて映画に夢中になる状態にも幸せを感じているんだなと思います。
おまけ
・マウスピース
就寝中の歯ぎしり や 食いしばりは歯や顎への負担が大きく、
また意外にも頭痛や肩こり、腰痛、目の疲れにも影響していると言われています。
就寝中にマウスピースをするとこれらの予防が期待されるので、
慢性的に疲れが取れない人は可能性ありです。
家族がいらっしゃる方は自分が寝ている時に歯ぎしりしていないか聞いてみてもいいかもしれません。私も家族から教えてもらって知りました。
個人的にとても効果を感じています！
できていない日は頭が重く感じたり、上手くいっていないとモヤモヤします。
逆にそういった時こそ、これらの習慣に効果があるんだなと再認識しています。
ストレスや疲れに気づいてからでは対処法を考える余裕もないので
余裕のあるタイミングで改めて自分がストレスに感じていること、自分なりの対処法を探す時間を取ってみてはいかがでしょうか！
