元底辺エンジニアが語る、エンジニアとしての生き様、そしてこれからの生き方

生き様095. テスト嫌いなエンジニアがテストを語る

»

新しいコラムニストさんが増えました

既に1ヶ月が経っていますが、5月からコラムニストさんが増えました。
庸晃さんです。

IT大好きエンジニアである僕と、IT大嫌いなエンジニアである庸晃さん。
この立場の違いが、いつの日か面白い対比になるのでは?と期待しています。
毎週のコラムを拝読していますが、嫌いな人の視点に「なるほど!」と膝を打つ日々です。

僕としては、全てのエンジニアが「IT大好きであれ」とは考えていません。
僕にだって嫌いだけど続けていることの1つや2つはありますからね!

ということで、今回は僕が嫌いな「テスト工程」についてお話していきます。


テストが嫌い

これはある程度公言していることですが、白栁はテストが大っキライです。

だって、テストって面倒くさくないですか?
作り終わって「出来たー!」ってなってる時に、チマチマアラ探しするみたいな。
性格悪い小姑みたいじゃないですか?

作ってる時に確認してますもの。大丈夫ですよ!
注意深く作っていれば、問題はないはずですから。

それと、テストドキュメントってのもキライなんですよね。
あんなに細かくテストする必要ありますか?
しかも、細かく画面のハードコピー残して、Excelに貼り付けて赤枠付けて。
馬鹿らしくないですか?
こんなん、プログラマの仕事じゃないですよ。

あと、適当に「ソフト弄っといて」って言われるテスト。
何すればいいんだよ!って。
シナリオもなんも渡されなくて、適当に弄ってたら眠くなるじゃないですか?
なんだか、暇な人みたいじゃないです?
それだったら、なんか開発の仕事下さいよ。


テストの大事さ

などと、一気にまくしたててみました。
きっとこれを読んだHOLLYさんは青筋を浮かべてらっしゃるでしょう。

少し大げさに書いていたり、過去のある時点に思っていたことが含まれていますが、大まかには真実です。
今でも、僕がテストに思っていることを書き連ねています。

ですが、今はそれに一言続きます。

「テスト大っキライだからこそ、テストの大事さがわかる」

かつての僕は、テストを蔑ろにしていました。
そうして大怪我をするに至りました。 それも、1回じゃなくて…。


マインド

残念ながら、僕はテストエンジニアではありません。
ですので、説明できるテストの技術は「プログラマが意識するべきテスト」の観点になります。

その中でも一番重要なのが、テストを行うマインドです。

今僕が「テストをする理由」として話しているのは「自分を守るため」です。
「自分の仕事の成果を確実であると証明する」「品質を上げて会社の利益を守る」等々、色々な【守る】
テストによってそれができるようになる、ということが、今、白栁がテストをする理由です。

ハードコピーExcelに貼り付けて残すのは「自分は確実に仕事をした」という証拠を残す為です。
それに印を付けるのは、証拠として突き出す際に、頭を使って分析しなくても結果を明白にする為です。


自動化テストの意味

人間、心に隙きができる瞬間があります。
その隙きは、機械的に同じ作業を繰り返していると、段々大きくなっていく様に感じています。
そして、その隙きにバグを見落とします。

自動化テストを導入することで、その隙きをすり抜けられない網を作る、そう認識しています。
自動化テストが得意なのは、機械的に同じ動作を繰り返す様な部分です。
人間が苦手なことを機械に任せる。
これほど効率的なことは無いと考えています。

後は、GUIでの入力だのボタンクリックだのを自動テストに任せるのが、もう少し楽だといいな~。
などと願っています。
もちろん、色々な会社から、GUIテストの為の製品が販売されているのは知っています。
しかし、導入コストだったり、使いこなす為の手間だったりが…、と感じるのです。


手動テストの意味

テストを手動で行うことにも大事な意味があります。
最大の特徴は「実際に使う人の視点で確認ができる」ことです。
どんなに自動化テストが進化しても、使う人の気持ちは人間でなければわかりません。 その1点だけでも、手動テストの意味があります。

