# システムの内部構造を理解するための奮闘 こんばんは。まなびのデバッグログ、もんちゃんです。 私が日々奮闘する中で見つけた、まなび焼き付きを内製しながら皆さんとシェアしていきます。 今日は、システムを図で描いてみて理解してみるという話をします。 私、1年目のQAエンジニアなんですけど、システムの内部構造ってやっぱりあんまりわかってなくて、 QAエンジニアとしてテストを考えるときにパターンで考えて、組み合わせで考えてみたいのは、 少しずつこういう頭の使い方で理解していくんだなとか、テストについて考えていくんだなっていうのはちょっとずつやってきてはいるんですけど、 システムの内部構造で考えて、この辺が怪しそうだなとか、不具合起きそうだなっていうような、 ホワイトボックス的な考え方ってやっぱり難しくて、 でもこれ、今後自分がQAエンジニアとしてやっていくのであれば、ちゃんと修行すべき部分だなっていうのは思っています。 その話をチームの振り返りでしたときに、まずは図で書いてみて、 それを他のエンジニアに聞いて、合ってるかなっていうようなすり合わせをしたらいいんじゃないかっていうのがあって、 実際先週やってみたよという話をします。 書いてみた図は、開発する機能の一番重要な部分を、 この部分はバックエンドからどういう情報をもらって、 フロントでは何を返してどう見えるようにしたのかとか、どうやって情報を渡しているのか、 データベースとしてはこういうものが入ってそうだなみたいなのを書いたり、 あと画面を点描するのはどのタイミングでしているのかなみたいなことを一回自分で図に書いてみて、 実装はどうなってますかっていうのをエンジニアと話すっていうのをやりました。 あと、件数表示のロジックとかは、 これがトゥルーがフォルスに変わったから件数がマイナス1件になって、 表示でもマイナス1件になるみたいなロジックとかを、 システムの内部でこういう処理が走っているってことですよねみたいなのを開発メンバーと話しました。 これを書いてみたことで、まだまだうまくできていないんですけど、 じゃあどんなテストが考えられるかみたいなことを考えるきっかけになりました。 例えば、ここは変更が加わっているからテストが必要そうだなとか、 ここのデータの正しさってテスト必要なんだっけみたいな、 こういうのはシステムの構造からテストを考えるっていう、 ちょっとあんまり普段やってないことだったので、もっとやっていきたいなというふうに思いました。 これは結構自分の引き出しを、今後開発チームに入っていく中で、 引き出しを増やしていきたいところだなというふうに思いました。 あとは、予期していないような形のデータが入ったときにクラッシュしないかとか、 そういう異常系のことを考えるっていうのは、今まであんまり手数がなかったので、 図で書いていくことで、知識深められるかもなというふうに思いました。 あとは、このプロセスっていつやるんだっけっていうのは考えたんですけど、 これはテスト分析でやるべきところかなと思いました。 テスト分析は何をテストするのかっていうところなので、 このロジックが壊れてないかとか、データがたくさん入ってしまったときにどう表示されるかみたいな、 テスト対象のロジックを考えるっていうのはテスト分析のプロセスにあたるなと思いました。 最近私、テストプロセスの中身が結構ごちゃごちゃになってしまってるっていうのが課題としてあって、 例えばテスト計画、テスト分析、テスト設計、テスト実装、テストケースを作るっていう、 その4つを全部ごちゃごちゃに考えてしまってて、 どうやってテストを進めるかっていう全体のところを考えることと、 何をテストするのかってことと、どうテストするのかと、 具体的にどういうケースでテストを進めていくかっていうこの4つがごちゃごちゃになってしまってるせいで、 最終的なアウトプットを出すときに漏れてしまったりとか、時間かかってしまったりっていう課題があって、 なので最近はこの観点を考えるときとかにも、今これは何のプロセスだっけっていうのを考える癖をつけるようにしてて、 そういう意味では今回図で書いたっていうのは、テスト分析、何をテストするのかっていう部分にあたるかなと思ったので、 今後も図で書いて、何をテストするのかっていうのを整理して、チームで話しながら、相談しながら進めていけるようにしたいなというふうに思いました。 これどうやったら引き出し増やせるのかな。図を書いてから、じゃあこの辺気になりますねってなるには、 どんな本を読んだらいいのかな。もし分かる人がいたらアドバイス欲しいです。 この図を書いて、結局この機能でエンジニアとして一番バグが出そうな部分とか複雑な部分ってどこかなっていうのを当たりがつけられるようになったらいいのかなと思って、 これまでだったら最初からどの辺ですかねって聞いてたんですけど、これからは一回まず図に書いてみて、 ってことはこの辺が怪しそうですよねっていうふうにある程度目星をつけて提案ができるようになれたら、 もう一歩進んだ急エンジニアになれるかなと思って今後やってみようかなと思います。 この図を書くって何て言うんですかね、この作業のこと。地味に聞いてみたんですけど、システム構成図とかって言われたんですけど、 ちょっと違いますよね、システム構成図って。なんだろう、超簡易システム構成図を書くみたいな感じなのかな。 あとはシーケンス図、データフロー図、概念図とかいろいろ提案されましたが、何に近いんですかね。 開発組織によってもいろいろ呼び方ありそうです。 メンタルモデルとかテストモデリングとも言われましたね。 メンタルモデルはシステムがどう動いているかという自分なりの理解、頭の中の地図のことです。いろんな専門用語がありますね。 今後は図で書いてみて、どの辺で不具合が起きそうかっていうのを知りたくって図を書いてみたので、 ディスカッションしたいですというふうに開発エンジニアと話していければなと思います。 いつにもましてまとまりのない話になってしまいました。 お聞きいただきありがとうございました。 このチャンネルは週2回更新予定です。フォロワーやコメントお待ちしています。 それではおやすみなさい。