JSTQB Technical Test Analystの学習で心に残ったことをまとめる
bun913今回もシラバスなどを読みながらブログやLTで発表する（アウトプットする）気持ちで気になったことを整理するというスタイルでやっていく。
Exam Structure で旅路を想像する
まずは Exam Structure をみてどんな問題が重視されるのかを確認することにした。
Test Analyst の時にはブラックボックスのテスト設計技法が半分程度を占めていたが、TTAではホワイトボックステストの比重は大きめではあるものの、結構いい感じに点数が散らばっていることがわかる。
- 2: White-Box Techniques ・・・ 17点
- 3: Static and Dnyamic Analsys・・・14点
- 4: Quality Characteristics for Technical Testing・・・21点
- 5: Revies・・・13点
- 6: Test Tools and Automation・・・11点
のようになっていることから、どれかの分野を中心的にやるというよりも「テクニカルテストアナリストとして」「どのような品質特性を大事にしながら」「テストや解析の仕事を進めていく」という意識を持って読み進めたり問題を解くことが大事そうだと感じた
bun913However black-box test techniques are normally applied first, coverage is then measured, and the white-box test technique only used if the required white-box coverage level has not been achieved.
2.8 Selecting a White-Box Test Technique
確かにこれまでの現場でもブラックボックステストが使われることが多かった。
bun913Note that when determining the white-box coverage levels to be achieved for a system, it is quite normal to define different levels for different parts of the system. This is because different parts of a system contribute differently to risk. For instance, in an avionics system, the subsystems associated with in- flight entertainment would be assigned a lower level of risk than those associated with flight control. Testing interfaces is common for all types of systems and is normally required for all integrity levels for safety-related systems (see section 2.8.2 for more on integrity levels). The level of required coverage for API testing will normally increase based on the associated risk (e.g., the higher level of risk associated with a public interface may require more rigorous API testing).
カバレッジレベルは同じシステムでも基準を変える。となると、やはり設計がとても大事だし、重要なドメインを切り出すの大事。設計とモデリング力が超大事だよね。
bun913Such choices are typically a compromise between the perceived risks and the cost, resources and time required to treat these risks through white-box testing. In some situations, other treatments, which might be implemented by other software testing approaches or otherwise (e.g., different development approaches) may be more appropriate.
安全性に直結しない場合、以外と慣習とか業界ルールでホワイトボックスのカバレッジが決まることが多そう。コストとかとの妥協の産物的な。
高橋先生も命に直結しないシステムは80%と書籍の中でお話しされていたな。
bun9132.8.2 より
安全性の基準として
SILというものがあることを知った
最高レベルでは10000年が故障間隔らしいよ。
bun9133.1 Control flow analysis
制御フロー解析というらしい。
はえぇぇぇ。グラフ化して整理する。
あぁぁサイクロマティック複雑度を整理するときに使うのか。高橋先生の本で読んだぞ。
エッジの数とノードの数、連結成分の数から算定できるよ。やっててよかった競プロ。
bun9134.1 Introructionより
4章は「TTAが関わるべき品質特性」のようなものが述べられていく章の様子。
In general, the Technical Test Analyst focuses testing on "how" the product works, rather than the
functional aspects of "what" it does. These tests can take place at any test level.
ここに書いてあるようにTTAは「どのように」プロダクトが動くかを意識してみる。機能面で「何を」というのはあまり領域ではない模様（この辺はテストアナリスト側の領域に近いはず）
bun9134.2.1 StakeHolder Requirements
In agile software development non-functional requirements may be stated as user stories or added to
the functionality specified in use cases as non-functional constraints.
アジャイル開発では、非機能要件はユーザーストーリーとして記載されるか、非機能な制約としてユースケースに追加される。
これは結構大事なことで、ユーザーストーリーって機能面しかかかれないがち。
どういう風にやれば、非機能面も漏れずにストーリー化できるかなぁ。
インセプションデッキなんかをしっかりやって（見直して）、ユーザーストーリーマッピングをやる時に非機能的な側面をいれることかなぁ。
bun913試験の特徴というかテクニックみたいになってしまうが、4-2 のTTAが関わるべき品質特性を理解しておくだけで8問分、16点分の得点が期待できる。
各特性の意味を理解しておけば十分得点が狙えるはずなので、日本語と照らし合わせて理解しておこう。
例えば「共存性」のイニが「異なるシステムや環境と共存できるか」という意味であることさえ理解しておけば、「単体テストレベルから実施するべき」という問題は違うなということを導けるはず。
bun9134.3.2 Security Test Planning
An essential aspect of security test planning is obtaining approvals. For the Technical Test Analyst, this means ensuring that explicit permission has been obtained from the Test Manager to perform the planned security tests. Any additional, unplanned tests performed could appear to be actual attacks and the person conducting those tests could be at risk for legal action. With nothing in writing to show intent and authorization, the excuse "We were performing a security
test" may be difficult to explain convincingly.
大事だけどなんか書きっぷりが面白くて草。
承認を得てからセキュリティテストをしないと、それはもはや攻撃的な。
大事すぎるかわざわざ書いてるんだろうな。温もりを感じる。
ちなみにこの分野は1点しかでないのだが、心に残ったので記録。
bun9134.4.5 Testing for Recoverablity
Recoverability is a measure of a system’s (or software’s) ability to recover from a failure, either in terms
of the time required to recover (which may be to a diminished state of operation) or the amount of data
lost. Approaches to recoverability testing include failover testing and backup and restore testing; both
typically include testing procedures based on dry runs and only occasional, and ideally, unannounced,
hands-on tests in operational environments.
こちらはセキュリティのテストとは逆に、抜き打ちで行われるのが理想とのこと。
ちなみにこの分野も1点しかないけど、なんとなく心に残った。
bun9135.1 Technical Test Analyst Tasks in Reviews
Technical Test Analysts must be active participants in the technical review process, providing their
unique views.
テストアナリストのシラバスでも同様に「積極的にレビューに参加して、特有の見解を述べるべき」みたいなことが書いてあった。
職責としてはテストマネージャーがテストに関する責任は取っていくけど、「アナリスト」として積極的に「技術的な観点から」助けになってくれ。みたいな意思を感じる。
テストアナリストはどちらかというと「ドメイン」や「ビジネス」を理解した上で、システムの機能性とかを中心に見る（使用性とかもユーザー目線だよね）ことが多かったが、テクニカルテストアナリストはもっとテック寄りな観点だなぁ。と改めて認識している。
bun9135.2.1 Architectural Reviews
Software architecture consists of the fundamental concepts or properties of a system, embodied in its elements, relationships, and in the principles of its design and evolution [ISO 42010].
Checklists1 used for architecture reviews of the time behavior of websites could, for example, include
verification of the proper implementation of the following items, which are quoted from [Web-2]:
“Connection pooling - reducing the execution time overhead associated with establishing
database connections by establishing a shared pool of connections
• Load balancing – spreading the load evenly between a set of resources
• Distributed processing
• Caching – using a local copy of data to reduce access time
• Lazy instantiation
• Transaction concurrency
• Process isolation between Online Transactional Processing (OLTP) and Online Analytical
Processing (OLAP)
• Replication of data”
この辺のアーキテクチャって例えばAWSでシステムを構成する時に自然と考えていることなんだよね。
この辺りをレビューするとなると、私の経歴的にも役立ちそうな部分がありそうで嬉しい。
bun9136.2.1 Fault Seeding Tools
単純に何それ？と思ったツール。
A tool for seeding (i.e., intentionally inserting) faults in a component or system.
意図的に欠陥を注入するツール？
Claude3 のSonnet君に聞いてみた。
「Fault Seeding Tools」と「Fault Injection Tools」はソフトウェアテストにおいて異常状況を再現するためのツールですが、その手法が異なります。
Fault Seeding Tools (フォールトシーディングツール)
テスト対象のソフトウェアのソースコードに意図的に欠陥(フォールト)を埋め込むツール
テストケースが埋め込まれた欠陥を見つけられるかどうかを確認する
欠陥の種類としては、メモリーリーク、デッドロック、null参照エラーなどを埋め込むことができる
主な目的は、テストの有効性を評価すること
具体例:
Javaの場合、muJavaというツールでメソッド内にエラーを埋め込めるようにしている
Fault Injection Tools (フォールト注入ツール)
ソフトウェアの実行環境に異常な状況を作り出すツール
ハードウェア障害、ネットワーク障害、リソース不足などの環境異常を人為的に発生させる
テスト対象システムがこれらの異常事象に対してどのように動作するかを確認する
主な目的は、障害許容機能や回復機能などの品質特性をテストすること
具体例:
CPUやメモリなどのリソースを意図的に制限するツール
ネットワークの遅延や切断を行うツール
つまり、Fault Seeding Toolsはコード内部に欠陥を埋め込み、テストの網羅性を評価するのに対し、Fault Injection Toolsは外部の環境異常によって障害対応の品質を評価するものです。
めっちゃわかりやすいやん。
なるほど Seeding はメモリリークなどの欠陥を注入して、テストがそれを検知できるかとかを見るのかな。
そして、Fault Injection Tools はネットワーク環境とかの外部的な要因のエラーを再現するためのものなのかなと理解した。
bun9135.2.2 Code Reviews
以下シラバスより抜粋。
例えば、Structure のフォーマットの部分とか本来人間が気にしてみるべきじゃないのよね。なので、TTAは自分のためにもフォーマッターは最初に入れておくべきだわ。
同様にLintもそうだね。
他にもN＋１問題とか、空間使用量的な話とかもきっとレビューできるべきだと思うし、良い設計を知ってないとコードレビューもできない。
少なくとも私が目指す開発者に近い位置でのテストマンになるには、引き続き開発者側の学習も要するのだとうことがわかり、心に残った。
ちなみにコードレビューに関してこちらのサイトでも述べられている。