テスト自動化って必要なんかな。

テスト自動化(Test Automation)

テスト自動化って、いつからかものすごく流行ってる感があります。 日本語にはこういう表現があるでしょう。

早い者勝ち

少し使われるケースが違うとは思いますが、テストって、時間との戦いになるところがあるので、 結局同じ意味になるんじゃないかなと思います。 テストから少しでも早めにバグの検出ができれば、リリースまでの品質や顧客信頼の向上にかなり貢献できるというのが自分の考えです。

バグのないプログラムというものが存在すれば、テストは要らない。

プログラムは絶対バグを持っているでしょう。自分の先輩はいつも、バグのないプログラムを実装するためには、何も実装しなかったらいいって言ってるほど、 プログラムにとってバグとは、必ず存在するものだと思います。必須不可欠って言いますかね。 どうせバグがあるのであれば、なるべく早い段階で検出し、そこに早いスピードで対応することができるんだったら、それが最高じゃないでしょうか。

でも我々デベロッパーは、テストってあんまり好きじゃない傾向があります。 頑張って作ったし、実装の段階で充分テストしてみたし、それをもう一度テストするって、結構時間もかかるので、 テストそのものが嬉しいデベロッパーは、あんまりみたことがないです。

テストが難しい理由

あと、デベロッパーには、テストするにあたって、致命的な弱点を持っています。 1. 実装する時、もう全て実装ができたと思っているので（勘違い）、テストの観点が深いところまでよく思いつかない。 2. 自分のプログラムに甘い。 3. いつも疲れてる。 4. 遅い。 5. 面倒臭い

ここから「テスト自動化」という観点が生じます。 なるべく早く、厳しく、ちっとの誤差も許さない誰かが必要になるのです。ここがまさに、機械に任せるべきなところ。自動化ツールの誕生背景になります。

長野に行きます。

さすがお盆休み。僕も2日休みを頂いて、9連休になったんですが、まずは観光です。ややこしいことは、行ってきてから考えましょうー

ブログ開設スタンバイ

Logo

パワポで作ってみました。5分ぐらいかかりましたね。（適当すぎw） OGタグとしても使おうと思います。

Domain

.ioにするか、.comにするか、すごく悩んだんですけど、 やっぱり国際化を考えると、comでしょうね。

あ、待って じゃ、ブログも英語で書かなきゃあかんなんかな？

Search Console

とにかく、グーグルさんにちゃんとインデクシングしてもらえるように、 サーチコンソールの方で、ドメインの変更も報告しました。 よろしくねー！グーグルさん！

自分はウェブ業界のエンジニアなので、自分のブログとしてSEOというものの実現って、 どう言う風にやっていったらいいかなとかも、検証できるようになるんじゃないかなって思います。

Google Analytics

アクセス情報収集スタート！

ローカル・ステージング・プロダクション

「絵はアトラシアンの可愛い絵を借りてきました。」

理想

開発者は、自分のローカルで、プログラムに対する変更を試してみます。 いわば開発環境になります。そこで試してみてから、行けそうな気がしたら、 その変更をステージングサーバにまで持っていきます。デプロイって言うでしょう。 この時、ステージングってのは、あくまで本番のテスト環境になります。 スペックも設定もいくつか違うのがありますが、OSやミドルウェアのバージョンなどが基本的に揃っていて、 本番に適用したい変更の全てを、この環境でテストすることになります。

なので、教科書ではいつも、「ステージング＝プロダクション」を前提として設定しています。 僕もそう教えてもらいました。

現実は？

違う。違う。めちゃめちゃ違います。 基本的な構成が一緒だとしても、ステージングって、一人で使う環境じゃないので、環境が想定と違う場合がありえます。

他の開発者が試しで作って、テストが終わっても、そのまま放置したりすることが十分あり得るからです。 プロダクションとステージングがまったく一緒だという想定の上で行われたステージングテストって、実際プロダクションでは どれぐらい意味があるのでしょうか。

そもそも想定って、エンジニアにとってはかなり怖いことかも知れません。想定ってのは、あくまで人間、詳しく言えば思考の主体として人間が 無意識的に決めている、他人とは共有できない自分だけの思考の枠である恐れがあるからです。 誰もバグを望んでいないです。意図したバグってありえないです。じゃ、なんでバグが発生するのか？そこが人間の想定って認識の死角です。

例えば、プロダクションの環境では、定期的にクーロンが動ぎ、別のサーバからデータの同期してくると考えてみましょう。 ステージングでもそういう定期的なジョブが設定されているでしょうか？ されてなかったら、その時点でアウトですね。しかも、ステージング上はテストのために、人間が手動でデータをベッドのディレクトリ転送したりする仕組みであれば、もうその時点で、真のテストは難しくなるかも知れません。

どうすべきか？

ローカルは置いといて、ステージング環境でのテストが、本番のテストにならない。なら、ステージングとプロダクションの環境って、 そもそも違うってことを常に意識するのが答えになるんじゃないかなと思います。

特定のモジュールを修正するプロジェクトがあるとしたら、最初の見積もりとして、両環境の差を確認する課題を用意したらどうでしょうか。 かなりプロジェクトの進捗に影響を及ぼすかも知れません。

１．ファイルやディレクトリ構成は同一なのか。 ２．モジュールのバージョンは同一なのか。 とかを事前に考えてみて、想定ってものの正確さを高めることができるのであれば、リリースの直前発生して、皆バタバタすることになる 原因を、一つでも縮められるのではないでしょうか。

失敗を繰り返さないこと。

私は韓国からきたアプリケーションエンジニアです。

社内で毎日いろいろな失敗をしています。

一回教えてもらったのに、忘れるのもあるし、そもそも知らなかったものもあるし、（あくまで外国語なので）上司の指示を理解し間違ったりするのもあります。

数え切れないですが、理由がどうであれ、同じ失敗を繰り返すのは、絶対避けたいです。

失敗から学ぶっていうでしょう。その考え方に基づいて、自分のミスったところを文章で書きながら振り返るのがまず一つ目の目標で、問題が何なのかとかについて、まず自ら診断、あとできれば読者の皆さんと何か生産性のある議論ができればなと思っています。

個人のサイトもあるんじゃあるんですけど、人が来ないので、ブログに投稿してみようと思います。ヨロピクです。