ソフトウェアの品質を学びまくる2.0

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

ISTQBの「性能テスト担当者」シラバス日本語版を読んでみた - その2

 今回は、1.2で扱われている、性能テストのテストタイプについての記事です。前回の記事はコチラ
 性能テストにはさまざまなテストタイプがあるので、1つのデファクト・スタンダードとしてISTQBが整理してくれているのはありがたいことです。
 またこの部分については、翻訳者でもある湯本さんがブログを公開されています。

note.com

 わたしはこのテストタイプたちを、また違う軸で捉えていたので、ちょっと整理してみました。
 縦軸はテストの目的で、実行条件が想定「以下」「内」なのか、想定「以上」「外」なのか。
 横軸は注目している時間範囲の長さを「短」「中」「長」に分けているます。

 このマトリクスに、シラバスにあるテストタイプを乗せると、こんな感じ。
 ★は、このシラバスには出てこないものです。

目的 時間範囲: 短 時間範囲: 中 時間範囲: 長
想定を超えた条件において、
どのようにふるまうかを確認する
スパイクテスト
コンカレンシーテスト
ストレステスト
キャパシティテスト
拡張性テスト
★加速試験
想定内の条件において、
要件通りにふるまえるかどうかを確認する
同上 負荷テスト 耐久テスト
★ソークテスト

 それぞれのセルを見ていきましょう。

時間「中」×想定「内」

 まずここが基本。
 「想定として定義された負荷条件に対し、どのような性能を示すか」という負荷テストが入ります。

時間「中」×想定「外」

 このセルには、ストレステスト、キャパシティテスト、拡張性テストの3つが入ると考えます。なぜ3つも入るのかというと、目的が異なるからです。目的を無視しているのが、このマトリクスの大きな欠点と言えるでしょう・・・。

 ストレステストでは、負荷が想定以上になった場合のふるまいを検証するものです*1。負荷テストのわかりやすい延長上にあります。
 キャパシティテストと拡張性テストの違いは、わたしにはよくわかりませんでした。ともに、「これからユーザや負荷が増えていったとして、どこまでなら性能要件を守れるか」と言っているように感じます*2

時間「短」

 この列は、想定「外」「内」は分けずに、スパイクテストとコンカレンシーテストを入れています。
 この2つは似ているようにも思えますが、別のものです。

 スパイクテストの特徴は、「突然」。次第に負荷が増えてピークを打ち、次第に下がっていくのではなく、いきなりガンと上がってすぐに収まるという、Twitterでいうバルス的な事象に耐えられるかに注意します。シラバスには「その後、定常状態に戻る能力」とも書かれており、「素に戻る」ことができるかもポイントです。

 一方コンカレンシーテストは、ある短い一定時間の間に「特定のアクションが同時に発生する状況」Tをテストするもの。
 各実行の操作対象が同一のものだったり、実行のために使うリソースが共有されていたりする場合に起きるような、逆にいうと単発の実行では起きない・起きづらい問題が、コンカレンシーテストで見つかることがあります。

 全然現実的なじゃなさそうですが、ある銀行口座に対する入金処理についてテストするとすると、

  • スパイクテスト: 1人が1分間に1000回の入金を行う
  • コンカレンシーテスト: 100人が1分間に1回ずつ入金を行う

といった感じでしょうか。

時間「長」×想定「内」

 ここには、耐久テストが入ります。単発では性能がよくても、時間が経つに連れて急激に悪化していくかもしれません。短時間では発見しづらい問題を、耐久テストで見つけられることがあります。
 「ロングランテスト」という別名に加え、わたしは「ヒートラン」という言葉も(方言的に)使っていたのですが、これは機械・電子機器の文脈で使われる、まったく違う意味の言葉のようですね・・・。

ヒートラン 【heat run】 エージング / バーンイン
ヒートランとは、機械や電子機器などの出荷前に行われる稼動試験、または、使用開始前に行われる「慣らし運転」のこと。
IT用語辞典より

 なお、秋山さんの以下の記事では、 「ソークテスト」 が説明されています。

note.com

ソークテストなら、長時間連続して、実際の利用環境であり得る嫌な負荷をかけ続けるテストということを押さえておきましょう。

 この説明を見る限り、ソークテストも「長」×「内」に入れておくのがよさそうです。