後は、自動化テストに比べて、変更に柔軟に対応できます。
テストの変更は仕様の変更ですので、柔軟に対応していいのか?とも思いますが。

他に得られる利点としては、機械的にすることが難しい、操作のゆらぎがあることです。
このゆらぎによって引き起こされるトラブルが、たまにあるのが厄介ですね。

幾つか、手動テストの為の技術を紹介します。
白栁が「いちプログラマとして必要と感じている範囲」の技術と観点での紹介です。
もし、間違いがあったらコメント欄で指摘を頂けると僕も勉強になります。

プロトタイプテスト

僕の中で、正確な用語からはズレて使ってる可能性が高い言葉です。
開発中でも、一回なんとなーく動くようになったら、それを関係者に配って見てもらうようにしています。
実はこれも立派なテストです。 アジャイル的な開発の現場では、頻繁に使われていると認識しています。

これをすることで、システムに対する操作の流れが見えます。
ですので、使い勝手という観点の確認ができます。
忘れられがちですが、「使い勝手」も立派なテスト項目だと考えています。

他にも、もやもやっとしたイメージからシステムを起こした場合に有効です。
きっちりと要件を書き起こした文章や、キレイに整えられた画面イメージ・遷移図を見ていてもはっきりしないものが、実際に触って動かせる画面があるだけで、初期のイメージとの齟齬が明確化されます。

大規模開発の場だと、完璧に動くものだけが求められがちです。
しかし、大規模であればある程、全体の像が掴みにくくなるので、なんとなく動く仮システムを動かしながら詰めていくのは、とても有効ではないか?と考えているのです。
大きな建築をする時に模型を作るように。

ストーリーテスト

事前に作成したシナリオにそって、システムを操作していくテストです。
実践的なオペレーションをしながらのテストですので、システムの根幹的な要求仕様が満たされていることを確認する為に実施されます。
大体、これやってOKだったらシステムは出来たと言えます。
他にも異常系のテストとか、重要なことがあるので「だけでOK!」とは言えないですけれども。

レバガチャテスト

これは、ゲーム開発の用語だと思います。
もしかしたら、僕独自の言葉かも?Googleで検索してもヒットしませんでした。
適当にあっちこっちのメニューを弄ったり、適当にボタンを押したりキー操作して、システムの耐久度を確認します。

前述の「ゆらぎ」にフォーカスしたテストだと考えています。
そして、前述の2つは正常系のテストであったのに比べて、こちらは異常系のテストです。

これを長時間できる人は本当に尊敬します。
僕は30秒で飽きます。


視点を変える

最後に視点の話に触れておきます。

開発者がテスト実施者を兼ねる場合、とても大きな障害があります。
それは「システムの中身が判っている」ということです。

判ってしまっているので、自然とその仕組みに沿った動きをしてしまいます。
一般的には不自然な動きでも「このシステムってこういうもんだよね」という思い込みでスルーしがちです。
この思い込みが、テストに対する最大の敵と言っても過言ではない、そう考えています。

これに対抗する為に、一度開発者の視点を自身から追い出す必要があります。
これを行う本当に簡単な手段は「人を変えること」です。他人に任せることです。
ですがなかなかこれができません。
開発者がテスト実施者を兼ねているケースが大半だからです。

そういう時は、一息入れるようにしましょう。
ちょっと気持ちを切り替えて、開発者としての思考を追い出すのです。
当たり前のことですが、物理的に時間が空けば、記憶は薄れます。
これを利用して、一晩置いたり、週末を挟むのも、視点を切り替える方法のひとつです。

僕の場合は「短期記憶が弱い」という欠点を利用しています。
2~3日唸って書き上げたコードでなければ、コードは大体短期記憶に格納されています。
ちょっとコンビニへ買い物へ言ったり、昼飯を挟んだり、休憩スペースでストレッチしたり、一服したり。
そういう動作を挟むことで、うっかり開発者の記憶を置き忘れてしまいます。
そのまま思い出さないようにテストに取りかかれば、ある程度視点を変えることができるのです。
短期記憶、弱く良かった!


