"テストから見えてくるグーグルのソフトウェア開発"を読んだ時のメモ
ここしばらくプログラム勉強ができていないのは私のせいですスミマセン。
いかんせん体系的に勉強したことがないので、非常につまらないところで長時間止まってしまうところがありまして。 で、思ったのが、ちょいと調べてわからないならわかる人に聞きまくるソリューションで行こうと思いました。分かる人、優しく教えて下さい。
今回の記事もプログラムの話ではなく、タイトルの本を読んだ時のメモです。 数年前に http://www.publickey1.jp/blog/11/post_144.html の記事を読んだことがあったのですが、本として出ていることを去年末に知ったので買ってみました。ボリュームあって読むのが大変でした。。。
部分的になりすぎてこの本の魅力をほとんど伝えられない投稿になってしまいましたごめんなさい。ホントはもっとQAもコードで話をしていくとか、デベロッパーと同等の立場、給料で働いているよとか、ややもすると開発者よりも格下に見られることのある仕事ですが、GoogleでのQAの位置づけってスゴイ（当然それだけの能力が求められるけど、そういう体制、文化を浸透させてきたという点で)なーと思いました。しばらくしたらまた読んでみます。
グーグルの社員として認められるにはコンピューター科学の基礎とコーディング能力を持っていなければならない。
とか
SWE…Software Engineer デベロッパーのこと。
SET…Software Engineer in Test SWEが作った機能のテストを書く。設計やコードのレビュー
TE…Test Engineer 第一にユーザー、第二にデベロッパーのために(エンドツーエンド)テスト自動化を書く。多くのコードを書く人もいればほとんど書かない人もいる。
って書いてあって、それぞれの職種がどんなことをやっているかの記述もあったのですが、、、、なんというかよく理解できませんでした。。。＿|￣|○ 色々書いてあるのですが「具体的にはなんだろう」って思っちゃったので。テストコード自体とか、テストフレームワークとかテストインフラを作ってる人がデベロッパーと同じ立場で仕事をしていて、自動でできるところは自動化するのが正義って感じだけど、人じゃなきゃできないところ(UIの美しさ、表示するとプライバシーの問題が起きるかどうか、などの人の判断を必要とする問題)だけを手動テストの領域に留める、と。
テストコードが役に立つのは、開発を加速するような形で実行できる場合であって、開発がスローダウンするのでは意味が無い。そこで、テスト開発は、開発の一部であって開発から切れたものにならないように開発プロセスに統合されていなければならない。
TDD、単体テストはデベロッパーが責任を負う、とした上で、この手法(体制？)ってどうやって成り立ってるのだろうか。グーグルくらい巨大な組織だからなのかなーとも思う。
テストプランは、テスト関連で最初に作られ、最初に無視されて死んだも同然になってしまう成果物だ
テストに直接結びつかないテストプランは無駄だ
んー、確かにテストプランは作ったはいいけど使われない、って思われますね。でもこれはWebの世界では同意しますが、メーカー(デジカメ)にいた時はきちんと効力を発揮していました。リリース判断の材料としてここで定義された「テスト」が完了していることが必須だったし、それに則ってプロジェクトが進行していたし。ただ、この本もテストプランは不要とは言ってなくて、最終的な成果物は(プロダクト)コードであり、コードのアップデートに合わせてテストプランも更新され、テスト中に役に立つ物じゃなければならない、ってことなのですが、それが大変なのよね。例えばあとから入った人がプロジェクトやテストの全体像、今の状況がすぐに分かるものである、とかね。
あと、BITE(Browser Integrated Testing Environment)についての記事が非常に興味深かったです。「バグの報告」を「テスターの時間や精神的エネルギー」を浪費する行為として位置づけ、もっとバグに警戒すべきときに集中力や創造力が失われてしまう、ということから開発されたらしい。
で、これは何かというと、Chromeのエクステンションとして存在し、Chrome上でバグがあった部分をクリックするだけでハイライトされ、自動でバグとして登録できるというすぐれもの。URL、ページ上の要素/テキスト、スクリーンショットの添付はもちろん、テスターがそのページでしていたことがリプレイできるJavaScriptが生成されるという・・・なにこれスゴイ。(もちろん手入力もできるフィールドも用意されている)ついでに、同じ要素に対して他の人がすでにバグ登録してないかとかも出ちゃったりして、二重登録とかも防げるって、ものすごくない？
だけど、https://code.google.com/p/bite-project/ に行ったら「I apologize but there is no one left to maintain this project.」ってことなので開発は終わっちゃってるんですね。。。画期的だと思うんだけどな。(Chrome以外のブラウザはどうすんだ、って話もあるけど)
他にもいーっぱい線を引いたところはあるのですが、まぁなんというか、今私が行っている「ブラックボックス中心のテスト」はそれはそれとして絶対に必要なのですが、もっとスマートにテストできるような仕組みにしなければと思うわけです。それには技術を駆使する必要があるわけで、勉強しようっていうモチベーションが上がってきました。
今はE2Eテストを自動化してみる、っていうのが目下の目標ですが、結局そのテストが「的を得ているか」は人が考えるわけで、行き着くところは人のアイディアだと思うのです。どれだけ意味のあるテスト項目を考えられて、効率よく実施できるかかってのがQAエンジニアの真価なんだろうなと思います。
