タイトル未定

品質や趣味について語りたいブログ

WACATE2019夏を通して感じたこと

はじめに

どうも、お疲れ様です。

WACATEのあと休みを取らなかったことでずっとテスト尽くしの12日間を終えて土曜日にたどり着きましたhalspringです。

WACATE2019夏に参加してきました(WACATEについての説明は省略します)。

この記事では自分がWACATEに参加して"感じたこと"を中心に書こうと思います。 ですので、今回のWACATEの内容については他の参加レポートやtogetterをご参照ください。

パッとしらべて出てきた参加レポートはこちら

qiita.com

note.mu

感じることというのはその人の周囲の環境や経験、体調や気持ちによって大きく異なります。 ですので、記事に価値のある情報はほとんどないかもしれません

興味のある方のみおもしろ半分で読んでいただければと思います。

目次

説明ができる

WACATEは2018冬が初参加で、今回が2回目です。 夏と冬でワークの時間も雰囲気も異なる影響もあるとは思いますが、冬のときよりも積極的に発言や説明を出来るようになっていた気がします。 ソフトスキルが向上した と言いたいところですが、班のほとんどが初参加者で若干頼られる存在になっていたことと、そのことを感じてある種の責任感があったのだと思います。

また、普段はチーム内でテストについてわざわざ説明を行う機会はあまりありません。組織によってはクライアントに説明をすることがあるかもしれませんが、例えば「テストレベルとは」のようことを話したりする機会は少ないと思います。( テストジョークのようなことを雑談で話したりはしますが )

普段 説明したり話すことの少ないことについても、(正しくない可能性は否定できませんが)自分なりに説明をすることができることに気が付き、1年前 やっと新卒研修を終えたばかりだった自分から成長できていることを感じられました。 ソフトウェアテストは 開発のように目に見えるアウトプットを作りにくく、成長の実感をすることも難しいと思います。 WACATEのワークショップは なにが説明できて何が説明できないのか 何を曖昧なまま使っているのか、その辺りをスッキリさせる良い機会なのかもしれません。

経験の共有

WACATE2019夏のひとつの目玉である(と勝手に思っている)テスト計画、 参加者の何人がこれまでに作ったことがあったのでしょう。 別に作ったことがあるから偉いとか、やったことがないからどうとか、そんなナンセンスなことを言うつもりはありません。

過去にテスト計画がテーマの勉強会でも「テスト計画を作ったことがある人」の質問に対して手が上がったのは半分に満たないくらいでした(手をあげるのが好きではない人もいるとは思いますが)。 テーマにテスト計画を掲げている勉強会でその割合であれば、テストプロセス全体をテーマとし若手を中心(新卒や業界1年目2年目の方も多かったです)としたWACATEでは より少ないだろうと思います。

ひとつ前で述べた責任感の話もあり、運良くテスト計画を経験したことのあるだけの自分は おこがましくはありますが、他の参加者になるべく多く自分の持っている知見を共有しなければと感じました。

全てがそうだとは思いませんが、経験できる/できないには運が大きく関わっていると思います。 しかし、経験を出来ずとも経験者から知識を得ることはできます。 当然、実際の経験から得られるものに比べれば不確かで、偏っていて、不足している情報かもしれません。 それでも自分の経験を出来るだけなぞれるように、聞いた人が咀嚼して飲み込めるように意識して伝える責任があると感じました。

経験を積めないことについては本人が悪いわけではありません。 (意図的に避けて経験を「積まない」場合は別ですが。)

自ら飛び込んでいけばいいと言う意見もあるでしょうが、飛び込んで行くにはそれ相応のリスクも必要です。 ただ本を読むだとかそのレベルなら良いですが、転職するだとか職種を変える必要が出てくると様々なものと別れる必要が出てきます。飛び込んだ先で叶うとも限りません。 自分が経験を積むために何かを捨てる必要があるとき、その決断を迷わず出来る自信は正直ありません。

ですから、運良く経験出来る立場になったら 経験出来ないけれど「せめて知識だけでも」と情報を必要としている人達に向けて共有しなければいけない、 そうしなければ、業界全体は良くならないように思いました。なにもせず良くなるとしても、したほうが格段に速いはずです。

土日にお金払って遠出してまでテストを勉強している我々です。 古臭い文化、目的のないテストが行われるような現場、QAエンジニア・テストエンジニアの価値向上、発展のために出来ることがあります。 今すぐは難しいかもしれませんが、加速していきましょう。大層なことを言ってしまったので自分も頑張ります。

リードするということ

テスト計画の経験から、計画を立てる際に班をリードして進める役に他薦して頂きました。 自分がテスト計画を立てるときに、どう考え、どんな流れで進めているのかを説明し、ひとつひとつの自分の判断に対してなるべく理由も話すようにしました。

「こんな理由から こんな感じに進めようと思うのですが、どうでしょうか?何かご意見ありますか?」と尋ね、合意を得ながら進めていったものの、「そういうものなのか」と丸呑みをさせてしまったのではないかと少し不安になっています。

ワークを進める上でなるべく全員に共通の理解を納得感を持てるように自分の意見を言う前に「ここはどう思いますか?」と先に話を振るなどもしてみました。

結果として班のメンバーから意見が出て、「こうした方が良いのではないか」「ここのリスクは◯◯なので優先度をスコープから外してもよいのではないか」と議論検討することもでき、充実したワークを楽しむことが出来ました。 しかし、全体への問い掛けでなく、もっと個人に振ればよかったのではないかと後悔もしています。 ファシリテートって難しいです。

班の方にはありがたいことに評価して頂けましたが、今後 同じような役割を担うときにもっと上手くできるように意識したいです。

リスク分析

自分はテストアプローチを考える時にまずはリスクを出してくのですが、全体のリアクションを見ていて「あまりリスク分析ってされていないのでは...?」と感じました。

意識せずにリスクを気にしている、ということは当然あると思います。無意識にリスク分析を行ってテストを設計することはもちろん不可能ではありませんが、無意識で行なっていては考慮していないもの(例えば機能)が出てきてしまうのではないかと思いました。

全体の成果物の発表を聴いていて、ほとんどの班が「リスクの大きい部分を中心にテストしました」と発表していました。 時間の都合もあって詳細までは聴くことができませんでしたが、テストする機能/しない機能の決定にロジックがあったのかなかったのか、あるならどう決定したのか、ひとつひとつの機能や複合的にどんなリスクがあるか検討していたのだろうかと気になりました。 (どんなアプローチを取っていたのか気になるので、差し支え無ければtwitterか何かでお教え頂けると嬉しいです!)

他の班としみじみアプローチや見つけた不具合について話し合う時間を取れれば良かったのですが、疲れと 人に話しかけるスキルの低さが露呈してしまいました。無念。

