5
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

テスト自動化失敗談を共有しよう! by T-DASHAdvent Calendar 2022

Day 1

自動化に関する 3 つの失敗談とその教訓

Last updated at Posted at 2022-11-30

はじめに

自動化完成!自動化を担当していて、これほど心躍る瞬間はありません。「これで楽ができる」、「これで早く帰れる」と期待に胸を膨らませるのもつかの間、待っていたのは失敗でした。ここでは自分が体験した自動化の失敗談と教訓を紹介します。

運用前の失敗談(教訓:環境チェックは念入りに!)

自動化に失敗するパターンで、おそらく一番多い原因が環境問題だと思います。開発環境で完璧に仕上げて本番環境に持って行ったところ、ライブラリがないとかバージョンが違うとかで悩まされることがあります。本番環境なのでバグ出しに時間を使うこともできず、かなり焦ります。

対策としては、下記を事前に確認しておくことになります。非常に基本的ですが、結構見落としがちな点でもあります。

  • 環境、ツールのバージョン
  • 使用されているライブラリ
  • 文字コード等

バージョンに関して、開発環境と本番環境で揃えておくことは原則です。しかし、新しいバージョンがリリースされると、ついつい使ってみたくなります。「開発環境だからちょっとお試し」のように使ってしまって本番環境と差分が出ないよう、細心の注意を払うことが重要です。

またライブラリも問題になることが多いです。例えば Python の場合、便利なライブラリがあるためついつい使ってしまいます。ところが本番環境では、セキュリティ上の理由から追加のライブラリはインストール不可という場合もあり、標準パッケージしか使えない環境もあります。その際には、標準パッケージだけを使うように開発時から想定しておくことも必要です。

最後の文字コードに関して、最近は Unicode で文字化けはあまりありませんが、問題になるのは改行コードです。CR, LF, CR+LF といった問題は、現在でも発生します。個人的な失敗例として、ログを外部システムに REST で POST する際に、json フォーマットに書き直す自動化でこの問題に遭遇しました。ログの改行コードを json で使える \\n に置き換えていたのですが、システムごとにログの改行コードが違い、json の validation エラーになってうまく自動化できていませんでした。

また上記のような場合に備え、そうした事態に対処できるよう、あらかじめデバッグログを出力するようにしておくなど、事前にデバッグコードを仕込んでおくことも重要です。本番環境ではデバッグの時間が取れないため、事前の準備がとても大切になります。

教訓

  • バージョン、ライブラリ、文字コードなど、環境差分には細心の注意を!
  • 本番環境で焦らないよう、あらかじめデバッグを想定しておく!

運用開始時の失敗談(教訓:フェイルセーフを考慮する!)

なんとか問題なく運用を始めても、想定通りに使ってもらえないことで発生する問題があります。自分では最高に使いやすい自動化をしたつもりが、パラメータに何を入れたら良いのかわからないという問い合わせを受けたり、想定外のパターンで使われてエラーになるということもあります。

対策として、下記をあらかじめ想定しておくことが大切です

  • 誰がどのように使うのか
  • 想定外のパターンには何が考えられるか

自動化の目的はさまざまですが、おそらく自分が使うだけではなく、新人や不慣れな方でも作業できるようにすることが目的という場合も多いと思います。その場合は使いやすい自動化を心がけましょう。CLI ではなく、ブラウザなどのフロントエンドを被せて使いやすくするというのも重要です。また自分では json でパラメータを指定する想定が、Excel にして欲しいという要望をあとから言われることもあります。その場合は、初めから Excel で自動化を設計しておいた方がはるかに楽です。

また想定外の使い方は常に想定しておく必要があります。想定外の使い方をしても止まらない設計にする、いわゆるフェイルセーフ (fail-safe) を考慮しておくことで、安定した自動化が可能になります。考えられるパターンは無限にありますが、主なものとしては下記が挙げられます。

  • パラメータの間違い(範囲外、数字の代わりに文字を入れる、「11 月 31 日」といったあり得ない日付を入れる、など)
  • 自動化対象の間違い(本来と異なる対象が選択されたなど)

教訓

  • 利用者と利用方法をあらかじめ想定しておく
  • 想定外のパターンでも止まらないための foolproof を考慮した設計にする

運用後の失敗談(教訓:誰でも継続して開発できる環境を!)

自動化が成功し、これによって楽ができると思いきや、逆に仕事が増えるパターンもあります。追加の機能を依頼されたり、新しいパターンをリクエストされたり。共同開発のはずが、結局自分だけで抱え込むことになってしまっては大変です。

対策として下記が考えられます

  • 開発の当初から、できるだけ読みやすい誰でも拡張できるような設計にする
  • 開発環境やツールを明確にしておく
  • あらかじめ共同作業を想定しておく

共同開発ができない原因として、まずコードが理解できないと言う点があります。開発の際、コメントを入れておくことで、そうしたことはだいぶ回避できます。初めは自分だけわかれば良いと思ってコメントを入れておかず、後になってからコメントを追記するのは大変です。初めから他の人も開発できるよう、コメントを入れておくよう心がけておくことが大切です。

また開発環境やツールを明確にしておくことも重要です。特定の環境下でないとビルドできないといった状態では、永続的に自分が開発を続けることになり、仕事が減りません。コードの説明に加えて開発環境の明確化も重要です。

複数人で開発するようになると、コードの管理も重要になってきます。Git レポジトリなどは、あらかじめ用意しておくと後で楽に運用ができます。また人によって書き方がバラバラにならないよう、書き方のルールも明確にしておくと後で読みやすくなります。Python でいえば PEP8 にどこまで準拠するのかといったルール決めも必要かもしれません。

教訓

  • コードへのコメントは忘れないように
  • 他のメンバーでも開発できるよう開発環境を明確に
  • Git 等によるコード管理やコーディングルールを明確に

まとめ

なかなか思うように行かない自動化も、最初の準備やプランニングをすることで、とてもスムーズに進むようになります。しっかりとしたプランで自動化をして、楽しい年末年始をお過ごしください。

5
2
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?