ソフトウェアの品質向上のためのQA手法

こんにちは、ココネQA室のIです。
今回は、ココネにおける品質保証にフォーカスし
ソフトウェアの品質向上のためのQA手法の一部を紹介してみたいと思います


ソフトウェアテストの7原則の話をしようかとも思ったのですが、もっと(会議室じゃなくて!)現場で起こっていること、現場で役に立つ考え方を紹介できればと。

※「QAって何?」と思った方は、是非ともコチラ(以前のQAの投稿)をご覧ください。

①品質を向上させる為にできること

ひとえに「品質」と言っても、コンテンツや組織によっても様々なイメージがあると思います。
ここでの「品質」は「エンタメアプリにおいて、お客様が操作される状況で遭遇する不具合の多寡」と置きます。つまり、その不具合を最小限にすることが品質を向上させることであり、QAに求められる役割ということになります。


そのためにQAが行うこととして、リリースされる前の動作チェック(テスト)はもちろんですが、

・そのテストをいつからいつまで何人でやるのか
・何に沿ってテストを実行するのか
・テストをより効果的に行うにはどうすればよいのか
・テストの結果がどうであればゴールなのか

…などなど、動作チェック前に行う様々な準備があります。

 

この「準備の段階」から品質を高めることができると考えております。
そしてそんな想いを以て日々取り組んでいることや考え方について、また、テスト実行時に意識するべきポイントについても(せっかくの機会なので)頑張って言語化していきたいと思います。

②事前準備編(設計・スケジュール)

どんなことでも準備は必要なように、QAでも準備がとても重要です。
テストの成否を分けると言っても過言ではありません。

 

ココネではテスト前の準備として以下のことを心がけています。

1:バッファのことを忘れない
2:仕様の裏を考える

1:バッファのことを忘れない

QA実行準備の第一段階として、工数を見積もる必要があります。
ある程度の経験をお持ちの方であれば、施策の内容からどれくらいのQA期間になるかが算出できると思います。

・画面数と機能数
・機能の難易度
・影響範囲
・不具合がどれくらい発生しそうか、起票と修正確認にどれくらいかかるか
・実装担当者・担当テスターによる違い

上記のような情報が不足していたり、不慣れな時は難しいですが、
案件に慣れてくれば「大掴みでざっくりとした工数出し」はある程度できるようになります。
しかしながら、そんな時こそ注意が必要です。

 

実測値に近い工数が分かるからこそ、正確な見積もりを目指してしまいますが、それ故についバッファの確保を失念してしまう場合があります。
そして、そんな時に限って複数の予期しなかったQA案件が重なったり、緊急のQA案件が差し込まれたりします。
こうなると、想定工数内ではちょっとしたトラブルを吸収できなくなります。

 

もちろん残業対応やスタッフ増員で乗り越えられる可能性はあります(きっと皆さん経験あると思います)が、集中できる作業時間の限界もありますし、次の案件の遅延に繋がってしまうリスクにもなります。

 

慣れてきた時こそ、全てのピースがうまくはまった時のスケジュールではなく、一定の不確定要素や発生し得るリスクを飲み込んで進行できるスケジュールを提案できているか、振り返ってみましょう。
リリース直前の工程であるからこそ、QAの遅延はサービスの遅延に繋がります。過剰なバッファを確保することはナンセンスですが、必要最低限はトラブルを吸収できる時間を確保すべきです。

 

(補足)
一部には「バッファ込みのスケジュールは仕事の緩みにつながるのでは?」と考える人もいるかもしれません。
しかし想定よりも早くテストが一巡終わったのであれば、探索テストで『漏れている箇所がないか』を確認する時間を増やすことができ、さらに品質を上げることに繋がります。
決して無駄にはなりません。

2:仕様の裏を考える

テストケースを設計する前に、テスト対象の仕様把握は当然行います。その際、「書いてあることをそのまま書き起こすだけ」でテストケースを作成するとテストの抜け漏れが多くなりがちです。

 

例えば、「イベントページで【参加】を【タップ】すると【イベント参加中】になる」という機能を素直にテストケースにすると、

・イベントページに【参加】ボタンが表示されていること
・【参加】を【タップ】できること
・【参加】が【イベント参加中】になること

というテストケースが出来上がります。
ちょっと考えると「イベント前後」の表示出し分けが増えるかもしれません。

 

この時、仕様の裏(仕様書には書かれていない条件や状態)を考えてみてください。その際出来る限り「ユーザーがどのような操作をするか」を想像すると、抜けていそうな観点に気付けると思います。そうすると、

・参加中に参加ボタンタップでキャンセルできる?
   →連打による連続処理への対応
・タップ時にSEって再生される?
   →サウンドチェック
・このイベントってまた開催される?
   →参加状態の保持確認

など、この単一の機能だけでもこのようにいくつか観点が出てきます。
人によっては「そんな観点、当たり前じゃない?」という意見も出るかもしれません。
ただ、QAとしての習熟度がない状態でテストケースを作成すると、こういった観点が漏れてそこが後々本番障害となる可能性があります。

