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

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

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

今日がQUESに参加したことがない人生最後の日なのでQAではない自分がありったけの劣等感を記載しておこうかなと思う

このブログは私のチラシの裏なので何を書いても良いのであった（枕詞）

そもそもなんで参加しようと思ったか。
ここ1年以上、知識を得るモチベーションが下がっているを通り越して、関わるのが怖いまでいっていて
うげーとなってしまうことが増えていたので、それを払拭したかったから。
こんな動機は書かない方が良いのではという気持ちをひしひし感じつつ
私が抱えている劣等感と、知識を得ることは切り離していきたいので書いておきます。

私はQAではなく、テスト計画を立てる人間でも、プロジェクトマネージャでもない。
たまにテストを設計しつつテストを実行する第三者検証の人間です。
品質に横断的な知識が「実際の業務で」「これから必要になるか」と考えた場合NOになってしまうこともあると思う。
でも、このQAではなく、テスト設計者としても特化しておらず、ただしテストには関わっている
という自分の状態を認識しないといつまでたってもイイハナシダナ～（けど関係ないよね）みたいなモヤモヤを払拭できない気がしました。
自分の視座を許容しつつ粛々と知識を得られれば、それが一番いいかなと。
テスト実行者やチェッカーは打鍵してれば品質の知識いらないよね！と言われる日がきたらそれが私が知識いらないよねって腑に落ちるタイミングかなと思います。
立場によって聞かなくていいよねがない（と思いたい）

全然劣等感と知識がどうこうを切り離すことができていなかった。
1年間テスト系の勉強会など全くのぞいてなかったのですが、それでも業務がテストの端くれなので無縁でいられないんだなあ…と思ったのが今年です。
無縁でいられないなら、自分のできる範囲でできることをのほほんとした方がいいよねと。

いつも通りとりとめもなくなってきました。
せっかくの機会なのでテーマの「シフトレフト」について雑感をかいておこうと思います。
テスト7原則のうちの「早期テストで時間とコストを節約」に言われるようにソフト開発の早いうちに欠陥を取り除くといいですよね（まんまや）
私は関わっているプロセス上、テストを作っているときに仕様の「？」なところを見つけられれば、実行の時に見つかるより楽だなあ
（というか、実行者の時間や原因究明の時間を使わなくて済むなあ）と思います。
もっと前、それこそ要件定義をするとき、仕様のさらに前の段階で、こういう作りこみをしたら将来どのようなリスクがあるか？を想定して
作れると、後でしみじみと良かったなあと思うこともありますよね。
でも、それをするには、ドメイン知識や「こんな仕様にしたらこれがやばかった」の知識がないと難しく、つまり可能性を広げて考える視野が必要なんだろうなあと思います。
多分、今度の話は、品質の知識をもってソフトを作りこむ前にリスクを取り除いてく的な話なのかなと思いますが多分ちがいます。

初めてJaSST Reviewを聞いてから4年の月日が経ち、加速もなんもしなければ文章のやばさもレポートの書けなさも全然変わりませんが、とりあえずいってきます。

では「テスト設計ができない」とは何なのか

忘れていましたが、このブログは私のチラシの裏的な書き殴りの何かでした。

■はじめに

「テスト設計がうまくできないのでテスト設計を学びたい」
「テスト設計ができない」
「テスト設計できるか」

この辺りの言葉って私もよく使うし周りでも（どこ、？）よく聞くのですが
では「テスト設計ができる」とは何なのだろうと。

…つい最近どこかで読んだような気もするし、前もどこかで書いたようにも思えます。

このような文脈で「テスト設計」が話に出る場合、大体の場合は
「テスト設計のプロセス全般」を指していると思います。

おそらく「要求分析」「分析」「設計」「実装」の設計だけできない
という意味で使う人はいないかと。
（いたらすみません）

■テスト設計は何か？について書かれている記事

「つい最近読んだ」を思い出したので貼り付けておきます。（記載内容と話が被るのを防止するため）
テスト設計って結局何なのさ？｜156

この記事を読む限り、156さんの経歴は私に非常に近いです（私も実行者から入っていて第三者検証）
私もよく「実行者が分かりやすいように設計をすること」で考えます。

■テスト実装：細かく書くか、ふんわり書くか

これは、ALTMかALTAかFLの（おいおい）具体的テストケースと抽象的テストケース（こんな名前だったっけ？）の話です。
テスト実行する環境に合わせてテストの粒度を調整する。