時間「長」×要件「外」

 シラバスにはここに当たるテストタイプはなさそうですが、「加速試験」(これも方言)が、一応これにあたるかもしれません。

 耐久テストにおいて、たとえば「1ヶ月稼働後の様子を確認したい!」といっても、なかなかできるものではありません。そこで、「想定される負荷の周期」を1/10にすることで、3日間で1ヶ月分を模擬する。雑にいうと、加速テストとはこんな発想のテストです。
 「加速した場合の動作を確認する」ことが目的ではなく、あくまでも「耐久テストを効率的に行う」ことが目的なので、テストタイプとはちょっと違いますね。
 いずれにせよ、それが本当に「模擬」と言えるかどうかは十分な吟味が必要です。

おわり

 以上、性能テストのテストタイプを、目的と時間範囲のマトリクスで分類してみました。
 正直、いくばくかの無理矢理感はありますが、分類してみることで理解が進むこともあるかもしれないので、ヨシとします。

Top speed

*1:シラバスでは、「リソースの可用性が低下した場合のシステムの処理能力を評価するためにも使用できる」とあります。障害時の「片肺運転」「縮退動作」中の性能評価ですね。

*2:湯本さんの記事では、拡張性テストは想定の範囲「内」、キャパシティテストは「外」で、後者とストレステストの仲間と説明されています。

ISTQBの「性能テスト担当者」シラバス日本語版を読んでみた - その1

 JSTQBから、性能テストのシラバスの翻訳が出ました。
 ついつい当たり前に思ってしまいがちですが、テストの知識のデファクト・スタンダードといえるISTQBのシラバスが日本語で読めるというのは、本当にありがたいことですね。訳者のみなさまに感謝。

jstqb.jp

 いわゆる「非機能テスト」というものはそれぞれに独特の難しさがあり、性能テストもその例に漏れません。このシラバスは、性能テストにおいて何を考慮し、何をしなければいけないかについて、全体感を与えてくれます。
 この記事では、シラバスを読みながら自分が考えたこと・理解した(気になっている)ことについて書いていきます。

「性能」という品質特性

 「性能」(または「性能効率性」)という言葉について、あらためてISO 25010を見てみると、以下のように定義されています(翻訳はわたし)。
 なお「性能効率性」が品質特性で、続く3つが副特性。副特性はシラバスではそれぞれ、「時間効率性」「資源効率性」「キャパシティ」に対応します。

性能効率性
明文化された条件のもとで利用されるリソース*1の量にかかわる性能を表す特性。この特性は、以下の副特性からなる。

時間的な振る舞い
プロダクトやシステムがその機能を果たす際に、レスポンス・処理時間・スループットが要件を満たしている度合い

リソースの利用
プロダクトやシステムがその機能を果たす際に、利用するリソースの量や種類が要件を満たしている度合い

キャパシティ
プロダクトやシステムのパラメターの上限が、要件を満たしている度合い

 ファミレスのホールで働く店員さんを例にとってみます。
 「この人、デキる人かな?」と評価するには、どういう点に着目すればいいでしょうか。

 チャイムで呼ばれたらそのテーブルに向かい、オススメやオプションを提示しながら、お客さんの注文を聞き取り、厨房に伝える。
 この作業の正確さは、品質特性でいうと「機能正確性」というものにあたるでしょう。

 しかし、この作業に毎回10分もかかっていたのでは困ります。お客さんの人数や性質に依るけれど、概ねx分くらいで済ませられる。これが「時間効率性」にあたります。

 さて、この店では注文を今も紙とボールペンでメモしている。ベテランの店員さんは、メニューごとに自分なりの符号を編み出していて、一品をカタカナ3文字くらいで表現できるのですが、新人はそれができず、長々と商品名称を書いてしまいます。
 紙とボールペン、めっちゃ使います。これが「資源効率性」です。
 まあ、紙とボールペンを大量に使うくらいなら、「もったいないなあ」で済むかもしれません。ところがある日、ボールペンのインクが切れてしまう。その店員さんは手書きでしか注文を受けられないので、対応できず固まってしまう・・・。これでは困ります。

 さらに、お客さんがたくさんいてひっきりなしに呼ばれたり、1回の注文の内容が大量だったときにも耐えられるか。これが「キャパシティ」ですね。

「キャパシティ」に関する事例

 『ポストモーテム みずほ銀行システム障害 事後検証報告』という本では、以下のような事例が紹介(引用の太字はわたし)されています。

