ちょっとしたコツシリーズ第三弾
今回は、リリース前に不可欠な「テスト」を実施する際のちょっとしたコツを、
初級エンジニア向けにまとめてみました。
ちょっとしたコツシリーズ、第一弾と第二弾もよろしければご覧ください。
【初級エンジニア向け】基本設計書のを書く際のちょっとしたコツ
【初級エンジニア向け】テスト仕様書のを書く際のちょっとしたコツ
文言確認は コピー ＆ ページ内検索
最も基本的なテストの一つとして、
「表示される文言が設計書（仕様書）通りであること」
といったものがあります。
「こんなの簡単じゃん、目で見て確認すればいいだけでしょ？」
と思った方は注意して下さい！
意外と、このテスト項目には落とし穴が潜んでいるのです。
例えば、このテックブレインのサイトを例にしてみます。
【確認項目】
ヘッダー部の文言が下記の通りであること
”フリーエンジニア求人案件（新着） – テックフレイン”
さて、この確認項目と実際のページを見て、
確認項目に”OK”をつけた人は注意が必要です。
確認項目では「テックフレイン」ですが、
実際のページは「テックブレイン」です。
よーく見たら気づきますが、さっと見ただけでは見逃してしまうような間違いです。
特にヘッダー部やタイトル部分のような、常に目に入っている箇所こそ
このような見落としをしてしまいがちです。
実際は「濁点がついているかついていないか」なんていう間違いはほとんど無いと思いますが、
よくある文言ミスとしては以下のようなものがあります。
◆「下さい」と「ください」
漢字を使うか使わないかという差異
◆「サーバー」と「サーバ」
表記が異なっても意味が通じるような差異
人によって表記が異なるようなもの
◆「フォルダ」と「ファイル」
字面と意味合いが似ているもの
混同してしまいがちな単語
こういったものは実際に私も経験してきて、
テストの際に見落としてしまいがちです。
これらのミスを無くすために確実な方法は、
文言をコピーして、ページ内で検索をしてみることです。
WindowsだったらCtr ＋F
Macだったらcommand ＋F
で、検索ウインドウが開くので、
そこの仕様書に書かれている文言を貼り付けて検索。
検索結果が表示されたら指定された文言通りに記載されていることが確認できます。
ちょっと小面倒ですが、これをやっておくことで
確実なテスト結果を得られるし、
ちょっとしたミスが格段に減ります。
またこの他にも、文言確認のミスを減らすコツとして、
・指差し確認（テスト仕様書と実際の画面を指差しして確認する）
・文言を声に出して読みながら確認する
といったことも有効です。
ぜひ試してみて下さい。
テスト観点を明確にする
観点とは
かん‐てん〔クワン‐〕【観点】の意味
物事を見たり考えたりする立場。見地。「環境保護の観点に立つ」「観点が違う」
出典：デジタル大辞泉（小学館）
つまりテスト観点を明確にするとは、
「どのような立場、見地からテストをするのか」ということを
明確にするということです。
もっと噛み砕いて言うと「なんでこのテストをするの？」
ということをはっきりするのです。
例えば、以下のようなテスト項目があったとします。
「hogeがDBに登録されることを確認する」
「fugaがDBに登録されないことを確認する」
テスト観点が明確になっていないと、機械的にこの２つのテストだけを行って終わりにしてしまいます。
しかし、蓋を開けてみたら
「このテスト同じことやってない？」とか
「piyoのケースもテストしておかないといけなくない？」
ということが発覚して、手戻りになってしまうことがあります。
これを防ぐために「観点」を明確にしておくのです。
例）
hogeがDBに登録されることを確認する
観点：hoge=100の際にエラーが発生しないことを確認する。境界値テスト
fugaがDBに登録されないことを確認する
観点：既にfugaの値が使用されている状態で、登録した際にエラーとなることを確認する。排他テスト
といったように、
「なぜこのテストをするのか」
「どのようなケースを想定したテストなのか」
といったことを考えながらテストをしていくと、
自ずと抜け漏れが減って行きます。
一口にテストといっても、その種類は様々で
前述した境界値テストや排他テストの他にも
性能テスト、負荷テスト、フォーマットチェック、重複チェック、などなど…
これらのテストの種類を理解した上で、
今自分がやっているテストは「何のために」「どのような立場から」テストをしているのか
ということを明確にしましょう。
「他人が見る」ということを意識する
これはテスト実施の際だけでなく、設計書などのドキュメントを作成する際も、
実装・コーディングをする際も意識しておく必要があります。
システム開発で得られる成果物は全て、
最終的には「他人」が見るものです。
設計書も、ソースコードも、テスト報告書も。
最終的に他人が見た時に、いかに見やすいか、
初見で理解しやすいか
ということを意識しておかないと、
後々とんでもない手戻りが返ってくる恐れがあります。
「そんなこと分かっとるわい」と思われるかもしれませんが、
実はこれが、意外と忘れてしまいがちなのです。
例えば、数名のチームで開発を行っていても、一部分は全て任され
設計・実装・テストの工程を一人で行うようなことがあります。
一人で作業をしていると、段々と自分の中で「当たり前」が生まれてきます。
・ここの処理はこうするもの
・この記述はあそこを指しているもの
そんな「当たり前」が生まれてくると
気づかないうちに記述を省略してしまったり、省いてしまったりします。
その結果、自分ではそんなつもりはなくても
「自分が分かればいいように書いている」
「他人が見ることを考えていない」
と思われてしまうような成果物が出来上がってしまいます。
このようなミスは、自分一人で没頭して作業している時に起こりがちです。
没頭して、集中して、作業をするのは良いことですが、
そのまま最後まで突っ走るのではなく、
区切り区切りで、他人に見てもらいましょう。
自分が向かっている方向が間違っている可能性を常に考え、
早い段階で他人から軌道修正してもらうことが重要です。
まとめ
テストを実施する際のちょっとしたコツ、いかがだったでしょうか。
「実装・コーディングは楽しいけど、テストはつまんない」
というエンジニアは大勢いると思います。（私もそうです笑）
しかし、つまらないテストでもこのような「ちょっとしたコツ」を見つけて、積み重ねていくと
自分のスキルが上がっていることを実感できて、
ちょっとだけ楽しくなってきます。
ぜひ皆さんも自分なりの「ちょっとしたコツ」を見つけてそれをブラッシュアップしていきましょう！