経験?ロジカル?閃き?

今回のワーク中、システムテストで主機能を確認、受け入れテストで全機能をシナリオベースで確認するアプローチを取りました。パフォーマンステストやクロスブラウザテストは今回のテスト計画からは外す方向で進んでいました。

ところが、班の人が使っている端末がwindows 4人とmac 2人であったため「システムテストをwin、受け入れテストをmacで実施すればある程度のクロスブラウザの担保はできるのでは?」と判断して、その方針で進むことになりました。

このようなアプローチのアイデア、これは経験から来るのでしょうか?それともロジカルに導いているのでしょうか?あるいは咄嗟の閃きなのでしょうか?

初めは閃きorロジカルから来るもので、徐々に脳にキャッシュされ経験から出せるものになるのでしょうか? だとすると、キャッシュが古くなり過ぎないように工夫しないとなぁと感じました。

twitter

前回も思いましたが、WACATEでtwitterアカウントを開設する方や、放置していたアカウントを掘り出す方、多いですよね。 今回は時間的制約の強いワーク中心であったため、あまり活発ではなかったのかなぁとは思いますが、勉強会やイベントでは大体 誰かが 議事録的なメモ、実況、疑問、感想をつぶやいています。 WACATEに関して言えば、ハッシュタグのない裏側で有識者達がTLの内容を見てつぶやいたりもしています。

この辺りの情報も拾いながら参加すると より視野が広がったり造詣が深まったりします。 疑問をつぶやくと講演者や有識者が答えてくれたり、誤ってメモしていたり理解していることは指摘してくれたり周りを見て気が付けたりします。

界隈の方には(よほどのことがなければ)とても温かく見守って貰えますし、自分はなかなかの人見知りですが twitterから認知して頂いて話しかけてくださる人が増えたり、登壇させて頂く機会を頂けたりと良いこと尽くしです。 リアルのコミュニケーションが苦手な方はテスト用のアカウントを作るもよし、ROM専でもよしなので、情報源は増やしておくことをオススメします。

QAの需要

感覚値ですが、開発やその他職種からテストエンジニア/QAにジョブチェンジしている人が多かった気がします。 テストの重要性が少しずつ理解されるようになって来ているように思えます。

ただ、QAの求人もよく見かけるようになってやはり「必要になったものの、今まで抱えていなかったからどうすればいいのかわからない」という面が見えます。

QA人材のおおまかな獲得方法は、

の3つだと思います。 中途で雇う選択肢は、評価できる/見極めることができる人が社内におらず 採用が難しいのかなと思います。 また、必然的にQAチームの立ち上げからになるので、チーム立ち上げ型転職芸人のような熟練者は別として、応募側にとってもハードルが高くなってしまうのかなぁと感じます。

新卒から育てる選択肢も同じような理由で難しく思います。わかる人がいないということは、育てられる人がいないのです。

そうなると残る選択肢はジョブチェンジです。 元々開発をしていれば、自社のドメインには詳しいですし、テストもまぁできる、開発をより良くするにはどうすればいいのか考えることもできます。 おそらくそういった背景の下、ジョブチェンジでQAになられた方が増えているのかなと思いました。

そしてその流れが進んでいけば 開発の知識やマーケティングの知識など、品質保証プラスアルファの知識を持つ方が増えてくるのだろうなと思います。 もちろんその流れがなくともそうなのですが、QAやテスト以外の技術や知識、観点も身に付けて自身の価値を創造して磨いていく必要を強く感じました。

最終的に目指したいところは自分の価値の最大化ではなく関わる方に与える価値の最大化なので、得たものは現場やコミュニティ、業界に還元できるよう頑張ります。

おわりに

色々と生意気なことを書いてしまっていると思います。大変畏れ多いです。

夏と冬でこんなに違うのかと驚きました。 WACATEはどんな参加者にも何かを与えてくれるので本当にすごいコンテンツですね。 実行委員の方々にはとても感謝しています。 そして次回も楽しみにしております。ありがとうございました。

探索的テストで やっていること・意識していること

 

どうも、halspringです。時というのは早いもので とうとう2年目になりました。 

こうして楽しく仕事したりテストについて考えたり発信できるのは読んでくださっているみなさまのおかげです。いつもありがとうございます。

 

selenium confが迫っているのに目が冴えてしまってこんなものを書いていますが、果して起きれるのでしょうか。

(追記 : 起きれました。)

 

さて、今回は探索的テストについて書いてみます。

Webサービスを扱う会社の経験しかないため、現場によってここで述べる内容に合う合わない等あるかもしれませんがご容赦下さい。

 

毎度の如く書いておりますが、

あくまで個人的な見解であり、独自の解釈や考えを述べておりますので、鵜呑みにせず 調べたり試したり自身の経験・考えと比較して見てください。

興味を持っていただき、テストを学ぶきっかけとなれれば幸いです。

 

 

 

探索的テストとは

 探索的テストとはテストのスタイルのひとつで、

テストケースを作らず、状況に応じて学習を繰り返し 頭の中でテスト設計をしながらテストを行います。(簡単なドキュメントは用意したりします。)

テストケースを起こさずに実施できるため、効率的にテストを行うことが可能です。

しかし、テストの再現性が低いことや、担当者によってテストの結果が変わること、マネジメントやスケジューリングが難しいといった特徴も挙げられます。

 

ここでの説明はこれくらいにしておきますが、

興味のある方、詳しく知りたい方のために 参考資料を置いておきます。

 

そして、ここだけは誤解せずに しっかりと使い分けてほしいのですが、

探索的テストはモンキーテストやアドホックテストではありません

現場からは以上です。

 

どんな運用をしている?

「探索的テストはアジャイルに向いている」といった説明を目にします。

確かに効率的なテストでスピード感があり、その意見は正しいと感じています。

しかし、だからといってそれだけではダメで 個人的には他の基本的なテストプロセスに加えて実施するべきだと思っています。

 探索的テストは網羅性には乏しいですし、

先ほど挙げた『探索的テストってなんですか? アジャイル時代のソフトウェアテスト』にも注意点として "探索的テストに100%頼らない" と述べられています。

 

 

どんな準備をしている?

自分が探索的テストを実施するときに準備するもの、あった方が良いと思うものは以下の通りです。

ディスプレイ

書くまでもないかもしれませんが、画面は多い方が良いです。

すぐにログを残せるようにしたり、仕様書を横で開いておいたりします。

 

バグの情報

ここまでのテストプロセスで見つかったバグのリストを用意して、事前に概要だけでもいいのですべて見ておきます。

件数が多い場合はざっと どの機能や画面にバグが多いかあたりをつけ、頭の片隅に入れておきます。