e-口座に切り替える定期性預金口座は約259万件。システム上の制限から45万件ずつ6回に分け、2月27日から3月14日までの土日にe-口座への一括切替処理を実施することに決めた。
この一括切替処理のシステムテストに際しては、実機での処理は8万件までしか試さなかった。実は定期性預金口座システムのDBは、前述のインデックスファイルに関する容量制限に起因して、更新件数が64万2969件を超えるとそれ以上は更新できなくなるという問題を抱えていた。しかしテストでの処理件数が不十分だったため、DBの設定にリスクがあることを検出できなかった。

 これを性能テストと呼ぶかはちょっと微妙ですが、上述した品質特性でいうと、キャパシティにあたる問題に見えます。

 本番環境と同等の環境や条件が手に入らないとき、何らかの仮定に基づいて、本番環境のグレードを一部下げた、サブセット的な環境・条件において性能テストを行うことになるでしょう。
 そのリスクについては、「4.2.8 性能テストケース実行のための準備」で以下のように語られています(引用の太字はわたし)。

性能と環境の関係は非線形であることを覚えておくことが重要である。つまり、テスト環境が本番の標準的な環境から離れれば離れるほど、本番の性能を正確に予測することは難しくなる。テストシステムが本番と同等でなくなるほど、予測の信頼性が低くなり、リスクレベルが高まる

 この話については、また考えていきたいと思います。

Top speed

*1:「時間」もリソースの1つという扱いなのだと思います。

コープランド本の例題から、ブラックボックステストとホワイトボックステストを考える

 プレスマンの白本*1・「第19章 ソフトウェアテスト - コンポーネントレベル」の「19.5 ブラックボックステスト」には、以下のような説明があります。

ブラックボックステストテストはホワイトボックステストの代替ではない。むしろ、ホワイトボックステストの手法でみつかるのとはまた別の種類のエラーを見つけることを期待できる、補完的なアプローチと言える。

 これを確認するために、『はじめて学ぶソフトウェアのテスト技法』(リー・Copeland著、日経BP社)の例題を見てみたいと思います*2

Binderの例題

 同書第1章の節「すべてをテストすることはできない」では、その例を以下のようなプログラム*3で示しています。
 関数blech*4は整数iを受け取って1を引き、30,000で割っています。余りなしで「商」を求める*5ものです。

gist.github.com

 ここで、本来は「1を足す」が正しい処理だったとします。その場合、この欠陥はどのように見つけられるでしょうか。
 なおここでは、intの最小が -32,768、最大が 32,767 という前提です。つまり整数だけ考えても、65,535 65,536の入力候補があることになります。

ホワイトボックステスト

 たとえば i = 1 の場合、正しいコードでも間違ったコードでも出力は0となり、間違いを検出できません。
 が、ホワイトボックステストの制御フローテストを考えた場合、i =1 を実行すれば、ステートメントカバレッジは100%となります*6

ブラックボックステスト

 それでは、ブラックボックステストではどうでしょう。
 ブラックボックステストを行う前提として、以下のような仕様が明示されていたとします。そのままプログラムみたいなものなので、現実には考えられないでしょうが・・・。

入力された整数に1を足したあと、30,000で割った商。

 テスト技法として、同値分割と境界値分析を使ってみます。
 まず、入力値の同値分割。
 1つの切り口として、整数iの領域を、正・ゼロ・負の3つのエリアに分割することが考えられます。その境界値は下から、intの下限、-1、0、1、intの上限という5つになります。

 次に出力値を考えてみましょう。
 結果となる商の領域も、正・ゼロ・負の3つのエリアに分割できます。商が-1から0になる境界と、0から1になる境界を考えると、入力値は -2、-1、29998、29999 という4つになります。

誤りを検出できる入力

 両者から重複を除くいた8つのテストケースについて、正しいプログラムと間違ったプログラムでそれぞれどのような出力になるかを整理したのが以下の表です。3つのテスト(i = -1, 0, 29999)で、誤りを検出(★)できていることがわかります。

i 期待する結果 実際の結果 検出 同値分割 (入力) 同値分割 (出力)
-32768 -2 -2
-30001 -1 -2
-30000 -1 -2
-2 -1 -1
-1 0 -1
0 0 -1
1 0 0
29998 0 0
29999 1 0
30000 1 0
32767 1 1

結論

  • ホワイトボックスでコードカバレッジ100%を達成したというのは、そのパスを通す一例が実行できたということに過ぎず、十分なテストをしたことを意味するわけではない。
  • 仕様に基づくブラックボックステストは、ホワイトボックステストでは満たせない部分をカバーすることができる。

