オープンリソースの新人プロジェクトブログへ、ようこそ。
今回のブログは、各チームの取り組み状況をレポートするブログ、
「●チームの取り組み」シリーズで行ってみたいと思います！
今回は献立提案アプリ「マルレ」を開発中のAチームの取り組み状況を
紹介していきましょう。
数回前のブログで中間報告レビューの臨むAチームの様子を紹介しましたが、
Aチームはこのレビューに向けてすでにテストフェーズに入っており、
さまざまなバグを抽出してその解決に取り組んでいる、という話を、
前回のこのシリーズでお伝えしていたかと思います。
レビュー後もテストは引き続き行われており、
通常業務で多忙を極めるY.K以外の3名のメンバーを中心に、
互いにバグの内容を共有しながら、分担してバグの解決にあたっています。
テストを続けていると、思いもよらないバグが発生したりします。
たとえば画面遷移を何度も繰り返していると、
メモリの使用率が延々と増えていき、最終的にはアプリが落ちる、
なんて現象も確認することができました。
メモリの使用率を上げないようにするためのプログラムを加えることで、
この問題は回避できましたが、
これは完成したアプリを実際に使ってみないとわからなかったバグと言えそうです。
他にもアプリが落ちる系のバグは、いくつか発見することができました。
各画面から「最初に戻る」のボタンを押した際に、
なぜかアプリが落ちる、という現象が発生していました。
これも全ての機能を統合して、実際にアプリとして使ってみて、
初めて気づいたバグということになります。
これもプログラムを変更することで、解決することができました。
ネットワーク接続の状態に伴うバグも、いくつか確認されました。
ネットワーク接続が必要でない画面から必要な画面への遷移をする際、
「ネットワーク接続しますか？」的なアラートを表示させているのですが、
接続した後もそのアラート表示が消えない、という現象がありました。
また本来であればネットワーク接続がされていないと遷移できない画面に、
接続がなくても遷移してしまう、という現象もありました。
これらのバグも、プログラムの修正によって回避することができました。
Aチームが行っているテストの手法は、「モンキーテスト」だそうです。
通常、システムやアプリケーションの検証やテストを行う際には、
「テスト定義書」というものを作成し、それにのっとってテストを実施します。
それに対して「モンキーテスト」というのは、
一般に操作手順やテスト箇所を定めず、実施者がその場の思いつきで操作してみる、
という手法のことを指します。別名「ゲリラテスト」とも言うそうです。
この手法のメリットは、思い込みによる予断を排し、
開発者の思いもよらない不具合を発見できることがあるところだそうです。
通常業務の中でも、こうしたテストはほぼ必ず行われますが、
Aチームのメンバーは通常業務での経験が浅い新人ばかりです。
「テスト定義書」の作成方法も先輩たちから聞いてやってみる、
という形にならざるを得ませんから、
自ずと「モンキーテスト」形式のテストが中心になってしまいます。
しかしながら結果的に、この方式でテストを行っていったことで、
「こういうことがバグとして発生することがあるんだ」
という経験を増やすことにつながった、とも言えると思います。
テストも次第に佳境を迎え、いよいよアプリの完成に近づいた感があります。
12月の終わり頃には、最終報告レビューに臨むことになります。
もちろんそのレビューの報告もさせていただきますが、
アプリが完成し、App Storeへリリースされるのが今から楽しみですね！