件数が少ない場合は拾える情報は可能な限り拾っておきます。

ここで軽くでも見ておくと、後々 テストをしているときに違和感に反応しやすくなると思います。

 

仕様書・テストオラク

自分は用意したサブのディスプレイに表示させておきます。

手間をかけずに正しいかどうか比較できるもの(現行版の画面など)を用意しています。

違和感を感じたところや 仕様にそぐわない箇所、画面からはわかりにくい処理の多い箇所や複雑な箇所を確認しながらテストしています。

 

メモ

紙のメモをそばに置いています。

どこを見ようと思ったか、どんな違和感を感じたかのログ用です。

ログを残す方法として紙にこだわる必要はないので、残しやすい形で残せばよいと思います。

自分はちょっとしたリフレッシュがてらアナログを挟んでいます。

 

イヤホン

思考に集中するために、外部の音を遮断します。

音があると集中できない方はノイズキャンセリング機能だけを使うと良いと思います。自分はがっつり音楽をかけて精神を隔離しています。

また、イヤホンを着けていれば「あ、なんか話しかけるの忍びねぇな...」といった雰囲気が生まれるので急ぎの用事でない場合 話しかけられるリスクを軽減することができます。

 他にも思考を妨げる要因に通知が考えられますので、ブラウザのタブからslackを排除し、カレンダーには【BLOCK】とスケジュールを入れてしまいましょう

 

お菓子・飲み物

テスト中、テスト後、疲れます

また、「喉が渇いたな」という雑念で思考が止まることを避けるためにも、

そばに水分や糖分を確保しておきます。

 

 

どんな流れ?

探索的テストをどんな流れで行っているかを説明します。

自分の場合は、

事前にスケジュールに何か追加されないようにタスクをセットし、

調べたバグのリストとオラクルになる資料や情報を別のディスプレイに表示

どんな箇所を見るか・どんな操作がしたいか 事前にまとめたメモをそばに置き、

イヤホンを装着、ガンガンに音楽を掛けたらようやく準備完了です。

 

探索的テストを開始してからは、

メモを基に試す内容をざっくりと決定し、操作をしていきます。

UIに違和感を感じたら大体はそこにバグが潜んでいるので、徹底的に叩きます。

ラクルと比較し、なにに違和感を感じたのか正体を探ります。

勘違いであってもメモに残し、その違和感は思い出せる状態にしておきます。(変だと感じた場所には仕様漏れがあったりするので)

 

基本的にはこの作業の繰り返しになるのですが、

「あ、今なんも考えてなかったな」とか「あれ、さっきと同じことやってるな」と思ったら一度中断しています。時間的・精神的・肉体的な限界を迎えています。

長時間ひたすらだらだらと続けていても効率的とは言えず むしろコスパが悪いので、

短期間しか持たなくても、その短期間を集中して成果を出せばいいんです。

 

休憩ついでに実施した内容や見つけたものをログにまとめ、頭を整理するとより良いと思います。

探索的テストは学習をしながら進めていくテストなので、このサイクルが大事だと思っています。

(ノリノリの状態が続いていればそのまま続けても良いと思いますが、キリがないので時間で終了のタイミングを決めておくと良いです。)

 

 

具体的にはどんなことしてる?

ログ

見つけたバグの内容は紙に書いています。

特別に理由があるわけではありません。

デスクにガラスペンだとか良いペンを置いているのですが、使うとモチベーション上がるからです。(紙のほうが関係性など書きやすいということもありますが)

  

XSSSQLインジェクション、ファイルアップロードなどを簡単に

セキュリティを考慮して実装していたり、ツールなどを使って脆弱性診断を行ったりすることが一般的だと思いますが、万が一があったら嫌なので確認しています。

画像ファイルに偽装してスクリプトファイルをアップしようとしてみたりすると結構楽しいです。

 

異常値

変な文字列を入力できないかをよく見てます。

仕様書に書いてある内容はテストケースでカバーしているのですが、仕様書に書かれていないけれど必要なバリデーションがあるといったことは良くあることだと思います。

 

他にもフロントで制御するバリデーションだけでは怖いので、異常値を無理矢理POSTしたりもします。

漏れを見つけられる可能性があるほかにも、フロント側とサーバー側でバリデーションが違ったりすることもあるので、そのへんも見ちゃいます。

主に、どんな実装をしてるのか、自分ならどの辺の実装が面倒だと感じるかを考え、ミスをしそうな機能を狙います。

 

一度の文字列に大量の変な文字混ぜ過ぎると結果から分析しにくかったりもしますが、ひとつひとつやっても効率悪いですし 網羅的な内容はテストケースで見れば良いと思うので異常がないかだけ確認できればいいと思います。

 

ただ、どの文字列がダメだったか程度ならともかく、

一斉に送ってしまってどのフォームでエラー吐いたのかわからないくらいのやり過ぎは良くないです。基本は忘れずに。

 

連打

連続でPOSTリクエストが飛ぶと大体ろくなことになりません

しっかりと制御されていることを確認しています。

裏でたくさん処理してそうなところも連打して意地悪したりもしますが、環境によってはほどほどにしましょう。

JSで実装されている部分なんかも連打のねらい目です。

 

矛盾する組み合わせとか

結構 意地悪です。

工数や優先度から多くの場合に実装されないであろう選択の組み合わせの制御部分を見ています。

これは正直「仕様です」の返事はわかっている上での行動で、

そうなることはわかっていて、それでも「この選択肢が選べちゃうのってあまり好ましくないのでは?」「ユーザーにとって親切ではないのでは?」と今後の検討リストに追加されたらいいなぁと想いを込めてやっています。

もちろん、自分はユーザビリティの専門家でも企画のプロフェッショナルでもありません。

フィードバックを送れる位置にいることを利用して個人の意見をぶつけているだけなので、ほどほどにしておきましょう。

 

paramをいじる

URLにparamが見えたら触ってみます。

検索用のクエリが入ることが多いと思いますが、変な文字入れるとなんらかの処理を失敗させたり 攻撃できたりすることもあるので、念入りに確かめています。 

 

その他

マインド

ゲームをしている感覚でテストしています。

 

ただ、ゲームにも色んなプレイスタイルがあると思います。

自分は開発者の作品への愛やこだわりを感じながら隅々まで見たいタイプです。

具体的には「村人とは台詞がループするまで会話する」「ループしても会話するキャラや内容によっては3回くらい粘る」「装備してって言われた装備をすぐ外す」「使ってって言われたアイテムをくれた人に使ってあげる」「装備全部外してパラメータ上 全裸の状態にしてみる」「ステージの最初は必ず後ろから見る」などなど

 

「こんなことしてもなにもないだろうなぁー...お? おおおぉぉっ!!」ってなる楽しみ方です。

 

