皆さん始めまして
Twitterでは「蒼の検証者」っていう名前でソフトウェアテストのこととサッカーのことを呟いてます。
こういった記事を書くのは初めてなのでちょっと緊張していますが。。！
今回お声がけいただき、Variserve Advent Calendar2021 19日目に参加します。お手柔らかに
はじめに
冒頭にも書きましたが、私は「蒼の検証者」っていうアカウント名でツイッタラーしています。
そのアカウントでは自己研鑽として行っている「テストの資料を読み漁り」をした時の所感をつらつら呟いてます。(あとサッカーのことも。いや、サッカーのことの方が。。。)
※余談ですが実はこのアカウントの名付け親は@yoshikiitoさんです。
そんなことを大体3-4年くらい続けていると、有難いことに時折テスト界隈の有名な方々からもイイね！とかリプが来たりして、一人で舞い上がってたりします。
なので、そんな私のソフトウェアテストを習得するしていく上での喜び(活動の内容)を聞いて貰いたいなぁというのと、その自己研鑽から通じて感じたこと/思ったことを記事にしたいと思います。
これまでやってきたこと
まず初めに、私がやってきた自己研鑽(お勉強)の内容についてです。やっていることは以下の感じです。
####◆なにをやっているの？
古のソフトウェアテスト関連書物を読み漁っています。主に、JaSSTレポートの資料を、"過去"からさかのぼって興味のある資料を読み漁っています。そこから派生して、語る夕べの資料とかその他の資料も読んだりはしますが、メインはJaSSTレポートの資料です。
↓具体的にはここ
◆URL : http://jasst.jp/archives.html
JaSST 2003から始めて、今はJaSST2010 Tokyoまで読んでます。多分、通算で40-50レポートくらいは読んだ気もします。
(ここ最近では「『スープカレー方式』によるシステムテスト分析と設計」にとても共感していました。)
「なんで過去の資料から読んでいるか」というと、「技術は過去を抜きにして語れない」と思っているからです。
ソフトウェアテストという活動を通じて、
「今目の前で作られているどんなに新しいプロダクトであっても、
過去20-30年で積みあがってきたIT技術をベースに成り立っている」
と痛感し、そしてそれはソフトウェアテストも同じで、ということはテストの歴史を抜きにして本質や未来のことは語れないのでは？というところから、敢えて過去の資料を読み漁るようになりました。
####◆なんでやっているの？
これはすごくネガティブですが、「部下に示しがつかない」という理由が発端だった気がします。
メンバーへ指導するとき、自分のスキル・経験が皆無だということに気付き、そこから朝の通勤時間で
自己研鑽を始めました(当初はJSTQB FLすら持ってなかった。。)。
ただ、知れば知るほど奥が深く、もっと知りたい、もっと色んなことを知って色んな所で活躍したい！
という気持も強くなり、今日まで続いています。
ただ絶賛ダニング=クルーガー効果の底を体感中なので、もっと頑張って色々身に着けたいと思っています。。
これまで勉強してきた所感
ここからは、実際に私がこのJaSSTの資料を読む活動を通じて感じたことを記載したいと思います。
(ここからが話したい内容)
#####・最初のころ(2003年とか)⇒「創意工夫の共有」
「うちはこんなテストをしてるよ！」というのを発表する場にしている感じが強い気がします。最初の頃には特にテーマ性もなく、Jmeterといったツールの紹介など、各々が現場で培ったテストの考え方や使用しているツールの共有がメインなように感じます。
#####・途中(2008年位)⇒「技術の共有と体系化への考え方の共有」
テスト設計技法の話をメインに、「テスト分析」「テスト戦略」「テスト計画」の話、時にはMBTなど、当時からすると結構革新的だったんじゃないかなと思える話しなども多々出てきます。
この辺りから各回でメインテーマみたいなものが見え、業界的に「ソフトウェアテスト」というものの統一化、標準化が大分浸透してきているんだな、というのがJaSSTの内容から見て取れました。
#####・2010年位まで⇒「テスト技術の確立」
体型的にテストを管理する、テストを運用していく話しになっていきます。2010年位までで比較的マニュアルテストの手法、つまり、テスト開発の上から下まで一通りテーマとして取り上げられている印象です。
なので、「大まかなソフトウェアテストのベース」は大体2010年位で確立されていると感じます。
それはつまり、10年以上前に、先人たちは概ねソフトウェアテストについて一巡している、ということも言えそうです。
※あくまで私個人の所感です。
まだ2010年位までしか読めておらず、ここからさらに技術の加速が高まってくるかなぁと思っています。
2010年でここまでしっかり体系的に確立しているのであれば、やはり過去からの成り立ちをきちんと理解し、そこをベースとして新しいことに取り組むことが真のテストに近づくのかなとも感じました。
これまでのことを踏まえて思うこと
ということを踏まえつつ、今回記事を書く上で過去勉強してきたことを振り返った時、1つ気付いた事があります。それは、「"テスト実装"についての議論がほぼ無い」という事です。
※ここではマニュアルテストに於けるテスト実装の話にフォーカスします
「テスト実装」について、JSTQBでは以下の様に定義されています。
テスト実行に必要なテストウェアを作成、および/または完成させる。
そこにはテストケースの順序を決定してテスト手順を作成することが含まれる。
つまり、テスト設計は「それをどうテストするか」の答えであり、テスト実装は
「テストの実行に必要なものすべてを準備したか」の答えである
いわゆる「ローレベルテストケース」が生まれるプロセスですが、ここについての議論が過去ほとんどされていないのです。それは何故だろうか、と考えた時、1つの結論に至りました。
それは「テスト実装は自然言語で記載することが多いから」ではないかなと思います。
テストの各工程は開発プロセスとよく対比されると思いますが、「テスト実装」は開発工程における「実装」つまり「programming」と対比されると思います。対比される中で当然幾つか似た側面を持つものもありますが、決定的に異なる点が「テストは自然言語で書ける」ということだと思っています。
では、自然言語で書かれると何で記事にならないのか(注目され難いのか)。ここから先はJaSSTの資料のことから離れて、テスト実装についてもう少し自分の見解を深掘りしてみたいと思います。
###①テスト実装の参入障壁は低い = 誰でも出来そうな作業
プログラムは特定の言語を用いて行うと思います。つまり、その言語を知らないと、そもそもプログラムを行うこと、PRJに参画することすらできないわけです。ただテストは自然言語で書くことが多く、制約条件が圧倒的に低くなります。つまり、「比較的誰でもできる」という感覚に陥りやすいと思っています。なので、注目するほどでもないということになるのかなと思いました。
###②テスト手順が間違っててもどうにかできてしまう
ロジックが正しくないとソフトウェアとして動作しないと思いますが、テストは自然言語で記載するために、多少の手順(ロジック)の誤りや抜けがあっても「人間」という"意思/思考"を介在させることで補うことができます。それは「変更に強い」とも言えますが、反面「間違えてても何とかできちゃう」という負の面も強いと思っています。なので、工夫よりも効率を取る現場が多いのかなと思いました。
上記を私は現場で「自然言語の功罪」と呼んでいます。
この①と②より、「テスト実装はクリエイティブな作業ではなく、比較的誰でもできる/修正が容易な単純作業」と思われがちになるため、創意工夫の発表などが生まれにくいのでは？」と感じました。(そんな意図は全くないとも思っています)
果たしてテスト実装は本当に比較的誰でもできる作業なのか
答えは「No」だと思っています。
私は現場で、テスト実装を行う、新しくチャレンジするメンバーに対し、よく以下の点を伝えます。
①「3年後、5年後でもリユースできるテストスクリプトを作りなさい」
②「手順は主観的にならず、自分を客観視(自分の上から自分を客観視)するイメージで作りなさい」
③「実装では詳細かつ明瞭に、また、テスト実行は「人間が行うのか、機械が行うのか」という
違いだけしかなく、実施者に余計な思考を介在させないように、一意な期待値を意識しないさい。」
どれも凄く基礎的で単純な話しだと思いますが、意外とこれが難しく、感覚がつかめない人は結構ハマる
ポイントだと思っています。例えば、前提条件が漏れる、非効率な順番である、あるべき手順が記載されていない、期待値が一意ではない、など多々あります。
「他者は自分ではない」
QA組織の拡大によりプロセス毎に担当者が変わる現代において、このテスト実装における「客観性」「明確化」「一意性」というのはテストの質を左右する大事な要素であると思っています。
クリエイティブな「テスト分析」や「テスト設計」がいかに美しくできても、最後の実装部分でクオリティが下がれば、テスト実施を始め全て悪影響が出てしまいまうとも思います。工数の増加、不具合の見逃し、意図したテストが実施できないなど、様々な面で影響が出てしまうと思います。
ただここでの注意点は「決して作業を止めるまでの致命傷にはならない」という点がポイントだと思っています。後工程でもリカバリーできるのがテスト実装を自然言語で記載する一つのメリットでもあるのは事実だと思っています。
ただプロダクトの質にも大きくかかわるため、そこに甘えるのではなく、テスト実装に於いても創意工夫したり、もっとフォーカスされても良いのかもな、と今回の活動を振り返った時に感じました。
さいごに
今回アドベントカレンダーへ参加するにあたり、自分でも共有できることは何かを考えました。その答えは「ソフトウェアテストの自己研鑽について」であり、じゃあその内容を纏めよう！とした時に、テスト実装の記事の少なに気付き、そしてそこからテスト実装の大事さについて考えること、普段私が大事にしている要素について整理、共有することができました。個人的にはとても楽しかったです。
これからも継続して勉強し、先人たちに追いつけ追い越せで頑張っていきたいと思います。
最後まで見て頂き、有難うございました！！