まとめに代えて

割と今でも、テストはめんどくさいって思ってます。正直な話。
そして、プログラマーがやることではない、とも考えています。

しかし、それは「テストはプログラミングとは違う専門性の仕事」という認識からです。
テストシナリオを計画するのは、プログラミングとは違います。
それは、もっと上流の工程で洗い出されるべきことでしょう。
テスト計画だって、実装を担当するプログラマではなく、専門性を持つ人間がやるべきです。
テストの実施に至っては、思い込みによる見落としや、バグを隠す可能性がある実装者ではなく、記録を残しながら視点を変えて公正に対応できる第三者がするべきでしょう。

そしてなにより【品質】を謳うのであれば「コストが足りないからプログラマにやらせよう」ではなく、
「専門性のある人間にしっかりと担保してもらうコストを割り当てよう」になるはずです。

もちろん、テストの観点をプログラマ各々が持つことは素晴らしいと思います。
ですが、それで責任まで負わせるのは違うだろうと考えているのです。

日本のIT業界において、テストエンジニアの地位は圧倒的に低いと感じています。
そんな世の中が、少しでも変わったらいいなという願いで締めようと思います。

以上!




主催イベント宣伝

2021年7月23日(金)に恒例のオンラインイベントを主催致します。
その名も【超ショート】90秒LT会【2021Summer】です。

夏本番を控えて暑さが増してくるこの季節。
ちょっとヒヤッとする体験をお話して、納涼しませんか?
もしくは、オンラインイベント登壇の試しに、90秒でお話してみませんか?
夏らしいアツい話題は、共通テーマの「推し紹介」でお願いします。
また、どんなイベントになるか見てみたい、という方も参加歓迎!!
他人の目標や登壇を聞くだけでも、勉強になりますよ!

現在、登壇参加者・視聴参加者を募集しております。 上記のイベント名が、イベントのConnpassページへのリンクとなっております。
そのページから、参加登録をお願いします。

また、このイベントは3ヶ月ごとの開催を予定しています。
今回ご都合が悪い方は、是非次回、10月のイベントへの参加をご検討下さい。
宜しくお願い致します。




ミニコーナー:こちらヤマネコシステム技術部三課!

ここは日本のどこかにあるかもしれない「ヤマネコシステム」社。
そこはかとなく、ブラックの香りがするこの会社の日常を、少し覗いてみましょう。

登場人物

三課:受託開発&新サービス開発
 ヒノモト : 主人公 アラサーエンジニア
 オラフ先輩 : 社内事情通、北海道出身
 ゴリタ先輩 : 三課の良心 沖縄出身
 アカゲ課長 : 三課の課長 長いものに巻かれるタイプ

テレワーク

ヒノモト「オラフ先輩、しんどそうですね」
オラフ先輩「ボクは道産子だからね。梅雨のジメジメした感じは苦手なのさー」
「北海道には梅雨がないからね(※本当)」
ヒノモト「いい加減、関東長いんですから、慣れましょうよ?」
オラフ先輩「『三つ子のタマシイ百まで』だよ?むりむりー」
ヒノモト「ゴリタ主任を見習ってくださいよ。夏でもキリッとしてますよ?」
オラフ先輩「ああ、ゴリタくんはウチナンチュだからね~、きっと暑さに強いんだよ!」
アカゲ課長「いや、そんなことはないぞ?」
「昔は『沖縄にはこんなジメジメした暑さはなかったぁ』って毎年溶けてたんだ」

(つづく)




ITエンジニアの視点で、時事ニュースを5分間で紹介する動画を平日毎日公開してます。
「日々の生活の中にエンジニアリングがある」からこそ、
身近な時事ニュースから学ぶことが重要です。

#ほぼ日ITエンジニアニュース

Comment(0)

コメント

コメントを投稿する