世界観を重視してるゲームに対してよくやっています。

ゲーム性を重視してるゲームに対しては、ルールをひとつ無視できたらどうなるのか考えて「バランスの取り方うまいなぁ」と考え込まれた仕様を感じるのが好きです。

 

といった具合に、開発者がどんなところまで考慮しているかを意識するようにしています。

プロダクトに込めた想いを感じ取りましょう。

 

この手の作りこみをゲームで体験したい方は、

  • undertale, deltarune
  • Doki Doki Literature Club!
  • OCTOPATH TRAVELER
  • シルフェイド幻想譚
  • The Stanley Parable

あたりをオススメします。

※かなり個人的な趣味嗜好が入っています

 

ログどこまで書くのか問題

自分の考えとしては、どんな意図でどんなテストをしたのか説明できなきゃいけないと思っています。

これは探索的テストに限った話でなく、すべてのテストにおいてです。

 

説明ができないなら、それは探索的テストの頭の中でテスト設計をしながら」に反しています。

説明のできないテストをしてもほとんど意味はないと思いますし、その場で偶然バグが見つかっても 今後も同じようなバグを見つけられる可能性は低いと思います。

個人の裁量が大きいテストなので、誰にでもわかるように書く必要まではないと思いますが、自分で振り返れる程度のログは残すべきだと思います。

  

 

 

 

 おしまいおしまい

と、自分が思っている・意識している探索的テストについてを述べてみました。

長々と書いてしましましたが、ここまでお読みいただきありがとうございました。

みなさんの何かしらのきっかけになれれば幸いです。

 

気になる部分、異なるご意見があればコメントなりtwitterなりで反応を頂ければと思います。

それではselenium confに備えて寝る必要があるので、このあたりで失礼いたします。

 

 

クラシフィケーションツリーを自分がどう書いているのか手順を追って説明します

 

どうも、あと1週間ちょっとで新卒一年目の肩書きを剥奪されてしまうhalspringです。

好き勝手に無責任なことを言える免罪符ともお別れです。切ない。

 

 

さて、執筆現時点で3月27日、28日にJaSST’19 Tokyoがすぐ目の前に迫っています。初のJaSST参加でドキドキワクワク過ぎてテカテカしてます。

 

こんなニッチな記事を読んでいる方達であれば申し込んでいる方も多いかと思います。 

そして 申し込んだ方なら同じことを感じたと思います。

はい、そうですね、申し込みのパターンでクラシフィケーションツリーを書きたくなりましたね

 

 

では早速ツリーを書いていきましょう。

どう考えてツリーを書いているのか なるべく思考の痕跡を残そうと思います。(途中で疲れていると思いますが どうか温かい目で...)

今回はツリーを作成するまでを中心に綴りますので テストケースの作り方については以前の記事や、 その記事で引用している井芹さんのスライドをご参照ください。

 

書いたことのない方は はじめに仕様だけ洗い出したセクションがありますので、是非一度ご自身でツリーを書いてみて比較して頂けると より一層お楽しみいただけるかもしれません。おそらくmaybe多分きっとあるいは。

 

 

あらかじめお断りしておきますが、

クラシフィケーションツリー法に関して論文を読んだり どこかで基礎からしっかりと学んだわけではないので、書き方や考え方に誤り(よく言えば我流)が含まれている恐れがあります。

この記事を鵜呑みにしてスタンダードだとは思わず、あくまで取っ掛かりとして頂ければ幸いです。

また、クラシフィケーションとたくさん書いてあると可読性が低下するかなと思ったので、因子という言葉とクラシフィケーションが混在していますが 目をつぶっていただければと思います。

 

最後に、明らかに誤っているところがあればご指摘いただければと思います。

(「大丈夫、あってるよ!」とか「参考になった!」などと言われると喜び悶えますのでそちらもよろしくどうぞ)

 

 

 

 

仕様把握

 

JaSST Tokyoの申し込みページから仕様を吸い上げます。

 

  • チケットには参加券、チュートリアル券、情報交換会の券がある
  • 参加券は27日、28日、2日券がある
  • いずれの参加券も事前申し込みすることで安くなる
  • 2日券の事前申し込みにはさらに早割が存在する
  • チュートリアル、情報交換会のみのチケット購入はできない
  • チュートリアルは27日の前半にセッションでは1,2、後半にセッション3,4があり、28日にセッション5がある
  • チュートリアルのセッションは時間帯の被るものは同時に申し込みできない
  • チュートリアル券も事前申し込みで安くなる
  • ただし、チュートリアルのセッション5の料金は変わらない
  • 情報交換会は事前申し込みでも当日券でも料金は変わらない

 

こんな感じですかね。

学生の招待制度については申し込みのフローが異なるため、ここでは考えないものとします。

 

 

それでは書いていきます。

 

 

 クラシフィケーションツリーを書いてみる

ドメイン

 

書き方に王道や正解があるのかわかりませんが、自分は根っこから書いていきます。

 

今回考えるのはJaSSTの申し込みなので、そのまま書きます。

 前回の記事でも書きましたが、せっかくsurface proとペンを買ったので活用しないといけない衝動に駆られているため手書きです。

f:id:halspring:20190325232554j:plain

 

 

ドメインクラシフィケーション

 

申し込めるものは、

になります。

 

そして、参加券こそ買う必要があるものの、チュートリアル券と情報交換会に関しては任意の購入になりますので、直交しています。

 

つまり、ドメインからクラシフィケーションが3つ伸ばせます

 

f:id:halspring:20190325232721j:plain

 

 

参加券

 

では、購入が必須 かつ 一番複雑な参加券から考えていきます。

 

参加券には1日券2日券があります。

ですので、参加券のクラシフィケーションから「1日券」「2日券」のクラスを伸ばします。

 

f:id:halspring:20190325232750j:plain

そして、1日券、2日券のどちらも、より詳細な購入方法の選択があります。

 

  • 27日の参加で事前購入
  • 27日の参加で当日券
  • 28日の参加で事前購入
  • 28日の参加で当日券
  • 27日、28日の2日参加で早割
  • 27日、28日の2日参加で事前購入
  • 27日、28日の2日参加で当日券

 

ここで、各参加券に共通する「購入のタイミング」という因子候補が出現しました。

枝を伸ばす前にこの「購入のタイミング」を考えてます。

 

 

まず、この「購入のタイミング」という因子がどれほど他に影響を与えるのか。

出現したタイミングだけを見ても、「参加券」の末端に位置するであろう 上記の7つのクラス候補を下記の4つに減らすことができそうです。

  • 27日
  • 28日
  • 2日早割 有
  • 2日早割 無

 

 

 

