ソフトウェアテスト - クライングドーベルマン

ウェブユーザビリティの法則 読了

一番重要なのは、ユーザーに考えさせないこと。よくある「クリック回数を何回に抑える」は間違い。
ユーザビリティテストでは、テスターに「今考えていることは何ですか」を常に聞きながら、なぜ、その操作を行ったかを説明してもらうということを実施する。

湯本さんにサインもらいました

現場の仕事がバリバリ進む ソフトウェアテスト手法の著者の湯本さんにお会いする機会があったので、サインをいただきました。

超うれしい！そして湯本さんはいつも話が面白い！またいろいろ教えていただきました。これから先の道も見えてきました。
目指すぜテストマイスター！！

検証対象によるテスト戦略の違い

ソフトウェアテストを行う対象によって、使用するテスト技法は似通っているが、使用するテスト戦略は変わってくると思う。

例えば、
IT家電の特徴は「納期優先」
商機が夏冬のボーナス、クリスマスに集中するので、発売日を遅らせることは最終手段となる。バグの多い機能を削ってでも安定させてリリースさせるようなテストを計画する。

エンタープライズの特徴は「処理速度優先」
システム構築の目的は「業務効率改善」がほとんど。現状3日かかる処理が短縮されない限り、リリースする意味が無い。

WEBシステムの特徴は「セキュリティ優先」
利用者が他のシステムに対して段違いに多いので、ハッキング対策が必須になる。XSSやSQLインジェクション、その他フィッシング対策等の手を打たないとデータ改ざん、情報漏えい、につながる。

と、言えるんじゃないかなー、と最近考えている。
つまり、検証「技法」の研究も大事だけど、検証「戦略」の研究も大事だな、と気づいた。

Web2.0時代のバグ管理ツールを作る（第5回）求められる「データマイニング」機能

紙おむつと缶ビール
アメリカのスーパーマーケットの購買履歴を分析した結果、紙おむつと缶ビールを同時に購入するケースが多いことが分かった、という都市伝説がある。
・かさばる紙おむつを買いに来るのは大体父親。
・スーパーにたまにしか来ない父親は、「ついでに」という気持ちで缶ビールを買って帰る。
という因果関係からこの結果が生まれるという。
風が吹くと桶屋が儲かる、だが、つまり紙おむつのと缶ビールを並べておくと売上げが上がる、ということらしい。

これをバグ分析に応用できないだろうか。
一見関係ないように見えるバグも、見方を変えることで新たな関係が浮かび上がるかも知れない。それによってシステムの品質予測を直感的に感じることができるかもしれない。

結論
・登録されたデータの依存関係をフレキシブルに分析する機能が欲しい
・分析結果はグラフィカルに表示されたほうが把握しやすい

そしてこの話題、次回以降に続きます。
(事情により、一部予定を変更してお送りしています。スイマセン。)
・これまでのツールの問題は[2006-02-26-1]
・エクセルでのバグ管理はなぜ駄目なのか[2006-02-27-1]
・バグ成長曲線をどこまで信じればよいのか[2006-03-27-1]
・ファイル添付機能は本当に必要か[2006-04-24-2]
・求められるのは「データマイニング」機能[2006-04-25]
・バグ管理ツールの問題に対する一つの回答
・新ツールの画面イメージ
・各機能の説明

Web2.0時代のバグ管理ツールを作る（第4回）ファイル添付機能は本当に必要か

既存のバグ管理ツールの機能のひとつとして、「ファイル添付」がある。
これはテストの結果、問題があった場合の証拠写真(スクリーンショット)や結果ログ、テストに使用したデータファイルを添付し、問題解決の分析を助けるために使用される。この事自体に何ら異論は無い。
が、
本当に「不具合管理ツールの機能」として必須なのだろうか。

私が感じるファイル添付機能の問題
・Webベースの場合、たいてい一度に1ファイルずつしか添付できないので操作手順が増える。
・バイナリの添付はデータベースが肥大化するので心配。
・機能の増加によって、バグ管理ツールのバグが増加する危険性がある。

結論
・「不具合管理ツール」自体にファイル添付機能は不要。
・別途FTPなり、Windowsファイル共有なりで実現すればよい。
・参照ファイルへはhttpやftpでリンクを張ればよい。

