JaSST nano vol.4 でお話ししたことの個人的なメモなの
初回開催に続き、第4回目となるJaSST nanoで喋ってきました。
当日使用したスライドはSlideShareにアップしていますので、よろしければご覧ください↓
(第一回同様、録画がYouTubeのASTERソフトウェアテストチャンネルにアップされるかもしれませんが、本の内容を引用しまくった内容をアップして良いものかどうか微妙なため、もしかしたら動画のアップはないかもしれません)
登壇のキッカケ
JaSST nanoは公式？(puki wiki)で登壇者を募集しているのですが、第4回はしばらく登壇エントリーが1件もありませんでした。ならば"登壇の楽しさをまた味わいたいしな～"とか考えてたところに、今回話したテーマが頭に降ってきたので"いっちょやってみっか"をしてみた次第です。
結果的には9人の登壇者が集ったのですが、僕の謎テーマエントリーを見て"ハードル低そう！"と感じてエントリーした方がもしいたなら嬉しいです。
話した内容
プロ野球選手および監督として大活躍された、野村克也さんの格言から"ソフトウェアテストに通ずるなにか"を学ぼう！という趣旨で話をしました。"異業種のプロフェッショナルから学ぶ"ということについては、JaSST Hokkaidoからヒントを得ました。
JaSST HokkaidoのレポートはJaSSTのサイトから閲覧できますので、興味を持った方はアクセスしてみてください↓
余談
・野村克也さんを題材としていますが、僕は横浜ベイスターズのファンです。
・落合博満氏の66の格言を収めた本も手元に合ったりするので、落合ver.にすることも考えました。
今回の内容で考えた部分
野村克也の"どの部分"を"どこまで"説明するか
ある程度プロ野球を知っている方なら名前を知らない人はいないくらいの有名人ですが、一方でプロ野球に興味がない方にとっては"誰それ？"だと思います。テスト界隈で例えるならば、マイヤーズやワインバーグくらい有名な方です(本当か？)。
野村克也さんの説明をするLTではないので、どこまで説明をするかは悩みましたが、結果として今回話した程度の内容にしました。プロ野球を知らない方でもわかるポイントとして、野村監督の就任前と就任後の順位推移さえ説明できれば充分かなと判断しました。
どの格言をピックアップするか
参考書籍である"野村克也人生語録"には76の格言が収録されています。この中からどの格言をピックアップするかはちょっと悩みました。一番話したかったことは、3番目に話した"配球には 一球、一球、 根拠が必要だ"なんですが、あとの2つをどうしようか…と。
結果的には個人的に好きな"価値に不思議の勝ちあり、負けに不思議の負けなし"と、それに続くような内容の"予測、実践、反省"をチョイスしました。ちなみに他に候補は以下になります。
・手段と目的を混同してはいけない
・固定観念は悪、先入観は罪
・小事が大事を生む
・プロとは、あたりまえのことをあたりまえにする者をいう
・進歩とは変わることである
スライドデザイン
前回は比較的ポップなデザインにしたのですが、今回は野村克也さんのイメージも考慮しつつ、ミーティングや授業の雰囲気を作りたいと考えました。
ホワイトボード風なデザインを最初に考えましたが、あまり目に優しくないこともあって黒板風に変更しました。このデザイン自体はMicrosoft公式からいただいてます。本来はバーチャル背景としての利用を想定されたもののようですね。
黒板背景 - 無料テンプレート公開中 - 楽しもう Office
フォントも拘りたかったのですが、あまり良いフリーフォントが見つからず…。最終的には"黒板=学校"なイメージもあったので、プリインの教科書体を用いました。ぱっと見で全くわかりませんが、チョークっぽさを少しでも出すためにフォントの透過度を調整してます。
伝えたいこと
取り上げた3つの格言で伝えたかったことはスライドの終盤で書いた通り、
①勝ちに不思議の勝ちあり、負けに不思議の負けなし
⇒負け(テストにおける失敗)の原因を突き止めよう
②予測、実践、反省
⇒(ソフトウェアはもちろん、プロジェクトの)変化を見る目を養おう
③配球には 一球、一球、 根拠が必要だ
⇒(一つ一つのテストに)根拠と責任を持とう
の3点です。(かっこ書きは補足)
特に"根拠と責任"については、日々頭の片隅で意識していなければならないものと思っています。"なんとなく"したテストからは、"なんとなく"動くソフトウェアしか生まれないと思っています。これは"不思議の負けなし"の部分にもつながる部分ですね。
今回の反省点
以下、若干ネガティブ感のある反省コーナーです。
話す内容をもう少し絞って良かった。
前述のとおり、一番話したかったことは"配球には 一球、一球、 根拠が必要だ"の部分です。これを話の最後に持ってきたことにより、時間に追われつつババババっとした説明で終わってしまったことが反省ポイントです。
ふりかえると、"予測、実践、反省"の部分をカットして、もう少しゆとりのある時間配分が必要だったかなと思っています。一番伝えたいことを中心に構成を考えよう！
声の張り
一人で喋る練習と経験の不足感はやはり否めず…。いや、その経験を得たい部分もあって登壇してるんですが、緊張感も混じるとボソボソなりがち＆カミがちでした。
YouTubeLiveとOBS Studioを利用して2回練習したのですが、本番でそれが発揮できるかは別問題…っ！！なにか対策を打たねばと思います(誰かと喋るラジオ形式にするとか、目の前に愛する妻を座らせて会話するように喋るとか？)。
前回より楽しめていなかった
喋ったあとに言うのもアレですが、今回の登壇用スライドが完成した時にまず思ってしまったことは「前回(vol.1)の内容の方が断然面白いなコレ…」でした。きっと全国に2人ほどいるもがねファンの期待を裏切ったことでしょう。ここに謝罪いたします。てへぺろぺろ。
前回で言えば"恋愛のヒントなの"という題材と、一発目の"テストは欠陥があることは示せるが、欠陥がないことは示せない"の内容のおかげで"掴み"はかなり良かったと思っています。そう思えたからこそ、途中の小ネタにもキレとコクが生まれたのではないかと思ってます。
今回はその掴みの部分が弱く、ストレートに表現すれば面白さに欠けていたと思います。"まず自分が喋って面白いかどうか"を考えたトークが必要だなと感じました。LTらしさが欠けてたかな～という部分もアリ。
おわりに
反省点はチラホラあるものの、毎月ステキな場を提供してくださるJaSST nanoお世話係の皆様には感謝感謝です。今後もエントリーしていきたいと考えていますので、その際は一層頑張りたいと思います。
またJaSSTの名のもとに誰でも気軽に話せる場なので、登壇を考えていらっしゃる方はぜひぜひチャレンジしてみていただければと思います。テストにまつわるいろんな方のLTが気軽に聞ける唯一の場だと思ってますので、今後もJaSST nanoが盛り上がっていくことを期待しています。
最後に、ここまで読んでいただいた方＆当日僕のLTをご視聴した皆さま、貴重な時間を割いていただきありがとうございました。
JaSST nano でLTした体験記なの
はー気持ちよく喋らせていただきました！ありがとうございますなの！ #jasstnano
— もがね (@moyashinomegane) 2021年6月15日
LT形式で行われる初のJaSSTで発表(登壇?)しました。
緊張と興奮が入り混じる10分間をエンジョイしましたので、その思い出をここに残したいと思います。来月には早くも第二回が予定されていますので、"発表どうしようかな～"と思っている方の参考になれば嬉しいです。
↓↓↓
◆追記
ASTERさんのチャンネルで当日の動画を配信していただきました！
JaSST nano vol.1 「テストの7原則から学ぶ恋愛のヒントなの」 - YouTube
↑↑↑
まず発表(登壇)した感想
最高でした！
まず喋る側として参加する気持ちよさと楽しさを知ることができました。運営(お世話係)の皆様の空気作りや、他の発表者のハイレベルなテーマの中に飛び込めて発表できたのは、本当にラッキーでした。
また試聴していただいた皆様も本当にあたたかい方ばかりで、チャットやTwitterで褒めていただいたりツッコんでいただいたり(?)、発表を盛り上げていただきました。
なぜ参加したの？
ふと目にしたツイートがキッカケです。
「JaSST nano」誰でも気軽にトークできる小さな小さなJaSST～を始めまーす。
— きたのしろくま (@kitanosirokuma) 2021年5月28日
月に1度、19:00～、オンライン開催
テーマはソフトウェアテスト、QA、品質に関することなら何でもOK！
第1回は 6/15 19:00～ です。
発表するぞ！意見聴きたい！という方は、エントリ↓してねーhttps://t.co/zkuRbloXSC
誰でも？気軽に？言いましたね？
ということでホイホイ申し込みました。この時点ではテーマを決めてなかったので、2日後に「テストの7原則から学ぶ恋愛のヒントなの」で申し込みDone！
正直"こんなテーマじゃ却下されるんじゃないかな～"と半分思ってましたが、なんのことはなく、このテーマで話すことになりました。もはやテストのことを話していないレベルですが、全然OKなの！それがJaSST nano！
僕自身小さいSES企業に在籍するポンコツテスターなので、こういった機会を設けていただいた運営の皆様には感謝しかありません。普段JaSSTは勿論のこと、様々なイベントで情報を享受するばかりなので、なにか発信する側になりたいという気持ちはありました。とはいえ、人に話せるほどの経験もスキルもない…という時、舞い降りたのがJaSST nano！そう、それがJaSST nano！
発表スライドの作成
考慮した点は大きく下記の3つです。
- 1ページあたりの情報量を少なく
- 見やすい配色
- テーマとマッチする雰囲気づくり
1ページあたりの情報量を少なく
LTということもあり、あまり読ませたくはないので基本"1ページ1文"を意識して作成しました。(結果的にスライド79枚を10分で!?できらぁ！)
また画面がポンポン切り替わる方が、より画面に目を惹きつけやすい(表現合ってる？)と考えています。あまり画面が変わらないままだと、聴きながら余所見したくなっちゃいませんか？(自分だけ？)
見やすい配色
参考にしたのはこちらの記事
大体いい感じになるKeynoteテンプレート「Azusa」作った - MEMOGRAPHIX
背景をクリーム色、文字を紺色、アクセントにレンガ色を使用しました。
今回は喋るのが"夜"ということもあり、真っ白や真っ赤等、目に鋭く入ってくる色を避けたいという考えもありました。
テーマとマッチする雰囲気づくり
今回は「テストの7原則から学ぶ恋愛のヒントなの」というスーパーゆるゆるテーマで話すので、その雰囲気にマッチしたスライドに仕上げました。具体的にはフォントとイラストで雰囲気づくりをしています。
◆使用したフォント
「コーポレート・ロゴ B」（ver1.1）
◆使用したイラスト
特にフォントの持つ力は絶大(?)と思っていて、スライドの雰囲気を決定づける最重要パーツだと思っています。名前のとおりロゴの作成に使用するフォントなのかなと思いますが、ポップ且つ芯のある(?)フォントがとても良い感じだったので使用しました。
イラストも線が太くてかわいらしい所が、発表テーマにもフォントにも絶妙にマッチしたと思っています。
発表テーマを「テストの7原則から学ぶ恋愛のヒントなの」にした理由
ここ1年ほど、自社の経験が浅いテスターを教育をする機会が増えました。
僕は人に教えることが決して得意ではないのですが、なるべくわかりやすくて印象に残りやすいように伝える工夫として、テストを恋愛や料理に例えることが多いです。
なぜ恋愛や料理に例えるかというと、誰でも想像しやすいと考えているからです。
例えば喜びの表現をドラクエに例えて「キラーマシンが起き上がってこちらを見た時ぐらい嬉しい(※)」という話をした場合、ドラクエを知らない人からすると全くピンとこないですよね。(※キラーマシンという強いモンスターを倒した時、1/256という低確率で仲間になるという話@ドラクエ5)
ただし、例え話はコアなほど面白いという一面もあります。聞いてもらう方全員に共通する話題があるならば、ブッこんでみるのも良いと思います。
…と、こういった工夫していることを少しご紹介できたらいいなと思い、今回はこのテーマで喋ることを選択しました。(前述のとおり、技術的な話をする自信もないので…)
「テストの7原則から学ぶ恋愛のヒントなの」の内容
使用したスライドをこちらに公開します。(SlideShareデビュー)
内容について下記にまとめました。発表時に緊張でうまく喋れてないと思うので、↓にも書き残しておきます。
なお"テストの7原則"については、JSTQB Foundation Levelのシラバスより引用しております。
JSTQB認定テスト技術者資格-シラバス（学習事項）・用語集-
①テストは欠陥があることは示せるが、欠陥がないことは示せない
テストが恋人関係の期間、テストが終わっていざリリース！が結婚と例えてみましょう。
自分にとって全てが完璧な人間などいませんから、恋人関係の間に色々と相手に対して問題が出てくると思います。
もちろん相手から見たあなたの問題も浮かび上がってくることでしょう。
恋人期間にその欠点を洗い出し、改善したり…受け入れたり…妥協したり…。
時間をかけて全てを整理し、最終的に"婚姻届"という名のテストサマリレポートを提出します。
…さぁ、果たしてもう問題はないと言えるでしょうか？答えはNoですね。
たまたま恋人期間中には浮かび上がらなかった欠点があるかもしれません。
恋人期間中に相手の欠陥があることは見つけられますが、これ以上欠陥がないことは証明できないのです。
3年~5年~10年~20年…結婚生活の中で色々な問題に直面することでしょう。
特に金銭面でのすれ違いや、お互いの深い部分の"価値観"は実際に結婚してみないとわからないことが多々あります。
(子供を授かると…なんて話もよく聞きますが、ウチは子なしなのでよくわかりません)
ただし大事な補足をすると、出てくるのは欠点ばかりではありません。
今まで知らなかった相手の"良い所"を見つけることも沢山あります。
相手の欠点ばかり見つけようとせず、良い所を積極的に見つける姿勢が大事かもしれません。
②全数テストは不可能
恋人や生涯のパートナーを、この世の全ての異性の中から選択する…なんてことは非現実的です。
限られた時間,お金,場所の中で出会いを求めなくてはなりません。
レミオ〇メンも「1億人から君を見つけたよ」などど唄っていますが、即座にこう言います。
「根拠はないけど」
ただなんとなく"出会い欲しい～"と思うよりも、どんな人と出会いたいか＆どうやって出会うかを考えて行動した方が、良い出会いに結びつくかもしれません。己という名のテストベースを分析して、設計をしてから出会いを探しましょう！
(でも人の出会いというのは、ある程度運命的なものだと思います)
③早期テストで時間とコストを節約
例えばあなたのパートナーに欠点があったとします。その欠点を早めに知ることができるかどうか…が重要だと考えています。
「いざ結婚してみたら旦那がギャンブル依存症だった！」
「妻にものすごい浪費癖があり、毎週のように服を買ってしまう！」
といったことを、結婚する前に知るのと後で知るのは違いますよね。
付き合う前、付き合って間もない頃、婚約前、結婚後、出産後…
改善するにも受け入れるにも(あきらめるにも)、後段になるほど"金・時・人"の負担は大きくなると思います。
発表時、ここで言い放ったのがそう、恋のシフトレフト(言いたいだけ)
④欠陥の偏在
ソフトウェアにバグが偏在する理由はいくつかありますが、その偏在を予測することがテストでは重要です。
そしてこの予測をする力は、恋愛においても非常に大事なことだと考えています。
人間関係の作り方が上手な人ほど、相手が喜ぶこと(逆に嫌がること)を予測して行動に移せる人なんじゃないかと思っています。
⑤殺虫剤のパラドックスにご用心
同じデート,同じプレゼント,同じ話…を何回も繰り返しているとマンネリを生み出します。
"大好きなプリンを定期的に買ってあげる"なんかは有効かもしれませんが、たまには変わったことをしてあげると嬉しいものです。
「考えてくれてる」とか「大事にされてる」って感情は、些細なことの積み重ねだったりしますよね。
(ちなみに僕は記念日にいつもより気合の入ったファッションとかされると弱いです)
ただし殺虫剤のパラドックスが有効なケースもあります。テストで言えば、リグレッションテストがこれに当てはまります。同じことを繰り返すことから、自動化に向いていると良く言われますね。
これを恋愛に例えると…同棲ないし結婚生活の家事全般です。掃除、食器洗い、洗濯なんかはほぼ同じことの繰り返しです。これらを積極的に出来る人は、個人的にはかなりモテると思います。
そしてこれらも自動化が向いている…？そう、だから全自動家電というのは人気なんですね。(ルンバ、ドラム式洗濯乾燥機、食器洗い乾燥機など…)
⑥テストは状況次第
全ての異性に通用する「誰にでも効果てきめん！イチコロテクニック！」なんてものはありません。
相手に応じて有効なアプローチはそれぞれ異なります。
もっと言えばその日の体調や機嫌の良し悪しでも変わりますので、状況に応じた行動を心がけましょう。
⑦「バグゼロ」の落とし穴
自分にとって相手の嫌なところ(自分から見た相手の不具合)を全て改善してもらったとしましょう。
「ゴルフばっかり行かないで！お酒は週1回までにして！お小遣いもっと貯金に回して！」などなど…
その結果、休みの日は家でただゴロゴロしてるパートナーが爆誕したらどうでしょう。
また過剰にストレスを溜め込んで体調を崩したり、仕事の成果が落ちたり、家のコトに消極的になったり…終いにはあなたにアタるかもしれません。
欠点を改善した結果、パートナーが魅力を失ってしまったらそれは改善とは言えませんね。
終わりに
テスト業界に足を踏み入れてから、初めて情報を発信する側に立つことができました。参加者が200人を超える中でとても緊張しましたが、初回のイベントを少しでも盛り上げられたなら嬉しいです。冒頭でも述べましたが、このような機会を用意していただいた運営の皆様にはとても感謝しています。ありがとうございます。
JaSST nanoは毎月の開催を計画しているそうなので、もし発表を迷っている方がいらっしゃいましたら是非飛び込んでみることをお勧めします。僕もまたなにかネタが用意できたらまた参加してみようかなと思います。
長くなりましたが、ここまで読んでいただきありがとうございました。
https://twitter.com/kitanosirokuma/status/1398129081149911042?s=20
https://twitter.com/kitanosirokuma/status/1398129081149911042?s=20
https://twitter.com/kitanosirokuma/status/1398129081149911042?s=20
JSTQB Advanced Level テストアナリスト試験に合格した話
ブログなんて書いてたっけ？レベルで久々の更新となります。仕事して社外活動して子育てして趣味も楽しんで副業して…みたいな方、ほんとスーパーマンだと思います。
さて本題に入りますが、表題にあるとおり"JSTQB Advanced Level Test Analyst"に見事合格しました。2回目の挑戦で無事合格できてホッとしています。
(ちなみに前回受験した時の記事はこちら↓)
moyashinomegane.hatenablog.com
これから同資格試験に挑戦する方や、僕のように過去に受験して不合格だったけど再チャレンジする方に向けてなにか残せればと思い、以下つらつらと書いていきます。
なぜ合格できたか
①2回受験したから
半分冗談ですが半分本気で、やっぱり1回挑戦した経験は生きたと思います。
勉強したつもりになっていた部分や理解が浅い部分は明確になったので、2回目の受験に向けてしっかり準備はできたのかなと。
ちなみに僕はドメイン分析に対する知識が浅かったので、そこはしっかり押さえておくようにしていました。テストケースの導出はもちろんですが、どういう場合にドメイン分析を活用するかも理解が必要です。(初回受験時はデシジョンテーブルとドメイン分析を活用する場面について、違いを曖昧に理解していました)
なお前回も今回も難易度にそれほど差はなかったように思います。(直交表に関する問題が出たり出なかったり？な多少の差はありますが)
②三種の神器を活用したから
三種の神器とは↓
JSTQB ALTA…合格してる！！
— もがね (@moyashinomegane) 2021年3月31日
三種の神器のおかげです https://t.co/aMDQydMIK9
https://twitter.com/moyashinomegane/status/1377149367128182787?s=20https://twitter.com/moyashinomegane/status/1377149367128182787?s=20https://twitter.com/moyashinomegane/status/1377149367128182787?s=20https://twitter.https://twitter.com/moyashinomegane/status/1377149367128182787?s=20com/moyashinomegane/status/1377149367128182787?s=20
ソフトウェアテスト技法ドリル
この試験のために買ったものではないですが、テスト技法を学ぶには欠かせないバイブルですね。
出題されるテスト技法(シラバスに記載されている技法)についてはこの本にほぼ網羅されています。 1~2回読んで全てを理解するのは難しいと思いますが、テスト技法で悩んだタイミングでこの本を読み返すと、理解を深めることができるかと思います。
私は何回読んでも頭の中で"なるほど～"ってなります。
ソフトウェアテスト技法練習帳
前述のソフトウェアテスト技法ドリルで技法を学んだとしても、実際に手を動かさないとなかなか身につかないと思います。そんな時に役立つのがこちらのソフトウェアテスト技法練習帳です。
- 同値分割法
- 境界値分析
- 状態遷移テスト
- 組み合わせテスト
についてみっちり問題が詰まっています。"同値分割や境界値なんて楽勝でしょ？"と油断していると、意外と"ムムッ!?"となります。(なりました)
実際にありそうな課題をテーマとされていて、少しユニークなテーマ(合コン会計アプリ!?)もあったりして飽きずに勉強ができます。
実際の試験問題も"〇〇な場面で〇〇技法を活用してテストケース数を答える"問題が多いので、イメージを掴むのにもGoodです。
そして解説が一つひとつ丁寧なので、著者の皆様には頭が下がる素敵な一冊です。
非認定 JSTQBソフトウェアテスト問題集
これについては一般販売されている書籍ではなく、同人誌として販売されているものです。
JSTQB Advanced Level 非公式問題集 - BOOTH
Foundation Levelと異なり、Advanced Levelは模擬問題が少ないことが悩みのタネで…と思っている方にピッタリな一冊です。
前述のソフトウェアテスト技法練習帳で取り扱っていないテスト技法の問題や、テスト技法以外の問題についても実際の試験をイメージしながら勉強できます。レビューに関する問題はかなりイメージを掴みやすいのではないでしょうか。
長文の問題については"実際の試験はもっと長いぞ"ということだけ頭の片隅に入れておくと良いかもしれません。
以上三種の神器のご紹介でしたが、クラシフィケーションツリーについてはカバーしきれていませんので、↓の資料を参照されると良いと思います。勝手に紹介していますが、非常に読みやすくわかりやすいスライドです。
クラシフィケーション・ツリー法入門 from H Iseri
③ その他のコト
3時間の長丁場とはいえ、試験のボリュームを考えると余裕があるわけではありません。実際今回の試験では終わった時点で残り15分でした。
長文問題が6割以上を占める(たぶん)のですが、問題文を全て読んでいると時間に追われてしまうかもしれません。
読み方はヒトソレゾレですが、時間がないときに問題文を読むコツとしては
① 冒頭部分を読む
② 問われていること(最後の部分)を確認する
③ ②に直接関連しそうなところを確認する
が良いのではないかと思います。
これで答えにたどり着ければ良いですし、たどり着けない場合はもう少し本文を読んで置かれている状況を把握すると良いと思います。
また問題は終わったら回収されますが、遠慮せず思いっきり汚してしまいましょう。僕は大事そうな箇所にアンダーラインや★マークを書いたり、"ふりかえりをしたら課題が～"みたいな問題文に対して"すばらしい！"とか書いたりしてました。
"あなたは〇〇なプロジェクトの〇〇に参画し～"のような問題が多いので、いろんなプロジェクトを股にかけるさすらいのテスターのような気分で問題を楽しんでしまうと集中力も維持できると思います。
あと単純な制約のないペアワイズで、テストケースが最小でいくつになるか…は知っておくと良いと思います。下記のような場合です。
デジタルカメラの各設定値の組み合わせをペアワイズで導出すると、何ケースになるでしょうか。組み合わせる因子(設定)と水準(設定値)は以下のとおりです。
画質：Standard,Fine,ExtraFine
シャッタースピード：AUTO,1/160,1/800,1/1600
絞り：AUTO,F1.8,F,3.2,F11
知っていれば瞬殺で、知らなければ組み合わせを手で書いてみることになると思うので、こういったところにあまり時間をかけないようにできると他の問題に時間をかけられますよね。
(そしてここから制約が増えるとテストケース数は減る？増える？変わらない？)
最後に、迷った時は"日々の業務で同じ場面に直面したら、自分ならどうするか？"を考えましょう。Advanced Levelは業務経験が3年以上ないと受験できませんが、実務と直結した形で考えられる人を対象にしているからではないかな…と勝手に想像しています。自分で自信を持ってステークホルダ(上司だったりお客様だったり…)に説明できる回答を選べば、悔いは残らないかと思います。
あとがき
僕は東京会場で受験しましたが、今回はコロナ対策の一環として座席間隔が広く空けられていました。長机1台すべてあなたのもの状態です。
3時間同じ場所に人が集まるので感染リスクを抑える点でもありがたいのですが、なにより前後左右の近い位置に人がいないのは集中力マシマシでした。
他にも当日の体調管理シート提出の徹底や非接触の体温測定など、色々と配慮された上で受験させていただき、運営されている皆様には感謝感謝です。
次回はおそらく1年後の2月になると思いますが、テストアナリスト試験に挑む皆様は是非合格を勝ち取ってください。
また8月21日(土)に予定されているTest Manager試験を受験される方も応援しています。(過去に合格したテストマネージャーの話はこちら↓)
moyashinomegane.hatenablog.com
ゴリゴリ書いてみましたが、またなにか思い出したり書き残したいことが出てきたら更新したいと思います。なお検索すれば僕よりもっと詳しくて読みやすくて役に立つ記事がたくさん見つかりますので、是非他の方の記事も読んでいただければばばば。
ここまで読んでいただき、ありがとうございました。
WAMMIのWはWebsiteのW！
SESテスターとコロナとリモートと
久々のブログ更新となりました。
本日↓のZoomイベントに参加することもあり、コロナとどう付き合ってきたか…を整理してみる記事です。
ザックリですが2月～5月の状況と、リモートワークの良い点と悩んでる点を書いていきます。
ちなみにブログの更新が滞る理由は下記の通り…うーん。
・単純にネタがない
・妻が家にいる時間が多いので書きづらい
・Switchに夢中(森、リングフィット、スマブラ)
・自社勉強会の準備
自己紹介(?)
僕はSES企業にテスターとして在籍しており、現在はSIerに客先常駐しています。通常であれば片道1時間ほどかけて、山手線沿線まで通勤しています。
あるモノと接続して使用するスマホアプリの結合(統合)～システムテストを担当しており、2年以上同じメンバーと仕事ができている状況です。感謝感謝。
2月～
あのダイヤモンド・プリンセス号がニュースを騒がせていた時期です。
職場でも話題にはなるもののまだ危機感は薄く、リモートワークの"リ"の字も聞こえてこない状況です。危機感持った人は個人で常にマスクを着用してる程度の状況で、僕自身はノーガードでした。
仕事にも影響は特になく、なんら変わらぬ感じで仕事していましたね。
3月～
この頃から職場でも"おいおいヤベェだろコレ"な空気感が出てきます。報道番組での盛り上がり方と比例していたようなイメージですね。
とはいえ皆きっちり出勤…休業指示もリモートワーク指示もないので当然ですね。SIerにありがちな"密"なオフィスでもくもくと仕事に取り組みます。僕もその中の一人。
…しかしながら家庭内では一悶着が。妻にこう言われます。
「もう渋〇には行かないで欲しい。行くくらいなら仕事辞めたほうがいいよ。」
はい、ごもっともです。月末頃にはテレビで↓のような報道が良くされていましたからね…。
仕事に熱もプライドも人並みに持っているつもりですが、"その仕事に命をかけますか？"と言われたらNoです。自分の命だけならまだしも、"ウイルスをばらまく=他人の命を奪うかもしれない"と考えたらもうね。どうしようもないですよね。リスクベースドですね。(テストっぽいことも書かなきゃという使命感)
しかしながら仕事はあるし、同じ勤務先にいる自社の仲間にも迷惑はかけられません。ここで"リモートワークしたい！"となるわけですが、
・クライアント(発注側)がリモートNGの姿勢
(機材を家に持ち帰ることも当然NG)
・リモートでやる準備(環境)が常駐先にまだない
といった理由でリモートワークは叶わず。家庭と仕事のサンドイッチな状態で悶々と仕事をしていましたが、ここで"可能な限り出勤日を減らそう！"という発想になりました。家での事情を自社と常駐先には伝え、"出勤する日はガッツリ働いて、可能な限り休ませてください！"という相談をしたところ、快くOKしてくれました。
常駐先は"やることやってくれれば問題ない"という回答をいただき、自社には"たとえそれで勤務時間が減って、売上が落ちたとしても大丈夫だから気にしないでくれ！"との回答が。いい会社(人)と仕事してたんだな…とちょっと感動しました。
こうして3月末頃からは週3勤務ペースで出勤する日々となりました。
4月～
常駐先ではついに"オフィス内マスク着用必須"となります。今更かい！と思うかもしれませんが、マスクの品薄はこの頃がピークだったことを考えると仕方なかったと思います(転売もひどかった)。会社としてマスクを確保して、手に入れることができない人には配布していました。
僕は変わらず週3ペースで出勤していたのですが、中頃に変化が訪れます。
リモートワーク解禁！
リモートNGの姿勢だったクライアントと話をまとめていただき、家庭のPCから"VPN経由で常駐先のPCにリモートデスクトップで接続※"するのはOKになりました。
とはいえ機材関連の持ち出しは相変わらずNGなので、あるモノと接続するスマホアプリのテストをしている都合上、家でできることは限られています。"家でできる仕事"と"家でできない仕事"を分けつつ、必要に応じて出勤とリモートを使い分ける日々になりました。
※ちなみにWindows10標準のリモートデスクトップを利用していますが、動作が警戒かと言われると……ですね。
チームのコミュニケーションにはTeams(web会議用)とSlack(ワイワイ用)を利用しています。
5月~
前述の通り、出勤とリモートを使い分ける日々が続いています。おおよそ半々の割合でしょうか。
通勤となった場合でも電車は以前より空いていて、オフィスも人がまばらなので3月以前よりは遥かに良い環境になったと思います。
以下、良いところと悩みを書きます。
リモートワークの良いところ
・コロナ感染リスクの低下
これがリモートワークの主目的ですから！
・通勤時間がない
このメリットはやっぱり大きいですよね。家事が捗るし、睡眠も増える。
・音が大きいお菓子が食べられる
音が出にくいチョコ系お菓子が中心でしたが、ばかうけや浅漬けも食べれる！My急須でお茶を淹れられるところもGood
・歌える
たまに歌いだしたいときありません…？
リモートワークの悩み
・他のメンバーにトコトコ近づいて話ができない
テストしていて、ちょっとした気づきや"キタコレ！"な不具合を検出したとき、やっぱり話したいんですよね。特にキタコレ不具合を検出したときは、すぐにｷｬｯｷｬしたいんですよ(バグの鮮度を重視…とでも言いましょうか)。
こういうところにテストの楽しさを感じてたんだな…とリモートが増えて少し感じています。
・環境面
リモートデスクトップでの作業になるので、モッサリ感は拭えず。また常駐先ではモニター2枚をベストポジションに配置しているのですが、家のPCはノーパソの画面1枚なので少々つらいですね。よく言われていますが、椅子の質も影響あり…。
・いつでも仕事できちゃう
"あーこれはもう夕飯食べてからやろう！"という発想が生まれてしまうんですよね(そしてやってしまう)。これは自分の中でコントロールすべき課題です。寝る前に"あ、あれが漏れてるんじゃないか！？"みたいなこと閃いちゃった時も同様。
・日が浅いメンバーのコミュニケーション面
僕は2年以上同じプロジェクトに携わっているのである程度プロジェクト内のコミュニケーションは醸成されているのですが、参画して間もないメンバーはコミュニケーションがストレスになったりするんじゃないかと思います。また"成果を出さなきゃ"のプレッシャーも相当あるんじゃないかなと思ってます。
顔合わせて長い間やってきたからこそ、離れていてもコミュニケーションを取りやすいし信頼もある＝リモートでもある程度うまくいく…はありますよね。今年度入社の新入社員なんかはメンタル大丈夫だろうか…。
・集中力の維持
家で一人の時は特に変わりませんが、妻が家にいるとなるとちょっと乱れます。なんかちょっと見栄を張りたい気持ちがあるのかもしれません。
小さなお子さんや、親と一緒に暮らしている方はうまくやれているのでしょうか。
…ざっくりと思うがままに書いてみました。
リモートワーカー(?)としてはヒヨッコなので、今後は良い対策やアイデアをどんどん仕入れていきたいと思います。特にリモートワークの良いところはどんどん知りたいですね。
2000円のデコポンとソフトウェアテスト
え～、JSTQB Advanced Level テストアナリスト試験に落ちました。以前の記事は"あ、落ちたやつが書いた記事だ！"くらいの感覚で見ていただけると多少救われます。。。
発表があったのは3月26日なんですが、その帰りに励ましスイーツを買いました。タイトルに書きました2000円のデコポンです。自宅近くのスーパーでは1個200円で売っているので10倍の銭闘力をお持ちでらっしゃいます。
このデコポン、ホワイトデーのプレゼントで親戚に送ったところ絶賛してもらえたので自分でも食べてみたかったんです。
"めっちゃ甘いんだろうな～"程度の気持ちで買ってみたんですが、まぁ素晴らしいこと素晴らしいこと。比較用に1個200円のデコポンも買って食べ比べしたんですが…
- 皮の色と艶
- サイズ
- 重み
- 水分量
- 皮の剥きやすさ
- 香り
- エグ味のなさ
- 袋の歯切れ
といった部分が明らかに違う…っ！普段カンヅメのみかんにサイダーかけてｷｬｯｷｬできる僕は感動を覚えるのでした。
…で？それがどうした？という話なんですが、今回僕は"めっちゃ甘いんだろうな～"という期待に対して2000円支払ったワケです。でもそれ以外に素晴らしい点が何個もあって、それが感動に繋がったんですね。
コレ、食品に限らず家具でも服でも…そしてソフトウェアでも同じですよね。自分がお金を払った部分というのはもちろん一番大事なんですが、それ以外の部分が優れていると満足度は格段に上がると思います。そんな経験ありますよね？
ガラケー全盛の時代を生きてきた自分の経験で例えると、動きのサクサク感だとか直感的なメニュー階層だとか…広末涼子や藤原紀香が表紙のカタログには載ってない部分です。(個人的にはソニーエリクソンが素晴らしかったなぁと)
あまり詳しくないですが、これがUX(ユーザーエクスペリエンス)というものなのでしょう。ソフトウェアをテストする側の立場としては、要求や仕様に合致しているだけでなく"ココもうちょっとこーしたら良くない？"とか"こうだったらいいのにな"の気持ちを大切にすべきなんだろうなと思うワケです。そしてこれを一番感じ取れるのは、テスターのポジションにいる人たちではないでしょうか。
もちろん限られた時間の中でテストするのが至上命題なので、難しい部分はあるでしょう。また話に出したデコポンは普通にものと比べて10倍も高いワケですから、素晴らしいのは当然と言えば当然なのかもしれません。ソフトウェアだってお金(人)をたくさん使えば、そうでないものよりは良いものができることでしょう。(じゃあ価格を上げちゃえ！なんてことはそーそーありません)
もしすべての要求に応えたソフトウェアが開発できたとして、それがエンドユーザーにとって価値がないものだったら…それはもうある意味"バグ"なのかもしれません。ユーザーにとって価値(感動)を作るテストエンジニアになりたいなと思ったデコポンイーターでした。
(…でも現実は色々厳しいよね！)
偽陽性を懼れるふるさと
先日こちらの記事読みまして、素晴らしいことが太字で書いてありました。
偽陽性であることを懼れずに遠慮なく不具合票を挙げるべきです。
(もちろん僕も太字で引用)
note.comこんなビッグな方の記事を勝手に貼って良いのだろうか？…と思いつつも貼っちゃいます。僕らのバイブル"ソフトウェアテスト技法ドリル"は大好評発売中です()
さてテストのおける"偽陽性"がなにかは是非上記の記事を読んでいただきたいのですが、以下これより実体験に基づくフィクション(?)でお送りします。
～～～
Once upon a time... SES企業に勤める僕はとある組込系ソフトウェア開発プロジェクトに参画し、日々テストにいそしんでいました。
そこは独立性の高い組織によるテストを重視しており、複数の組織(企業)で競い合わせるように探索的テストを実施する文化がありました。
そしてそこには厳しい掟があったのです。
・同件は決して挙げるべからず
・制約事項は指摘するべからず
・仕様書に記載されていることを質問するべからず
・指摘する根拠を明確に述べよ
～～～
…ん？"全部あたりまえじゃないですか！"と思ったソコのアナタ。そうですその通りです。仮にこれらを守らない場合、デバッグしていただく開発の方々に余計な工数が発生したりするわけですから。
また掟が厳しめになる理由として、組織同士で競い合っているがために"有効なバグの報告数"と"却下されたバグの報告数"が定量的に評価できる適当な値であることも挙げられます。(もちろん各個人の評価も)
こういった環境に問題があるかと言われるとそうではなく、問題はこの掟を守らない人を強めに咎める一部のメンバーの存在です。
ねちっこく"なんで？どうして？"で責められるのはともかく、メンバー間の笑い種にするような空気がそこにはありました。(酒の席なんかではまーひどいひどい…)
こうなってしまうと経験の浅い方やメンタル的に少し打たれ弱い方は、インシデントの報告に非常に慎重になってきます。"偽陽性＝恥"ということが頭にインプットされてしまうワケですね。特に性能面やユーザビリティ観点の報告数というのは極端に減ってしまいます。
以下個人的な意見になりますが、僕も偽陽性は懼れずにドンドン報告をすべきだと思います。仮に偽陽性の報告があったとして、それは全くの無駄ではありません。むしろプロジェクトの改善につながるヒントになるものだと思っています。仕様書が誤解を招くような記載になっていないか…暗黙知が盛りだくさんになっていないか…などなど...。(もちろんトンでもない報告はアレですが)
少なくとも"ああ、これは勘違いしても仕方がないな"と思える偽陽性な報告は優しく受け止め、また質問＆相談しやすい環境づくりも大切なことと思います。そして質問＆相談に答えた側がキチンと評価される世界が理想です。(これが評価されないと、工数的な負担が不満につながることもあるので)
優れたテスターの要素の一つとして、アウトプットが多い人であることは非常に重要だと思います。(去年のJaSST Tokyoでこのことをどなたか仰っていて、とても共感しました)偽陽性報告を懼れ、アウトプットが減り、精神的にもあまり良い状態でなくなってしまったとしたら、なんだかもったいないですよね。ソフトウェアテスト界としても損失になってしまいます。(少し大げさでしょうか)
テストの世界に飛び込むキッカケや、それまでの生い立ちは人それそれです。飛び込んできてくれた人のサイダネ(古い！？)が芽を出せる環境づくりを、僕は心がけていきたいと思います。そして僕がテストの仕事をここまでやれてきているのは、周りに恵まれている面も大いにあるハズなので、改めて感謝したいです。
僕は文章の最後に()を付けることが多いなと思いつつ、この記事を〆ます。
JSTQB Advanced Level テストマネージャー のはなし
過去2回書いた記事で、一人称が"僕"だったり"私"だったりしていることに気づきました。
ので、今後は"僕"で統一していこうと思う所存…。
～～～～～
JSTQB AL TMは1回落ちて、2回目で合格しました。
合格の秘訣は「1回受けて慣れれば2回目はイケますよ！」と言いたいところですが、受験料が高い(22,000円)上、1年に1回ということを考えると得策ではありません。
ので、自身の経験からアドバイスできることを書き留めておきたいと思います。次回受験される方に少しでもお役に立てば幸いです。
出題内容について
JSTQBのポリシーとして"出題された問題を公表してはならない"ことになっているため詳しい話はできませんが、一大テーマとして挙げられるのは"リスクベースドテスト"です。もちろん出題範囲はこれだけではありませんが、リスクベースドテストに関する知識は必須かと思います。
シラバスにもリスクベースドテストに関する記載はありますが、取っ掛かりとして非常にわかりやすいと思った資料はコチラ↓(勝手に紹介して良いのだろうか？)
リスクベースドテストを活用しよう from H Iseri
www.slideshare.netこの他にもWACATE様(様？)の資料は色々と無償公開されていて、本当に頭が下がります。WACATEには一度ぜひ参加してみたいと思っています。(次回開催される5月末までにコロナ静まらないかな…)
他、メンバー編成の構築や底上げ(Aさんになにを勉強してもらうとプロジェクト的にGoodか…的な)や、工数を計算する問題もあったりしますが、この辺については特に意識して勉強せずとも問題文をしっかり捉えられればわかるレベルじゃないかな…と思います。
試験当日の話
1回目の受験で失敗したのは 集中力が維持できなかった コレに尽きます。ではナゼ集中力が維持できなかったか、失敗した点を紹介します
①会場が寒かった。
試験は真夏(8月末頃)に行われるためかなり暑い日になるのですが、試験会場は冷房がシッカリ効いています。試験は3時間と長丁場なので、普段から冷房が苦手な方は防寒対策用の上着を持っていくことをお勧めします。
僕は1回目の試験ではキンキンに体を冷やされたため、2回目は着慣れたパーカーを持って臨みました。
◆追記(Twitterで@____rina____さんより耳寄り情報)
会場によっては空調を調節していただけるそうな…？ツライ時は我慢しない方がいいですね！
②トイレとの格闘
1回目の受験時、電車遅延等を恐れた僕はかなり早く会場付近に着きました。頭を早く覚醒させようと、
家を出る前にレッドブルを1本
近くのマックで朝マックwithコーラ
を摂取して試験に臨んだワケですが…はい、カフェイン採りすぎですね。試験開始前にトイレは済ませていたものの、開始から1時間半くらいで尿意と格闘することになりました。前述の寒さとのシナジーもあり、集中力はかなりサゲリシャスな状態となってしまいました。
2回目は反省を踏まえ、水分補給は少量の"水"で済ませています。
(余談ですが、1回目の受験では近くにゲ〇プを繰り返す方がいたり、スマホを鳴り響かせる方がいたり、僕の集中力を削ぐ刺客が多く送り込まれておりました…ぐぬぬ)
◆追記
トイレは手を挙げて申告すれば試験中でも行けます。(僕は時間に余裕がなくて、トイレに行く時間すら惜しんだ民という話です;)
③見直し
試験問題の6割強は文章問題となっています。1回目の受験では答えがすぐに出せない問題に対して"あとでもう1回考えよう"と飛ばして進めていたのですが、結果的に時間が足りなくなってしまいました。(僕の処理速度が遅いせいもあるとは思います)
そこで、2回目の受験では"一度読んでしまった問題は1回で答えを出す"スタイルに変更して臨みました。つまり基本的に見直しをしない作戦です。(最後にマークシートが正しく塗れているか程度は確認します)
文章問題を飛ばした後、再度読み直すのはスタミナを消耗します。なので、その世界に一度入ったら答えを出してしまう方が僕には合っていました。問題用紙も60ページくらいあるので、戻るのも結構大変です。
なお1回目の受験では"回答の選択肢に誤りがあったため、当該問題を全員正解扱いにします"という問題がありました。つまり考えても答えの出ない問題が出題される可能性もあるので注意しましょう。
余談
余談にはなりますが、日々の業務の中で"マネージメントされている方"の動きを意識して見ると勉強になることがあります。
ALの受験には"実務経験3年以上"という条件があるのですが、僕はマネージャーでもなければマネジメント経験なんてありませんでした(サブリーダーレベル)。身近の先輩方から見て学び、時には疑問に思うことを質問してみるのもいいかもしれません。今ではTwitterでつぶやくなんていうのもいいかも？
～～～～～
思いついたままに書きましたが、技術面については一切書けてないですね…。いずれ技術的な部分も語れるようになりたいなと思います。