気になること

 Copelandさんのこの節で、よく理解できない点が2つあります。

  1. 入力の例として、1、42*7以外に、intの範囲を超えた40,000、-640,000を挙げている。「期待される結果」「実際の結果」も合っていない。

  2. 例題において、欠陥を検出できる入力は4件としているが、上の表にも示すように、6つの入力値で出力の差が出る。

 わたしの方が間違っているのかもしれませんが、誰かこの謎を解いてください・・・。

Cat eyes on black body"Cat eyes on black body" by Stefan Tell is licensed under CC BY 2.0

2022/3/30追記

 「気になること」について、辰巳さんにが原著や引用元をあたってくださり、概ね以下のことが判明しました。ありがとうございます!

事実1 引用・改版・翻訳で情報が変化

 Copeland本ではこの例を、Binderの本からの引用としていますが、これはさらにFriedman*8の本からの引用であるとのこと。
 またCopeland本の翻訳の過程で数字が(おそらくは意図せず)変わってしまったり、原著の方ではErrattaが出ているなど、間違いが何箇所かで紛れ込んでいるようです。

事実2 入力例に誤植あり

 入力値-640,000というのは、本書が前提としているintの下限以下であり、例としてはおかしいと考えていました。この点、原著では-64,000だったとのこと。
 ただ、-64,000も下限以下なんだよな。。

事実3 負の数の除算の扱い

 -7/3 = -2.333... の小数部を切り上げて-2にするか、切り下げて-3にするかについて、Pythonの //演算子では切り下げになっており、また割り算の定義もこれに合致するため、この記事では切り下げを採用しています。
 が、Copeland本では切り上げを採用しているようです。

 切り下げと切り上げでは、欠陥を検出できる入力値も個数も変わってきます。

  • 切り上げ(ExcelのROUNDDOWN()イメージ): -30000 -29999 29999 30000 の4つ
  • 切り下げ(ExcelのINT()イメージ): -30001 -30000 -1 0 29999 30000 の6つ

 Copeland本でいう「4つ」というのは、この結果だと思われます。

事実4 Binder本では「40個」

 Copeland本の引用元となるBinder本では、欠陥を検出できる入力値は40個であるとしているとのこと。これは、割る数が30,000ではなく3,000となっているからのようです。
 割る数を3,000とし、また負の数の除算を切り上げで考えると、確かに40の入力値で差分が出ることが確認できました。

 一部のマニアしか興味をもたないと思いますが、わたしは好きなので残しておきます。将来Copeland本をマジメに読んで「!?」となる人のためにはなるかもしれません。

参考

 不定期に盛り上がる同値分割、境界値分析に関するTogetterを参考にしました。
 読み直して、今持ってなお自分が、基本にして最難関のこの技法を十分に理解できていないことを感じました。

*1:『実践ソフトウェア・エンジニアリング 第9版』のことです。

*2:正直、この記事の内容には自分自身でも疑いを抱いています・・・。

*3:Robert Binderの『Testing Object-Oriented Systems』からの引用とのこと。

*4:英辞郎によるとblechは

間投 《嫌悪》ゲーッ、オエッ、ゲッ、くそっ、ウヘッ、ヒェッ

*5:負の整数の割り算について、 -7÷3 = -2...-1 ではなく、-7÷3 = -3...2 という計算をするようです。 定義上、0≦余り<割る数 と考えるため。

*6:ブランチカバレッジも100%です。そもそも分岐がないので。

*7:42は、生命、宇宙、そして万物についての究極の疑問の答えを表すため、代表値として選択する価値がある。ja.wikipedia.org

*8:以下、教えていただきました。
M. A. Friedman and J. M. Voas. Software assessment: reliability, safety, testability. 1995.

JaSST '22 Tokyoの発表資料を公開しました #jassttokyo

 JaSST '22 Tokyoで、翻訳メンバーとして参加した『実践ソフトウェアエンジニアリング 第9版』のセッションを担当しました。長過ぎるタイトル*1と概要は以下のとおりです。

「ソフトウェア開発にかかわる全てのエンジニアの一般教養「ソフトウェアエンジニアリング体系」における品質技術 ~翻訳者が語る「実践ソフトウェアエンジニアリング(第9版)」における品質技術の概観」

