第41回勉強会（2015/06/23） テストエンジニアへの道 第2回
システム開発やソフトウェア開発における、テストってちゃんと学べてる？
Windows女子部で連載した＠Typeさんでの記事では、44000pvを超えるテストの記事。（2015/06/23現在）
http://it.typeac.jp/period/index/2
JaaSTのテスト設計コンテストでの優勝経験もある Satsuki さんに講師をやっていただきます。
書いても書いてもうまく伝えられない気がして惑っているうちに、6月です。
このblogは手法も伝え方も、そして書いている自分自身も手探りでやっていますので、では今回は、と、思い切ってリアルタイム記述と更新にチャレンジしております。
第1回は？ と思われると思いますが、恐縮ながら、この第2回を更新することで、己へのプレッシャーともして、近日公開……とさせていただければと思います。
閑話休題。
TypeItの記事でも、エンジニア界でも、「テスト」の重要性については非常に関心が高いのだそうです。
一年前には、「要件定義」の勉強会をしたWindows女子部ですが、時間を経て今度は「テスト」勉強会。合間に行われた「JavaScript勉強会」も含め、エンジニアとして学ぶ必要性の高い項目を、じっくり進んできた感があります。
第1回は、テストとはなにか、そしてどんな手法があるかを座学で学びました。
（※ 資料は近日、参加者に共有されます）
ちなみに第1回のなかで示された「W字手法」という手法がありますが、これはまさにTypeItの連載で、Windows女子部の記事でも書かれていますので、ぜひご参照ください！
第2回のサブタイトルは、「よいテストを作る技を身につけよう」。
- 欠陥（バグ）を摘出
- 対象の品質レベルの保証
- 意志決定のための情報
- 欠陥の作りこみ防止
こういった事柄が、テストの目的です。
では、この目的に沿って、テストの項目を決めるためには、テスト対象の分析が必要になります。
「そ・れ・は・あ・た・る」というキーワードで分析観点をまとめられている方の書籍だそうです。多角的な視点を身につけるという意味では、テスト以外でも利用できそうな気がしたので、紹介された書籍もメモ。
質問が上がったのは、テストに対して求められている観念、「MECE」とはなんぞや……というところ。ここもメモしておきますね。
今回は「ソフトウェア」を主としたテストを学ぶ場なので、その土台としての考え方もいくつか紹介していただきました。
仕様ベース（ブラックボックス）
構造ベース（ホワイトボックス）
経験ベース
テスト技法は世の中に多数あるそうなのですが、ポジショニングマップとしてまとめられているものがあるそうなので、最終的に求める着地点を基準にしてテスト技法を探すためにはこのマップを参照してみるとわかりやすそうです。メモ、メモ。
では、テストに取り掛かる前に、意識しておくこととしては「テストの7原則」。
- テストは欠陥があることしか示せない。
- 完全なテストは不可能。
- 初期テスト
- 欠陥の偏在
- 殺虫剤のパラドックス
- テストは条件次第
- 「バグゼロ」の落とし穴
テスト、なんだか思想的。
人のつくるものを人がチェックする、ためには人の観点と視点、それから人ざらなるものの観点と視点（神の手！）が必要なわけで、なんとも哲学的な話だなあと思いながら説明を聞いておりました。
ここからは全員でワークをしながら、分析で必要な「定義付け」のための項目について、それぞれ「手を動かして」学ぶ時間に。
同値分析、有効分析、無効分析、境界値分析、デシジョンテーブル……とは？
ここで求められる「対象の前提条件」「その言葉の定義付け」を着実に眼と耳と手で学ぶのは、おもしろーい！
というのは、非エンジニアのわたしでも、日常のなかで他人とコミュニケーションを取るために、どんな観点を持っていたら認識のすり合わせが容易か、ということを改めて知り、学ぶ機会になるから、かもしれません（といいつつ、単なる自分の好奇心かもしれませんが……）
定義付け、といえば実は、「要件定義」の勉強会でも繰り返し繰り返しWindows女子部のなかで出されてきたキーワードです。
エンジニアの方々、は、非エンジニアのわたしから見れば雲の上にいるような、「わからない世界」にいる方たちというイメージ（ファンタジー風に言えば、過去記事のように、「魔法使い」だとさえ思っていますので！）。
けれど案外、その考え方を紐解くと、「ひと」と「ひと」のコミュニケーションを形にするひと、というのがエンジニアと言えるのかもしれません。文系エンジニア、理系エンジニアなどという言葉もよく耳にしますが、結局ひとは、「学びのアウトプット」で生きている限り、区別なんてできないのかもしれません。
テスト、というたった三文字なのに、こんなに多彩なチェック方法と考え方と観念と目的があって、逆に言えばそれだけの多彩な作り方と考え方と主張と製品があるのですよね。つまり組み合わせや、確率論、ベクトルの掛けあわせが発生します。
学生時代に涙目で数学を勉強しながら、これがいったいおとなになってなんの役に立つの？ と言う言葉をこぼした人も多そうですが（自分もその一人ですし、SNSでも未だによく見かける言葉ですね）、こういう勉強をするたびに、若かりし己の頬をぶって、
「必要！ 何を学ぶにしても必要な基礎が学生時代の勉強だ！」
と強く言い聞かせたくなる、次第。
（……そんな思考の寄り道をしながらワークを解いてみましたが、ASCII文字コード表、の説明のところでやっぱり頓挫しそうになったのでした……）
こういう、ひとつひとつの事象を紐解いて、こつこつと消化していくのが、世の中の「テストエンジニア」と呼ばれる方たちなわけで、その対象のものごとを、
「つかうひとたちが安全に、目的に沿って、何かを得られ、なおかつ造り手がスムーズに、目的に沿って、何かをアウトプットしきることができる」、
すなわち、
【造り手】>= テストエンジニア =<【利用者】
というバランス力のある方たち、ということなわけですね……？
エンジニアさんが魔法使い、と書いたのは1月の勉強会の記事ですが、テストエンジニアさんたちは魔法の箒のようです。
きちんと魔法使いたちを乗せて、ひらりひらりと宙でバランスをとって、障害物にもぶつからずに、目的地まで達します。乗っている人を落とさず、待っている人を待たせず（そして最後に落っこちて両者を潰してしまったりもせず）、きちんと両者を引きあわせたら、魔法使いの横でひっそり、けれど誇らしく、穂の先をぴんとのばしてすっくと立つ魔法の箒。こどもの頃、おそらく多くの方たちが乗りたかったことがあるであろう、憧れのアレです。
わたしたちは、いつもこんな魔法に囲まれて暮らしているのかと思うと、身近なモノがまたすこし、愛しく思えたりしませんか。勉強するって、知るってそういうことなんだなあと思う、最近の日々です。
最後に、初代部長の椎野さんからご紹介された、「テストエンジニアなら誰もが持っていると言われている書籍」も、メモ。
そして、テストに興味を持たれた方は、こちらなどもどうぞご参照ください！
▼若手テストエンジニアによる若手テストエンジニアのためのワークショップ
WACATE
▼ISTQB/JSTQB ！JSTQBの申し込みは今年は07/07だそうです。まだ間に合う！
その他テスト関連のイベントや勉強会、コミュニティについて知りたい女性は、facebookのWindows女子部ページもぜひ、訪れてみてくださいね。
……余談。リアルタイムで書いてみますと、どうしてもあれもこれもと欲張りになりますね。書いていく方法は、じっくり、あれこれと未だしばらく模索することになりそうです。
