2021年に出会った障害と2022年の目標

こんにちは、カトです。弥生でQAエンジニアをしています。

2022年、新しい年になりました。目標を立てる人も多いですね。 目標は「SMARTゴールで設定」、「モチベーションがあがる目標」が良いと言います。しかし、現状を正しく認識しないと、適切な目標を立てることはできません。 ということで、私が2021年に出会った障害をふりかえり、同じことを繰り返さないように目標を立てていきます。

弥生開発者ブログを参考に、ふりかえっていきます。

障害ふりかえりに向き合う

「カレンダーがケーキに見える」

カレンダーとケーキを誤認?
安心してください。障害票のタイトルではありません。

製品・サービスの画面に、日付を指定するためのカレンダーアイコンがあります。カレンダーアイコンをクリックすることにより、カレンダーを表示し日付を選択する仕組みです。
今回の対象は、"あの"カレンダーアイコンです。

テストをしているとき、システムごとにカレンダーのアイコンが異なっていることに気がつきました。
ログを確認したところ、カレンダーアイコンを使っている1つのシステムで、カレンダーアイコンを「マンスリーカレンダー」の絵から「日めくりカレンダー」の絵に変更していました。
その変更ログに残されていたのが「カレンダーがケーキに見えるため、アイコンを変更」というメッセージでした。

なぜサービスごとにカレンダーのアイコンが異なってしまったのか、障害ふりかえりをしました。

「類似機能なのに、処理結果がちょっと違う」

似ているだけではダメ?
追加機能開発において、「既存の処理と同じように」動作するように実装することがあります。
まるっきり同じ処理であれば、コードを複製するのではなく、同じ処理を呼び出すことで対応できますが、何をどの順序で呼び出すのか?流用できるところと流用できないところはどこなのか?の見極めをしなければなりません。
闇雲なコピー&ペーストでもいけないし、安易な呼び出しでもいけません。

テスト作成時、既存の処理のテストケースを見て、入力と出力が同じ結果になるようなテストパターンを検討しました。
しかし、過去に作成していた既存の処理でのテストには漏れがありました。そのテストが漏れていたパターンにおいて、既存機能と追加機能で、同じ入力をしても出力が異なってしまうという事態が発覚しました。

なぜ予定していた記述型テストで障害検出することができなかったのか、障害ふりかえりをしました。

 運用開始後、境界値が「こんにちは」

境界値 隠れ身の術?
設計書に書いていない境界値があることは承知しています。「設計書に書いていないからテストしない」ではなく、「設計書に書かれていない情報を引き出して明確にする」ことが、テストの活動の一つだとも思っています。
境界値テストのイメージ
2値を選択するか、3値を選択するかという内容は、今回は割愛します。

今回の対象は、画面入力した文言に対し、内部でIDを採番してデータを持つ機能です。 IDの最小値は1。最大値は、手動でテストできない数となっていました。
最大値で登録できることの確認はコードレビュー・単体テストにて実施しました。手動テストでは、1つめの登録、2つめの登録を確認しました。
他のテストにおいても登録をしているため、テスト期間中に少なくても10回の登録は実施しています。
これで、この登録におけるテストに漏れはないと思っていました。

ところが…

突然、なにか出てきた!
しばらくすると、テスト環境で、「入力した文言ではなく、IDが表示される」という事象が発生しました。 テストをしたはずなのに、なぜ?と思いながら障害票を起票、エンジニアに調査をしてもらいました。

調査結果は、「IDを金額と同じような3桁区切りの情報として扱ってしまっている箇所があった。IDが1000以上の場合に、区切りなしの値と区切りありの値が不一致とみなされ、IDに紐づく文言ではなく、IDそのものを表示してしまっていた」ということでした。

なぜ予定していたテストで検出できなかったのか、障害ふりかえりをしました。

 ふりかえりをまとめる

「どのチームが作った」「その時、誰が担当していた」という情報は、弥生の製品・サービスを使っているお客さまにとっては関係のないことです。
チーム弥生として、お客さまには、「かんたん・あんしん・たよれる。」を提供し続けなければいけません。

ふりかえりから、2022年の目標

2021年の障害ふりかえりに向き合ってきました。
「ふりかえりは大事」であることは理解していますが、真剣に向き合うのは、大変です。

ふりかえりから、2022年の目標は、

製品・サービスの、現在を見る/過去を見る/周囲を見る


とします。

まだ、この記事の中で、私の目標は、SMARTゴールである、Specific(具体性)、Measurable(測定可能)、Achievable(達成可能)、Relevant(関連性)、Time-based(期限)は明確になっていません。
これは、また次の機会としましょう。
この目標を達成するためにやるべきことを落とし込んでいけば、SMARTゴールになっていくはずです。
目標のためにやるべきことを具体的にし、現実的に実践が可能なのかどうかを考えて、製品開発に取り組んでいきます。

さいごに

弥生の開発メンバーはどんな目標を立てているのでしょうか?
2022年最初のもくテクは、1月20日に開催です。テーマは、「新年の抱負を語ろう!LT」
さまざまな分野やキャリアのエンジニアの目標を聞いて、自分の目標をブラッシュアップしていける機会になります。
ぜひご参加ください。 mokuteku.connpass.com

弥生では、「かんたん・あんしん・たよれる。」を実現するために、一緒に、弥生の製品・サービスの品質を追求するメンバーを募集しています。
herp.careers