「購入のタイミング」自体は { 事前, 当日}  の2クラスで済みそうなので、合計して見ても末端となるであろうクラスを1つ削減できるため、採用しても良い感じがします。

 

さて、「購入のタイミング」は他にも影響を与えるでしょうか。

仕様を見返すと、

とありますので、この因子を足すことでチュートリアル券のクラスも減らすことができそうですね。

そして、情報交換会には影響を与えないのでドメインから伸ばすクラシフィケーションとして採用して良いと言えます。

悪い影響を与えないことも採用するかどうかの判断に使います

(この辺はうまく言語化できないのですが、ツリーを複雑にするくらいなら少しの冗長は妥協したほうが見やすくなると思ってます。) 

 

f:id:halspring:20190325232826j:plain

 

 

チュートリアル

 

次に「チュートリアル」です。

チュートリアルは1~5まで存在し そのうち4つは27日に開催され、さらに前半・後半でわかれています。

(スペースが足らなそうなのでずらします。これがデジタルのいいところですね。)

 

f:id:halspring:20190325232915j:plain

 

ここにチュートリアル5を追加したいです。

1~4と5を隔てているのは日付です。27日・28日で価格も変わりますので、もう一段大きいところに「日付」のクラシフィケーションを作るとちょうどよさそうです。

 

 

f:id:halspring:20190325232937j:plain

 

情報交換会

 

あとは「情報交換会」に参加するかしないかのクラスを作ればツリーの出来上がりです。

情報交換会は事前購入でも当日でも料金が変わらないので、そういった情報は頭の片隅に置いておくか、近くにメモしておくと良いです。

 

 

完成!!

 

完成したクラシフィケーションツリーがこちらです。

 

f:id:halspring:20190325232951j:plain

 

 

いいですね、かわいいですね。

 

あとはこのツリーからテストケースを作成していきます。

このツリーで料金を大きく変える因子は「購入日」で、「購入日」の影響を受ける因子は「参加券」と「チュートリアル」です。

また、「参加券」と「チュートリアル」には禁則が多く存在するため、この辺りからテストケースを作っていき 残りの因子は網羅基準を満たすように配置してください。

 

網羅基準を満たした後は「テストの手間が増えるので "なし" を選択する」「処理が複雑で心配なので入念に」など、定めたアプローチや設計者・ステークホルダーの考えで選択してください。

 

 

いかがでしょうか、これで少しでもクラシフィケーションツリーが書けそうな気がして頂ければ幸いです。

クラシフィケーションツリーを書くのは楽しいですが、どんな場面にでも適応できるわけではないので、頭の片隅でその存在を覚えておいて ここぞのタイミングで思い出してあげてください。

きっとツリーも喜びます。

 

 

それでは、よい Classification Tree Method Life を。

 

 

なぜ自分が開発したソフトウェアのテストをするのは面倒なのか?

どうも、そろそろ1年目を名乗れなくなりますhalspringです。

要件定義、仕様策定、設計から開発まで関わったシステム」に対して「自分でテストを設計して実施する」機会があったので、そこで感じたことや考えたことを踏まえて いつものようなテストのエモい話を語ります。

 

  

テストは面倒くさい?

 

この記事を読んでいる方の立場にもよって意見も別れると思います。

貴方は開発を行う立場でしょうか?

貴方はテスト設計を行う立場でしょうか?

それとも、貴方はその両方でしょうか?

 

恐らくですが、テスト設計をメインに行う立場の人ほど「テストは面倒」とは思わないのではないでしょうか。

 

そして、開発をメインに行う立場の人ほど「テストは面倒」なのではないでしょうか。

 

 

なぜ開発を行う立場に近づくとテストが面倒に感じてしまうのか、今回はそれを考えてみました。

 

 

 

開発するとき無意識にしていること

 

開発経験のない方でもイメージできると思います。

開発者はエディタを開いてプルリクを出すまで何をしているでしょうか?

(※ 完全に私個人の見解です )

 

 

仕様を確認して、

ロジックを考えて、

コードを書いて、

コーディング規約の確認もしつつ、

動作確認をして、

問題なさそうなのでgit commitして、

プルリクを送る

 

 

これだけでしょうか?

いいえ、違います。

 

 

 

書いたコードが1発で正しく動作するなんてことは、よほど仕様がシンプルでない限り稀です。

大抵はうまくいかず、修正をしながらコードを書き進めていきます

 

 

コーディングして、

動作を確認、

不安なところは念入りに

あぁここclass名変えたんだった...、

コードを直して動作確認、

バリデーションは大丈夫だろうか

変なメールアドレス入力してみよう

よし大丈夫だ、次だ次...

 

 

概ね、こんな感じではないでしょうか?

 

 

ところでこれ、ちょっと何かに似ています。

テストに詳しい方ならお気付きかもしれません、そうです探索的テストです。

 

 

修正に当たる部分をissueやバグ票に置き換えるとあまり違いがないようにも思えます。

つまり開発者は、開発中に探索的テストに近いことをしているのです。

 

 

 

 

テストの順番

 

実施するテストには順番があります。

もちろん、プロジェクトやテスト戦略によって色々ですが、個人や会社である程度の型は経験則としても持っているかと思います。

 

 

例えば「パフォーマンステストをしてからシステムテストをするつもりです」と言われたら、耳を疑いますよね?

「探索的テストをがっつり実施してからシステムテストの設計をしてください」と言われても、気乗りしませんよね?

(スモークテスト的に行うことはありますが) 

 

テストにはそれぞれ目的があり、適したタイミングで適した不具合を見つけることが大切です。

 

 

探索的テスト

ちなみに、探索的テストはいつ行うのが良いのでしょうか。

 

もちろん絶対的な正解はありませんが、

一般に、様々なテストを行った後に補完的に行われることが多いと思います。

 

JSTQB ALTAのシラバスにも、次のように記載があります。

優れた探索的テストは、しっかりと計画されており、相互作用的で創造的である。探索的テストは、テスト対象の システムに関するドキュメントをほとんど必要としないため、ドキュメントが存在しないか、他のテスト技法では適 切でない場合に使用することが多い。また、多くの場合、他のテストを補完したり、追加のテストケースを開発す るための基準を提供したりするために使用する。

 - 2012 年度版 Advanced Level シラバス日本語版 - テストアナリスト

 

 

先程も例として書きましたが、仕事でテストをしている方であれば、

「探索的テストをがっつり実施してからシステムテストの設計をしてください」と言われるとなんとなく二度手間感があったりして、面倒臭さが出てくると思います。

( 完全に私自身の見解です )

 

 

 ところでこの状況、なにかに似てませんか?

 

 

そうです、先程の開発しているときの話をしました。その開発の後にテストが待っています

