# タイトルコール ようこそ、世界が広がるソフトウェア品質へ。 このチャンネルでは、エンジニアリングマネージャー兼QAリーダーのサミーが、 ソフトウェアテストやソフトウェアの品質保証を中心に、日々奮闘している方が考えていることをお話しします。 毎日、お昼の12時30分に配信しています。 ゲストの方やリスナーのあなたと、テストや品質の世界を広げていきます。 # テストエンジニアとQAエンジニアの違い？ こんにちは、さみぃです。今日もテストしていますか? 今回はテストエンジニアとQAエンジニアの違いについて話していこうと思います。 そこからですね、キャリアアップだったりとか、 どう給与を上げていくのかみたいなところのお話まで深掘りできたらさらに良いなという風に思いながら今話し始めています。 ということで、テストエンジニアとQAエンジニアの違いって何だと思いますか? それは何ですかね、明確に正解は多分ないので、 まあ多分それぞれで定義ってちょっと変わってくるとは思うんですけれど、 私の場合とテストエンジニアとQAエンジニアの違いっていうところは、 まず見ているスコープが違う、守備範囲が違うっていうのが一個あるんじゃないかなっていうのを考えていますね。 テストエンジニアはプロジェクトとか案件とか、何か新しい新機能のこれこれを出すみたいなプロジェクトがあって、 そのプロジェクトが守備範囲なんですね。 そのプロジェクトでどういうテストが必要なのかっていうところを考えて設計したりとか作って実行していくのがテストエンジニア。 まあリードもしているから場合によってはないっていうのがテストエンジニアなんですけれど、 QAエンジニアの方はスコープはプロジェクト全体だったりとか、ちょっと組織によっては違うんですけど部署全体とか、場合によっては会社全体みたいな感じで、 スコープはまず1、プロジェクトだけではないもっと広いスコープを守備範囲として活動しているっていうのが一つあると思います。 別の観点としては深さなのかな、なんか違うのかもなというふうに思っていて、 テストエンジニアはその名の通りテストを考えるので、 基本的にはテスト計画とかもそうですけど、どういう今回テストの目的を置いて、 その目的のためにはこういうテストのアプローチが必要だねっていうテスト戦略を考えて、 そのテスト戦略にのっとって、今回こういう修正とかが入るからこういうテストが必要だねっていうテスト設計を分析していく。 これがテスト分析なんですけど、 そしてそのテスト対象のどういう特性を確認したいのかっていうところを言語化をして、 テスト設計をしていく、テスト実行していくとか、そういうのがテストエンジニアのイメージなんですけど、 QAエンジニアの場合はその名の通りQAというのはQuality Assuranceで品質保証ですよね。 なのでそのテストどうするかっていうだけではなくて、 例えばプロダクト全体で見たときとか開発組織全体で見たときとかに一番パッとイメージしやすいのは、 どういう進み方をしたら品質を担保しやすくなるのか、テストを実行しやすくなるのかっていう文化づくりみたいなところだったりとか、 実用に応じてプロセスを改善していったり変更していったりっていうのもあるだろうし、 あとはポストモーテムと呼ばれるような大きな障害が起きたときに振り返りを行うんですけれど、 そこをリードする、振り返りをリードしたりとかっていうのも、 その後、今後、今回起こしてしまった障害から一体何を私たちは学んで次に活かしていくのか、 次に活かしていくんだったらこういうことをやったらいいよねっていうアクションを関係者で集まってディスカッションして話して決めて、 そしてそのネクストアクションをやり切るっていうとこまで、ネクストアクションをやり切ることによって、 次また同じような障害を起こさない、問題を起こさないようにするっていうのが結果として、 よりよく効率的に、効果的に、効果的にプロダクトを作っていくっていう活動につながっていく。 なのでそういう活動もポストモーテムなどとしては振り返りとネクストアクションをリードしていく、推進していくっていうところもQAエンジニアがやっていくこと。 なのでそういう深さとか、やっぱスコープになっちゃうかな、が結構テストエンジニアとQAエンジニアでは大きく異なるのではないかっていうのが私の定義になります。 ここまでいろいろ話してきましたけど、超ざっくり言うとテストをうまく回す、テストを意味あるテストを行うとかっていうところ、 テストをいかにうまく実行、推進していくかがテストエンジニア。 QAエンジニアの方は品質を良くしていくためには何が必要か考えて企画、実行、推進をしていくというのが超ざっくりしたまとめですかね。 ここからは自分のテストエンジニアあるいはQAエンジニアとしてのキャリアアップだったりとか、給与もちょっと上げたいぞみたいな思いがある方もいるかなと思いますけれど、 そういったときにどういうことをやっていったらいいんだろうかっていうところを言語化していきたいと思います。 テストエンジニア、QAエンジニアだけじゃない気はしているんですけれど、 多分基本方針としては自分の行っている活動だったり言動を含めてですけど、 の影響範囲が広くなっていけばいくほど給与が上がっていくんじゃないかというのが大前提として自分の中にありそうだなというふうに考えています。 例えばテストエンジニアとして一番最初にやるのって多分おそらく誰かが作った先輩だったり誰かが作ったテストケースを実行するというところから始まるんですよね。 もちろんお客さんへのインパクトというのも影響というのはもちろんあるんですけれど、基本的には開発チームというチーム内の貢献という単位のイメージを持っているんですよね。 そこから例えば自分でテスト設計をするようになって、じゃあもうちょっとみんなでチームで効率よくとか効果的なテストを設計できるようにテストケースのフォーマットを見直しましょうとかそもそも作りましょうみたいな話、活動していくとQAチームの中でのバリュー価値が出せてくるようになる。 そんな感じで開発新機能のプロジェクトの振り返りとかを通してちょっとこういうことをチャレンジしたいみたいなものが出てきて、それを実行するやり切る、そして何かプラスのポジティブな影響だったり効果という成果というものが見えてくると、自分の言動の影響力というのが自分のチームだけじゃなくて、 自分のチームはどこかっていうのはあるんですけど、例えばQAチームに所属している人間として、だけど隣の開発チームも含めて何か自分の言動、リード、アクションによって何かいいインパクト、影響を与えることができたってなったら、またちょっと自分の影響を与えている領域、人数感、規模感というのは大きくなっているわけですよね。 さらに、じゃあプロダクト全体として開発プロセスを見直しましょう、ちょっとそれは話が大きいかもしれないんですけど、例えばそんな感じで、今こういうプロセスになっているんですけど、今回こういう失敗があったのでこういうふうに変えていきませんか、変えてみましょうよ、一回やってみましょうよみたいな感じで、各開発チームのリーダーの人たちと相談だったりディスカッションとかをしながら何かを変えていく。 それによって、例えばより認識済みが少なく開発を進められるようになったとか、スピードが上がったよねとかということがもし成果として出れば、さらにプロダクト全体であるいは部署全体での何か活動推進ができるようになったというふうになっていくんですね。 そんな感じでどんどんどんどん自分の言動が与えるインパクトだったり、インパクトがどんどんどんどん大きくなる、広くなるというふうになっていくと給与も上がってくるのではないかというのが私の考えですね。 なので、どうやって上げていったらいいかというと、やっぱり自分のできることだったりスコープ、自分のできることを増やしていくと。 どうしたらより多くの人に影響を与えることができるかというと、ちょっと私の言いたいことと違う言葉になっちゃってる気がするんですけれど、 より多くの人にメリットだったりを提供できるかということを考えながら自分の次はこういうことをやってみよう、こういうことをキャッチアップしてみよう、勉強で実践してみようというふうに考えていくと ステップアップ、自分のできることも増えてくるし、より大きな成果につながっていくんじゃないかなというふうに思います。 そして、自分一人でやる必要は必ずしもなくて、自分がやるんじゃなくて、周りの人をうまく巻き込みながら一緒に推進していくということができていくと、さらにより大きな成果につながっていくんじゃないかなと思ってたりします。 ということで、今回はテストエンジニアとQAエンジニアの違いについてお話をしました。 そして、どうスキルアップしていったらいいのかなというところを自分なりに言語化をしてみました。 ぜひ、あなたの意見も教えてください。 # AIコソコソ話 AIコソコソ話のコーナーです。 今回はですねクロードスキル図の話をちょっとだけしようと思います。 10月16ぐらいでしたっけに発表がありましたよね。 ちょっと気になっていて早速クロードで スキル作ってみようと思って作ってみたんですよね。 で何がしたかったかというとテストを 作れるスキル、テストスキルをそのスキル図にまとめたかったっていうことがあって もともとっていうのかな最近のその悩み事としてはせいせいにテストケースとかテスト コンテンツを出してもらうんだけどそれが何に基づいてどういうロジックでっていうのかな 何に基づいてアウトプットされたものなのかっていうのが根拠がよく自分にはわからないので テストケース作りましたって言われたんだけどその成果物の妥当性というところが判断できないっていうのが一つ 最近の悩みですと。それに対して 今考えている仮説としては ISTQBで紹介されているもの、シラバスの内容だったり あとはテスト設計技法みたいなところのノウハウみたいなところをベースに設計されている とかだったらもうちょっと説得力が上がるんですよね。私の納得度が上がるんでそういうことできないかなと思っていた時に出てきたのがこの Cloud Skillsです。でちょっとやってみて 良さそうというのが今の所感です。 また別の放送だったりとかブログとかでもう少し詳細にご紹介できたらなというふうに思っております。 以上、AIこそこそ話でした。 # 次回予告 今回も最後までお聞きいただき、ありがとうございました。 次回はですね、一度やってみたいことについて、いろいろこう妄想しながらですね、考えていこうと思います。 今回の放送を聞いて、なるほどな、確かにな、学びになったなと思った方はぜひ、 画面右下、ハートマークでいいねを押していただけると、とっても励みになります。 SNSや口コミでのシェアもぜひぜひ、よろしくお願いします。 それではまた明日、お会いしましょう。ごきげんよう。