備忘録

プログラマの日々の業務の備忘録です

DevOps時代のテスト自動化カンファレンス

DevOps自体のテスト自動化カンファレンスに行ってきました。

数年前から少しずつ検証しているテスト自動化。情報収集のためにセミナーに参加してきました。参加者は、20代と50代は少なく30代、40代が多い気がしました。多分、リーダーと付く役職の人が参加したのでしょうか。会場は満員で大盛況です！

そもそもの参加の理由

少ない人数でも品質の高いものを作り続けるには？という考えから。

もう少し詳しく書くとこんな感じです。

  • Redmine+Jenkinsをもう少し欲張りたい。
  • 開発文書のメンテナンスを行うなら、テストの自動化を行いたい。
  • 少ない人員でも品質を向上したい。
  • 機能が増えてもデグレードの発生を抑えたい。

■感想

技術的な情報よりも、これからのエンジニアの考え方を聞けて良かった！という感じ。

これからのエンジニアに必要なモノ…大雑把に問題解決力。エンジニアに限らない話じゃないですね。実感したのは、技術的なスキルだけじゃなくコンサル的な視点（問題の本質を見抜くというか、皆が幸福になる方法を選択できるとか）も必要だということ。

■文化

DepOpsを推進するには「文化」が重要になる。個人の考えではなく各人の共通認識が重要って事なのでしょう。そもそもテスト自動化も、常日頃から「この作業が自動化できたら楽だろうか」とかアイデアがない限りは必要ないでしょう。

【１】静的解析

  • クリーンなコードでなければ自動化できない
  • すべてを自動化するのは非現実的
  • 高リスク箇所を見極めて自動化を行う

テスト自動化には、テストのためのアーキテクチャが必要となる。

確かに静的解析ツールでのコードレビューは、個人意見でのレビュー意見がなくなるので良いかも知れない。また人に指摘されるよりツールで指摘された方がプログラマの心も痛まない。プログラマも心が痛まないで自己鍛錬できるからモチベーションがたもてる…か？

個人意見に左右されるものはツール化してしまった方が、各人の考えに依存する必要がない気がする。

多分、VisualStadioなどではツールとして提供されていると思うが…、こうなるとコーディングの先生はツールになりますね。

それはそれで良いか。

プロジェクトが炎上すると、個人能力の最大値を求められるので他の人に依存しない構成はありがたいかも知れない。

1.テストを自動化するには、それに適したアーキテクチャ

2.テストに適したアーキテクチャには自社の静的解析ツールが良いですよ

と、先ずは自社ツールの導入を勧める道筋が出来ていて良かったです。

【２】テスト自動化を成功させる秘訣

品質を向上するには、先ずは地道にテストを行いなって目標の品質にたどり着きなさい。

以下の問題点が浮き彫りになるはずです。

  • 優秀なテストエンジニア
  • 正しいテストケース
  • 膨大なテスト工数

これらを浮き彫りにしてから「自動化に最適な項目を抜き出しなさい！」というのが秘訣。急がばまわれ。ツールによって目標値を達成するのではなく、達成した目標値をいかにコスト低くたもてるか？の方が成功に結び付きます。

どのみちテスト自動化を行うには最低半年の時間が必要になりますので。

この手間を考えるならば、アウトソーシングを使うのも良いです。

テストツールならば、数人のプロジェクトならセレニウム(Selenium)程度が良い。

（でもSeleniumだとJavaの知識が必要になりますよ）

テスト自動化を考える前に、テスト自体に真面目に取り組みなさい。その後に自動化が必要かどうか考えなさい。テストの自動化を考えるならば、先ずは目標を明確にしよう！

でも上からは「テスト自動化をしなさい！」としか言われないんだろうなぁ…。

テストの自動化が目的になってしまうと、本来の目的であるバグの削減を見落してしまう状態になることが多い。

【３】テスト自動化の体制

NTTDataでは「テスト自動化に4000万掛かったが成功プロジェクトだった」との話があった。テスト自動化のキモは、実際にそのコストを抱えている運用側の意見の総意が必要である。

費用対効果を判定できる部署の合意は必須である。

よって、テストの自動化には Dev(=開発側）とOps(=運用側）の考えが必須である。

ボトムアップからテスト自動化を提案する場合は、オープンソースで効果を確かめながら導入を判定するのが良い。

 

ツールが定着するかしないか。

定着しないパターン）

・トップダウンが製品選択して導入した場合

定着するパターン）

・現場で発生している問題に着目し運用フローまで考えた場合

 

製品選択から入るのでなく先ずは問題点に着目し解決策を考えなければ定着しない。 コンサル的な視点から考えないと当然定着はしない。

【４】テストの品質向上

品質向上にはテストケースの充実が必須である。要件を理解している人がテストケースを作成するのが最も抜けがないという話。

これは、開発者がテストケースを作成すると要件に対するテストケースが漏れるという考えから。でも開発現場からは、要件を理解している人がテストケースを作成するとシステム的な異常に関するテストケースが漏れるという話がある。

結局、両方が必要なのでしょう。要件定義も出来てプログラミング出来ること。

【５】QAエンジニアにはプログラミングスキルは必要か

これからはQAエンジニアにもプログラミングスキルが必要になると思われます。

テスト自動化ツールを導入したとしても、以下のことが予想されます。

  • プログラミングではない自動化は再利用性がない
  • プログラミングではない自動化は海外リソースで低コストで済む

国内でQAエンジニアとしてやっていくなら、ある程度のスキル（Chefなどのスクリプトを掛ける程度のスキル）がないと仕事が無くなっていくと思われます。人海戦術なら海外リソースの方が安いため。

【６】スモールスタート

何が問題か見極める必要がある。全てが問題と思っている場合は、先ずは静的解析を始めるくらいのスモールスタートで良いと思われる。

※補足

「エンジニアとして成長したいならオープンソースの開発者として登録しなさい」という感じ？オープンソース開発者は開発ツールに関しても優遇されている気がしました。