初めまして、品質向上チームの柳澤と申します。
ウェルスナビではQAエンジニアとして、システムの品質向上に繋がるQA業務や開発プロセスの改善に関わっています。またチーム内ではテスト自動化も進めています。
ウェルスナビにおけるテスト自動化までの苦難の道のり
この記事では、テスト分析に焦点を当てて、入社したばかりの私が関わったプロジェクトでのテスト活動についてお話しします。
はじめに
私はこれまでシステム開発に十数年、その後QAエンジニアとして3年のキャリアを経て2023年4月にウェルスナビに入社しました。 金融業界に携わったのは初めてで、お客様の資産に直結するミッションクリティカルなシステムに関わることも初めてだったので入社した時は緊張と高揚が入り混じった状態でした。
入社して1ヶ月後に大きな開発プロジェクトに関わることになったのですが、既存システムの理解不足、ドメイン知識不足が最初の壁になりました。 ウェルスナビは新入社員へのオンボーディング資料がしっかりしているので、入社直後にシステムの全容や関連する業務知識を学んだ上で実務に入るプロセスになっています。ただ、QAエンジニアとしていざテストを考えるとなったとき、当然システムのさらに奥深くの詳細な機能や業務を理解しないといけません。
テストの初歩から考える
自身に色々足りていない状況で何から手をつけようかと考え、
QAエンジニアとして初心に立ち返り、JSTQBのテストプロセスに則ってテスト分析から始めました。
まず手をつけたのは、テストベースは何かを特定し整理するためのテストベース集めでした。(要件定義書、仕様書、お客様向けのFAQ、過去のインシデント...)
テストプロセスにおけるテスト分析はどんな工程かというと、テスト対象のソフトウェアについて何をテストするかを正確に把握するためテストベースを整理し分析するプロセスです。
参考：ブロッコリーさんのブログ
テスト分析での問題
テスト分析に取り掛かっている段階で次の問題に直面しました。
情報が散在していて、理路整然と機能を把握してテストケースに落とし込むことが難しい
1で各ドキュメントからテストケースに落とし込んだあとのトレースが難しくなる可能性がある
UATのもとになる業務フローがわからない
1は、断片的な情報がConfluenceやNotion,Google Driveのあちこちに散らばっていました。さらに、既存の仕様書に対して開発範囲の情報が反映されるのでなく、開発部分の情報が新しい資料として作成され、見るべきドキュメントがかなり多い状況になっていました。そのため、機能を正確に整理して理解することが困難でした。
また、2に挙げたようにあちこちにある情報もいつアップデートされるかわかりません。
そのため、情報をもとにテストケースを作成した後でアップデートされたり整理されることで情報自体がなくなると、テストケースが何を根拠に作られたものかを追うことができなくなってしまいます。
3について、UATを実施する上では業務フローを理解したいのですが、情報が散在していて業務の流れの全体像を把握できない状況でした。
機能・業務の見える化
上記の問題に対して、次の対策をしました。
散在している情報を整理して、機能一覧の形で整然と見える化
お客様目線、その他業務遂行のためにシステムを利用する社員の目線での業務フローを作成
こうして作成した機能一覧と業務フローと、前述のテストベースを合わせて、何をテストするかがだんだん把握できる状態になり、ここからテスト観点を作成していきました。
機能と対になるテスト観点
業務フローに基づき、システム利用者が実施する運用の流れでINPUTに対してOUTPUTを確認するテスト観点
過去のインシデントから、デグレが発生していないことを確認するためのテスト観点
上記の取り組みをしたことでようやく何をテストするかが見えてきましたが、別の側面での狙いもありました。
1.テスト実行担当者が、受動的・機械的にテストケースを実行することを避ける。
テストケースの根拠となる要件・機能の振る舞いを俯瞰で把握してからテストを実行するとします。そうすることで、要件や機能の背景にあるものと実際のソフトウェアの動きに一貫性があるか、まで考えながら確認できるようになります。
2.今後、対象の機能に変更が発生したら関連するテスト観点とテストケースを流用することでテスト活動の時間短縮を図ることができる。
こうしたテスト分析を経て紆余曲折あり、2023年12月現在ようやくテストを終えることができました。
よかったこと、学び
今回担当したプロジェクトでのテスト活動でよかったことは、業務フローを作ったことで機能や業務の理解が深まったことです。
業務の流れで誰がどの時点で何の機能を使うのかを整理する過程で、その背景まで知ることができ、テストでその機能を使うときにシステムを使うお客様や社員の利用シーンを想像しやすくなりました。また、ユーザー目線でのテストにおいての気づきや観点の視野を拡げることができたのがよかったと思います。
今後の課題とやってみたいこと
今回のテストで気づいた課題と、今後やってみたいことは以下の３点です。
成果物のメンテナンス
当たり前品質の強化と魅力品質への着手
システムの本質を理解する
今回作成した機能一覧と業務フローは当然今後も変更が発生することになるため、メンテナンスをしていかないと資料が陳腐化してしまいます。それを放置してしまうと、次に大きなプロジェクトが発足して業務フローが必要となったときに同じことが起きる可能性が大いにあります。変更の発生からメンテナンスまでのフローは今後の課題かなと考えています。
２点目として、今回はとにかく機能を正しく理解することに時間をかけて機能的な品質の担保、言い換えれば当たり前品質の保証に注力しました。 今後は、安全性の評価等、当たり前品質評価の強化とともに、弊社の魅力品質とは何かを明確にして非機能や異常系の範囲にも着手していきたいです。
３点目のシステムの本質を理解する、ですが、今回業務フローを作ったことで機能の背景を知ることができましたが、それもまだほんの一部です。
システムを機能として正しく動作していることを確認するだけでなく、
サービスとしてそれが正しいか
お客様が期待する品質なのか
というような観点で評価し、よりお客様にご満足いただけるサービスを提供しする一端になればと思います。
明日は、エンジニアリングマネージャー 伊代田 の「ウェルスナビのWebフロントエンド開発チームのEMの仕事」です！
お楽しみに！
📣ウェルスナビは一緒に働く仲間を募集しています📣
https://hrmos.co/pages/wealthnavi/jobs?category=1243739934161813504
著者プロフィール
柳澤 宏之
新卒で入社した会社で15年業務アプリケーションの開発全般に関わり、
その後の転職でプロダクト・プロジェクトの品質評価の業務を経験して
2023年4月にウェルスナビにQAエンジニアとして入社。
他社の障害事例、アプリレビュー、デザイン、動線...日常目にするあらゆるものに品質向上のヒントがあると思って情報収集を心がけてます。
