はじめに
この記事は、CYBOZU SUMMER BLOG FES '26の記事です。
こんにちは、QAエンジニアのみずみずです。
普段はkintoneという製品のQAをしています。
私は2025年に新卒として入社し、今年で2年目になります。
入社前はQAは未経験で、プログラミングスキルとしてもスクールに通ったことがある程度のものでした。
この記事では未経験QAがテスト設計ができるようになるまでにやったことを書こうと思います。
テスト設計ができない！😭という1年目の私のような人の参考になれば幸いです。
配属直後
一番最初は回帰テストの実施をひたすらやっていました。
目的としては仕様の理解や、kintoneの操作がしっかりとできるようになることです。
実施の対象は、所属するチームでよく使う機能や、知っておいた方が良い機能の回帰テストでした。
REST APIの実行にとても苦戦した記憶があります。いまだにREST APIには苦手意識があります…。
一通りの回帰テストが終わると、次はその時開発中だった機能のテストを実施しました。
先輩が作成したテスト仕様書に沿ってテストを実施していきました。
回帰テストとは書き方や形式が違ったり、手順の粒度が違ったため、どうやるんだろう？？と詰まることが多かったです。
同じ質問は2回しない
回帰テストも新機能のテストも、わからない言葉や概念がたくさんで、何がわからないかもわからない状態でした。
そんな時に心がけていたのは、「同じ質問は2回しないこと！！」です。
毎日15分ほどの先輩とのミーティングがあったので、その日実施しながら思った質問をそこでしていました。
その質問の時間までに、思いつく限り自分で調べるようにしていました。
サイボウズは社内のナレッジがたくさんあるため、それらを調べたり、ネットを検索したり、過去の自分のメモに似たものがないか調べたりしていました。
しかし、ナレッジの検索の仕方や、そもそもこの概念はどういう単語で調べればいいんだろう？ということもわからなかったので、ほとんどはミーティングで質問していました。
質問したことは、ミーティング後に自分用のメモにまとめて、またわからなくなった時に見返すようにしていました。
当時のメモは今でもたまにテスト実施の時に役に立つことがあります。
テスト仕様書を作成
テストの実施のみを数回やったあとは、テスト設計も任されるようになりました。自分で設計して、レビューをテキストでお願いする形で行っていました。
最初の数ヶ月は、1回のレビューでは直しきれず何度もレビューしてもらっていました。
情報を探す力をつける
まず最初にしていたのが、過去の参考になるドキュメントを探すことでした。
しかし、これが全然できなくて苦戦しました。何を参考にしたら良いのかも、どう調べたら良いのかもわかっていませんでした。
先輩はどうやって検索しているのか？と思い1on1で質問したり、画面共有してもらっている時にどう検索してるんだろう？と観察したりしていました。そうやって試行錯誤して、何度も調べるうちにコツを掴んできました。
具体的には、以下を意識するようにしています。
- 絶対に入る単語は何かを考える
- 期間や人でも絞ってみる
- こういう時はここを見る、というドキュメントを見つけておく
該当しそうな記述を見つけたら、それに入ってるキーワードでもまた調べて…というようなことをしていました。
関連しそうな単語を並べて、総当たりで調べる、というようなこともしています。
同じ指摘を繰り返さない仕組みを作る
丁寧にレビューしていただいていたので、直す箇所がとても多かったです。
全て直しきれず、再度のレビューでも同じところを指摘されることもしばしばありました。
理想を言えば、同じことは二度と指摘をもらわないようにしたかったのですが、なかなかそううまくは行きませんでした。
ただ覚えよう、気をつけよう、だけではだめだ！と思い、自分用のマニュアルを作るようにしました。
しかし、レビュー内容をそのまま書くだけではうまくいかないと思い、できるだけ抽象的、汎用的になるように心がけて書いていました。
具体的には、予習はこういうことを調べてほしい、タスクがこういう状況ならこうして、ということを書いていました。
それだけではまだ漏れが多かったため、チェックリストも作成しました。
レビュー前にはこれをチェックする、レビューの直しを見てもらう前にはこれをチェックする、という感じのチェックリストを作りました。
今ならAIにレビューしてもらうのも良さそうな気がします。
チェックリストと自分用のマニュアルを作り、レビュー内容を毎回その2つに反映するようにした結果、レビューを複数回お願いしないといけない状況はなくなりました。
考慮漏れへの指摘が1〜2個くらいになってきた
レビューの形式も変わりました。それまではテキストベースでしたが、ソフトウェアエンジニアにミーティングで共有するのと同じタイミングで、QAの先輩にも一緒に見てもらう形になりました。
修正項目がだいぶ減ったことによる変化で、嬉しかったです。
この頃には考慮漏れもだいぶ減って、1〜2個くらいミーティング中に言われる程度になっていました。
設計の経験が増えたこと、この変更ならこういうテストをやると良さそうという引き出しが増えたことも大きいと思いますが、以下のことを意識して行っていました。
観点の根拠を言語化する
レビューのミーティングの前に一人で、1ケースずつ手順や期待結果を読み上げて、さらになぜ追加したのか？の根拠を話すようにしていました。
「仕様書にこう書いてあるので追加しました」や「こういう不具合が出るかもしれないと思ったので追加しました」というような、なんでこれが必要だと思ったのか？を答えられるようにしていました。
これをやると、書き漏らした観点や、書き間違いにも気がつけるのでとても良かったです。
再現性を意識して質問する
この頃から、質問が今迷っているという話よりも、「こうやってみたけどもっとベストなやり方があったでしょうか？」に変わってきたように思います。
「これどうしたらいいですか？」ではなく、「こうしたんですがもしかしたら〇〇の方が良かったですかね？」のような感じです。
答えてもらった後も、「今自分は理解しているのか？」ではなく、「もし同じことが起きたらちゃんとできるか？」という再現性を軸に考えるようになりました。
「〇〇というふうに理解したんですが合ってますか？？」や「ということは次もし〇〇になったらこうするといいってことですかね？？」みたいに自分の言葉で説明する段階を踏むようにしています。
設計に時間がかかりすぎる
まだ解決していない課題としては、何をやるにも時間がかかることです。これくらいで終わるだろうから大丈夫、と思ってタスクを取っても、全然終わらないことが続いています。
これはシンプルに設計や実施に時間がかかっている、という話と見積もりが甘いという話があると思っていて、それぞれにいろいろ試行錯誤をしています。
時間がかかったタスクは先輩に相談する
特に時間がかかった設計や実施に関しては、先輩に相談することにしています。
こういうタスクで、これくらいの時間がかかってしまったのですが、もし先輩ならどう設計や実施をしますか？というような感じで質問しています。
これはまだあまり回数をこなせていなくて、これからいっぱい質問して知見を蓄えていきたいです。
着手・完了・実働を記録して見積もりを直す
着手時間と、予想完了時間、実働時間を記録するようにしています。
AIに今からやること、何時までに終わらせたいこと、終わったらその旨を伝えるといい感じに表を作ってくれます。これをAIと一緒に分析すれば自分の見積もりのクセがだいぶわかってくるんじゃないかな？と期待しています。
データをためて、振り返って、ということをいっぱいやるぞー！と思っています。
まとめ
未経験で何もわからなかった配属後から、まだまだ完全に独り立ちとはいきませんが、少しは成長できたのではないかなと思います。
どうすれば再現できるかを考えて仕組み化すること、ちゃんと根拠を説明できるようにすることが大事だったように思います。
1年目の方の参考になれば嬉しいです。
2年目も頑張るぞー！！