開発者はコーディングする中で探索的テストのようなテストケースのないテストを行っているため、その後にテスト設計を行うことが億劫に感じるのです。

( ※ 完全に私個人の見解です。 )

 

 

  

では、なぜ探索的テストの後のテスト設計は億劫なのでしょうか。

 

 

 

テスト設計時に無意識にしていること

開発するときにどう考えているかを勝手に考えてみましたが、

次はテスト設計するときにどう考えているか考えてみます。

 くどいようですが完全に私個人の見解です。

 

 

弊チームのボスからとある話を聞き、考えてみたところ、

自分はテスト設計をするときに、ソフトウェアがどう実装されているかを考えていました。

 

 機能の追加や改修があれば、どんなロジックを追加する必要があって、どんなところが複雑になるかを考え、「こんな実装をしているだろう」のイメージを作っていました。

 

 

いくつかの「こうすれば実装できる」のイメージから、

・データのやり取りがありそうだから、ここをしっかり見ておきたい

・自分だったらこのあたりでミスしそう

といった感じにリスクや観点を考えています。

 

その後、改めて仕様書を見てリスクや観点を洗い出し、先程のリスクや観点を比較して漏れがないか考えます。

 

この記事を読んでいる皆様と自分で どんな流れでテスト設計をしているか異なるとは思いますが、共通して仕様書からいろいろと要素を拾い上げることはしているはずです。

 

 

ところで開発者は...

さて、時は実装前まで戻ります。

この記事のはじめにも書きました、コードを書く前に仕様を確認していますよね。

 

そうです、実装するまでに仕様書を読み込む必要があるわけです。

また、どう実装するか、そのロジックに至るまでも頭に叩き込んであるわけですね。

 

その後にもう一度 どう実装するか考えたり 仕様書を読み込んだりしたくないわけですよ!

 一度頭に入った情報は材料にもなりますがノイズにもなり得ます。(私個人としてはこのノイズがテスト設計のときに思考の妨げになっていました。)

 

 

探索的テスト後のテスト設計の二度手間感も同様でここに起因していると思います。

二度手間「感」ではなく、本当に二度手間を掛けているわけです。

 

 

 どうすれば面倒にならないのか

 本当はここで画期的な提案ができればよいのですが、残念ながらここはまだ模索中です。

 

 現状思いつくのはテスト駆動開発です。

 ユニットテストを設計・実装しながら開発を進めることで、探索的テストライクな部分がユニットテストに置換されます。

 

ユニットテストも結局仕様を把握する必要はありますが、テストの順番として違和感が軽減されます。

単体テスト結合テストを実施してからシステムテストを行うのは至って自然です。

 

もちろん個人・チームでのやりやすいように 納得感を持って進めていただければ良いとは思いますし、面倒に感じてしまう理由も人それぞれだと思います。

テストが面倒に感じる方は是非一度こういった観点からアプローチをかけ、少しでもテストを好きになって頂けたらと思います。

 

学んでみると テストは世間で思われているほど悪いやつじゃない と思えるかもしれません。

クラシフィケーションツリー法の自由さを活用する

アドベントカレンダー

本記事はソフトウェアテストの小ネタ Advent Calendar 2018 24日目の記事になります。

qiita.com

前日は とろさんの記事でした。沼ダイブ、自分ももっと頑張りたいです。

testertoro.hatenablog.com

ご挨拶

ご無沙汰しております。 クリスマス前日、皆様はいかがお過ごしでしょうか?

どうも、こたつで猫を抱えながら細々と記事を書いているhalspring(@halspring_qa)です。 昨日中古で買ったモンハンワールドに時間を溶かされています。

12月はWebQAAI4SEwacateと盛り沢山でした。 去年のこの時期、暗い顔しながら卒論を書いていたとは思えません、今はとても楽しいです。

語りたいこと

今回、クラシフィケーションツリー法について書いてみたいと思います。

はじめにお断りとして、高々テスト歴半年程度で書いておりますので、技法や用語、考え方等に誤りがある可能性がございます。 どうか温かい目で見て頂ければと思います。ご指摘等もお待ちしております。

クラシフィケーションツリー法に関して前知識を準備しておきたい方は井芹さんのこちらの資料をどうぞ。

www.slideshare.net


それでは、クリスマスツリーの代わりにクラシフィケーションツリーを眺めながら一緒に愉快なクリスマスイブを過ごしましょう。

クラシフィケーションツリー法

クラシフィケーションツリー法はテスト対象が持つ要素を木構造モデリングするテスト設計技法です。 今回はクラシフィケーションツリー法を用いてテストケースを作っていく際に、クラシフィケーションツリー法の利点をどう活かすかを書いていきます。

文章のいいところは、何度クラシフィケーションツリーと言っても噛むことがないところですね。つい必要以上に何度でも繰り返しちゃいます。

直交表との違い

テストケースを作成するフェーズになると、直交表と同じでは?と感じることがあるかと思います。 直交表では、主に2因子間の水準組み合わせを網羅するように使われています。ちなみに3因子間の網羅でも使えるそうです。

さて、この直交表のメリットは、組み合わせテストにおけるテストケース数の削減各水準の組み合わせが均一に表れるところにあります。

この記事で語りたいクラシフィケーションツリー法のメリットは、後者の各水準の組み合わせ均一に表れるという縛りがないことにあります。 (wacate 2018冬にて中村さんが口頭でおっしゃっていて「ハッ!」となりました。ありがとうございます。解釈が間違っていたら申し訳ないです...)

クラシフィケーションツリー法のメリット

それでは、「各水準の組み合わせ均一に表れるという縛りがない」とはどういうことか説明したいと思います。


まず前提として、組み合わせを考える際にすべての水準の重要度や使用頻度が等しいことは稀であると思っています。(この前提が共感できなければ、おそらくこの記事で伝えたい内容は入ってこないかと思います...)
相互に作用する組み合わせと、仕様上独立している組み合わせ同様の比重でテストするだけで十分か?という観点で実施をします。 (もちろん業務であれば、要件としてどれくらい網羅するかの基準はあるかと思いますので、状況に応じて考えて頂ければと思います。)


実際に例を見ながら説明していきたいと思います。

テストケース作成の例

問題

テスト界隈ではそこそこメジャーらしい"ラーメン"をテーマに問題を作ります。

「あなたはラーメン屋めぐりにハマっています。あなたは検証が大好きなので、訪れるラーメン屋を見切るまで通い続けます。 しかし、次に訪れるラーメン屋は麺の太さや硬さ、スープの種類を好きに選べるタイプのお店です。 しかし、早く次のラーメン屋検証にも進みたいため、なるべく早く見切る必要があります。毎食食べるとして、何日で見切ったと言えるでしょうか?」