そしてこの話題、次回以降に続きます。
(事情により、一部予定を変更してお送りしています。)
・これまでのツールの問題は[2006-02-26-1]
・エクセルでのバグ管理はなぜ駄目なのか[2006-02-27-1]
・バグ成長曲線をどこまで信じればよいのか[2006-03-27-1]
・ファイル添付機能は本当に必要か[2006-04-24-2]
・バグ管理ツールの問題に対する一つの回答
・新ツールの画面イメージ
・各機能の説明

Web2.0時代のバグ管理ツールを作る（第3回）バグ成長曲線をどこまで信じればよいのか

不具合の状況を把握するツールのひとつに「バグ成長曲線」がある。これはテスト期間中に累計で何件のバグが検出されたかと、何件のバグが修正されたかを線グラフで表したもの。
（サンプルグラフ）

グラフの読み方は、
・テスト期間初期は基本機能テストやテスターの不慣れでバグがあまり出ない
・テスト期間中期は複雑な機能のテストを行うのでバグがたくさん出る
・テスト期間後期はバグが出尽くすのでバグがあまり出ない
つまり、グラフが山を作って水平になってきたら高品質確保、出荷OK、ということ。
バクテリアが増殖する時に、一定期間で増殖が飽和する曲線と似てます。

実はこれがクセ者で、
・テストをがんばってもなかなかグラフが寝ない
・意図的にグラフを寝せて品質が確保されたようにするのが簡単
という大きな矛盾をはらんでいたりする。

テストをがんばってもなかなかグラフが寝ない
テストを続ければ続けるほど、警告ダイアログの言い回しやOKボタンの位置などの細かい問題が出続けたり、複雑な手順や微妙なタイミングによる問題が出続けて、グラフが一向に収束する気配が無い。

