Forkwell主催 Front-End Study #3「『当たり前』をつくりだすWebアクセシビリティ」に登壇しました
2021年1月13日…
QA(Quality Assurance)について勉強してきた
2015年8月9日
恥ずかしながら、QAという言葉は3日くらい前に知りました
QAという言葉を恥ずかしながら今まで知らず開発をしてきたわけであるが、たまたま会社の方にQAについて勉強会を紹介してもらったので、行ってみた。参加した勉強会は、ソフトウェアテストによるソリューションを提供しているヒューマンクレスト社主催の 5minQues(ファイブミニッツキューズ)という勉強会だ。なお、一応調べてみたが、勉強会のQuesは、テスト関連のソリューションを提供する株式会社Q’Sとは関係はなさそうである。
今回の記事は自分なりの勉強会まとめというか、QAというものはなんなのか、それはなぜ必要なのか、どう導入するか、など考察をしながら書いていきたい。登壇者のセッションの内容は省略する。基本的に勉強会全体を通して、僕がQAについて学んだことを導入的な内容から書く。一応断っておくが、話題的にはWeb関連開発にまつわる分野のQAである。
QAとは何か
はじめに、QAとは何か。勉強会では、QAの明確な定義自体については、既知のこと、みたいな部分があったので、実際のところ明確な定義のようなものは説明はなかった(おそらく、短時間のライトニングトークと呼ばれる、技術的な勉強会によくあるスタイルだったため)。とりあえず、WikipediaのQAの項を参照することにする。
品質保証（ひんしつほしょう、英: Quality assurance, QA）は、効率と品質が求められるあらゆる活動において、それらに保証を与えるのに必要な証拠を提供する活動一般を指す。
というわけで、具体的に何をすればそれはQAだ、みたいなものはない。とにかく、この定義を信用するのであれば、「品質を担保しようとする活動全般」のことを指すので、やることは様々だ。実際に、勉強会のセッションでも、手動でのテストだったり、自動化されたテストだったり、各社さまざまな手法でQAの業務をおこなっているようであった。
QAの恩恵と重要さ
QAの取り組みを導入するメリットで、セッションから分かったことでいうと、テストがないことで発生する、ありがちなバグが少なくなることが1つ、あとはテスト自動化によって、手動テストからテストに要する時間の大幅な短縮であった。中には開発環境構築の段階から、サポートをするチームもいた。この場合、開発が開始する前段階からQAの動きが始まっていたりするので、その恩恵は計り知れない。
組織におけるQAの部隊は、大体どの組織でも製品の不具合を見つける最終ラインの防衛チームという感じの配置だったので、とても重要。よって、その防衛チームがあるかないかと言われれば、あったほうに越したことはないはず。
余談だが、ビジネスよりの具体的な1つの知恵としては、アプリケーション開発を外部に発注する際、QAについての取り組みを聞くとか、テストの一連の流れはどうしているか、などを聞くと、良いかもしれない。外注あるあるネタということで、開発を分かっていない人が変に権限を握っていて、ほとんど人月単価のみを参照して発注をしてみる。そして、製品が納品されたは良いが、要件は満たすものの、変なバグが出たりするということはあるあるだと思う。そういう事故をある程度未然に防ぐ対策として、外部の企業に開発を依頼する場合には、QAやテストの取り組みに関する質問は、発注の際にはそこそこ有益だと思う。そもそも、受託開発の市場での多くが、人月単価というアレな指標で動いているので、そういう状況下でQAやテストなんていう事自体が、そもそもの高望みかもしれないけど…(人月についてdisが始まるとどうしようもないので、ここでやめておく)。
QAを組織に導入するには
セッションでは触れられていないが、もしQAチームを組織に導入するとしたら、こうだというシナリオを書いておく。
1.QAチームをつくる
では、実際にQAを組織的に導入するにはどうするのかだ。まずは、QAをするチームをつくることから始めなければならない。僕がセッションから学んだのが、QAチームを名乗らずしてQAをやらないほうがいいということだ。理由は単純で、登壇した6企業の方々が、すべてQAにまつわるチームに必ず所属していたからだ。なので、例えば、ディレクターの業務にQA業務も組み込む、ということでも成り立つ場合もあるかもしれないが、最初はQAチームを構築して始めるのが良いと思う。組織というのは、新しいこの導入時の最初はルール化されていないと、認知されなかったり、分かりにくい場合もあると思う。また、組織がスケールしている場合には明確にチーム化されているほうがいい。だからまずチームをつくる。本気でQA業務を行う場合に、開発サイド・ディレクターサイドなどに意見が寄らないために、完全に独立したチームを設置するのが個人的には一番良いのではないかと思っている。
2.QAチームに権限を与える
結成されて間もないチームだったりすると権限が与えられないことが多いが、QAの場合、この権限がモノをいうことになるので、彼らに権限を与える。どんな権限かというと、「彼らがOKしないと世の中に製品を出すことができない」というかなり上位の権限である。前述のように、品質を確認する最終ラインがQAチームなので、当然彼らもプレッシャーである。
忙しい事業会社だったりすると、ディレクターが権限を握っていたり、上からの圧力で足がないジオングみたいなサービスをやむおえずリリース、なんてこともあるかもしれないが、これはQAが「ノー」といえばもちろんリリースできない。開発チームは、QAの指摘した不備を修正して、QAからオッケーをもらわないといけない。権限があることで、起こりうることが少しでも考えられる問題をQAチームは防ぐ。ちなみに、OkWave社ではQAチーム発足後、自社比90%のバグ減少という成果も上がったという発表があった。OkWave社では、チーム発足が1年足らずで、まだテスト自動化までは本格的にはやっていない模様。それでもこの驚異的な成果である。おそらくはQAチームの権限移譲がちゃんとしていて、QAチームが立ち回りやすかったから、未然に多くのバグを防ぐことに貢献したと推測したので、僕は強力な権限が必要だと考えた。
QAチームの実作業
QAチームの作業は、やはり主だったものはテストである。それ以外の動きについては、今回は割愛したい(勉強会ではいくつかテスト以外にも動きがあるようだったが、僕にはまだ理解ができなかった)。
手動テスト
よくある人の手によるテストである。テストのやり方は特定機能のプログラムだったり、そもそも出来上がったアプリケーションかもしれない。様々なテストパターンをテスト仕様書に書き出し、テストを繰り返す。テストの基本である。専門ツールを使わずしてテストができる。QAチームがあるだけで開発の質が担保される方向に向くので、のちに紹介する自動化テストもいいが、導入は手動テストでも全く問題はない。ただ、手動テストの場合の大きなデメリットとしては、再現性があくまで人の手なので、なかなか再現が難しいケースもあるということだ。そのため、自動化されたテストに注目が集まる。
自動テスト
テストの自動化にはツールが必要だ。僕もセッションを聞いて驚いたのが、今の世の中、GUIさえあればなんだってテストできるようなツールがあるようだ…。セッション中で紹介にあったツールで、具体的にいうと、eggPlantというツールで、これはサイバーエージェント社のローンチするアプリケーションすべてのUI部分のテストに使われている。ちなみに、このハードウェアの部分が高い車が買えちゃうくらいには高いらしいので、かなり高価なモノ！あくまで、1例なので、一旦コストはさておき、ともかく自動化テストの場合、なんらかのテストスクリプトを必ず書く必要がある。
なので、セッション中何度も話に出たが、テスターとしての「バグを出す」能力よりも、開発者よりのツール向けの言語を覚えてスクリプトを書く、という新しいスキルが要求される。スクリプトがあることで、問題の再現性がほとんど100%に近くなる一方で、作業者の要求スキルがテスターの域を越えた別分野にまで及ぶ、という課題がある。ちなみに、ある企業のセッションでは、現場にテスト自動化を落とし込むべく、まずは現場に開発者としての能力を身につけるべく、開発プロジェクトをやってもらい、そして自動化のツールを導入していくなどをしたらしい。しかし、要求スキルがテスターとそもそも異なるので、なかなか現場の技術力の向上は、思うようにいかないとのことだった。テスト自動化は、導入されたら便利だが、既存のQAチームに開発スキルがない場合は、そもそも導入が難しいという問題がある。
テストの自動化ツールであるが、ちょっと調べると、お高いeggPlantではなくとも、特定環境向けのテスト自動化は、コストをかけないでも十分に実施できることがわかる。おそらく、こういう便利なツールが他にも多くあることだろう。あとで詳しく調べてみようと思う。
JenkinsとSeleniumでWebの自動UIテスト環境を作ろう – ICS
技術の学習
最後に技術の学習だ。セッションを聞く限り、どうしてもテスト自動化はどの企業でも推進したく、また前述のように、導入時のハードルの高さが課題であるようだ。テスト自動化については、6社全社が何らかのキーワードで言及していた。手動テストがQA業務のメインで、すでに、QAチームへの技術的なトレーニングを実行している企業は3社中2社であった。なので、今後本気でQAをやるのなら、技術の勉強をしつつ、開発スキルがないとQA界のトレンドには着いていけないのかもしれない。実際に、GREE社とガイアックス社のQAチームの技術的なトレーニングでは、アプリケーションの開発をやっている。GREE社のセッションでは、QA担当者は最終的には開発そのものが分かっていないとダメと言い切っていた。また、DeNA社のセッションでは、
「QAは品質を測るもの。品質を作るのは技術と開発」
とそのまま、とても印象的な言葉があった。
QA業界のトレンドやキーワード
QA界が一番アツい視線を注ぐのは、やはりテスト自動化であるだろう。トレンドでいうと間違いなくこれだ。あとは、キーワード的には、「デバイスファーム」という言葉が何度かでてきていた。これも注目されているキーワードなのかもしれない。他で注目すべきは、eggPlantのようなGUIのテスト関連ツールだ。うちはアレを使った、どうだった、みたいなディスカッションもあったので、GUIテストのツールもかなり注目がされている。
感想
勉強会に出て、あー…QAっていうのがあるんだなー→QAないとか冗談もいい加減にしておけよ！！くらいにはQAの大切さを勉強できたと思う。
企画サイドでは、早くリリースをかけて効果を測定し、次の施策を練りたいのは分かるが、ディレクター・プロデューサードリブンな会社ほどテストに関する認識は甘いと思うので(技術者でも自分みたいにときに知らなかった人間もいるくらいだし)、企画サイドこそテストの重要性について認識したほうがいいと思う。
個人的には、開発者より、企画サイドがテストについて理解を深め、真剣にQAの取り組み活性化考えるべきだと感じた。 QAを真剣に取り組む場合、もちろんコストはかかるだろうが、リリースのトラブルは減ること請け合いだし(OkWave社では自社比90%のバグ減少！)、もし社内にてQA的な取り組みがない場合、十分に試す価値はあると感じた。
余談だが、世の中にはトラブル時にはなんならサービス停止をしても良かったり、デプロイしちゃいけないのにディレクターの謎権限で未完成機能でも強制デプロイ、その後延々と致命的な仕様の欠陥を引きずり続けて、あげく責任は一方的に開発者に押し付ける会社があると聞いたことがある。こういった会社はもはやQAなどは不要な概念かもしれないが。さすがに噂だし、こんな魔境みたいな会社あるはずないよね…？自分はテスト推奨。とりあえず、テスト書くのを面倒がらずに自分の開発ができるよう、努力をすることから始めたいと思う。以上！
Discussion about this post