テスト自動化で少し困ったこと
伊藤忠テクノソリューションズ株式会社 Buildサービス推進チーム クオリティエンジニア(QE)の 日野杉です。前職まではQA(Quality Assurance)で品質関連の仕事に従事していました。
今回はテスト自動化で困ったことと解決方法について備忘録として記載します。
そもそもQEって何?
QAとどう違う?SETのこと?疑問に思った方はいると思います。
諸説ありますが、Buildサービス推進チームでは下記の記事を見ていただけるとわかりやすいかなと思います。(ステマ)
従来のQAと比べると、各QAの職種要素を含めたテスト自動化エンジニアと呼ぶと分かりやすいかもしれません。
ポイントとしては「開発と同じチーム」であり「実装と並行して動く」ことです。
これは、従来のQAと違うあり方なのですがメリットもデメリットもあります。ただ、今回はその話をすると長くなるので次回以降に!
今回はE2Eのお話
前提として、今回のE2Eの話は
Testing Library
Cypress
上記2点を使用しています。
テスト自動化を進めるにあたって困ったこと
例えば、下記のようなサンプル入力フォームがあるとします
今回は、この項目に対して「無効なメールアドレスを入力されたとき、メッセージが表示されること」という自動テストを記述したい!とします。
この時、テストケースとしては下記のような感じになると思います
前提:項目が存在していること、メールアドレス欄が未入力であること
操作:メールアドレス入力領域に「test@」を入力、フォーカスを項目から離す
結果:有効なメールアドレスを登録してください と表示されること
手動テストだったら一瞬で終わるケースですね!
他にも、テストの粒度をあげていくと「エラーとなること」とか「赤文字のメッセージであること」とかが期待値に挙げられますが、今回は上記で行きます。
QEは上記のようなケースも基本的には自動化していきます。
今回のテスト自動化は画面の項目に対して要素を特定、取得し、メッセージが表示されているかを確認します。
各要素の取得方法はcy.get(Cypress純正)かcy.findByXyz(testing library)を利用します。フロント側の実装パターンを見極めてどちらかを採用するようにします。
調べたところ、Nameがないので、Roleのalertを取得します。
各要素の特定をページモデルで記述し、それらをパーツとして使っていくと言う感じで進めます。
// ページモデルSample
export default class SignInPage {
// 各要素の取得方法はcy.get(Cypress純正)かcy.findByXyz(testing library)を利用
// フロント側の実装パターンを見極めてどちらかを採用するようにする。
// メールアドレス入力テキストボックス
static get mailAddressTextBox() {
return cy.findByRole('textbox',{name:'メールアドレス'});
}
// エラーメッセージ表示ラベル
static get failMessageLabel() {
return cy.findByRole('alert');
}
そしてテスト実行文はこちら。
('testSample | バリーデション - メールアドレス不正', () => {
// GIVEN ログイン画面にアクセス可能
// WHEN メールアドレステキストボックスにメールアドレス形式ではない文字列を入力
// THEN "有効なメールアドレスを登録してください"がメールアドレス入力テキストボックスの下にエラーメッセージとして表示されること
SignInPage.mailAddressTextBox.type('test')
SignInPage.failMessageLabel.contains('有効なメールアドレスを登録してください')
});
上記のテストはPASSされますがここで一点困ったことが(やっと本題です)
contains と eq の使い分けです。
例えば contains の場合は 画面に
「有効なメールアドレスを登録してくださいって言ってるじゃん」みたいな文字列が画面に表示されていても PASS しますが
eq だったら上の文字列だと FAIL します。
だったら eq の方が正確でよさそうに見えますが、ちょっとエラーメッセージが変わっただけでもテストを変えなきゃいけなくて、テストの保守性が下がってしまう欠点があります。
例えば自動テストでは
「有効なメールアドレスを登録してください」を正とした時に
画面側では
「有効なメールアドレスを登録してください。」
と句読点追加されるだけでFAILします。
正確性と保守性のどっちに倒すか、なので正解はないと思っております。
が、これは困りました。
テスト観点としては正確性の方を大事にしたいです。
ですが、QCDのバランス・保守性で考えると、ユーザにわかりやすいメッセージが表示されていればオッケーとしたいです。
結局どうしたのか
プロダクトオーナーやソリューションオーナーに確認をし、保守性を重視していくことにし、containsで進めていくことに。
まとめ
この辺はどっちに倒すかをプロダクトオーナーやPMに適宜確認して進めてみようねって心構えでコミュニケーションとっていけば良さそうですね。
と言った感じでテスト自動化は細かい作業を積み重ねてやっていきます。