SeleniumHQ 座談会

想形社の砂生貴光(さそう・たかみつ)さんを発表者にお迎えし、SeleniumHQ の概要を紹介していただきました。砂生さん、どうもありがとうございました。

(2010年2月26日開催)

テストは誰が行うのがよいか?

かわのテストケースを誰が書くのかという、ツールの質問というよりはプロセスの質問なんですけども、ウェブのサービスとか、設計・デザインして作る人がいますよね。テストケースを書く人というのは、設計・デザインをしている人がテストケースを書かないと書けないような気もするんですけど。

さそうそうですね。そこは確かにそのとおりだと思います。サービス自体を理解していない人がテスト問題を作っても不十分ですね。

いぬいそれは企業文化によるんじゃないですか? 僕はしばらくアメリカに行っていたんですけど、アメリカってすごい進んでいるなぁと思ったのは何かというと、作る部隊とテストする部隊が完全に分かれているんですよ。で、お互いが対立しているというか、仲がよくないとかね。例えば、作る方は一生懸命作るけど、テストする方は徹底的に意地悪なテストをいっぱいして突き返すんですよ。日本の中小企業とかだと自分らが作って自分らがテストするというが普通ですけど。僕はウェブではなくプログラムの開発でしたけど、ウェブも徹底的にやるなら、自分がテストすると甘くなるので、そういう部隊が専門にいて「ここを通過しないと出せない」とか意地悪テストをいっぱいやるとか、そういうことを日夜研究しているチームがあるんじゃないですか? 僕が行った何社かのアメリカの企業ではテスト部隊っていうのは結構力を持っていて、日夜バグ出し、「どうやったらバグ出んの?」って検討していましたよ。場合によっては開発の方の責任者を召喚して、テストチームの会議で「ここはどうあるべきか」みたいなことをやるんですよ。日本もNECさんとか…

あだち大手はやっていますよね。僕も一時期出向で行っていた頃は品管が別にいました。ただ、アメリカでは今おっしゃったようにテスト部隊がいろいろと研究しているじゃないですか。日本の品管は会社にもよるんでしょうけど、今いち、開発とか設計できる人がエリートという文化がすごく強い気がしていて、品管に来る人って、非エリートという言い方は申し訳ないですけど、できる人から落ちてきちゃう人が品管に行ったりしていることがあって、割と見逃しとかがあったりするんですよね。だから、日本ではテスト部隊って“派遣が行くところ”とか“非エリートが行くところ”というイメージがすごく強い気がしているんですけど、本当は仕様書を読んでテストを書くというのは、多分作るより大変なこと。

いぬい僕が行っていたところはテスト部隊がすごく技術を持っていて、バグを出すためのプログラムを作るんですよ。単に手でテストするとかじゃなくて当然自動化がされていて徹底的にやるとか、負荷テストとかはいかに負荷をかけるかというプログラムを作って研究するわけですよ。それを見てカルチャーショックを受けましたけど。

さそう日本だとテスト部隊というのは、今おっしゃられたように一段低く見られていて、なかなかレベルの高い、スキルの高い人が採用されることが少ないですね。大手企業も、最近は専門のテストツール、負荷を検証するとかセキュリティチェックしたりっていう製品を利用するという形になってしまって、なかなか専門家、テストチームというのをここ数年はあまり見たことがないですね。

あだち品管が開発責任者を呼んでいろいろ討議するってこと、あんまり日本ではしない気がするんですよ。テストをやって「テストがこうだったからここを直してくれ」というのをパラっと出すんだけど、それが本来どうあるべきだというのは多分ほとんど言わないんですよね。「これが仕様書にあったからこの通り試験しました。はい、終わり」と言ういうだけで、テスト部隊が本気で力を入れて「ぶっ壊すぞ」くらいの勢いでテストっていうような文化って、日本ってどうなんですかね、あまりなさそうな気がしますけどね。

しおやSEとプログラマはいますけど、テストエンジニアっていうクラスはなかなか聞かない。

さそうテストするにしても技術だけじゃなくてパフォーマンス的なこと、もしくは業務のサービスの内容とかも理解しなければいけないし、それに応えるためのPMとか上層部も、上流の業務はわかるけど技術分野まで把握しているかというと難しいですし、だんだん専門分野の分業化が進んでいってるから...テストって全体を見ないといけないから上の人も下の人も「うちが今作っている、管理しているシステムってどんなものなんだろう」というのを、広く浅く土台ベースで共有していないと、言葉で討論するときに「私はプロジェクトマネージャだからサービスしかわからない。何だ、Seleniumって。Javaって何だ。」「いやいや、そうじゃなくて、Javaだとこういうセキュリティとかあるんですよ」というコミュニケーションが成り立たないというところもあるのかな。ただ、少数精鋭でパッケージを作っているベンダーとか、そういうところはそういう体制ができていて、マネージャでも技術がわかるし、エンジニアも作るだけじゃなくてどういう売れるサービスを作るんだろうとか、そういうところを考えているところが多少あるかなと。