例えば、テストを実行する人が開発を行っているところから物理的・組織的に離れている（第三者検証に出す場合など）や
後で組織の人間が入れ替わったときにテストケースを流用（過去の不具合情報を利用する場合など）は
具体的に書くことが必要になります。

逆にテスト実行する人がチーム内にいる場合やすぐフォローできる場合
また、ドメインに詳しい場合は「ざっくり書く」方が良いです。
これは、細かく記載しないことによるテスト作成工数の短縮や、他の場所も広げて確認できるメリットの方が大きくなるからです。

この「細かく具体的に書くかざっくり書くか」は
・JSTQBやIVECの資料で知識を身に着ける
・現場でテストの粒度をどう書いたかで得られる経験（あまりにもテストが進まない、逆にテストを細かく書きすぎて作成に時間かかる、メンテナンス工数がかかる）
これらの複合で徐々に身についていくと思います。

■テスト設計（暗に分析）ができない

ここまでの「テスト設計ができない」の話は、テストを実行可能な状態にするためにどう書くか。
すなわち「実装」の話です。
余談ですが「技法うまく使えない」は「設計」の話だと思います。

話を戻します。
私が「テスト設計できない」と言うときに意味しているのは「分析」の話です。

・テスト対象はどういうことをできることが求められているか
・どういうことが起きてほしくないかを求められているか
・その要求に対してどのような切り口でテストを構築するべきか
・テスト対象をどのような機能単位でグルーピングして考えるか
・どの実装単位でグルーピングして考えるか
私が「テスト設計できない」というときはこの構造化について話しています。

■余談：一般的に「テスト設計ができるようになりたい」は何を指すか

他の方から私が「テスト設計できるようになるには」を話されているときは
上記のように分析に限定せず「分析～設計～実装」を複合して話されていることが多いと思います。

「自動化したい」もしかり「～したい」「～できるようになりたい」の話である間は
その中の細かいプロセスには分割されておらず、それを実現しようという段階になって
初めて細かく考えるのかもしれません。

■どうすれば「テスト設計」ができるようになるか

テスト分析の部分をできるようになるには、自分に関して言えば
「パターンを学ぶ」「思考の障壁を取り除く」この2点です。

分析手法をうまく使うことができず尻込みしてしまうのが一番の障壁になっているように思えるので
その心の障壁を減らしていき、パターンを地道に積み上げるしかないかと。
先日のVSTEPの勉強会しかり、その他過去の記憶（おいおい、、）しかり
地道に分析の手法を学んでいくしかないようにも思えます。

あるパターンを過信して「これで考えればもう全部考えた！大丈夫！」になるのは良くないかもしれませんが
それはパターン思いつくようになった段階の後の話であり、最低限、良く思いつきうるパターン
（例えば品質特性。テストレベルやテストタイプで割ることもパターンの一つですよね）を
さっと思いつくようになるくらいになるところが第一歩の一歩の一歩かなあと…
はあ…

■他人に「テスト設計」を教えるにはどうすれば良いか

「分析」「設計」「実装」に分けてまず考えます。

分析は、テスト対象を機能対象で割り、テストする観点で割り、テストするタイプで割り…
など。テスト計画や戦略も考慮しながら。
（自分ができないので書き方も曖昧になります）

設計は、分析した対象に対してどのような設計技法を使ったら良いか。
組み合わせを使用するべき場面や状態遷移図を使うべき場面、
状態遷移の先で組み合わせを使っても良いなど。

実装は、書き方の粒度とか、環境・前提条件なども書くなど。
より実施しやすい、観測しやすいようにすることの重要性など。

テストを作ることは、自分の中では暗黙知の塊になっている気がします。
先人が整頓した資料をたくさん残してくれているのだから、それにインデックスをつけて最大限活用せねば…
と日々思いつつだらだらと生きています。

うわっ…私のVSTeP、ゴミ屋敷？！

■演習で学ぼう！VSTePを使ったテスト分析の勉強会に参加していた

何で参加したかというと慢性的にテスト「分析」に課題感を感じているから…というよりまったくできないからです。

内容はVSTePの概要説明→個人演習→個人演習の内容をグループで共有してみよう、といった感じでした。
VSTePはテストすべき時に考慮するものは全部観点なんですね。
多分この幅広さが後々出てくる「ツリーの第一階層どうしよう問題」に絡んでくるんだと思います

＜私が書いても大体間違えてそうなのでイベントのスライドをおもむろに貼っておく＞
演習で学ぼう！VSTePを使ったテスト分析の勉強会 - Speaker Deck