といった問題です。 ラーメン屋の詳細は以下の通りとします。
スープは味噌・醤油・塩の3種類
麺の種類は細麺・太麺・ちぢれ麺の3種類で、 バリカタ・かため・ふつう・やわらかめの4種類から硬さを選べます。
トッピングは著者の独断と偏見および簡略化のため海苔のみとします。

ツリーを書く

問題を元にツリーを書きだすとこんな感じになります。(気持ち程度に名称を加えてます。Surface買ったのでペンを使ってみたかっただけです。) f:id:halspring:20181225213301j:plain

ツリーの形が異なる方もいるかもしれませんが、今回は説明のためこのツリーを使います。 因子と水準が洗い出せたら格子を書きます。 f:id:halspring:20181224163803j:plain

テストケースの作り方

ツリーが書けたら基準を決めます。 ここでクラシフィケーションツリー法の本領発揮です
まずこれらの水準で、相互に作用するものがあるかどうか考えてみます。

例えば、「海苔の有無」と「麺の硬さ」はそれぞれに影響があるでしょうか? 自分はないと思います。 よって「この2つはペアワイズにする必要はない」と判断します。
では、相互に作用するものはなにか。そうです、麺の「種類」と「硬さ」です。

「相互に作用し、かつ重要度が高いためこの部分はしっかり網羅したい」のでペアワイズで考えます。 f:id:halspring:20181224165039j:plain

こんな感じです。
では、ここに先ほど触れた海苔を考えてみます。 海苔の有無は麺に影響を与えないものの、一度は食べてみないと見切ったとは言えませんね。 よって、1ワイズで網羅します。

f:id:halspring:20181224165902j:plain

海苔に関する網羅率はひとまずこれで十分ですね。

最後にスープや残りの海苔の有無について考えていきます。
クラシフィケーションツリー法では人の意思を介入させることができます。 水準が等しく表れる必要はありません。

よって一度の検証で余計な要素はなるべく減らしたいので、海苔はできるだけ「無」にしたいと考えます。 しかし、「海苔はスープとの相性もあるのでは?」と考えたりします。

そう感じたのであれば、そこはペアワイズを考えればいいわけです。 既に12ケースが作成されるのは必然なので その中で網羅し、必要な分書けたら残りを「無」にします。

f:id:halspring:20181224170949j:plain

このような具合に、テスト対象の特徴や要件に合わせて網羅基準や水準の選定基準を考えます。

  • この店の主力商品はなにか?
  • 自分が絶対に 食べる/食べない 組み合わせはあるか?
  • もう1回 海苔を入れて試してみたくなった

などなど。 例えば今回は自分のための検証なので「ちぢれ麺は味噌以外で食べることはほとんどない」といった潜在的な情報があったりします。
このように「ユーザーはほとんどが20代~40代なので、60代以降よりも重点的に見る」や「金額表示に関わる部分なので重視する」といった基準を自分達で考えることができます。

この潜在的な情報はプロダクトによって様々で、

  • 使用頻度にばらつきがあるところ
  • 開発が苦戦していたところ
  • ロジックが複雑なところ
  • 法的に問題を起こせないところ
  • 会社として守らなければいけないところ

など様々な判断軸があると思いますので、自分たちのプロダクトに合わせてテストケースを作成して下さい。


ちなみに「スープと麺の組み合わせを網羅しないとは何事だ!!」という意見は、もちろん誤りではありません。 それもまた潜在的な要件であり、今回 自分が必要としていた要件ではなかっただけのことです。

必要ならその条件を足せばいいわけですし、不要なら考えなくて良い、自由に基準を決められる利点を最大限活用してみてください。

終わりに

改めて用語や考え方に誤りや及ばない点があるかと思いますが、大目に見てくだされば幸いです。

クラシフィケーションツリー法について書かれた情報が少ないので、もう少し身近に感じてもらえればと思います。

それでは皆さん、良いクラシフィケーションツリーライフをお過ごしください。

メリークラシフィクリスマス

「QAとは」の記事に対するコメントのやり取り

例の記事

これに対してリリカルさん(@mhlyc)から頂いたコメントとやりとりをまとめたものになります。 え?記事数稼ぎ?
自分の中では語りきれなかったり、考えが及んでいなかった部分もあり、 そこを深掘りしていただけたり、伝わりにくい部分の補足が出来たような気がするのでこのようにまとめさせていただきました。


ご 本人から許可も頂いております。ありがとうございます!

結論だけ読ませろ

結論と言うようなものではありませんが、やり取りの中で私側の主張をまとめてくださいました。 正直、ここだけ読めば私の意見がどんなものかは伝わるのではないかと思います。

やりとりを順に

新人なりに ”QAとはなにか" の問いに対する自分の考えを語ってみた

目次

前置き

筆者について

興味を持っていただいてありがとうございます、halspringと名乗っている者です。

現在、web系企業に今年4月入社、配属からようやく4カ月のひよっこQAエンジニアです。

あくまで個人的な見解、意見なので賛同・反論・助言することがあれば 是非コメント等お願い致します。


現場の環境や状況が不明瞭な状態で語るよりも、どんな環境で働いてどんな考えを持ったか、どのような立場の意見かが はっきりしていた方が良いかと思うため、

少々説明を入れます。


さっさと次!という方は読み飛ばして本題だけお読み頂ければ幸いです。

 

開発文化

弊社では開発チームが企画からテストまで行います。

各チームにQAのような立場の人がいるわけではなく、別組織に近い形で必要に応じて開発チームをサポートしています。

  もっとも近くにいる独立組織のような立ち位置だと思います。  

QAの関わり方

弊社では、ヘルプを求めてきたチームもしくはリスクの高いPJに関与します。

(その他、自動テストでデグレチェックもしていますが割愛)


関わり方も様々で、

  • 開発チームへのレクチャー

  • テスト計画書の作成(ヒアリングから)

  • 開発側が作成したテスト計画書やテスト仕様書のレビュー

  • テスト仕様書作成のために観点の洗い出し

  • 開発側が洗い出した観点のレビュー

  • テストケースの作成

  • テストケースのレビュー

  • テスト実施状況の可視化

  • バグ分析

  • メトリクスの収集・分析

  • スケジュールの設定・見直し

  • PJ進行方針の提案

  • ツールの導入

  • 探索的テスト実施

等々、いくつもパターンがあります。 (むしろ パターンがないのかもしれません。)

 

ここまでツラツラと書いておいてなんですが、

予め理解して頂きたいことは「QA ≠ テストする人」の環境で育っており、その認識で今QAをしている、ということです。

 

新人なりに考えた”品質とは”

今の業務に就き、"品質とはなにか"を考えるようになりました。

この界隈では非常にあるあるな問いですが、明確なひとつの答えをもつものではないので意見が割れるところだと思います。

 

