# タイトルコール ようこそ、世界が広がるソフトウェア品質生。 このチャンネルでは、Qエンジニアのサミーが、 ソフトウェアテストやソフトウェアの品質保証を中心に、 日々奮闘していることや考えていることをお話しします。 毎日お昼の12時30分に配信しています。 ゲストの方やリスナーのあなたと、 テストや品質の世界を広げていきます。 # QAの仕事は広くて深い🌊 こんにちは。Q.Engineerのサミーです。 今回はQ.Engineerの仕事は、海のように広くて深いというお話をしようと思っています。 前半と後半に分けて、前半が広さの話、後半が深さの話ということで、 自分の感じていることを、考えていることをお話ししていきます。 まず最初に、Q.Engineerのお仕事って何だと思いますか? リグレッションテストを中心に、リグレッションテストの管理をする人なんでしょうか? テストベンダーの方の管理をしながら、テストの実行管理とかテストを管理していく人なんでしょうか? あるいはテスト自動化を推進する人なんでしょうか? あたまたテスト戦略やプロセス改善を推進する人なのか? それともプロジェクトに入って、テスト設計やテストの実行をする人なんでしょうか? どれも正解なのかなというふうに私は考えています。 というのも、企業によっても、Q.Engineerに求めているスキル経験ということが違うんですよね。 また、自分の経験、これまでの業務の経験としても、もちろんテストベンダーの方の管理をしたこともありますし、 プロジェクトマネージャーとして、動いた方がチームのためになると思ってプロジェクトマネージャーの動きもしたこともあるし、 あと周りの人で見てみると、スクラムマスターを兼任する方もいたりします。 Q.Engineerやってるんだけれど、スクラムマスターの勉強もされて、経験というか役割、ロールとしても、 スクラムの中でスクラムマスターをした方というのもいらっしゃいます。 仕事の範囲が広いと、どこからキャッチアップしたらいいんだろうかとか、 どこにくれてしまうこともあるんですけれど、そこに対する回転はまだまだ自分の中でも正直見つかってはいません。 ただ、今現時点で考えていることとしては、自分のやりたいことと会社に求められている課題感だったりスキル感だったり、 というところのベンズで重なる部分、その部分からキャッチアップするなり、経験を積んでみるといいのかなというのが今のところの私の回答です。 一つの参考情報として、Q.Engineerのロードマップってこういうのがあるよねっていうのが英語の資料なんですけれど、 サイトがあるので、このチャプターにリンクを貼っておきます。 例えばですね、品質保証とは何かとか、まず基礎を学ぶ、その上でソフトウェアのデリバリーのライフサイクルを学びましょうとか、 手動テストはこういうのがあるよねとか、いろんなスキルとか身につけるべきもの、ロードマップとして書いてあるサイトがあります。 ということで、ここまでが広いQ.Engineerの仕事って広いよねという話でした。 ここからは深いという話ですね。 私の経験談というか、これまでやってきたQ.Engineerとして働いてきて、4つ、何かQ.Engineerのお仕事って難しいなって思ったことを、プチエピソードみたいなものを4つお話しします。 まず1つ目がテスト設計技法の選択って難しいですよねという話です。 より効果的、効率的にテスト設計をしていきたいとなったタイミングで、テスト設計技法を勉強される方は多いんじゃないかなと思います。 動地分割、境界地位とか、ディシジョンテーブル、状態性因数とかですね。 それぞれのテスト設計技法の考え方とかやり方とかっていうのは書籍でも勉強することができるんですけど、 いざ自分の業務になってみると、どういう時にどの設計技法を使ったらいいのか、選択したらいいのかっていうのが結構最初慣れるまでに時間がかかりました。 なので一言でテスト設計っていうふうなQAエンジニアの業務、テストエンジニアの業務としてあるんですけれど、結構思ったより深いなというふうに感じたエピソードです。 2つ目がですね、肥沃高QAエンジニアのときにテストの目的というものを考えるのがすごい難しかったなというふうに感じました。 ここで言っているテストの目的っていうのは、いわゆる一般的ななぜテストをするのかという目的ではなくて、 プロジェクト案件で行うテストの目的は何かという文章というか定義を決めるのが難しかったという話です。 なぜテストの目的を考えるのが難しかったかという話ですね。 今振り返ってみるとではあるんですけれど、肥沃高QAエンジニアのときはプロジェクトで何を一番守りたいのか、 何を担保できたらそのプロジェクトのテストは成功と言えるのかというところを理解していなかったから、 やっぱり問題の本質を理解していなかったからテストの目的というのを考えるのが難しかったのではないかなというふうに考えています。 何が大事なのか、そのプロジェクトで一番何を守りたいのかというところを考える周りの人と認識を合わせるという意味でも テスト計画のフォーマットってやっぱりすごいんだなというか大事だなというのも感じたりはしましたし、 そこを考えると言いますか、何が一番大事なのか、何を一番担保したいのか守りたいのかというところを考える必要があるので、 QAエンジニアって難しいんだな、仕事って深いんだな、難しいんだなというのは感じたエピソードです。 3つ目がドメイン理解って難しいよねという話です。 特にですね、私は社会人1年目のときに最初2B向けの業務システムを作る会社に入ったわけなんですけれど、 部署としてはHR系ですね、人事ローム系のプロダクトだったので、社会人1年目のときにネマ調整という制度そのものを理解するのがとても難しかったです。 配属されて最初はQAエンジニアの先輩が書いたテストケースを自分で実行するということをやってたんですけど、 そもそも何が書かれているかというか、なぜそのオペレーションになるかというところが最初は全然理解ができなくてですね。 後々QAチームの中で人事ローム部の1年のお仕事とか、どういうお仕事があるのかみたいな勉強会をやったりしたんですけれど、 ドメイン理解って難しいんだなというのをすごく感じていましたし、 QAエンジニアのお仕事としてもテスト対象のシステムの理解、システムの理解じゃないですね、業務、ドメインの理解というのもとても大事なので、 難しいんだな、単に触ってテストすればいいというわけではないので、QAエンジニアの仕事って深いんだなというのを感じたエピソードです。 最後4つ目ですね。QAエンジニアになってからはテストの重要性だったりとか、テストの構成を確保してもらうことって難しいなというのを感じています。 ここ3年ぐらいはテストの重要性というのがかなり広く渡っている感じがするので、そこまで重要性の必要性、テストがなぜ必要なのかというところを一生懸命説明する、説得するという必要性はなくなってきたんですけれど、 でも新卒で開発エンジニアを始めましたという方はあまりテストといえば単体テストのことを指していて、もう少し広い意味でのテストの理解はまだ浅い方も多かったりしますので、 他にもこういうテストが必要なんだよみたいな話はやっぱり必要だったりします。テストの構成を確保するというところなんですけれど、意図をせずというのも結構あるんですが、 開発の見積もり案件で開発の見積もりをするときに、手動でのテスト、最後の動作確認、あるいは修正確認というところ、不具合修正のコースと修正確認まで行うというところのコースまでが見積もらわれていないということは結構あります。 そうすると開発コーディングが予定より時間がかかってしまったら、もうテストの時間がないといいますか、修正確認までの時間が足りなくなってしまう、バッファーを使い切ってしまうことになったりもします。 一方で結構バッファー盛り盛りで見積もる方もいるので、その場合はテスト実行とかテスト設計というコースの見積もりの観点から、ここってこんなに必要そうですかねみたいな話もする必要があったりします。 という感じで、QAエンジニアになってからといいますか、アジャイルスクラムの開発プロセス全体を見るように意識するようになってからは、テストの重要性だったりとか、テストのコースを適切に確保するみたいなところがなかなか難しいなと日々感じております。 ということで、今回はQAエンジニアの仕事は海のように広くて深いというお話をしました。ぜひコメント欄でQAエンジニアのこういう仕事って難しいよねとか、深いよねみたいなエピソード、考えがありましたらぜひコメント欄で教えてください。きっと他に聞いているリスナーさんの勉強を学び、新たな築きにつながると思います。 # #29のコメント返し🥰 コメント返しのコーナーです。今回は29話目のコメント返しをします。 1週間前の29話目では、テスト計画で苦労していることについてお話をしました。 コメントは初コメントなんですけど、読み方はちょっと自信ないな。 ふうわスティーブさん、スティーブンさんからコメントをいただきました。 初コメントありがとうございます。いろいろ勉強になりましたということですね。 本当にこういうコメントを言っていただけると、私もやりがいと言いますか、すごい嬉しいです。 ぜひこれからも聞いていただけると嬉しいですし、コメントしていただけるともっと嬉しいです。 以上、コメント返しでした。 # 次回予告 今回も最後までお聞きいただきありがとうございました。 次回はテストの目的とは何かという話をしようと思います。 今回の放送でも少し話はしたんですけれど、 テストそのものの目的、なぜテストが必要なのかの話ではなくて、 案件におけるテスト計画書で書いているテストの目的とは一体何者なのかという話、 そういう話は深掘っていきたいなと考えております。 今回の放送を聞いて、なるほどな、確かにな、学びになったなと少しでも思った方は、 画面右下のハートマークでいいねを押してください。 ぜひフォローもよろしくお願いいたします。 それではまたお会いしましょう。ごきげんよう。