意図的にグラフを寝せて品質が確保されたようにするのが簡単
テスト期間(日付）を軸にグラフを書いた場合、テスト実行数を減らすと不具合検出数が減るのであたかもバグが出なくなったように見える。こう書くとあたりまえなのだが、日付を軸にバグ曲線を書いているチームは多い気がする。
ただ、この件はテスト実施件数を軸にとれば回避できる。
この辺についてはソフトウェア・テスト PRESS Vol.1に詳しい。

一番の問題は
不具合の一件一件は重みが違う、ということ。バグ成長曲線上では、人が死ぬ可能性がある超A級問題と、誤字等のC級の問題が同じ1件としてカウントされてしまう。バグ成長曲線だけでシステムの安定度を予測するのはちょっと乱暴。

結論
・不具合件数だけでなく、もっと複合的な要素で判断すべき
・システムの状態を任意の軸に沿って総合的に把握できる仕組みが必要

そしてこの話題、次回以降に続きます。
(事情により、一部予定を変更してお送りしています。)
・これまでのツールの問題は[2006-02-26-1]
・エクセルでのバグ管理はなぜ駄目なのか[2006-02-27-1]
・バグ成長曲線をどこまで信じればよいのか[2006-03-27-1]
・バグ管理ツールの問題に対する一つの回答
・新ツールの画面イメージ
・各機能の説明

システムテストとおいしいご飯の関係

テスト専門部隊に所属していると、開発チームからテストレベルの違いについて質問されることがある。
「単体テスト、結合テスト、システムテストは、どこがどう違うんですか？」
「じゃあ、我々が行う結合テストって、何をすればいいんですか？」

テスト技術者資格制度Foundation Level シラバス 日本語版(PDF)によると、

単体(コンポーネント)テスト
コンポーネントテストは、分離してテストが可能なソフトウェア（例えばモジュール、プログラム、オブジェクト、クラスなど）の欠陥を摘出し、機能の正しさを検証するテストである。開発のライフサイクルやシステムの特性により、コンポーネントテストは、システムのほかの部分と切り離したテストが可能である。この場合、スタブ、ドライバ、シミュレータなどを使う。
結合(統合)テスト
統合テストは、コンポーネント間のインターフェース、また、OS、ファイル・システム、ハードウエアなどのシステムの別の部分との相互処理や、システム間のインターフェースをテストする。
システムテスト
システムテストは、開発プロジェクトやプログラムのスコープとして定義したシステムやソフトウェアプロダクト全体の動作をテストする。システムテストでは、テスト環境はテストできない環境関連の欠陥のリスクを最小限にするため、最終的なターゲットや運用もしくは使用する環境と可能な限り同じでなければならない。

…分かりやすいとは思うが、何となく面白い例えが思いついたので、これから誰かに違いを聞かれたときは、以下の説明で補足していきたい。元ネタは「炊き上がったご飯から石ころを探すのは非効率」ということば。どなたの発言かは失念してしまった。すいません。

おいしいごはん開発プロジェクト

単体テスト
お米とお釜に分けて作業する。
（お米チーム）
・米の正確な計量
・不純物の取り除き
・お米研ぎ
(お釜チーム)
・お釜の容量
・お釜の熱効率
・ヒーターの加熱上昇率
・炊飯タイマー

結合テスト
炊飯器でお米を炊いてみる。
・炊飯温度
・水の量
・炊飯時間
・蒸らし時間

システムテスト
世の中で人気があり、かつバラエティーに富んだ製法と合わせて、さまざまな条件で実際にご飯をたべてみて、おいしいかどうか確認する。
(バリエーション)
・ハンバーグ…人気者系庶民派
・カレー…汁系インド派
・すし…固め系酢飯派
・炒飯…いため系中華派
・赤飯…もち米系めでたい派
・お茶づけ…汁系ひたひた派
・おはぎ…甘味系仏壇派
・まぜごはん…混沌系桃屋派
・おにぎり…固め系モバイル派
・おかゆ…汁系病弱派
（環境）
・雨の日・晴れの日
・暑い日・寒い日
（タイミング）
・炊きたて
・よそって30分
（対象）
・子供・大人
・男性・女性
※ほんとは、ISO/IEC 9126とかに則っていわゆる「品質特性」（機能性・信頼性・使用性・効率性・移植性・保守性）等の観点から見ます。

システムテスト設計のエッセンス
・同値分割（ハンバーグがおいしく食えれば、とんかつでもおいしく食えるはずだからテスト不要）
・境界値分析（カレーはサラサラとべっとりの両方でテストする必要あり）
・優先度付け（松茸ご飯のカレーは一般的でないのでテスト不要）
…みたいな事をする。

結論
開発チームには、せめて腐ってないこと、ご飯の中に石ころが入っていないことぐらいは確かめておいてください、というのがテスターからの意見。炊き上がったご飯をぐちゃぐちゃに混ぜて石ころを探して、すっかり冷めてべちゃべちゃになったご飯を客に出すのは忍びない。

TimeSnapperで「バグ発生の再現手順不明」をなくせ

受け入れテストも大詰めになってくると、バグが多く出ている機能や実装が遅れた機能など、「アヤしい機能」が絞り込まれてくる。テスト業界にはいわゆる「ハチマルニーマル」（バグの80%はシステム全体の機能の20%の部位に偏る）という都市伝説があるが、優れたテスターほど経験的にそれを見つけ出す。
そこでテストチームはテスト戦略を変更して、「叩けばほこりが出そう」な部分を狙った探索的なテスト、つまりテスト仕様書を拡大解釈して、準備したテスト手順に各自アレンジを加えて実行するという、ノウハウの塊のようなテスト行うことがある。問題は、そもそもテスト手順書に書かれていない「行間」を埋めながらのテストは、見つけたバグの再現手順が非常に複雑になることである。テスターは「発生した問題は全て報告する」という教育を受けるが、個人的な見解としては、テスターが「再現手順不明」というバグ報告を行うことはかなり恥ずかしいと思っていて、何とかして少しでも多くの情報を開発者に届ける術を考えるべきだと感じている。

複雑な手順のテスト実行ログを取るための方法は、以下の様な手段があると思う。
・ビデオカメラで作業者の肩越しに画面を録画する
・キャプチャーボードで画面を録画する
・キーロガーで入力を保存する
・画面スクリーンショットを定期的に取る
予算や準備の都合を考慮すると、スクリーンショットの定期保存が現実的な選択肢となるだろう。

結論
TimeSnapper - make timesheets a snapというアプリを使用して、PCの画面を一定間隔でキャプチャーした画像ファイルを自動的に保存してみた。昨日一日「3秒間隔でpng保存」設定で試したところ、一日で保存された画像ファイルは4500枚、400MB弱であった。
TimeSnapperの良いところは、
・キーボード・マウスの入力が停止するとキャプチャー中止されるので無駄が無い
・保存した画像を紙芝居のように時系列に閲覧する機能がある
というところ。

自動保存したファイルは、容量や日時でサイクリックに削除する機能もあってまさにテスター向け。
あとは、撮影時にタスクトレイのアイコンが点滅してくれたり、定期実行の有効/無効化でアイコンが変化してくれたりすると、完璧。アプリ作者に機能追加依頼をだすか。（英語だからめんどうだな。）

以前も同じようなことを思いついて、WinShotを使用して定間隔スクリーンショット保存機能を使用したことがあるが、どうもPCの動きがカクカクして、テストに支障が出そうだったのですぐ断念した。TimeSnapperではカクカク現象は発生しなかったのでおすすめ。

JTCBテスト技術者資格認定

合格しました。今日からみんなオレには敬語な。

Web2.0時代のバグ管理ツールを作る（第2回）エクセルでのバグ管理はなぜ駄目なのか

バグ管理ツール導入の話をする前に、マイクロソフトExcelによるバグ管理の問題点をまとめておきたい。多分、世の中のバグの多くはエクセルで管理されていると思うが、意外とエクセルはバグ管理ツールには向かない、というのが個人的な意見。

エクセルによるバグ管理の問題
・更新履歴が残らない
検出されたバグは、再現手順とともに報告され、開発者によって修正され、テスターによって修正の確認が行われる。このやり取りは決して一方通行ではなく、質問や追加情報の提供など、開発者とテスターの間で常にボールの投げ合いになる。エクセルによる一覧表だと、そのやり取りの一時的なスナップショット保存、としての機能しかないので、あとから見た場合にそのバグがどのように修正されたのか、経緯がわかりづらくなる。

・ファイル共有の不安
一つのエクセルブックを共有して作業すると、どうしても編集の競合や、ファイル破損の不安がつきまとう。少なくとも僕は「ブック共有」していたエクセルファイルが破損してデータが紛失した経験が2度ある。それ以来、複数人によって日々リアルタイムに更新される重要なデータをエクセルで管理しようとは思わなくなった。

結論
・更新履歴が残るシステムを使うべし
・バグ情報はデータベースで管理すべし

そしてこの話題、次回以降に続きます。
・これまでのツールの問題は[[2006-02-26-1]]
・バグ管理ツールの問題に対する一つの回答
・新ツールの画面イメージ
・各機能の説明

Web2.0時代のバグ管理ツールを作る（第1回）これまでのツールの問題は

製造中システムの不具合やバグ管理の仕事をしていると、数多くのバグ管理ツールを使ったり試したりするチャンスに出会う。しかしどのツールも一長一短というか、痒いところに手が届かないというか、とにかく悲しいことに決定版、と呼べるバグ管理ツールに出会ったことが無い。困った。コマリングドーベルマンだ。今後、このサイトを通して、新時代に通用するバグ管理ツールを作っていきたい。まずは現状分析。

バグ管理者から見たツールの問題点

・バグ管理項目のツール上での設定が大変
製造するシステム・製品の特徴や、企業の品質保証基準、あるいは人的リソース等、様々な理由によって、データベース上で管理したい（管理できる）情報は多岐に及ぶ。また、同じような理由で、バグの「発見→修正→確認」のワークフローも千差万別であるのが現状である。つまり、バグ管理パッケージ導入時には、多かれ少なかれツールのデフォルト項目をカスタマイズする作業が入る。このフィット&ギャップ結果をツールの制約を考慮しながら反映させる作業が意外と面倒くさい。
また、バグ管理ツールもひとつの「システム」である以上、実際に使用していく中でどのような情報を管理するか、という「ユーザーの要求」は日々変更される。そのたびにツールの設定を変え、データベースの項目を変更していくことはツールの安定度・動作レスポンスの悪化を招く可能性が高い。

・バグ状況の把握が大変
バグを管理する目的のひとつに、バグの検出状況を分析してシステム全体の問題点を予測することがあるが、バグの発生状況、修正状況がどうなっているのか、「本当に知りたい情報」がグラフなどで感覚的にわかる仕組みが用意されているツールは多くない。なぜなら上で述べたように、本格運用されているバグ管理ツールはデフォルトとはかなり異なった項目でデータ収集されているため、ツールの分析機能が役に立たない場合があるからである。

結論
・ツールのメンテナンスをできるだけ無くしたい
・バグ分析を簡単に行いたい

おまけ
バグ管理の概念が一番わかりやすく説明されている書籍はこれだと思う。


そしてこの話題、次回以降に続きます。
・エクセルでのバグ管理はなぜ駄目なのか[[2006-02-27-1]]
・バグ管理ツールの問題に対する一つの回答
・新ツールの画面イメージ
・各機能の説明

日本が世界に誇れるテストツールSelenium IDE

Webサイトの自動テストツールSeleniumのFirefoxプラグインSelenium IDEがリリースされた。これまでSeleniumユーザーが作って大好評だったFirefoxプラグインのSeleniumRecorderが、OpenQAの正式ツールとして採択された、という感じ。
実際に動かしてみて、SeleniumRecorderと比較してもUI以外あまり変わったところは感じなかったが、気になるのはリリースバージョンが「0.71」なところ。本家Seleniumが0.6なので、オリジナルをバグフィックスしたバージョンが内容されている可能性高し。IE用サイトをテストするにはオリジナルじゃないと駄目なので、あとで内包されてるSelenium0.71(?)だけを取り出して使って見る。後日報告。

ていうか、このSeleniumRecorder作ったのが日本人であることは、日本でどの程度認知されているか気になる。日本人が世界に通用するアプリを作ってる例って、宮本茂以外にもあるんだね。

Seleniumについては[[2006-01-15-1]]参照。

テスト仕様書に「正常系/異常系」のカテゴライズは必要？

システム開発者向け(?)の本とか、実際に開発者が書いたテスト仕様書を見ると、スプレッドシートに「正常系/異常系」の項目があったりする。また開発者から直接「正常系だけじゃなく、異常系のテストもした、しない」みたいな話を聞いたりする。これを見たり聞いたりしたのは1度や2度ではないので、一般的なのだろうと思う。

第三者テスト、とかソフトウェアテスト専門部隊、に属する僕個人の意見としては、「正常系/異常系」のカテゴリーはテスト仕様書には特に必要ないように感じる。
多分、「正常系/異常系」というカテゴリーはテスト実行の優先度として使用する目的で設定していると思うが、「とりあえず正常系から先にテストする」という戦略は時として重大なテスト漏れを発生させる危険があると思う。難しいのは正常/異常のしきい値をどう定義するかで、「プログラム上の例外処理やエラー処理かどうか」で「正常/異常」を決定している場合は、一見効率的な優先度に基づいて重要な部分からテストできているようで、実際の運用を省みないテストになりがちだと思う。

非常に極端な例ですが
・5万ページを端から端まで印刷する正常系
・パスワード欄に「' OR 1=1--」と入力する異常系
システム運用上、一般的に言って後者の優先度のほうが高いと思う。

個人的な結論
「正常系/異常系」はヤメて、運用上の重要度から見たテスト「優先度」という項目を設定するのはどうだろうか。

おまけ
一応、テスト屋の教科書とされているIEEE829のテスト仕様について引用すると

IEEE829標準規格におけるテストケース仕様書のテンプレート
1.テストケース仕様書識別番号
2.テストアイテム
3.入力仕様
4.出力仕様
5.環境要件
6.手順についての特記事項
7.テストケース間の相互関係

via 体系的ソフトウェアテスト入門


こんな感じ。7番はよく分からんが、必要最低限、だと思います。

若手SEのための ソフトウェアテストの常識

購入。

第1章 ソフトウェアの品質
第2章 信頼性からみた低品質の原因
第3章 品質向上のための開発段階の対策
第4章 ソフトウェアテストを設計するときの10の心得
第5章 ソフトウェアテストを実施するときの10の心得
第6章 ソフトウェアテストの設計と実施に必要な能力
付録1 ソフトウェアテスト仕様書の書き方
付録2 しなければならない一覧表

1章を読んだ感じでは、品質を（いわゆるプラスとマイナスの）2つに定義していて、わかりやすく、まじめな印象。
目次を見るに、4,5章のキャッチーさが非常に気になる。詳細後日。

Software QA Testing and Test Tool Resources

Software QA Testing and Test Tool Resources

This page lists over 500 software testing and software test tools sites we hope you will find helpful.
ApTest is your source for software testing. If you're interested in having test technology developed or a product or web site tested please get in touch with us. We'll work with you to understand your needs, and our deliverables will delight you.

テストツールに関する大量のデータ。ここからよさそうなのをコツコツ探そう。

ホットキーで計測するストップウォッチ WinStopWatch

http://www.asahi-net.or.jp/~ib7y-nmr/software/winstopwatch/

このアプリケーションは、Windows上で動作するストップウォッチソフトです。他のストップウォッチアプリケーションの「計測結果をテキストとして出力できない。」「キーボード操作でのラップ計測ができない。」「計測時間が正確でない。」といった不満を解消するために作成しました。他のソフトとは比較にならない操作性を気に入っていただけると思います。

仕事柄ストップウォッチは必須アイテム（らしい）けど、前に使ってたストップウォッチはなくしちゃった。急ぎだったので、Windows用でグローバルなキーフックに対応してるストップウォッチアプリを探したらこれがヒットした。
個人的にはフォント変更とかできても良いかな、とも思うが、機能は申し分無し。測定開始時に前面表示しておく必要がないので、快適。

TIPS
僕の場合ホットキーを以下に設定して、
・Stop : Alt+E
・Reset : Alt+R
・Start/Stop : Alt+S

1)計測前にAlt+EとAlt+Rを連打して完全停止かつリセット
↓
2)Alt+Sで計測開始
↓
3)Alt+Sで計測終了
↓
4)前面表示して値確認

