ぜにのQAブログ

どこかの企業でQAエンジニアとして働いてる人のブログです

2年間の振り返り【後編】

ぜにです。

前編に引き続き、2年間を振り返って気になったこと、課題に感じたことを書いていきます!

 

▼前編をご覧になっていない方はこちら!

qaminarai.hatenablog.com

 

もくじ

  1. こんな振り返りしたよ
  2. 気になったこと、課題に感じたこと
  3. まとめ
  4. 余談

 

1. こんな振り返りをしたよ

※前編と同じ内容です

 

【前置き】

入社時点での開発組織はこんな感じでした

  • 開発組織全体の人数は約30名ほど
  • QAチームなど品質管理を専門としたチームはまだない

企業規模拡大の時期だったので、開発組織としても品質を専門としたチームが必要といった方針でQAエンジニアの採用が進み、ご縁あって自分がQAチームの第一号の社員として採用されました。

※自分のこれまでの経歴についてはこちらの記事をご覧ください。

 

【ここから本題です!】

ざざっと時系列で起きたことや良かったこと、気になったことなどをまとめてみました。

※なるべく企業にまつわる固有名詞は伏せています。

入社1年目のタイムライン

入社2年目以降のタイムライン

タイムラインという振り返り方法を実施しており、こちらの記事を参考にさせていただきました!

細かくて見えないところもあると思うので雰囲気を掴んでいただければ。

 

 

2. 気になったこと、課題に感じたこと

気になったこと、課題に感じたことを上のタイムラインから抜粋し、

それによって困ったことや、こうしたら良かったと思ったことをまとめました。

 

テスト自動化を早期に目指しすぎたかもしれない

【困ったこと】
  • 自動化すると効果的なテストが不明確で、テストを作成してもそれが有効であると言えない状態
  • 定期メンテナンスを行うことが難しい状態
 
【なぜ起きたか】
  • 自動化すると効果的なテストが不明確で、テストを作成してもそれが有効であると言えない状態
    • ツール選定を最初に行った
      • 社内全体のテスト(開発側行われているものも含む)を把握していない状態だった
      • QAで行う回帰テストが本当にこの内容で良いか精査していない状態だった
    •  自動化ツールの選定タイミングが早かった
      • メンバーが自分1人しかいなかったのになんでもやろうとしすぎた
      • とりあえずやってみなきゃわからない精神(自動化に関する興味はあったが知識がなかった)
  • 定期メンテナンスを行うことが難しい状態
    • 作成済みの自動テストに変更を加える必要がある場合、担当者が都度修正していたが、QAチームとして定期的に一定の基準を持ってメンテナンスをするというルールはなかった
      • 現在は回帰テスト/自動テストの内容精査のmtgを定期開催しておりメンテナンスへの動きが前進しているが、始めるタイミングが(自分の退社タイミングにとって)遅かった 
      • 機能リリースに対するテストで現状のチーム人数で手いっぱいのため、リソース不足な部分があった

 

【こうすれば良かった】

とりあえず1人しかいないのに色々やろうとしない...!

一旦やってみるの前に、目的や方針くらいは有識者に一度相談しておくべきだった。

やってみなければわからない部分もあるが、ある程度社内のテストの現状と自動テストにするべき項目をまとめておくべきだった。
 
ソフトウェアテスト293の鉄則にある「自動化は"銀の弾丸"にはならない」を身をもって体感しました。
ソフトウェアテスト293の鉄則_鉄則105 より引用
 
 
 
QAEチームの立ち位置や開発工程のどこから関わるかが曖昧だった

【困ったこと】

  • QAチームも開発側も両者にどう関われば良いか探り探りで、開発者やチームメンバーを困惑させてしまった
  • QAチームのミッションを決めたが、チーム/開発部内でも浸透していない気がした
 
【なぜ起きたか】
  • QAチームも開発側も両者にどう関われば良いか探り探りで、メンバーを困惑させてしまうこともあった
    • QAチームで限られたリソースの中でどういった条件でどのようにプロジェクトに関わるか定義づけられていなかった
      • 各プロジェクトのリリーススケジュールを優先していた
        • リリーススケジュールを見てQAのリソースを見積もり、それをもとにQAがプロジェクトにどう関わるかを決めていた
    • 各プロジェクトのPjMとの接触タイミングが少なく、連携がとれていなかった
      • QAチームから主導していく形ではなく、あくまでプロジェクトから必要とされたときに受動的に動いていた
  • QAチームのミッションを決めたが、チーム/開発部内でも浸透していない気がした
    • こまめな周知がされていなかった
 
【こうすれば良かった】
QAチームで品質の定義、プロジェクトの関わり方を決め、毎月毎週でも周知したり時にはアップデートしていくと良かった。
開発者からはQAチームは未知の存在だったと思うので、QAチームから積極的に歩み寄る、参加した方が良いと感じたmtgには呼ばれていなくてもいくべきだった。

 

プログラミングスクールを途中で退会した

これについては、意志が弱かったに尽きる。
業務時間内に勉強しても良い、と言われていてもQAの業務が優先と感じて意図的に勉強時間を潰してしまっていた。
QAの業務を言い訳にしているが、就業時間外にいくらでもできただろうと言われるとそうだなと思う...。
この有給消化期間中に目的や目標を再設定したい。

 

勉強会/イベントなどから吸収する情報で、概念の理解は割とすぐにできるが具体への落とし込みに弱い
【困ったこと】
  • 見聞きした内容を業務に取り入れようと思った時にスムーズに実践できない
 
【なぜ起きたか】
 
自分の業務で実践する具体的な像が見えていない
  • 話の聞き方に課題がある
    • 話を聞いた時に、即座に「〇〇の場合」「もし〇〇だったら」などバリエーションが思い浮かばない
      • 話の中に複数パターンがある項目を見つけようとしてない
    • 話の中で引っかかるところがあっても一旦全部聞こうとすると引っかかったところを忘れる
    • 概念を理解するのが得意というか、見聞きした情報をもとになんとか辻褄を合わせようとする癖がある
      • 辻褄を合わせるので、ん?と思ったことを自動的にスルーするようになり、解消した方が良い疑問を解消しない

 

【こうすれば良かった】

  • 話や情報の中から、せめて自分の環境に置き換えるとどうなるか考えて引っかかったところを書き留めてみる。
  • 見聞きした情報をそのままメモして満足するのではなく、情報に対してどう思ったか、その情報に複数パターンや例外は存在しないか振り返ってみる
  • イベントなどで事前にテーマがわかる場合は、そのテーマにおける自分の状況を振り返っておき、聞きたいことを明確にしておく

 

3. まとめ

良かったことをまとめた前編と比べてどんよりとした記事になってしまいました... 🙏

根暗なのがもろ出てしまってるし、終始抽象的な話しかしていないのですが、自分の気持ちの整理として書いている記事なのでご容赦ください!

 

4. 余談

家だと集中できないのでシェアラウンジとかで記事を書いたのですが、良かったところ載せておきます🍹

 

▼ 飲み物とお菓子が充実してて席間隔ゆったりしてて最高でした!周りの本棚の本も読み放題 📚

store.tsite.jp

 

▼おしゃれ空間なので自分もおしゃれになった気分になれますが、パスワードの打ち込みに苦戦してしまいおしゃれな人たちにダサい姿を見せてしまいました!

www.te-fu.jp