プログラマーは必ずバグを出してくるし、何度も何度もテスト。。
なんか良い方法ないかなぁ。
こんにちは、古賀です！
本記事では、
はてな
「単体テストの効率を上げる裏技」
を教えたいと思います。
ただし注意点があります。
注意ポイント
「プログラム知識がある程度必要で、誰でもできるわけではない！」
「リスクもある！」
AIの力を使うだとか、ツールの力を使うだとか、
最先端の方法ではありません！
原始的な方法です！
差し支えなければ、お試しください！
自己紹介が遅れましたが、
わたしは大学卒業後、上場IT企業に就職し、プログラマー、システムエンジニアとして
約１０年間働いておりました。
プロフィールの詳細はこちらです。
-
-
プロフィール
こんにちは、古賀正雄です。現在３６歳です。 簡単ではありますが、こちらのページで自己紹介とこのブログについてお話します。 高校時代 学生時代は主に野球をしていました。 進学先の高校も野球で選びました。 ...
続きを見る
※YouTubeに同内容を公開しております。
単体テストの効率を上げる「禁断の裏技」！それは「自分で直す！」
結論を先に言いますと、
「バグを見つけたら自分で直す！」
です！
「はっ！？作業増えてんじゃん！」
と思うかもしれませんが、わたしの狙いは、
「作業量自体を減らすことでなく、作業時間の削減」
です！
作業量が増えるのに、なぜ作業時間が少なくなるのか？
それについて説明していきます。
単体テストを非効率にさせる原因を排除する！
そもそも単体テストが、なかなか終わらない原因は何なのでしょうか？
テスト項目が多いのもありますが、
「バグが発生して再テストが必要になる」
ことも大きな原因ではないでしょうか？
プログラマーが「パーフェクトプログラム」を作ってくれれば、
単体テストは相当楽ですよね。
でもそんなことができるのは、極少数のプログラマーだけです。
プログラマーも人間です。
誰もがミスをします。
怒ったり、イライラしてもバグは減りません。
先程の単体テストが長引く原因である
「バグが発生して再テストが必要になる」
を、手順化して考えると、
- バグを発見する
- プログラマーに修正依頼する
- プログラマーが納品する
- 再テストをして修正確認する
という流れになります。
当たり前ですが、
「システムエンジニア」⇒「プログラマー」⇒「システムエンジニア」
というステップを踏むことになります。
プログラマーがすぐ修正してくれればいいですが、
他の作業をしていて、数日後に修正が納品されることもあります。
その間、システムエンジニアも別作業をしています。
さて、納品されてきたから再テスト。
テストの準備して、どんなテストをしてたっけと思い出し、テストをする・・・
「直っていない！！！！」
とかなってしまったら発狂ものですね。。
バグが発生し、一度他人の作業が間に挟まることで、
余計な時間が掛かり、修正待ち時間が作業効率をかなり下げます！
なるべく
「システムエンジニア」⇒「プログラマー」⇒「システムエンジニア」
の往復作業を減らすために、わたしは
「バグを見つけたら自分で直す！」
としています。
直した後は、さっき自分がやっていたテストをやるだけなので、
作業効率のロスがまったくありません。
特にソースコード目線で見つけたバグに関しては、バグの修正は一瞬で終わります！
※ソースコード目線のテストに関しては、こちらの記事をご覧ください
-
-
単体テストのやり方！高品質かつ効率の良い単体テストの方法とは？
いきなり「単体テストをやれ！」って言われても、何をしたらいいかわからん。。 クソ真面目にやると、めっちゃ時間かかるし。。 どんな感じで進めていけばいいんだろう？ こんにちは ...
続きを見る
一見作業量が増えて、時間が掛かりそうと思うかもしれませんが、
圧倒的に早く単体テストを終えることができます！
単体テストの効率を上げる「禁断の裏技」のリスク
圧倒的に作業効率が上がりますが、リスクもあります。
注意ポイント
- バグを増やす可能性がある
- 複数人でチェックしたことにはならない
- プログラマーのプライドを傷つける可能性がある
この３つです。
バグを増やす可能性がある
リスク１つ目が、
「自分で修正することで、逆にバグを増やす可能性がある」
ということです。当たり前ですけどね。。
わたしはプログラマー経験が長かったので、
ちょっとした凡ミスから、中級ミスまで幅広く直してましたが、
プログラミングに自信がなければ、自分で修正するのは、
「条件分の不等号にイコール抜けている」
「画面に誤字がある」
程度の凡ミスレベルだけにしておきましょう。
メインどころの処理だったり、他の処理に影響を与える可能性がある場合もやめておきましょう。
修正したことによるリスクを察知できるかどうかが大事です。
複数人でチェックしたことにはならない
リスク２つ目が、
「自分で修正することで、複数人でチェックしたことにはならない」
ということです。これも当たり前ですけどね。。
通常は、
「プログラマーのデバッグ」の目と、
「システムエンジニアのテスト」の目で、
複数人でチェックしたことになりますが、これが１人になります。
リスク１つ目と重なる部分もありますが、
完全自己完結作業になるので、作業の正確性に自信がなければやめておきましょう。
プログラマーのプライドを傷つける可能性がある
リスク３つ目が、
「自分で修正することで、プログラマーのプライドを傷つける可能性がある」
ということです。
プログラマーは、自分が作ったプログラムを、他人に勝手に修正されることを嫌う人もいます。
（※これはわたしのことです。。）
直してくれて喜ぶ人もいますけどね。。
プログラマーとの信頼関係を結べているのであれば問題ないですが、
初対面の人に対して、この方法を取るのはあまりオススメしません。
プライドを傷つけるとはまた少し違いますが、
「プログラマーの成長」という面でもマイナスですね。
「ミスをしてしまった。。」
と自覚させることも大事ですし、コードを修正して勉強させる機会も奪ってしまいます。
プログラマーのプライドを大切するにしても、
成長を考えるにしても、
常に「相手」がいることを忘れないようにしましょう！
まとめ：単体テストの効率を上げる
ここまでの話をまとめます。
ポイント
単体テストを効率良く終わらせるために、
「バグを見つけたら自分で直す！」
方法が有効！
「システムエンジニア」⇒「プログラマー」⇒「システムエンジニア」
の往復作業をなくし、作業効率ロスを防ぐ！
自分で修正する裏技はリスクがある！
- バグを増やす可能性がある
- 複数人でチェックしたことにはならない
- プログラマーのプライドを傷つける可能性がある
タイトルにある通り、この裏技はオススメしません。
時間に余裕があるのであれば、やめておいた方が良いです。
「テストしっかりやれよ！」
って言うくせに、
「時間が全然ない！」
そんな時にやってください。
この方法はプログラミングスキルがあればあるほど、力を発揮します。
プログラマーが１回納品して、後は自分だけでなんとかなってしまう。
そんな状況にすることができます。
うまくハマってしまうと、恐ろしいほど作業効率が良くなるので、
時間に余裕がある時もやってしまいそうになってしまいます。
それを続けると、
自分しか信じられず、
「他人に仕事が振れない病」
にかかってしまいます。
それはやがて自分を苦しめます。
これは「ドーピング」のようなものです。。
なので、困った時にだけ使ってください！
仲間と一緒に戦って、仕事がうまくいった方が気持ちが良いはずです！
チームのみんなを信じましょう！
