現役エンジニアが、現場で駆け出しエンジニアを育ててみて思うところあり⑤

こんにちは、引きこもりのHisashiです。

前回、「現役エンジニアが、現場で駆け出しエンジニアを育ててみて思うところあり④」で、#非エンジニアと要件定義からリリースまでやってしまおうの、実装フェーズのお話をしました。

今回は、試験フェーズのお話をしたいと思います。

そもそも、試験工程があることすら知らなかった

いきなり衝撃な事実ですが、このプロジェクトが始まるまで、非エンジニアの方（以下、彼）は試験工程があることすら知りませんでした。

独学やプログラミングスクールでプログラミングを学んだとしても、これが実態だと思います。というのも、

・メンターがそもそも試験工程を知らない、体験したことがない（これは論外）
・メンターが試験工程まで教える時間がない（あるある）
・試験工程を独学で学ぶにしても、ググるキーワードすら連想できない

といった潜在的な問題点が垣間見れました。

今回は、そのような非エンジニアの彼を（できるかどうか？の適性も踏まえつつ）エンジニアにすることがプロジェクトの目的でもあります。

そこで、実際に、
・機能試験
・内部結合試験＆運用試験
を体験してもらうことにしたのです。
※今回の開発するシステムには外部結合点が存在しないので、外部結合は省略しています。

試験工程をどのように進めたか？

ありきたりな方法ですが、要件や仕様をベースに、

・どんな試験が必要か？（試験仕様、試験観点の洗い出し）
・どんな試験パターンが必要か？（マトリクス、データパターンの洗い出し）
・試験の実施有無（共通部分の処理は1回だけ試験する、とか）

といった感じで、試験工程を現場のSEと同じようにすすめてみました。

成功した点

成功した点は、

そもそもなぜ試験が必要か？が理解できた

というところです。現役エンジニアにとっては「ふーん」で終わる話ですが、非エンジニアにとっては、「そこまでしないとバグをつぶせないのか」という現場の隠れた苦悩を理解してもらうことができました。

規模の小さいシステムは、どうしても動確レベルで終わってしまうのですが、自分も含めてバグを結構見逃していたりします。

ポータルサイトの開発であればそれでも良いのですが、ECや決済が絡む場合はその限りではありませんし、バグによっては試験パターンを出せ！と顧客に詰められるケースもあります💦

そういった、システム開発やWeb制作では表に出てこない試験工程を実際に体験することで、発注側に立った時に、エンジニア目線で細かい要求や仕様改善を出しやすくなるのではないかと期待しています。

失敗した点

失敗した点は、時間に起因する点が大半でした

・Unitテストを書いてもらう時間がなかった
・試験パターンやケースの洗い出しが少なすぎた

現場あるあるなケースなのですが、今後はUnitテストも書いてもらうケースがあると想定していたので、せめて重要な機能に関してはUnitテストも実施したいのが本音でした。

Unitテストに関しては、本プロジェクトの追加開発時に、改めて実施しようと思っています。

最後に：現場での教育は、時間との闘い？！

要件定義～試験工程に関して、ここまで振り返ってみて思ったのは、

要件定義～試験工程まで、全部教えるとなると時間がない

という極論でした。

・要件定義：顧客の要求をもとに要件を決める
・設計：要件をもとに仕様を決める
・実装：仕様をもとに実装する
・試験：仕様をもとに試験する

といった、各工程においてそれぞれ専門的な技術が必要になります。

また、リリースに関しても、Dockerを使っていない環境の場合は、リリース作業はかなり属人的です。ところが、今回はリリース作業まで体験する時間すらありませんでした。

その専門的な技術を教える時間を、各工程でどのように確保するか？がクリアできないと、現場で非エンジニアをエンジニアにするのはかなり難しいと肌で感じました。

現場からは以上です。
最後までお読みいただきありがとうございました。