« jenkins導入に関するページを作成しました! | トップページ | 「実践!、コードレビュー」の話 »

現場でSeleniumを使ってみた!

11月の定例会にて、某大手サイトの1カテゴリー分の改修開発に、アーキテクト・兼・プロジェクトのサブリーダーとして参画している三文字さんから、現場の実案件にSeleniumを導入した実績からお話をして貰いました。

Pict2667_2参画時点ではSeleniumIDEを使った疎通(正常系をざっと流す)試験にのみ利用されていたようですが、本格的な導入と言うほどではなかったようです。

Seleniumは、当ブログのWebページにも記載させて戴いていますが、決して開発上の「銀の弾丸」として万能の効力を発揮するものではありません

適用のポリシー決めと、メンバー各位への周知と理解・合意の徹底。
コストと納期、コードの寿命、画面・機能の特性など、様々な要素から考えて、自動テストの適用範囲と運用フローを決めなければなりません

また、テストコード自体に対するコーディング規約やポリシー、共通部分を含めたテスト実装のアーキテクチャも決めていなければなりません。

これが抜けていると、テストコードがメンバー間で重複したりで、テストコード量が増えてメンテナンスコストが激増してしまいます!!
(これは、今後に際しても負の遺産としてメンバーに苦痛を与え続けることになります...)

Pict2669_2リリースに迅速性が求められていますし、当然ながらコストも無視できません。

単発のサービスやイベントとは違うので、ある程度長い目で見て、品質を担保しつつ、トータルで低コストで、かつ退屈で品質リスクを伴うな手動テスト(担当者への個別依存性は出来るだけ下げたい)は可能な限り避けたい(モチベーションの低下にも結び付き、これは人間である以上は品質にも直結しますよね)。

Seleniumの本格的な導入には、当初はリーダーさん(顧客側)からは難色を示されていたようですが、部分的&試験的な実施により、実績値を取って(Selenium導入機能と、非導入機能とで工数や不具合件数を比較した)リーダーさんに提示&説明することにより、本格導入にゴーサインを戴けました。

三文字さん得意の、ソースコードを中心とした自動生成技術と併用することで、顧客からプロジェクト単位での高い評価を得ることが出来ました!

これは嬉しい事です!!

しかし、同時に、Seleniumは想定していた以上に運用コストも大きいことが分かって来ました。

テストコードのアーキテクチャの改善と共に、テスト適用対象の絞り込みが重要であることも大きな学習ポイントとなりました。

Pict2670_2これは、インターネット上で検索すれば多々見かける情報なのですが(当サイトのWebページにも記載していますが)、Seleniumでのテスト実行は「テストそのものに驚くほど時間が掛かる」!

まるで、20年ほど前に、「ビルドを始めたら4~5時間かかるので、1日に1~2回とか、帰宅前にしか実行できない」ようなレベルです。

なので、全テストを一気に自動実行するのではなく、テストをブロックに分けて実行しました。

この辺に関しても自動化(テストブロックの自動実行; エラーが出たらそこで止まって担当者に通知メールを流すなど...)をしたかったのですが、諸々の事情によりとにかく時間が無い...。
結局、ビルド管理を三文字さんが引受け、ブロック毎のテスト実行を手動でキックすることになってしまいました...。

次回以降では要改善点ですね。

でも、実現できた様々な点、メリットも有ったし、メンバー間で共有も出来た!

これは大きな収穫だったと思います!!

これを今後のフェーズにも活かしたいし、別プロジェクト間でも横断的に、ナレッジの共有・交換を進めていければと思います。

三文字さん、まだ終了ではありませんが、一旦はお疲れ様でした!&社内共有有難う御座いますっ!


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

|

« jenkins導入に関するページを作成しました! | トップページ | 「実践!、コードレビュー」の話 »

定例会、勉強会など」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 現場でSeleniumを使ってみた!:

« jenkins導入に関するページを作成しました! | トップページ | 「実践!、コードレビュー」の話 »