私は迷いの中にいる

毎日眠気しかない謎の深海魚の一言日記

第三者検証テスターのつらさ、そしてつらさ

思い立ったので下書きにぶち込んだままのパクり記事を公開してみようと思います。
怒られたらもう一度下書きに戻します。

■この記事を書こうと思っていたきっかけ

第三者検証テスターとかいうマイナー業務について言及しているブログがあったので↓
第三者検証テスターのつらさ、そしてよさ｜ごまずん
第三者検証打鍵マスター（？？？？）たるものこのビックウェーブに乗らなければだめだと思ったから。

■とりあえず第三者検証テスターのつらさとつらさでも書く

大体上記の記事で書かれているのでわざわざ再記載するまでもないかな…

と思いましたが、それだと話も進まないので、なるべく視点を変えて書いていきます。
当事者を回避しては...いけない!!

私から見たつらさは
・人の境遇バラバラ過ぎて共感しづらい
・共感できないので課題が解決しづらい
・課題解決しづらいから学習性無力感が蔓延しがち
・頑張りすぎが悪になる
・技術の基準があんまりない
この辺ですね。ひとつづつ書いていきます。

■人の境遇バラバラ過ぎて共感できない

第三者検証だけではないかもしれませんが、多くの場合関わる人の境遇がバラバラです。
まず背景がバラバラ。私のように他業種から流れついた人、アルバイトの人、ソフトウェア工学学んだ人、疲れてしまったスクリプターなどです。
次に責務。管理をする人、テスト実行だけする人、派遣先で指令受けて働く人。全部責務がバラバラです。
こんな感じで全く共通した境遇であることがほぼないので、課題感の共有がめちゃくちゃしづらい。
何かを解決するのってまず「困るよね」の認識、それに対する温度感を合わせることだと思うのですが
そのスタートに立つのが大変という話です。

■共感できないから課題が解決しづらい

育ってきた環境が違うから好き嫌いは否めないけど、それをコミュニケーションでどうにかするのがこの仕事です。
しかし「一緒に働いている以上チームでがんばろう」に到達するまでに
人の好き嫌いだったり視座だったり乗り越えなきゃいけないものが多すぎて
そのコミュニケーションコストを払ってもそれを成すのは果たして得られるメリットが大きいのか？
みたいなジレンマに陥ることが多いように思えます。（そして課題への熱量が空中分解していく）

■課題解決しづらいから学習性無力感が蔓延しがち

そんな感じなので課題解決するという成功体験が無いがち。

■低予算で頑張り過ぎるのが悪

基本仕事している以上最低限は頑張るかな～と思うのですが
テスターに払われている予算がアレすぎるので（もしアレじゃない企業があったらすみません）
頑張りすぎが悪になる日もあるのです。
自分の現状の仕事に予算を付け、対価を求めなければいけない。
なので、今の対価でどこまで頑張るべきか？を意識しなければいけないのが、時には辛くなる日も、あるのです（？？？？？

■技術の基準が明示しづらい

バグを出す件数を基準にしている企業があるとがっかりしませんか？（何の話？？
バグを出すのが仕事というのも個人的にはがっかりします。
云わんとしてることは分かります。ソフトウェアに直すべきところがなければテストいらねーだろってなりますもんね。
でも、バグの件数＝ソフトの品質になりませんよね？
例えば機能を作り込んでる段階のときに表示見切れてるよってバグを100個起票されて喜ぶ人っているのでしょうか。
仕様を作り込んでる段階でドキュメント未記載や誤字を指摘されまくることを喜ぶ人がいるのでしょうか。
総じて、第三者検証テスターの技術がバグをや指摘をだしまくったりなど「量」だけで判断するのは正しいとは言えません。
じゃあ何が第三者検証テスターの技術か？それは、プロジェクトの行間（今何が求められているか、どんなところを叩けばいいか何に着目してほしいか）を読むこと。なんていわれても「何言ってんだこいつ。。。」って思いますよね。
こういうところです。＞技術の基準が明示しづらい

■私はこの記事書いて何がしたかったんだ…

この記事を下書きしてからだいぶ時が経過してるので
書いたことに対する気持ちも「そんな風に考えていた時期が私にもありました」みたいな感じになりつつあります。
あとは、この記事かなり露悪入ってるので、公開してもなんだかなあって思っていました。
もっと建設的なこと書いた方が自分のためにも他人のためにもなるんじゃないかと。
それでも書いたのは、そうですね、、書くことで、己の悲しみを救いたかったからではないでしょうか。ねまーす

まさかお前生き別れたはずの

■じぇ、JCSQ...
とりあえず始める痛みのコブを超えるべく、今日は過去問をダウンロードしたり過去問をみてみたりテス友やってみたりしました。
テス友はともかく、過去問は「すがすがしいくらい忘れている自分」を可視化できてなかなかでした。

