VisasQ Dev Blog

ビザスク開発ブログ

ビザスクのQA業務を紹介

QAチームの2人目として、去年(2019年)の11月にQAチームにJoinした綱取です。

社会人になって10年以上経過しているのですが、そのほとんどをQA(ソフトウェアテストや検証も含めて)に関わっている者です。
ビザスクに入るまでは、お客様に常駐する形の検証(第三者検証)であり、その常駐先で実施しているのはウォーターフォール型の開発に合わせたテストのみでした。
そんな自分がビザスクで実施しているテストをご紹介させていただきます。
基本的な検証の流れであり、細かい内容は割愛させて貰いますが、ご容赦ください。

ビザスクでのテスト

テスト依頼

必要事項を記入する
Slackのワークフローより、テスト依頼用のフォーマットにテストを始める際に欲しい情報(リリース予定日、対象pullrequestなど)を入力して貰う。

タスクが積まれる
Slackのワークフローにて依頼されたものは、ClickUpというタスク管理ツールに積まれるので各担当者が順次着手していく。

テストを行う

テスト範囲を検討する
機能テストはエンジニア側でも検証済みので、QAでは機能テストで漏れている部分が無いか、使用してみて表示や操作、業務フローとしての違和感がないか(いわゆる非機能の部分)を主に気にして進めていく。
その理由としては、エンジニアによるテストの品質が高いからだ。
エンジニア側のテスト範囲が機能テストだけでなくシステムテストに食い込む位まで広範囲に実施しており、QA開始時点で「テスト対象となっている機能が動作しない」「画面遷移できない等の不具合(ブロックバグ)がありテスト進められない」事が殆どない。
また、QAやエンジニアのどちらが実施するテストであったとしても、テスト中に見つかった不具合を修正した際に異なる不具合が入り込んでしまう(エンバグ)事も少ない。

テスト実行は省力化する
テストしたい状況を準備したいときに、自動テストの一部を動かして済ませてしまう。
例えば、公募のステータス遷移が見たい、決済関連を見たいと言ったような異なる状況を用意する必要があり、その必要な数に合わせて公募の数も必要となることがある。
そのたびに手入力で作成することは少し手間であるため、纏めて自動作成することで手間を省いている。

不具合報告する
気になる挙動があれば不具合か仕様かの確認をSlackにて確認をしている。
不具合であっても現段階に直さなくても良さそうなものは別途GitHubのbugsに登録して、次回直すタスクとして積んでいく。

テスト終了する
最終的には検証内容を纏めたら、QA内で抜け漏れがないかを相互チェックのために検証内容のレビューを実施。
QA内のレビューが終わるとテスト終了となる。そして、次のタスク(検証)に取り掛かる。

テストの合間に行っている事(一例)

自動テスト作成修正
仕様変更があると当然のように自動テストも合わせて修正する必要があるため都度対応している。
また、テスト実装出来てない箇所(機能)もあるため徐々に増やす事も進めている。

業務改善
テスト依頼でSlackでワークフローでテスト依頼して貰う、依頼された内容をClickUpにタスクとして積んでいくというのは、もともと手作業で行っていた事でしたがZapierを使い自動化を進めている。
このような直接的なテストに関わる業務では無いけど省力化できそうなところを適宜改善している。

まとめ

今までは実施してきたのは計画→設計→実行→終了報告と一つ一つの工程が順次進んで、各工程は分業であり、別の人が実施している。というような進め方である現場が多かった自分としては、テスト工程を凝縮した感じ(各工程での検討→行動のサイクルが短くなった感じ)の進め方がとても新鮮だなと思いました。
とはいえ、紹介したような方法以外の方法(項目書を作ってから始めることもある)が良いと考えて実施することもあります。テストの仕方やテスト以外の業務も含めて改善するために、色々と試すことに抵抗がほぼ無い環境も面白いなと思います。