Help us understand the problem. What is going on with this article?

みんなでやろう、システムテスト!

テックタッチアドベントカレンダー22日目担当の@mosimosiです。

21日目は@mochibuta による golandの設定紹介 でした。
テックタッチでは特に希望がなければ開発チーム全体でIDEを統一し、ノウハウをうまく共有できるようになっています。
実際 @mochibuta によりチーム全体のgolandの活用が飛躍的に向上しました。ショートカット一つにしても、こういった共有って嬉しいですよね。

はじめに

みなさんKatalonというE2Eテストツールはご存知でしょうか?
Katalonは2015年1月にリリースされた比較的新しいテスト自動化ツールです。
まったく新しいツールかと思いきや、古くから実績のある元祖E2EテストツールSeleniumのコアエンジンを活用できるようにSelenium上に構築されています。
ガートナーレビューでも、負けず劣らずの評価を得ています。

Katalonはエンジニアはもちろんですが、非エンジニアも想定利用ユーザとして作られております。

この想定利用ユーザの広さがKatalonの魅力の一つであり、システムテスト運用に置いて利用ユーザの広さが如何に重要かという点をお話ししたいと思います。

(最初はKatalonの紹介記事を書こうと思っていましたが、少しづつ脱線してしまい、このようなまとめになりました。紹介記事はまた今度書こうと思います。)

想定利用ユーザが広い

Katalonはエンジニアはもちろんですが、非エンジニアも想定利用ユーザとして作られております。
例えばテストケースを書くエディターですが、それぞれに合わせたものが用意されています。
エンジニアはコードベースで記述できるScirptエディターを選択できますし、非エンジニアの方はGUIベースのManualエディターを選択できます。

Manualエディターを用いた場合でも、かなり複雑なテストケースを作成することが可能です。
alt

ではなぜ、システムテストの運用において「想定利用ユーザが広い」必要があるのかソフトウェアテストまで立ち返って考えてみましょう。

(最初はKatalonの紹介記事を書こうと思っていましたが、、、紹介記事はまた今度。)

システムテストの役割は何?

こちらにV字モデルというソフトウェアテストライフサイクル(STLC)の図があります。
最下部をCodingとして、右側上部へ湧き上がっている部分が「検証フェーズ」となっています。

alt

逆に、左上から最下部のCodingに向かっているのが「開発フェーズ」となっています。
「開発」と「検証」が対になっており、こちらをみるとシステムテストが要件定義を検証する為のものということが確認できます。

要件定義を検証するって何?

これはわかりやすくいうと、そのプロダクトがお客さんに届ける価値を検証すると言い換えることができます。

誰でもできる!

例えばGmailという製品を例にとってお話しすると、以下のような一つの価値を提供していると言えます。

「誰でも簡単に始められ、特別なソフトを必要とせずブラウザさえあればメールが送信でき受信できる。」

この要件、僕的には満たされていると思いますが、皆さんはどう思います?
もちろん結果は◎ですよね。
そう、システムテストって作り手じゃなくてもできるんです!

要件を検証するに当たって重要なのは、内部のプログラムがどのように作られているかではなく、ユーザ目線に立ち、要件を満たしていると言えるシナリオを如何に作り実行するか。ではないでしょうか。

「誰でも簡単に始められる」というのは、こういう事なんだ!というシナリオを作られる方がシステムテストの最適な担当者で、そこにエンジニアとしての知識はマストではないと僕は思います。

エンジニアがやるべきシナリオ

非エンジニアのシステムテストへの関わり方についてお話ししましたが、もちろんエンジニアもシステムテストに置いて重要な役割があります。

もう一度Gmailの価値をみてみましょう。

「誰でも簡単に始められ、特別なソフトを必要とせずブラウザさえあればメールが送信でき受信できる。凄くセキュアな環境で。」

最後に文章が追加されています。

製品の要件の中には当たり前のように、セキュリティ、可用性などが入ってきます。
こういった部分を検証するシナリオ作成と実行にはエンジニアとしての視点が重要になってきます。

alt

ユーザの中には、優良なユーザだけではなく悪意のあるユーザもいます
そんな人たちが取るべきシナリオを想定して、如何にブロックするかもシステムテストが担保するべき領域ではないでしょうか。

システムテストは全員で向き合う

システムテストの領域ではエンジニアと非エンジニアの境界線などはなく、全員の共通認識としては、自らのプロダクトの価値を検証するためのテストという位置付けであり、それぞれに役割があります。

役割を持つ人が全員コードが書けるわけではない。
ただその人たちの品質を上げていこうという気持ちに応えるために、Katalonは利用ユーザの裾野を広げているのだと、僕は思います。

alt

つづく

今回、非エンジニアと表現した人の職種は何でしょうか?
一般的にはプロダクトチーム内のQAを筆頭にスモールチームではPM、PdMと言う方達も思い浮かべると思います。
では、デザイナの方がシステムテストにどの様な役割を持てるでしょうか?

システムテストに限らず、テストの領域ではそのテスト設計や運用の良し悪しは費用対効果で語られることがあります。コストを如何に抑えるかは、全てのテスト領域においていつでも議論されます。

システムテスト(自動化)においてのコストはやはりメンテナンスコストになると思います。日々変化していくプロダクトにおいて、シナリオに正常な検証機能を持たせるのは大変です。

この辺りの鍵を握っているのはデザイナの方々だと僕は思っています。
次回はこの辺りをお話しできればと思います。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした