検証のために目的を意識すること

Hiroyuki.Ito
WingArc1st Inc.
Published in
Dec 21, 2022

こんにちは。イトヒロと申します。

これはウイングアーク Agile and DevOps Transformation Stories のAdvent Calendar 2022、2022年12月21日の投稿です。

1年ぶりのブログ

去年私は「 第三者検証と、社内QA検証の違いをフラットな目線で考察してみた 」というブログを投稿しました。

これは「ベンダーの立場から検証をしたい」という思いから転職した私が、比較をしてみたという記事です。良ければ読んでみてください。

そんな私がベンダーという立ち位置に来て1年が経ちました。
この立場から検証をすることによって、より意識することになったことを書いていこうと思います。

今回は検証・QAの仕事を始めたばかりの人、テスターとして頑張っている人に向けて書いています。

自分の仕事をする上で良く考えることとは?

私は検証活動を行う上で常に考えていること、気を付けていることがあります。こう書くと大げさに思うかもしれませんが、いたって普通のことです。
それは検証対象の「目的」を意識することです。

何を目的として作られた製品・サービスなのか。機能なのか。どんな意図をもって設計されたのか。

これを私は意識しています。

Photo by Aron Visuals on Unsplash

検証は仕様どおりの動作を確認するだけじゃない

何故意識するのか?それは仕様を超えて検証観点を持つためです。

検証の役割として第一に品質の保証があります。その方法の一つとして仕様どおりの動きであるかを確認します。
これは基本的な検証活動ですね。

ただ、検証の役割は仕様どおりの動作を確認するだけに留まりません。ここからもう一歩踏み込んで、そもそも仕様が好ましいものであるのか、要件・企画の意図に沿ったものなのかといった視点で考えることも必要です。(現場によって、求められている活動の範疇を逸脱していないかという前提もありますが)

仕様と合致していても製品の設計思想・目的から外れてしまう場合がある

例えば、「非エンジニアの方でも使いやすい・わかりやすい製品」というコンセプトで設計していたはずが、開発を進めるにつれてエンジニアからの要求・使いやすさを盛り込み過ぎてしまい、エンジニア向けのUIになってしまった場合など。
これが仕様書的には合致しているが、設計思想とズレたUIになってしまったということになります。

こういった場合に製品の目的に立ち返る視点を持ち、指摘していく為に「目的を意識する」ことが大事だと思います。

この他にも通常の不具合検出、不具合起票時にも私は目的を意識します。
「こういう目的の機能だ」という認識を持っておくと不具合起票時の情報整理に役立ちます。
不具合が複合的なものだと混沌として整理しづらくなるのですが、前述の認識を持っておくと、達成されるべきゴール(目的)に対してNGだからという一貫した状態をもって記載しやすくなるのです。

※仕様だけを頭に入れた状態の場合、1つの不具合によって複数の仕様に対するNGが発生していると、不具合チケットにあれもNGこれもNGと記載することになって「情報は正しいけど余計な情報が多い」というチケットになることもあります。

とはいえ意識するだけでは難しいこともありますね

目的以外にも、もう一つ意識していることがあります。
それは、ユーザーがどんな使い方をするかを考慮することです。

使い方の幅が大きくユーザーにゆだねられるもの、ユーザーが自由な発想で組み上げるという利用が想定されるサービスはユースケースを考えるのがとても難しいです。
私の携わっている「dejiren」というサービスがまさにそれです。

dejirenは、普段クラウドサービスを用いて行っている仕事を手順化し、「バーチャルアシスタント」と呼ばれる仮想のアシスタントに組み込み、お仕事を任せるというサービスです。

dejirenはMotionBoardなどウイングアークの製品に限らず、他社の様々なクラウドサービスと連携して動かすことができるのですが、1つのバーチャルアシスタントの中で複合して複数のクラウドサービスに繋ぐことができるので、出来ることの幅が広くて広くて…
可能性を考えるのが楽しいやら、手が回らなくて苦しいやらで、複雑な思いで日々検証しています。笑

最後に

今回お話した「検証の為に目的を意識する」ということは私の役割がステップアップしていく中でも変わらず指針として残り、大切にしていることです。
テスターでもテストデザイナーでもテストリーダーでも変わりません。

ただベンダーとしての立っている今、より視野を広げる必要を感じたのは前述のようなユースケースについてです。
ここを広げていくには想像力だけでは足りません。
実際のエンドユーザーから情報を得ることが必須だと考えるようになりました。
より良い製品の為に自分からエンドユーザーに近づくこと。
ここにもまた、私はベンダーと第三者検証の違いを見ています。

ベンダーの側に立ち、思い返す中でまだまだ勉強することがあるなとやりがいを感じる1年でした。

dejirenサービスのQA担当としてこれからも、目的を意識した検証活動をより一層頑張っていきます!

--

--