GIHOZ、前に起動したときは状態遷移図、デシジョンテーブル、あと何かもう一つしかなかったような気がするのですが
今日開いたらCFDやVSTepや色々機能増えててびっくりしました。
どうぶつの森を放置してたらラフレシアが咲いていた気分です。

一通りVSTePの説明が終わったあと、エアコンをお題に個人演習が開始しました。

■個人演習：うわっ…私のVSTeP理解、全然たりないよ編

ここからは自分の聞いたことのメモがわりです
・基本的にテスト対象はTOPのみ（対象の下に対象をツリーにしたりはしない）
・具体値はVSTepには含めないけど、一概に分解できない具体値と判断できない事もあり難しい
（私は温度の最大値・最小値や運転モードの冷房・暖房を具体値に例えましたが、確かにここから更に他の観点が連想できないかっていうと違いますね、、）

■第一階層どうしよう問題

個人演習前の神の声：第一階層で迷ったら・・・機能ごと、画面ごと、CIBFW（“条件（Condition）”、“テスト対象（test Item）”、“ふるまい（Behaviour）”、“嫌なこと（things Faulty or hazardous）”、”世界（World）"）で分けてみるのも手ですよ、…
↑演習がはじまったら忘れてました（えーー
機能を洗い出すのでいっぱいになってしまい、テストフレーム作成までもいけなかったです。第一階層は機能だけになってしまいました。
今振り返るとおもうのですが、第一階層をいかに広げるかによってテストの範囲が広くなるか狭くなるか決まるような。。
むずかしかったです。

VSTePは観点をツリー構造にして抜け漏れ無いかを見るもの（だと思う）のですが
私がやると頭の中の散らかりをそのまま可視化するみたいなものになってしまいました。
でも考えてるときは、ああもしかしてこうやって発想を広げてって後で整頓するのかな、とも思い
いくらか楽しかったかもしれません。
↓上昇負荷で成れ果ててしまった何か

ゴミ屋敷

■グループ演習：第一階層それにすればよかったのか編

グループ演習は何人かのグループに分かれて、個人演習で作成した図をプレゼンする内容でした。
ここで第一階層にそれを持ってくればよかったのかー！と目からうろこになりました。（詳細省きます。機能ではなかった）
他の方の図をみるのはいいですね、、「正解を探す」というのではなく「発想を出して考え抜く」ツールであるというのが感覚的にわかるような・・・

■正解はないが、いくらかの経験を積むことでフレームみたいなものが用意できる？

最後は講師の方が作ったサンプルの紹介とまとめでした。
講師の方のサンプル、グループ演習でみた他の方の図をみておもったのですが、VStePの第一階層（第二階層あたりも）は
その人がもつ「こういう風に全体をざっと考えていく」みたいなフレームが出ます。
そのパターンをいくらか持っておくと考えるときに便利なのかなーと。
ある時は品質特性であったり、CIBFWであったり、その他もろもろ。。

私は某テスコンでも某IVECでも、非機能とユーザーの使用に基づくテストの発想が弱いことが結構可視化されているので
それを考えるときのフレームにいれる＋機能だけ考えがちになってしまう所からの脱却が課題なのかなーと今回もおもいました。
いかんせん地道に手数をこなしていくしかないかな。。

負け筋が立て込む

■応用ｍ、、、
よくやってきたのでわかるのですが
大体挫折するパターンは
①体調不良が続く→今日はもうやめておこう→明日も略
※些細な自分の不調による妥協
＋
⓶文章や計算問題が頭にはいらねー目が滑るー
そして時が流れ、、午後を勉強せずに終わる
このパターンなのです。
特に⓶。まさに今乗り越えられない壁にぶち当たってます。
ド暗記すればいいのですが、、ド暗記するにも目が滑る。。ぐぬぬ

ちなみに昨日は①でした。

マジでどんなモチベーションで頑張るのかわからねええ
ねますや

へぐらしの応用情報受けるころに（もうネタ切れ

■応用情報

思えば応用情報って何回受けたか分からないくらい受けていて
加齢も相まって落ちた回数を忘れてきた。
原因はいつも勉強不足で、過去問でもやるか or テキスト一からやるか（壮大すぎてドン引き）
で始まってさぼって終わる（でも試験は受けに行く）を延々ループしているのです。
まさにひぐらしのなく頃に。

こんなことを書いているのは今日やはり過去問やったり緑本を読んだりして
「あっこれ1年前もやったわ」ってなったためです。
計算問題用のノートみたら全く覚えてないけど去年の日付が書いてあって笑いました。
うわっ…私の応用情報、挫折しすぎ？！
ねますや