元々の知識はともかく、私は長年打鍵屋、、第三者検証をやっていた関係上
「品質を全体で考える」が苦手です。思考の癖がテストに毒されているんですよね。
テストに毒されているというのはどういうことかというと、動作を修正する方向やそれは修正するべきか？みたいな
プロダクトを修正するか否かの範囲に思考が収まりがちであるということです。
（もっと狭く毒されているならば、動作が不ぞろいを気にするとか、かなりやらない動作をした時の動作を気にするとか
「違和感を見つけるために特化してしまう」もそれです）

いっぽうJCSQEの記述（つまり品質屋に求められる視点）とは、求められる品質の具体化とか、方針の策定とか
もう少し視点を変えてみないとダメなところが有る。
なのでこれから少しづつ思考の癖をとっぱらっていかなければいけないのです。できるのかな、、

とりあえず今日は構成管理も何もかも忘れてました。
11月までこれを続けられるなら、久しぶりにアセスメントできるよう今時点の記録をつけておきます。
テス友：2回で80点、60点
中級第14回過去問：
説明問題を根本的に間違えた（これからどうするかではなく起こったことへ言及するような対策をかいてしまった）
解説問題は少しだけわかったけど、信頼性の具体化への言及があまりできなかった。
ねるかな～

はてなのAIにこの記事のタイトル考えてもらったらこんな感じでした（後ろ3つはソーシャルメディア向けとのこと）

・テストに毒される思考の囚われ
・品質全体を見据える視点の欠如と修正の過程
・アセスメントへの向かう道：思考の癖を処理する
・コブを超えるための過去問ダウンロード！ #テスト
・品質全体を考えられる私の思考の癖 #視点変えて
・アセスメントできる記録つけます！ #信頼性具体化

1番目が好きですね。
ソーシャルメディア向けのタイトルは元の記事がいみふなので
全然アクセス稼げなさそうなタイトルになってます。

この「日記を書いて己の悲しみを救う」ビックウェーブに乗るしかない

■特に何もせず4月になった
今年もすでに4月で笑います。
私はというと、のほほんと暮らしていました。
仕事は忙しいですね。仕事をしたり、仕事をしたり、仕事をしたりして過ごしてました。

突然書こうかなと思ったのは、己の悲しみを救いたいからというより、ただそこにブログがあったからです（？）
悲しみ、、悲しみ、、悲しみを書けばキリがないけれど
悲しみを書き留めなければ1分くらいで悲しみが霧散していくのが一番悲しいんじゃないかなと思います。
F検定のグラフを想像してみてください。悲しみの減衰の仕方がちょうどこんな感じです。
悲しみをきちんと書き留めて作品に昇華した道綱母は凄いですね。

■そろそろJCSQEでも受けるかな、、
私が受けるのは中級なのであと200日あるからワニも2周くらい死ぬし会社員も2回くらい退職するほど日数あります。
でもそろそろなんかしようかな～と思い、いつも通りどうやって勉強するかなーだけ考えて終わりました。
昔ブログ検索したとき、中級の記述について結構分解したこと書いてあった記事があったのですが、どこに行ったか分からなくなってしまいました。
とにかく受験者の経験談は「SQUBOK熟読」に偏ります。それはそうか。。
SQUBOKを3つにぶった切ってマーカーしている人のブログが一番参考になりました。

全然関係ないけど、この仕事の悲しみの一つに「コンテキストがバラバラすぎて分かり合うのが難しい」があると思います。
そしてコンテキストがバラバラなので資格試験について「こうすればいけるんじゃね」と書いた試験の経験談も
暗黙知の部分が違いすぎて人によっては全く参考にならないという。。とほほ
でもこの悲しみを乗り越えるのもこの仕事の醍醐味なのかもしれないですね。何書いてるかよく分からなくなってきたので寝ます。ねますや

2023年でも振り替えっとくか

今年を振り返っておきます。という下書きをしたまま放置してて今年も終わりそうなので適当に公開しておきます

■一言で
何もせずのほほーんと生きた1年でした。

■試験とか
去年11月に受けた試験のうち、IVECレベル5は合格し、JCSQE中級は選択問題44点で落ちました(今年は受けてない)
今年は応用情報を春に受けて落ちました(秋は受けてない)

■仕事
忙しかった

■イベントとか？
JaSST東京に初めて参加しました。
論文の話(目をつけてないとこを探して調べる)と、シフトさんのSAP導入支援の話ての、丸投げじゃなくユーザー企業側と一緒にやっていくのあたりが印象に残っています。
丸ごと独立して業務を請け負っちゃうのはソフト開発にしろシステム移行にしろあんまり良い選択ではないのだろうなと

あとはVStepの講習？に参加しました。
私がVStep全く分かっとらんなが分かったので参加して良かったです。ベリサーブの講師の方のようになりたい。

11月には4年ぶりにオフラインイベント（Ques）にいきました。
これはオフラインイベントに参加する価値を考えるいい機会になりました。
話の内容については、途中からプロジェクトに参画するときに、最初からいきなり入り込むのではなくまず観察するってのがなるほどなーと思いました