あだち中小はテスト部隊を持てる体力がないところが多いんでしょうね。そのために別に人を割くとか、5人開発を置いて5人テストを置くっていうような体力は、多分、今どこもない。

しおや開発もやってほしいしテストもやってほしいしっていうのが現状ですね。

あだち多分、2つ機能があって、2チームでやって片方は開発やって片方はテスト作って、今度は逆に片方は機能をやって片方はテストをやろうとかいうやつになっちゃうんですよね。

コードのコミット、レビュー

いぬい僕がやっていたときは、ソースコードを書いて、それをコミットするのがめっちゃ大変でした。うちは今Subversionとか使ってまして、CVSでコミットとかあるじゃないですか。うちはその部類(グループ)を幹と読んでいますけど、幹とか枝とか呼びますけど、コミットするときももう1人連れてきて内容を確認させたりとか、ツールで書くことがいっぱいあるんですよね。いっぱい書いて、同じチームにいるレビューアを呼んできて、レビューアに説明して確認して、そのレビューアの名前も見ることができて、パチっとクリックして、更にそれをプロジェクトリーダが見て、プロジェクトリーダが承認しないとソースコードに反映されないという。その中はそんなに面倒臭いんだなぁと。面倒臭いんですけど、それが製品がテスト部隊に渡る前なので、そういう風に管理しないと、適当にやるとむちゃくちゃになるんですね。しかも、何人とかの開発じゃなくて、百人はいなかったと思いますけど何十人も開発に携わっているので大変でしたけどね。

さそうみんながみんな好きな書き方で、英語で入れてフランス語で入れて「話している内容は同じだ」みたいなのを挙げられちゃうと、最終的にまとめるのが「どうまとめよう、これ」みたいな。

あだちアメリカってプレコミットレビューは多いんですか?

いぬいプレコミットレビューって何ですか?

あだちコミットする前に必ずレビューしないと絶対にコミットさせないというルールです。

いぬいそうですね。その頃はレビューアひとりでしたね。あとはプロジェクトリーダのところへ行くので、プロジェクトリーダが最終的にOKしないと、プロジェクトリーダが「おや?」とか思って「これ、なんか…」「この話は?」みたいな感じで差し戻しになります。差し戻しはあんまりなかったですけど。

さそう日本だと比較的どんどん入れてって、入れるに当たって「こういうルールでやろう」とか、「考え方としてコンパクトにしよう」とか、共通そうな機能に関してはプロジェクトリーダがきちんと聞いてから作ってコミットしようとか、そういう事前準備とか簡単な教育をしつつ、あとはやりながらルールを整備していって、「こういうやり方で今回システムとか、プログラムというコードを書いていこう」というような、やり方を育てていくというようなのが多いですかね。中には好き勝手上げられちゃって収集がつかないというようなこともありますけどね。

あだち企業によるんじゃないですかね。僕が前にいたところは国内企業ですけど、ソースコードレビューは一応やらされましたね。外注の仕事を取ったときは納めるところにコードを全部、何千枚もプリントアウトして行って、一人一人に渡していって、さすがに何千枚も全部はできないので一部抜いては「これはどういうことですか?」とか聞いてくるので、それを説明するということはやっていました。

かわのコードでですか?

あだちコードです。

かわのへぇ。

いぬいコードレビュー、やりますよ。で、何時間かけた、とか書くんですよ。

かわの結果が出ればいいんじゃないの? コードは実現手段でしょ?

いぬいでもね、あんまり適当にやるとデグレードって言って、前に動いていたところが動かなくなるんですよ。プログラムってちょっと微妙で、皆さんわかっていると思いますけど、他には影響しないと思っていながらも影響することって往々にしてあるんですよ。もう1回そこら辺を確認するとか、そういうことをやっています。

あだちあとは、どんどん後の工程になるほど、そのときのミスを直すコストが高くつく。単体でそのコードのテストをすぐにやってそこでわかれば一番いいんですけど、結合テストとかシステムテストで出ちゃうと、そのためにまた他のところも回帰テストをやらなければいけないとか、コストが非常に高くつく。当然、お客さんに出ちゃったりしたら企業のイメージとか、そういったものに対するダメージがすごく大きいので、なるべく早い段階でわかるところは直しましょうという意味合いでコードレビューというのがあります。

かわのなるほど。よくわかりました。

いぬいコードレビューもやりますし、一つのC言語の関数が200行くらいの関数を作るごとにスタブとドライバを書いてテストしなければならないとかって、一生懸命やってましたよ。200行書くためにすごい時間かかるんですよ。

かわの自転車に乗ってプログラミングするのとちょっと違う話ですね(笑)。家やビルを建てるようなものですね。

しおやそうですね、こうなってくると。

(以上、インフォサイエンスにて)