講演者4名を含むSEPA翻訳プロジェクトでは、米国修士課程においてベストセラーとなっている体系的解説書「Software Engineering: A Practitioner's Approach 9th edition」を翻訳し、「実践ソフトウェアエンジニアリング(第9版)」としてオーム社より12月1日に発刊した。(https://www.ohmsha.co.jp/book/9784274227943/
本書は米国を中心とした海外で大学生教育における教科書として採用されている世界的名著である。JaSST'09 Tokyoに著者であるプレスマン氏を招聘したことをご記憶されている方もいらっしゃるのではないだろうか。
本書は、QA/テストエンジニアにとっても、一般教養たりうる書籍である。
本セッションでは、最新版である第9版日本語版について、翻訳プロジェクトや書籍の全体概観を紹介し、「第3部 品質とセキュリティ」について訳者によるディスカッションを行う。

 本セッションは、大きく3つに分けられています。

 1つ目、「第9版」全体の概要や、過去の版からの推移などを水野昇幸さん*2が解説。
 2つ目が、JaSSTらしく本書第3部「品質とセキュリティ」の超概説をわたし鈴木が。
 3つ目は池田暁さん*3のファシリテートで、第3部の訳を担当した根本紀之さん*4とわたし、プラス水野さんがテストやレビューについてディスカッションするというものです。

 わたしのパートが予定より押してしまい、ディスカッションが少し短くなってしまったのですが、Discordのチャットにもたくさん投稿をいただき、ほっとしました。セッションタイトル的に割と真面目そうだし、10人くらいしかこない系か?とも思っていたので・・・。

 当日の資料はこちらで公開しています。

speakerdeck.com

 全9章ある第3部を20分で概説しようということで、最初に作ったドラフトは、「少ないっ・・・! 情報がっ・・・! これでは何ら変わらない・・・ 目次とっ・・・!」*5でした。目次を吟じるだけのセッション、さすがに許されない。

 で、もう少しちゃんと作ってみたところ、今度は早口でも40分以上かかるような内容に。
 結局、対象を5章に絞り、各章の説明を少し厚めにして、なんとか許容範囲の時間オーバーとなったのでした。

 ということで、公開されなかった残り4章分も、いつかどこから日の目を見させてあげたいと思います。
 参加いただいたみなさま、どうもありがとうございました!

*1:トラックオーナーの方が困っていた・・・。

*2:@noriyukimizuno。ファーストネームの漢字まったく思い出せず、検索した。

*3:@ikedon0505。ファーストネームの漢字をギリギリ思い出せたが、検索した。

*4:@nemorine。ファーストネームの漢字まったく思い出せず、検索した。

*5:最近読んでいる・・・ 『1日外出録ハンチョウ』!

ドキュメントテストって一見地味だけど、とても大事ですね

 JaSST '22 Tokyoのセッションの中で、『プレスマンの白本』*1の「21.12 ドキュメントとヘルプ機能のテスト」で言及されている、「ドキュメントテスト」*2についてお話しました。

 なおこの用語はISTQB用語集では見つからない*3 のですが、プログラムそのものと一緒に提供されるドキュメントに対するテストを意味しています。リリースノートや製品マニュアル*4などが対象になりますが、この記事ではマニュアルのテストについて書いていきます。

ドキュメントテストが難しい要因

 マニュアルはユーザが直接利用するものであり、製品の一部です。そのチェックに手を抜いていいと思う人はいないでしょう。それでも、品質が十分でないマニュアルが最後の方まで残っていることがあります。

 マニュアルのテストが不十分になる原因は、大きく2つあります。

  1. マニュアルが製品と並行して完成に近づく性質があり、最後の最後まで更新が続けられがちなので、テストを後回しにしてしまう。
  2. 他のテストに比べて単純で退屈に見えて、軽視してしまう。

 さらに、『アクティブユーザのパラドックス』という概念があります。Nielsen氏の記事から引用してみましょう。

ユーザは絶対にマニュアルを読まない。いきなりソフトウェアを使い始めるのだ。彼らには始めようという意欲が旺盛であり、目前には片付けるべきタスクもある。システムそのものには関心がなく、事前の取り決めや設定、学習パッケージに時間を割くつもりはないのだ。

 こうなると、ろくに読まれもしないドキュメントのテストの費用対効果って?と疑問に思うこともあるでしょう。