ていう手順で使ってます。

アマゾンでDRETEC 大画面ストップウォッチ SW-111WTを買おうと思ったけど、これで代用できるので買う必要がなくなった。

単体テストを見直せば開発コストは低減する、アジター

http://www.atmarkit.co.jp/news/200601/24/agi.html

米アジターソフトウェア CEO兼社長 ジェリー・ラディシン（Jerry Rudisin）氏はソフトウェア開発において無駄に費やされているさまざまなコストを挙げ、単体テストの重要性を指摘する。例えば、84％のプロジェクトが当初の開発計画通りには進まないというデータや、成功するプロジェクトは全体の29％に過ぎないという数字である。

こういう数字はメモっておいてプレゼンの参考資料に使いたい。
記事自体に特筆すべきものは無し。

新しいソフトウエア開発手法

http://www007.upp.so-net.ne.jp/kengai/fowler/newMethodology_j.html

過去数年にわたり、「ライトな」ソフトウエア開発手法が急速に関心を集めつつある。それらは、官僚制に対する解毒剤とも、ハッキングのライセンスとも見なされているが、ソフトウエア関係者全ての興味をかきたてている。このエッセイで、私は「ライトな」開発手法の単に「軽い」側面だけでなく適応的な性質や人間中心主義に着目しながら、それらが流行る理由について掘り下げてみたい。また、この系統のプロセスに対してサマリーとリファレンスを提供し、この踏み出されてまもない道を行くべきかどうかを選択するために、考慮すべき要因について考えてみたい。

