Visual Regression Testing便利そう
Visual Regression Testing（VRT）、今まで使ったことなかったけど便利そう。
そもそもなんで今まで使わなかったかといえば、WebElementやテキストの存在確認だけでニーズを満たせていたから。
ただ、リファクタリングや改修を行う際には必要になるんだろうな、と思い始めた。
デザインが意図せず変わっていないことを目視で確認するの、かなり大変な作業だと思うので、、
不具合を検出する以外にも、開発者に安心感を与える効果もあるみたい。
ただ、画像がちょっと変化すると（例えばWebページ内の日付が変わったりすると）、比較したい部分が一致していても失敗してしまうのでは、、という心配もあるので、調べたりトライしたりしながらやってみたい。
品質を高める活動について
「ATDD（受け入れテスト駆動開発）で『テストフェーズ』を限りなくゼロに近づけたい」株式会社SmartHR 泰楽 無雅氏 より引用
夢としては、現実問題として、ゼロにはできないと思いますがテストフェーズをなくしたいと思っています。そして、テスト専任やテストメインのQAをなくしたいイメージを持っています。やはり、QAでテスティングはあくまでひとつの手段だと思うので、それ以外の領域で活躍できる場を広げていきたいと考えています。そういう意味でのテストを減らしていきたいですね。
これまで、QAやテストで品質を保証する考え方がされてきました。しかし一方でアジャイルのような開発ではチームとして品質を捉え、向き合うように見方が変わってきています。QAだけがテストをするのではなく、チーム全体としてテストの重要性を理解するテスト文化を根付かせ、QAの活動領域を広げていくことが大切になっていくと考えています。
（中略）
テストの領域でやり方を変えてもエンジニアには影響が少ないので抵抗がなく、開発と並行できます。そのようにしてゴリゴリと進めていき、エンジニアに対してレビューをお願いしたり、実装とつき合わせたり要件とつき合わせたりしていきました。このようにすると、エンジニアにもテストの意識が生まれ、ソフトウェアテスト全体の効率化にも繋がっていくと考えています。
QAの責任は重い。だから楽しい より引用
柿崎さんがGAに入社したのは2018年だ。当時からプロダクトの品質向上は命題だったという。お客さまに提供するサービスの全ての品質を極限まで高める、というのがGAの目指すものだ。気持ち良く製品を使ってもらい、満足してもらうこと、それをGAの全てのメンバーが目指している。QAチームも、プロダクトの品質を究めるべく切磋琢磨（せっさたくま）している。
（中略）
QAは開発にブレーキをかけることになるため、普通の会社なら煙たがられる存在かもしれない。しかし、GAにはそういうことが一切ない。QAチームとして、その環境は非常に恵まれていると感じつつも、柿崎さんはその責任の重さも痛感している。
「自分のひと言で、品質を高める行為が一気に走りだします。だから言葉の責任は重い。『ここまずいよ』という指摘をする際には、情報の裏付けをしっかりしなければなりません。そういった強い責任を、QAエンジニアとして感じています」
最近のQA界隈では、QAがテストの枠を超えて活動したり、エンジニアと協力して品質を高める活動をしたり、という行動がどんどん湧き上がっているように感じる。
SmartHRもGA technologiesも、テストに閉じた活動はしない、という点で共通しているように思えた。
僕もこの考え方には賛成で、品質を良くしていくには、品質を作り込む活動に足を踏み入れる必要があると思っている。テストはあくまで品質を測定する活動であり、品質をよくするためには品質が作り込まれるフェーズ（仕様検討や実装）に手を加える必要がある。そのためには、テストの知識ももちろん必要だし、エンジニアやPdMといった他職種のメンバーとの関わり方も重要になる。QAだけで品質を高めることはできないので、品質を高めることがいかに大切であるか、という文化づくりもしなくてはならない。
以前、誰かが言っていた「今後のQAはコンサル的な立場になる」というのも、コレを指しているのかもしれない。テスターとして手を動かすだけでなく、品質を高めるための相談役として動き、PdMやエンジニアと共に品質をリードする立場になるのかもしれない。
同じテーマの本を複数冊読むことについて
テスト自動化エンジニア界隈を見ていると、Dockerを動作基盤としてE2Eテスト構築しました、みたいな記事を時々読む。なんだか取り残されているようで不安を感じたので、自分もDockerの勉強をすることにした。
Docker、というかインフラの知識に乏しく、入門書を２冊買った。なぜ２冊買ったかというと、複数の視点から解説を読むことで理解度が深まると思ったからだ。
同じ入門書と言っても、筆者によって微妙に本の構成や表現が異なっていたりする。１冊だけでは理解できなかったことも、２冊めを読むと急に理解できたりする。
たとえば今回の場合だと、「たった1日で基本が身に付く！Docker/Kubernetes超入門」を１冊目として読んだ。この本は、とにかくまず動かしてみよう、解説はそれからやります、みたいなスタンスで書かれており、とりあえずDockerというものが何やら動くらしいというところまでは行くことができた。ただ、Dockerの仕組みやコマンドのオプションに関する説明はやや乏しいように感じた。そこで２冊目として「仕組みと使い方がわかる Docker＆Kubernetesのきほんのきほん」を読んだ。この本は、手を動かす内容はほどほどだが、解説がしっかりしている。イラスト付きだし、平易な表現で初心者にも非常にわかりやすい。おかげで、１冊目で手を動かして体で覚えつつ、理解が追いつかなかった部分を２冊目で補完する、という学習をすることができた。
ちょっとお金はかかるが、同じテーマについて書かれた本を複数冊読むのは効果的な学習法であるらしいと気づくことができた。今後新しいものを勉強するときにも活かしていきたい。
受動的なエンジニアを変えるには
面白い研究テーマだと思ったので、つい読んでしまった。
僕は、受動的な業務態度が必ずしも悪いことだとは思っていない。受動的であっても言われた仕事を愚直にこなし続けることのできるタイプの人というのはいて、実は結構リスペクトしていたりする。だが、現場の悩みとして能動的な人が増えてほしい、というのも現実的にあるんだろうと思う。
今回の研究で提案されているCLDATは、筋が通っていてわかりやすい手法だと思った。能動的エンジニアと受動的エンジニアの違いを明らかにできたという点も素晴らしいと思う。受動的エンジニアは、「当事者意識を持って課題分析できない」という特徴があるらしく、まぁ確かに積極的な姿勢でないと難しいのかもしれないな、と感じた。研究では、エンジニアが受動的になってしまう要因についても調査がされており、興味のある方は読んでみるとよい。
ところで、これは野暮なツッコミなのかもしれないが、研究背景を読んでいると、
- リーダーから確認されるまで進捗遅れを報告しない
- メンバーが自ら不明確な箇所を解消しようとせず、放置する
- リーダーに促されるまで検出した障害の報告をしない
という行動特性を持つ人が「受動的なエンジニア」と表現されているのだが、これは受動的か能動的か、というよりももっと別の問題なのでは、という気もした（受動的であっても、言われたことをしっかりこなす人なら問題を放置したりしないと思う）。
いずれにせよ、現場のリアルな課題に向き合っている良いテーマだと思った。今回は受動的な人を能動的に変化することによってリーダーの悩みを解決するものであったが、今後の展開としては「受動的な人をいかに動かすか」というリーダー目線の研究があってもよさそうだと感じた。
俺の屍を越えてゆけ
わかりみが深くて辛い気持ちになった。
自分も似たような経験をしたことがある（闇的な意味で）。
新卒の頃、何も考えず新旧機能とわず自動化しまくっていたら、メンテナンスコストが爆上がりし、失敗原因調査とメンテナンスだけで１日が潰れる時期があった。「自動テストは少しずつ実装・運用しながら増やすのが良いんだな」と学ぶことができるよい機会であった。
枯れた機能のテストを自動化する場合はともかくとして、新しい機能のテストを自動化する際にはタイミングに気をつけたほうがいい。僕だったら、機能がリリースされた直後くらいから実装を始めると思う。新しい機能なので細かい改修は都度入るだろうが、大枠は固まっていると思われるためだ（テスト設計まではリリースより前に済ませておくと、スムーズに実装を開始できると思う）。
あと、テスト自動化の経験が浅い場合は、最初は少人数から始めた方が安全そうだと感じた。経験の浅いエンジニアが大量に一斉にテスト自動化を始めると、実装方法がマズかったりメンテナンスコストを考慮できていなかったりして短期間で破綻してしまうような気がする。少人数の場合は、破綻するにしても手戻りコストは比較的小さくなるので、もうすこし安全というか確実に前進できそう。
それにしても、（自分も全く同じ経験をしているのでとやかくいえないが）テスト自動化系のスライドを見ると、みなさん大体同じような失敗をしているのだなと思う。テスト自動化のSaaSを開発するなら、この点に注目してみるとユーザーに喜ばれるかもしれない。
JaSST nano で発表した
開催２日前に、運営の１人であるるみおかんさんからお誘いがあり、英語の勉強法についてお話ししてきた。
自分が英語を勉強する理由を見つめ直す、良い機会になった。
スライドには書いていないが、英語ができることそのものよりも、英語を使う習慣があることで
- 英語の情報にアクセスしようという発想になる
- より多くの情報にリーチできるようになる。日本にはないタイプの品質保証の本に出会うとか
- 英語を使った活動をしようという発想になる
- 活動の幅が広がる。ISTQBの資格を取得するとか
ことが、英語を使える（≒英語を使う）メリットだと気づくことができた。正直な話、情報にリーチしてしまえば、あとはDeepLやGoogle Translateがなんとかしてくれるかもしれない。でも、そもそも英語を使わなければ、そういう情報に出会うこともできないのだ。これを言語化できたのは本当によかった。るみおかんさんには感謝である。
IT界隈には英語が苦手な人が多い印象があるが、国際化の波は避けられないし、さまざまなメリットがあるのは間違いないと思うので、少しずつでも勉強するとよいと思う。
ISTQB Gambling Industry Tester
ISTQBのWebサイトを眺めていたら、ちょっとユニークな資格を見つけたので、適当に翻訳してみる。
これは、ギャンブル産業を対象としたテストの資格っぽい。カジノ、オンラインカジノ、宝くじ、あとはスポーツとかレースの賭け事も対象になるっぽい。
＝＝＝ここから＝＝＝
オーディエンス：
The Foundation Level Gambling Industry Tester Specialist Certificateは、４タイプの専門家を対象としている：
- 伝統的な方法による詳細なテストの経験があり、Foundation Level Gambling Industry Tester Specialist Certificateを取得したい専門家
- Foundation Level certificateを持ち、ギャンブル産業におけるテスターの役割をより知りたいと考えている、Junior professional testers
- 比較的テスト経験が浅く、ギャンブル産業におけるテストのアプローチ、方法、技術を実装する必要のある専門家。この専門家には、テスター、テストアナリスト、テストエンジニア、テストコンサルタント、テストマネージャ、user acceptance testers、ソフトウェアデベロッパーといった役割の人々が含まれる。
- Foundation Level Gambling Industry Tester Specialist certificationはまた、ギャンブル産業におけるソフトウェアテストをより深く理解したい人々にも適している。例えばプロジェクトマネージャ、品質マネージャ、ソフトウェアデベロップメントマネージャ、ビジネスアナリスト、ITディレクター、マネジメントコンサルタントなど。
Business Outcomes：
the Foundation Level Gambling Industry Tester Specialist certificationを取得した者は、以下に記載するBusiness Objectivesを達成できる：
- ギャンブル産業で用いられる用語を用いた効果的で効率的なミュニケーション
- ギャンブル産業でテスト活動をするうえで必要な品質特性の理解
- ギャンブル産業における標準的なソフトウェア開発とテスト技法を説明することによる、典型的なテストプラクティスの理解
- ギャンブル用ハードウェアとソフトウェアの認定への理解（ギャンブル産業と他産業での主な違い）
- ギャンブル産業特有のニーズに合わせたテストを設計する際の、確立された技術の利用
- ギャンブル産業における、管轄区と規制当局の重要性の認識
一般的には、Certified Foundation Level Gambling Industry Tester Specialistにはギャンブル産業のテストチーム、環境で効果的に業務を遂行するために必要なスキルを習得していることが期待される
＝＝＝ここまで＝＝＝
日本だとパチンコ、スロット、競馬、競輪、競艇あたりがギャンブル産業となる。パチンコ、スロットは相次ぐ規制強化で市場規模が縮小しているものの、14兆円規模の市場がある（他のギャンブルも合わせると最大25兆円くらい）。
海外の市場規模はというと、多分シラバスに何らかの記載があると思うのだが、わざわざ専用の資格を作るくらいだから相当な規模なのだろう。日本でもカジノを誘致しようという話があり、実際にいくつかの日本企業（ユニバーサルとか）は海外でカジノ事業をやっているようなので、こちらの分野に興味がある方は資格を取得しておくと将来役に立つかもしれない。