ドキュメントテストが大事な理由

 では、マニュアルはいつ読まれるのか。
 経験上、それは「最初の最初」と、「困ったとき」ではないでしょうか?
 そんな場合にマニュアルの品質が悪いと、どうなるか。

 「最初の最初」は、ソフトウェア製品でいうと「インストール」にあたります。インストール方法がわかりづらい、ましてや失敗するとあっては、どんなに魅力的な機能を謳ったところでむなしいだけです。
 「困ったとき」は、その時点ですでにストレスが溜まっているわけです。イライラしているところにきて、マニュアルに沿って操作してもうまくいかない。場合によっては事態を悪化させる。不愉快の二乗です。こんな最悪なユーザ体験ってあるでしょうか。

 またユーザからすると、「マニュアルに書いた通りに動く、ことすら確認していないのか、この製品は」ってなりますよね。
 ユーザを助けるためにも、また信頼を失わないためにも、ドキュメントの品質はとても重要なのです。

ドキュメントテストの2つの段階

 では、ドキュメントの品質はどのように評価*5するのでしょうか。
 白プレでは、ドキュメントテストを2段階に分けています。

1段階目はテクニカルレビューで、ドキュメントが明確な文章であるかを確かめる。2段階目は動的テストで、ドキュメントと合わせて実際のプログラムを動かす。

 マニュアルって、ユーザが直接目にするもので、つまりある種のUIなんですよね。
 決められた体裁に従っているか、文章が論理的で、長すぎず、主述のねじれがなく、適切に箇条書きや図表が利用され、・・・みたいな、テクニカルライティングのお作法に沿っているか、を確認する必要があります。これが1段階目で、レビューの対象になります。

 そのうえで、書かれたことが「正しい」かどうかは、テストの対象。2段階目です。  

 時間のない中で作られたマニュアルは、「まるっきり間違っている」よりも、「部分部分は正しい、全体としては正しくない」になりやすいように思います。あることを実現するために10ステップ必要な場合に、1~5は正しい、7~10も正しい、でも6が抜けている。みたいなイメージです。

 こんなことが起こる要因にも、いくつか考えられます。

  • マニュアルに載せる手順を、部分部分の切り貼りで作っている。
  • 書き手が中身を知りすぎていて、暗黙のステップを飛ばしてしまう。
  • いろいろと「設定済み」の開発環境で動かしているために、本来は必要な設定の手順が漏れる。

 ですのでマニュアルのテストはできる限り、「そのマニュアルを作った人以外」が、「ユーザがその操作を行うであろう状態を模擬した環境」で、「手順を一気通貫して」行うのがよいと思います。

 なお、ドキュメントテストを完全に独立したテストとして行うことが必須かといえば、そんなことはありません。インストールテストの中でマニュアル確認を兼ねたり、エラー系・障害系のテストでトラブルシューティングの章を検証したりというのは、悪くない作戦だと思います。

マニュアルを書くのは誰?

 マニュアルを誰が書くかは、組織によっていろいろでしょう。開発者がマニュアルまで書く場合もあれば、専門のテクニカルライターがいるケースもあるでしょう。今回の記事は、どちらかといえば前者の場合に当てはまるかなと思います。

 後者の場合は、開発部門とライター部門の垣根を低く、連携を密に、お互い敬意をもって、みたいなコミュニケーション上の留意事項も出てきます。
 ともあれ、「ユーザによって読みやすい文章を書ける」というのはプロフェッショナルのスキルであり、それがしっかりできるテクニカルライターさんには敬意を感じます。

books"books" by whereisyourmind is licensed under CC BY-NC-SA 2.0

*1:『実践ソフトウェアエンジニアリング 第9版』の通称。略称は『白プレ』。

*2:なぜか資料内では「マニュアルテスト」と表現していました。これだと手動テストと混同されそうです。

*3:これをTwitterでつぶやいたところ、辰巳敬三さんが以下のように教えてくださいました。

documentation testingはGlossaryのVersion 3.1迄はあり、Version 3.2で"Not mentioned in any syllabus"という理由でremoveされています。
定義は、
documentation testing: Testing the quality of the documentation, e.g. user guide or installation guide. ドキュメンテーションテスト(documentation testing): ユーザガイドやインストールガイドのようなドキュメントの品質をテストすること。

*4:取扱説明書、ユーザーズガイドなどと呼ばれることもありますが、以下「マニュアル」で統一しています。

*5:ドキュメントの品質の「作り込み」は、テクニカルライティングという別の分野の要素が強くなるため、この記事では触れていません。