■諸々
仕事が忙しくほぼ仕事に専念した1年でした。
1つのことに専念できるのは思いの外精神負荷が低くてよかったです。

勉強してないなーという焦りと諦めは半分くらいありますが年始よりだいぶ減ったかな、、

自分が資格を取ることやイベント参加することに意味はあるか？に対してのひとつの回答として
自分だけだとあまり意味がないけれど、その知識が他の人に連鎖していくことがあれば、それが意味のあることになるのかもしれないと思えるようになりました。

体は一年健康でした。家族も然り。
気候は夏からずっと暑かったです。

世の中はコロナが5類になって、コロナの病態どうこうより病態がなんだろうが気にしないでオッケー方面に全振りして(いるように見え)ます。
私は健康に自信がないので相変わらずですが、この先は病気になりたくないなーを気にするかしないかで色々諦めることも出てくるのだろうなと感じます。

抽象的な感覚ですが分断が更に一段階進んだような。

あと今年は生成AIとChatGPTの躍進がすごかったですね。

ただ海外映画業界がストしている通り生成AIで代替できることによる社会的影響は考えていくべきと思います。
スマホ、YouTube、サブスクによって淘汰されていったものと同様のことを人間の「作り出す」行為に対して起こしていいのかを。

文章やコード作成をChatGPT丸投げにする人が増えて
何が正しいのかを理解することがブラックボックスにならないことを祈りますが、
その妥当性をテストするなにかとかもあるのかもしれないですね、（？）

でも、技法とかさくっとツールで出来るのが良いのなら、もう今は計算機の仕組みを知る人がいないのと同じようにブラックボックスになってもいいのかな、、

■来年どうしよう
JCSQE中級受けたいんですがまだ考え中です。
他はあまり何も考えていないですが、テスト設計とは何か？はもう少し分かるようになりたいですねー

Quesいってきたよね

このブログは私のチラシの裏であって（略）

■Quesに初めていってきた（オフラインで）
昨日も書いた通り思い立ってQuesというQA専門のイベントにQAではないけど行ってきました。
普段あまり外出しないので世の中が花金（死語）で飲みに行っているんだなあと知れたのはよかったかもしれません。
全然イベントの感想になってないがな。

オフラインで行ってみて何をしたわけでもないのですがなんとなく見てみて良かったかなあとは思います。
Zoomでもいいんですが話している人の熱量というか、空気感が分かるのが。

シフトレフトがお題でしたが、話していた内容は
特にアジャイルや短期間リリースにおいてはテストに使える時間は限られているので、
目的を定めて厳選してテストしていくよ！といった内容が多かったかなと、、違うかもしれません。

■ぱいんさんの話で印象に残ったこと
ぱいんさんのお話はザク―っというと
リリース頻度を早くするためのブロッカーを取り除きたい
→そのブロッカーがテストフェーズで差し戻しが出ている
→実行が早くても仕様がずれていると手戻りが減らないので
その手戻りを減らすにはどう改善したらいい？というその改善の取り組みの話でした。

その対策の中で、レビューを工夫するというのがありました。
ちょっとうろ覚えですが
「レビューの用意に時間かかりすぎて開発のさまたげにならないようにする」
というのがあって、確かに効率化しようとしてるのにプロセスが重くてボトルネックになったら本末転倒だよなあと思いました。

あとはリグレッションテストを減らすことで
目的に沿ってテストを取捨選択する話もうなづけたかもしれません。
どちらも、目的という軸がないとダメなことだなあと。
自分がテストを取捨選択したりするときに何を軸にして考えているかは立ち戻りたいかもしれないです。その目的が途中（例えばカバレッジ満たしたいだけとか）で止まってないかとか。


■Summyさんの話で印象に残ったこと
シナリオテスト（ユースケーステスト）を結構早い段階で書いて
PdMや開発な人とわちゃわちゃしていくことで
リリースの直前でジャッジしてやりたいことができてないよを防ぐよ、的な話だったとおもいます
（全然違いそうなのでちゃんと資料をみたほうがいいです）
シナリオを早い段階で色んな人を巻き込んでテスト実装していくことは
・ユーザが使いうる範囲のところがあとでダメだーとならない
・シナリオ（ユースケース？）が具体的に合意できる
このへんの点でよさそうですよね（意地悪観点じゃなくいわゆる普通に使う観点を担保できるみたいな）

印象に残ったことは「抽象度をあげた確認ポイント」の話でした。
いわゆる「ここは重点的にみたほうがいいよね」のポイントで
・作るときに議論が活発だったり、仕様が途中で変わったりした箇所
・プロダクトに関わる法律（やレギュレーション）が変化した箇所
・ロジックが複雑な箇所
これらを挙げられていましたが、これはおそらく汎用的に使えるポイントなのだろうなと思いました。

私が今日聞いたことを今すぐ生かせるかって言えばそんなに自信ないですが
取捨選択する、そのために目的に立ち戻るは常にやりたいなとおもいつつねますや