ですので、ここで述べる意見もあくまで一個人の考えです。もちろん、人間ですから考えが変わることもありますし、考えをぶつけ合ってよりよいものにしていきたいものです。


 

少し脱線しました、"品質とは"に戻ります。

私なりの"品質"の考え方は「ユーザーが本当に求めているもの(価値)を提供できているか」という軸で成り立っています。

つまり、「Aを良くすれば品質がよくなる」だとか「Bを早くすれば~」とか「Cの故障率を~」や「Dのバグを~」のようなものではないと考えています。

 

例えばWebであれば表示が早くなれば品質が上がったと言っても もちろん間違いではありません。

しかし、「ただ早くすればいい」ではないということです。


よって、よく言われる「テストをすれば品質があがる」「バグがなければ品質が高い」というのは"品質"の本質ではないというのが私なりのスタンスになります。

 

テストは何のために行うのか

テストで品質はよくなる?

ですが上記の通り、普段 私は業務でテストに関することをしている割合が多いです。

「言ってることとやっていることが違うじゃないか!」というのは早合点で、テストを行うことで品質を高めることはできます。

ただ、テストだけが全てではないですし、テストをすれば絶対に品質がよくなるわけではないと考えています。 (まさにバグゼロの落とし穴ですね)  

品質を高めるには

テストで品質を高めるためには、「テストをする目的や意図」を理解・意識しながら行う必要があると思います。

「現場で先輩がこんな感じにやればいいって言ってた」「過去のテストケースみたらこんなこと書いてた」では

そのテストでどんな品質が保証されたのかわかりません

テストをなぜ実施するのか、それは、

ある特定の要素に対して、それを保証するためです。

 

ここで言う特定の要素は、機能・速度・正確さ・効率・保守性・信頼性・安全性やそれ以外にも多岐に渡ります。

いずれにせよ、何かを保証したり確かめるためのテスト、すなわち、保証したいものがあってこそのテストなのです。


  テストの意図や目的を理解・意識してこそ、正しく設計・実施・保証ができるというわけです。

   

ではQAとは

「今度はテストが大事って話になってきてない?」はい、そうかもしれません。

テストが大事なのはもちろん認識として持っています。


ではQAはテストをしっかりと目的を意識して設計・実施すればよいのか?

それは少し違う気がしています。


テストに関することだけを行うのであれば、それはQAではなくテスターやテストエンジニアでいいのではないでしょうか。

QAは品質保証を行う業務です。ですので、品質を高めるためにできることをやるのが仕事だと思います。

組織の文化や体制によってできることは異なります。

しかし、そのできること郡の中からいかに品質を高めるために動くことができるか、がQAとしての腕の見せどころではないでしょうか。


テストを担うことしかできないのならテストで品質向上に努めるように、

一歩離れた位置にいるのなら客観的なレビューやプロセス改善、他にも開発が開発に専念するためにできることがあるはずで、

それを行うのがQAだと思っています。

明確に役割を定義せず、あえて曖昧さを持たせることが重要な気がしています。

どうせ正解はないので、自分の思うQAとは何か、を自分の中に持っていればいいと思います。

十人十色のQAがあるべきです。

理想的なQA組織って?

QAの在り方

QAは特に役員のような強い権限を持っているわけではなく(持っているところもあるかもしれませんが)、

企画段階から方向性に口を出せるような立場ではないことが多いと思っています。

(これは業界に詳しくないので確かではありませんが)

 

また、仮にそのような"強いQA組織"があったとしても、

「そんな初期段階から文句を言われるくらいなら、最初からあんたらが作ればいいじゃん」といった不満が出ないとも限りません。

(私が開発側なら少なくとも1回はそういった不満を漏らすでしょう)


QAはあくまでも開発チームに寄り添う存在であり最高の右腕で在ることが望ましいと私は思います。


開発が開発に専念するためにテスト設計をサポートしたり、バグの分析を行って作り込みを防止したり。

メンバーにテストや品質特性について質問されれば、真摯に向き合い全体の意識を高められるようレクチャーしたり。

プロジェクトがあらぬ方向を向き始めたら、一歩引いた冷静な立場から熱が冷めないようにそっと軌道を修正したり。


この絶妙さが難しく、しかしおもしろい。これこそがQAの在り方だと思います。

QAはいなくなるのが理想?

  最近まで、最終的にQAはいなくなるのが理想なのでは?と考えていました。

開発チームや組織全体の品質意識を高め、全員が他所でQAを名乗れるほどになれば"QA"という組織はその組織には不要ではないかと。

そして、それが理想なのではないか、と。


たしかに、これはQAの思い描く「夢」だと思います。

全員が自分達のような品質に対する思いを持って、正しくテストを理解して実施できる。

夢のような光景です。


ですが、品質に満場一致の充分はありませんし、十人十色の品質があるのではないでしょうか。

また、QAがいなければ誰が客観的な立場から品質を確かめることができるのでしょうか。


開発者は開発者であるが故に"純粋なユーザー"にはなれないのです。

だからこそ、一番近い他人のような一歩引いた立ち位置から開発側の思いを理解しつつ、

そのプロダクトやサービスを享受するユーザーのことも考えることができるQAという存在が必要だと思うようになりました。


「QAがいなくても全然やっていけるんじゃない?」と冗談交じりで言われるくらいの組織を作るのはもちろん間違いではなく、目指すべきだと思います。

しかし、本当にQAがいなくなってはいけない。

だからこそ、QAの思い描く「夢」なのだと私は思います。


全員が法律を学び正義の心を持って行動すれば警察は不要か、裁判官は不要か。

答えはNoで、第三者の視点は絶対になくてはなりません。

ちなみに「全くの第三者に裁いて貰えばいい」というのも誤りです。

その第三者の"本来別のことに使うはずだった時間を搾取"しています。

  そうなると、最初はうまく回っていても いつか必ず破綻すると思います。

開発チームは人の集まりであり、理想はあくまで理想のまま目指すものとして持っているのがちょうど良いのではないでしょうか。

 

おわりに

まとまっているような、まとまっていないような文章になってしまいました。

書き始めると熱くなってしまうので、話が脱線したり極端な方向に向いがちですね...


結果 第三者による客観的な助言が必要なのでQAはやっぱり必要ですね(強引なまとめ)


冗談はさておき、これは個人的な思いですので、読んでくださった皆様が異なる意見であっても否定するつもりはありません。

"十人十色の品質"があり、むしろそうであった方が健全な気がします。

拙い文章でしたが、ここまでお付き合い頂きありがとうございました。

少しでも皆様が改めて何かを考えるきっかきになったり、何かの後押しになれば幸いです。


皆様の感想やご意見等、お待ちしております。