スタートアップAshiraseの開発 #後編【実装～結合テスト～イテレート】

こんにちは。Ashirase CTOの田中です。
前回の記事ではあしらせを創業してから今までの開発を振り返り、全体概要から上流工程までをかきました。今回は後編として、実装からテストを行い、それをイテレートしていく部分について書いていきます。

前回記事です！

想定読者

ベンチャーやスタートアップで働いてみたいと思っている方
あしらせに興味がある方
ものづくり開発に興味がある方

②実装・単体テスト

あしらせではSWの領域が3つに分けられます。組み込み、モバイル、バックエンドです。 それぞれ概要を記載します。

エッジデバイス

言語はC言語を使用してます。いつかC++やrustに置き換えたいと思っています。
ローカル開発環境は、VSCodeを利用しており、拡張機能のRemote - Containersを利用してDocker単体テスト環境と繋げています。
Dockerでは、CMakeとCUnitを利用し単体テストを実行可能にしています。またgdb, gcovを利用して、デバッグや、カバレッジの計測を行っています。
実機で動作を確認するための環境としてはIARを利用しています。こちらのツールではICEを使用して実機実行中にデバッグを行えたり、CERTによる静的解析・動的解析を行うことができます。また、制御系の解析を行うためにEVRICAを使用しています。EVRICAではRAMをリアルタイムにモニタリングできます。
バージョン管理はgithubで行っています。また、CIとして、githubアクションにより上記の単体テストがpush時に自動に走るようになっており、カバレッジの計測結果もアーティファクトとして出力されるので、カバレッジがどのように変化したかも比較的簡単に負うことができます。
組み込みの環境でCIまでやっているところはあまり多くないと思います。

モバイルアプリ

言語はSwiftで、ローカル開発環境はXCodeです。
バージョン管理はgithubを利用しています。
単体テストはXCode内で構築出来ることは確認していますがまだ書けていないのが現状です。改善の余地が多分にあります。

バックエンド

言語はPythonで、フレームワークはFlaskを使用しています。
インフラはAzureを利用しています。
ローカル開発環境は、VSCodeを利用しており、拡張機能のRemote - Containersを利用してDocker単体テスト環境と繋げています。
Dockerでは、Pytestを利用し単体テストを実行可能にしています。またxxxを利用して、カバレッジの計測を行っています。
バージョン管理はgithubで行っています。また、CI/CDとして、githubアクションにより上記の単体テストが自動的に走るようになっており、カバレッジの計測結果も表示することが出来ます。また、mainへのプルリクエスト承認後、Webappsのステージング環境に自動的にデプロイされます。

③結合テスト

システムテスト

各システム(エッジデバイス・モバイルアプリ・バックエンド)毎にシステムテストを行います。システム要求に対するテストはVerificationと言います。これは、システムがシステム要求通りに作られたかどうかを確認するためのテストです。
システム要求図に対してテストケースを結びつけていきます。要求図は枝葉のように分解されてますが、上位の要求に対してテストケースを紐付けたのであれ下位の要求にテストケースを紐付ける必要はありません。
これにより、システムに対する要求を網羅的かつ体系的にテストすることができます。
あしらせでは、EAの拡張を利用して結びつけたテストケースをExcelに出力しています。出力したテストケースに対してテスト観点や手順と期待値を記載します。テストケースに結びつけた要求に下位の要求がある場合は、それら要求を満たせるようにテストを作成します。
最後にテストを実施して結果を記載します。

システムテスト仕様書

妥当性確認

システム要求はユーザー要求をシステム目線に変換したものですので、システムテストではユーザー含め各種ステークホルダの要求が満たされているかは分かりません。
そこで、ステークホルダ要求に対してテストを行います。これによりシステムがユーザー要求を達成できているかを確認します。これをVaridation(妥当性確認)と言います。
実施までの手順はシステムテストと殆ど同じです。ステークホルダ要求に対してテストケースを紐付けます。紐付けたテストケースをExcelに出力し、テスト観点・手順・期待値を記述します。
システムテストとの相違点はステークホルダ要求をユースケース毎に整理しているため、テスト自体もユースケース毎に整理しておくと、ユースケース毎に実施するテストが明確になります。
妥当性確認は実際のステークホルダに行って貰うことが望ましいです。
注意点として、このテストに合格したとしても各ステークホルダがサービスに満足してくれるかは別問題です(※ステークホルダ要求は自分たちで翻訳したものであることを思い出してください。)

システム結合テスト仕様書

④イテレート

これまで説明してきた内容をイテレートします。ユーザーからのFBが良くない、妥当性検証が未達、システムテストが未達の場合、適切にモデリングできていないことを意味します。これまでの内容でトレーサビリティは追えるので、問題箇所を特定し、これまでの内容を繰り返します。
これは、新規で機能を追加するときも同様です。

まとめ

最後まで読んでいただきありがとうございます。あしらせの開発フローを紹介させていただきました。あくまでも一例ですし、完成形でもありません。各々のプロジェクトにテーラリングされるべきですし、より良いフローにしていくべきだと思っています。
本ノートを通して、ものづくりとは？ゼロから作るとは？ということの概要を掴んでいただけたら幸いです。
最後に、あしらせでは一緒に働く仲間を募集しています。
スタートアップを創業しゼロから開発をすることは想像よりはるかに大変で、想像よりはるかに楽しいです。どの技術を採用するかや、環境整備等、すでに用意されていることも多いと思いますがスタートアップでは何も用意されてません。すべて自分で用意することになります。 また、ゼロから作るということは、自分がやってきたことがすべて跳ね返ってくるということで、言い訳も出来ません。しかしゼロからやることで点と点が繋がることが非常に多いです。
ものづくり、スタートアップ、あしらせに興味を持っていただけた方、上記の開発を一緒にやりたい、より良くしていきたい方、是非応募待っています！