荒っぽく言うとXPについて。かなり面白い。とても参考になる。

■[SIer]ディフェンシブな開発 〜 SIビジネスの致命的欠陥
この辺と読み比べると考えさせられるなぁ。


…ところで、「新しいソフトウェア検証手法」は？

エンジニアのための実践ソフトウェア技術誌『開発の現場 Vol.003』

『開発の現場 Vol.003 効率UP&スキルUP エンジニアのための実践ソフトウェア技術誌』

提案書、設計書、テスト仕様書、議事録などすぐに使える実用ノウハウが満載。ユーザーにわかってもらえるドキュメントの書きかた、JavaDoc/Excelを利用したドキュメント自動作成のテクニックなど、現場で役に立つ情報がいっぱい

これから買って読んでみる。つまらなかったらこのエントリーは消す。

無料テスト技術認定試験

無料テスト技術認定試験：JTCBテスト技術者資格認定 Foundationの腕試しに！

こちらは無料で、テスト技術者の知識を点検することを目的とした、技術者の技術者による技術者のための認定試験を行うサイトです。
ISTQB、JTCBテスト技術者資格認定 Foundationと同等の出題範囲の試験が無料で受験できます。

早速受けてみた。

総合評価
問題数＝40
あなたの得点＝29点
正解率＝72.5％
う〜ん残念。不合格です。
一応、ISTQBの合格ラインは超えていますが、この程度では実際の試験では落ちるかも。
間違えたところを確実に復習し、９０％以上を目指してください。

…ダメじゃん。

しかしこのGonzo!試験システムつうのはよさげ。別用途でも使えそう。社内教育とか。