はじめに

私「品質やテストに関する活動どう続けるか悩んでます！」
上司「advent calanderとか書いてみたら？」
私「(advent calenderって何や？)あ、枠ちょっとだけ空いてる」
というわけでだいたい５秒ぐらいで書くことが決まった記事です。

テストの技術というよりは私自身のテストのとらえ方や大事だと思ったマインド的なところを徒然と書きます。

Qiita初投稿なのでコメントいただけると嬉しいです！

目次

1. これまでの経験と自己紹介
2. テスト設計について
3. テスト実施について
4. テスト管理について
5. テスト全般について
6. おわりに

これまでの経験と自己紹介

初投稿なので自己紹介から入らせてください。

すみすと申します。

大学院修了後、第三者検証の某社に３年半勤務の後、決済系のシステム開発の会社に最近転職しました。
３年半はもちろんQAとして、そして今はPMOとして働いています。

好奇心旺盛なほうなので、前職では主にウェブ系の請負業務（数週間でテスト設計→実施とか）を主に行っていました。

入社半年したぐらいからテスト管理やテスト自動化に関りはじめ、
最後は自身もPLをしながらPL/設計者の育成や社内展開のための自動化マニュアルの作成等にも関わっていました。

JSTQBのFoundationLevelを取得しており、社内勉強会の講師も１年間務めました。
↑ALTAに更新予定

得意だと思っていること

・アドホックテストで意地悪な不具合を出すこと
・仕様に乗っていない箇所をテストケースに落とし込むこと
・不具合の起票

苦手だと思っていること

・長いプロジェクト
・テストケース通りにテストを実施すること
・人に任せること

テスト設計について

スタンダードとオリジナル

テスト設計はスタンダードとオリジナルだと思っています。
で、個人的には観点レベルでのオリジナルと詳細レベルでのスタンダードが重要かな、と考えています。
これはどう評価されるかという話になりますが、詳細レベルでは普通のものを作れるかどうかが評価される（逆にいうと絶対必要なものを漏らしてはいけない）、
観点レベルではもう少し上を目指せて、普通のものを作った上で「なるほど」と思わせるものを提示するぐらいの余裕があるものと思います。
私のレベルでの話かもしれませんが。
最初から詳細レベルでオリジナルを目指すのはあまり良くないかなあ、と。

仕様書を読まない

もちろん、最初は、の話です。
どうしても仕様書があると読んでしまって、その通りにテストケースを作りたくなるんですが、
大事なことは仕様書にはだいたい書いていません。
なので、最初は仕様書を読まずに妄想（こういうテスト必要だよな、こういう機能あるよなというのを考える）が必要だと思います。
大枠でとらえた後に詳細を書き出すのがあくまでテスト設計の作業だと思います。

設計する意味

私もですが、たぶん誰もがどこかで「設計しなくても仕様書とか見ながら実施したらよいんじゃない？」という思想に行き着くと思います。
私が感じる「設計する意味」は２点で、
１点目は何をテストしたかの証跡としての意味。
そして２点目のほうが大事だと思うのですが、実施が始まる前の時間の有効活用です。
実施できる状態からテスト設計するならそれは確かに優秀な人がアドホック込みで実施からしたほうがいい可能性もあると思いますが、
それまでの時間で設計しておくほうがはるかに良いでしょう。と思います。

テスト実施について

not テスター but ユーザー

テスターとして思想が固まってきちゃうと、特にユーザビリティの面が見えなくなってしまいます。
なので、実施の際は（もちろんテストケースを消化するという意味ではテスターとしてふるまわないといけないのですが）
いまのテスト対象が本当に良いかはユーザー目線で見ることを習慣としないといけないと思います。

気になったら止まる

テスト実施＝テストケース消化、ではありません。
（テスト設計の質云々は置いておいて）テストケースから外れたところに不具合はよく潜んでいます。
例えば「これ不具合ではないけどちょっと嫌だな」と思ったらちょっとその周辺で影響ありそうなところをたたいてみるとか、
自分の感覚を信じて立ち止まることもときには大切になります。

自分の担当範囲に収まらない

大きなプロジェクトだと、自分の担当機能が決まっていたりすると思います。
担当機能といった時点でわかると思うのですが、それでシステム全体にかかわる不具合は見つけられません。
でもそっちのほうが重要で、だいたいSTやUATの終盤になってとやかく言われることになります。
そのため、まずはテスト対象の全体を理解して、アンテナを常に張るようにしましょう。

テスト管理について

数字と感覚

テスト管理は基本的には数値で測るものです。
ただ、数値を正確にとるのは難しいため、感覚も必要です。
例えば、「少し触った結果この機能は不具合が多いと思うから先に実施しているので」進捗が遅れている」といった
数値と感覚を織り交ぜた報告は必ず必要になってきます。
数値だけを追っていたらみえない数値にやられます。

進捗より不具合

テストの目的は消化することではなく不具合を出して品質を担保することです。
進捗が良いからと安心するのではなく、進捗が良いのであれば幸運にも時間があるはずなので、
他に不具合の潜んでいる場所はないか、品質をあげるために他にできることはないか、
といったことを考えるのに時間を充てましょう。
バグゼロの落とし穴は自分から回避しにいくものです。

過ぎたるは及ばざるが如し

テストやりすぎ、進捗良すぎ、そんなプロジェクトには必ず落とし穴が待っています。
それは殺虫剤のパラドックス的な話だったり、テストは条件次第的な話だったりします。
何かが良すぎるときは何かリスクが潜んでないか考えましょう。

テスト全般について

テスト≠品質

テストは品質を向上させる手段の１つでしかなく、テストをすれば品質が良くなるわけではありません。
品質をあげるためのアプローチは様々なので、QA担当として生きるのであればそこも考えないといけません。
テストをしていると品質に貢献しているという実感は出てくると思いますが、そこに満足しないほうが良いと個人的には思います
※とはいえ、テストをしっかりやることは大切なので、そこを極めるキャリアもありだと思います。

最後の砦として

特に品質の悪いプロジェクトで、テストは最後の障害とみなされることが多くあります。
ただ、実際には最後の砦で、ここで止めないとどうやってもリリースは止まらない場所でもあります。
本当にリリースしてもよいのか、その条件は何なのか、そういうことが言えるのがテストです。

体のケア

テストをしていると体に来ることが多いです。
私は目と腰～背中が特にきつかったのですが、整体には通うようにしました。
職業柄体が固まりやすくなると思いますので、体のケアは欠かさないようにしましょう。

おわりに

精神論的な話が多くなってしまいましたが、いずれは技術の話もかけたらいいなと。

コメントいただけると嬉しいです。