また仕様書には書かれていない条件や状態を洗い出す上で、実装の仕組みを理解することは大変重要です。
開発者がその機能実装を実現するために「どういった作り方をしたのか」は、「どういう不具合が発生しやすいか」という傾向判断に役立ちます。

 

例えば「〇〇の画面の作りと同じように実装した」とあれば、「『〇〇』で報告された不具合と近いものが発生する可能性が高いのではないか」と予想を立てることができ、対応するテストケースの作成に繋がります。
ただそのためには、実装者(多くの場合は開発者)とのコミュニケーションが重要です。

 

実際これまで何度も、実装された内容について開発者の方から説明してもらい、その中で「ならばこういった場合は…?」と、動作の深い部分や見落としがちな影響範囲をカバーすることができました。(いつも分かりやすい言葉で、過去事例なども引き合いに出しつつ丁寧に説明してくれる開発の皆さんに感謝です)

 

もしQA関係者の方でテストケースの抜け漏れを改善したいと考えているようでしたら、実装内容について開発者とたくさん話をするのがお薦めです。(また開発者の方でしたら、QAに実装内容を伝えることでテストのカバー率が上がるので、やはりオススメです)

③テスト実践編

さて準備を進めたら、後は実行です。
テスト実行中に心がけていることは以下の2つです。

 

1:テストケースの実行だけがテストではない

2:施策担当外の関係者に説明してみる

1:テストケースの実行だけがテストではない

テストを実行する際にテストケースに沿って進行すると思います。
その際に、「事前準備で「仕様の裏」まで考えて組んだテストケースなのだから、安心してテストケースだけ進行していれば不具合の取りこぼしなどありようもない」
などと考えてテストを実施するのは危険だし、とてもつまらないのではと思います。

 

「攻略通りに進行するゲーム」や「レシピ通りに作る料理」を経験したことがある人なら分かると思いますが、ただ手順をなぞるだけでは「気付くこと」が少ないのではないのでしょうか。
「こうじゃないかな?」と想像して苦心するゲームは記憶に残り、「こんな味になるかな?」と作った料理の方が楽しいように、自分の想像力が介在すると思いがけず良い仕事になります。

 

それはQAでも同じだと考えています。テストケースに記載されている事象をなぞるだけだと「その範囲」の不具合は検出できても、「+α」の不具合にたどり着けないことがあります。
またケースの設計時はあくまで仕様書を参考に行いますので、実際の端末上での操作を行うことで気付ける点があります。

 

例えば

・ボタンの配置が誤タップを誘発する
・1画面に収まっていないために記載を誤解しやすい

などはケースに起こされていない場合もあります。

 

「テスト対象の機能が何をもたらすのか」だけでなく「お客様がどんな目的でその機能を使って、どんな気持ちになれるのか」まで想像しながらテストにあたると、思いがけない不具合の再現手順に辿り着いたりします。

 

勿論、仕様の相違や影響範囲の大きな不具合の検出、期日の遵守は大前提ではありますし、QAへの期待値の多くはそこだと思います。
リソースは無尽蔵ではなく、最適なパフォーマンスを目指してはいますので、あくまで「最大限」にはなってしまいます。
それでもテストケースから少し外れて、ユーザーのプレイを想像しながら探索テストに取り組んでみる余裕を見付けると、更に品質を高めることに貢献できると思います。

2:施策担当外の関係者に説明してみる

施策や実装の担当者と話をしてテストを進めることはよくあることですが、実はその担当外の方々と「実は今こんな案件があるんですよ」程度でも情報共有を行うと、思わぬQAのヒントを貰えることがあります。
先述のように開発者から実装の仕組みを伺った上で、そういった実装になっていることを別の人に話してみる。すると予期しない影響範囲の話が出てくることもあり、それが結果として観点漏れを防ぐことになる場合があります。

 

一人のQAがあまねく影響範囲を想定できればそれに越したことはないのかもしれませんが、実際のテストの現場では様々な人の知見で救われています。このような経験は真摯にQAに向き合ってきた人ほど実感しているのではないのでしょうか?

 

また担当外の人に説明することのもう一つの大きなメリットとして、自己の理解が深まり、観点の漏れに気付かされることがあります。

 

頭の中で理解しているつもりでも、人に説明する時や相手からの質問に返答する時に理解が十分でないと、言葉に詰まったり「あれ?どうだったっけ?」と疑問に思います。もしそうなったのであれば、恐らくその辺りに確認漏れがありそうだと判断でき、その観点を追加したテストを実施することで不具合を検出することもあります。

 

相手に理解してもらおうとテーマを絞り順序立てて説明することは不具合報告の質向上にも繋がり、おすすめです!

 


ココネでは一緒に働く仲間を募集中です。

ご興味のある方は、ぜひこちらの採用特設サイトをご覧ください。

https://www.cocone.co.jp/recruit/contents/

Category

Tag

%d人のブロガーが「いいね」をつけました。