サクッとできそうだったので、作った。
リポジトリを確認してもらえればわかるが、特に難しいこと、複雑なことはなく作れたのでよかった。
質問等あれば@hideshis_qaまでどうぞ。
参考文献:
大学院に行くの、どんな動機でもいいんですよ。研究者になりたい、モラトリアム、仕事で行き詰まってる、キャリアアップしたい、働いてて感じた問題意識を深めたい、カルチャーセンター感覚、趣味の延長…どの動機でも、学問はきっと楽しい。分野が盛り上がれば嬉しい。
— 森 薫 | Kaoru MORI❄️📚🦖 (@mori_irom) 2022年1月13日
こんなツイートを見かけた。
これは自分も同意で、いろいろな理由があって良いと思う。
ちなみに自分は、正直なところ「就職が楽になるかな」「もうちょっとだけ研究してみたいな」という理由で大学院に進学した。
が、そこでは良い出会いがたくさんあった。
優秀な先輩、先生に出会うことができた。世の中には様々な人がいて、自分はちっぽけな存在なんだな、何も知らないんだな、と理解することができた。留学生や社会人学生との出会いも、今の人付き合いに生きていると思うし、今でもお世話になっている方がいる。この方々との出会いがなければ、僕の人生は全然違ったものになっていたと思う。
ソフトウェア工学に出会うことができた。厳密にいうと、高専在学中のテーマもソフトウェア工学ではあったのだが、当時はそのごく一部(ソフトウェアセキュリティ)しかしらなかった。大学院では、ソフトウェア工学のテーマとしてレビュー、人材教育、ビジュアライゼーション、バグローカリゼーション、コードクローン、優秀なプログラマの特徴分析、OSSなど、様々な研究に出会うことができた。自分が生業としているテストとも大学院で出会った。僕は、大学院に進んでいなければQAエンジニアをしていなかった可能性は大きいと思う。少し極端にいえば、キャリアの方向性が決まったのは大学院だということになる。
そんなかんじで、割とフワフワした理由で大学院に進んだものの、そこで得た経験、出会い、知識は膨大なもので、自分のキャリア観、ひいては人生観に多大な影響を今でも与えている。何かの分野に興味がある人にはもちろんおすすめだし、何に興味があるかいまいちわからない、でも何かがしたい、という人も一度検討してみると良いと思う。出身校では年に2−3度オープンキャンパスがあり、研究のポスターを展示したり学生や先生と話す機会があったので、活用してみると良いと思う。
大胆な変更も安心できる
一連のシナリオを実行するテストを書けば、何度でも使えるので、そのシナリオ中に関連するコードを変更する際にリグレッションテストとして機能します。 問診のフローはかなり複雑に関連しあっているので、これまでは変更にかなり慎重に取り組まなければなりませんでしたが、テストが増えていくにつれて大胆な変更が可能になりました。
ユーザーに届く前に品質を担保されている状態とはなにかを考えるとリリース前に客観的に「これは品質が高い!」といえる状態だと考えた。客観的に品質が高いと言えれば開発者は安心してリリースすることが出来る。
最近気づいたことであるが、自動テストには「開発者に安心感を与える」という効果があるらしい。
前職ではAPIテストを書いていたが、ここでも「早めにバグを検出できると安心できる」といった声を聞いたし、「何かを変更するときにあらかじめ自動テストが用意されていると安心して開発できる」といった声を聞いたこともある。
自動テストといえば、
といった目的が挙げられがちだが、こういった側面もあるのか、と目から鱗が落ちた。
たとえば、機能Aの改修を行うことがわかっている場合に、予め機能Aに対してAPIテストなりE2Eテストなりを整備しておくことで、開発者は十分な安心感を持って改修に臨めるようになるのではないか、と思った。
このとき、「開発者に与えた安心感」「安心感を得られたことにより向上した生産性」を定量的に測定するのは少々難しいのかもしれないが(ググってもそれらしい情報は出てこなかった)、しかしやってみる価値はあるかもしれない。もし知っている方がいれば@hideshis_qaまで連絡していただけると嬉しい。
Yahooの社員は、日本国内であればどこでも住むことができるようになるみたいで、とても素晴らしい。
ふと思ったが、QAエンジニアの場合は検証端末の確保どうするんだろうと思ってしまった。
Yahooってモバイル端末アプリ作ってたと思うけど、検証端末のやりとりって郵送でやるんだろうか。それとも出社して検証するんだろうか。
以前いた職場では、出社して検証する方式であったり、端末-テスターを完全に結びつけて、当該端末で検証したいときにはそのテスターに依頼する運用であったり、会社によって異なっていた気がする。
個人的には、こういう素晴らしい制度が出来上がったのだから、郵送でやり取りする運用であって欲しいと思う(そうでないとメリットが減ってしまう)。
まぁそういった場合、「この端末誰が所有していますか」といった端末管理の課題が浮かんできそうだが、それはうまいこと解決していきたい。
自宅で仕事できるのはメリット大きいが、自分は週に2回くらい出社する方がメリハリがつくタイプだと思っているので、多分地方に引っ越したりはしない(できない)んだろうなぁ。
毎営業日自宅で仕事するのも結構しんどいので、会社がコワーキングスペースとかレンタルオフィスとかを大量に借りてくれるといろいろな場所で働けて楽しそう。
しっかし
— 雪山雪乃介 (@yukiyama2003) 2022年1月8日
NoCodeって流行ってるけどサービス終わったらどうする気なんだろ
こんなツイートを見かけた。
これは、自分も同じことを感じている。
テスト界隈だとAutifyやMagicPodといったサービスがあり、非常に好評なのだが、企業である以上サービスを終了する可能性があるわけで、サービスが終了した途端に運用しているテストがポシャってしまう、、ということになるのではと少々心配している(心配しすぎかもしれない)。
じゃぁOSSが完全に安心であるかというとそう言うわけでもないので悩ましい:
ただ、OSSは開発が止まったり変に改ざんされたりしても、リポジトリが残っている限りは前のバージョンを使えば何とかなる、という点では安心できる。
個人的には、ノーコード/ローコードツールを使うよりもOSSを使う方が自由度が高く、無料だし、サービス終了の心配をしなくて良いので嬉しいと思っている。
ただ、ノーコード/ローコードツールには学習・運用コストの低減という大きなメリットがあるし、たとえばコードが書けない人でもテスト自動化ができるようになるので、このメリットが甚だ大きいのも事実。
なので、基本的にはOSSを利用し、限界を感じたらその部分だけノーコード/ローコードツールに頼るという運用はありだと思う。
プロダクト開発にmablを導入しました、という発表資料。
自分はmabl使ったことがないので興味があり読んでみた。
SaaS使う上で、学習コストどうなんですか、と考えてしまうんだが、mablに関してはコスト少なめなようで素晴らしいと思った。
一方で、idやnameが付与されていない要素は記録通りに動かないこともあるようで、制約としてはちょっと厳しいかも、と感じた。
自動テストのSaaSが普及した結果、SETはどうなってしまうんだろうと思うこともあるが、コンサル的な役割にシフトしていくかもしれない。知識とノウハウを提供する形、相談役的な役回り。あるいはテスト自動化のマネジメント。
(個人的にはコード書けるに越したことはないと思うんだが)コード書けないQAエンジニアでも自動化を実施できるのは素敵なことだと思うし、こういったSaaSがもっと発展すると良いと思う。
一方で、テスト実行環境の整備、テストデータの自動注入、E2E以外の自動テスト、その他QAタスクの自動化など、SETが活躍する場もしばらくは残っていきそう。
ふと、PROGRIT CAREER for エンジニアというサービスがあるのを思い出した。
これは、エンジニア向けに英語教育を提供し、その後プログリット経由で転職すれば受講料を返還する、、というサービス。ただし、残念ながらサービスは終了してしまっている。
自分は今まで日系ベンチャー、日系大手、グローバル企業、フリーランスと渡り歩いてきたが、英語で会話することが求められたのは、一部のベンチャーとグローバル企業だけだった。その他の企業では、
といった具合だった。また、リモートワークの普及もあり、口頭での会話よりもチャットによるテキストのやり取りの比率が高くなりつつある。そのため、英語を喋る機会は限定されてきていると感じている。
どちらかというと、エンジニアにとってはスピーキングよりもリーディングの方が大事で、それはなぜかというと技術のキャッチアップをしなくてはならないからである。
が、これもDeepLやGoolge翻訳といった機械翻訳により解消されつつある(前述のチャットコミュニケーションもそう)。
さらに、自分が観察している限り、機械翻訳に希望を見出し英語学習のモチベーションが低下しているエンジニアも少なくない。
そのため、英会話を学習したいと思うエンジニアのモチベーションは
という感じになりそうで、商機を見出すのは若干厳しい時代かもしれない、と思った。