①はじめに

アドベントカレンダー9日目。書きます！
気軽にコメントやマージリクエストください！
予約投稿となっておりまして即日の反応は難しい可能性もありますが、14日15日辺りには返信します。
早く本題から確認したいかたは、「④早く言います」をご覧ください。

この記事を書いた私のレベル感(押すと開きます！)

- QAとして - QAになって3ヶ月目を迎えました。 - 3ヶ月よりも前までは、C#でWindowsフォームアプリを主とする開発をしていました。 - 業務の中で自分で基本設計をした機能についての開発、単体テストケース作成、単体テスト実施、結合テスト実施はおこなったものの、結合テストやシナリオテストのテストケース作成の経験はありません。 - 当時はテストについて**「ワタシ！テスト！ツクル！ジッシスル！」**という枠組みでしか捉えておらず、そのことに課題意識があり2019年8月のJSTQB FLに挑戦しました。 - また、TDDを知って[NUnit](https://qiita.com/rohinomiya/items/47f09523f1b9dfa015b1)を使ったユニットテストの導入を試みたものの、どこを自動化すれば効率がいいのか皆目見当がつかず、当時は挫折してしまいました。 - プロジェクトで色々な難しさに直面する中で、どうすれば手戻りが減りかつ品質の良いプロダクトが作れるのだろう、そもそも「品質が良い」とはどういうことだろう、と考えていたときにQAという職種やアジャイル開発などを知り、QAとして転職をしました。 - テスト技法やテスト設計の流れについてはJSTQB FLである程度「知った」ものの、「知る」と「分かる」、「分かる」と「できる」の間にはまだ段差があるなと感じています。 - 英語力 - 大学時代は言語と野球に興味があったため、社会言語学×英語学×野球の分野で卒論を書きました。 - 興味のある分野の学術書であれば、苦しみながら読むことができたりできなかったりします。

②The Principles of QA

#とは何か

“The Principles of QA“という本はありません。

『ソフトウェアテスト293の鉄則』という本の原著が、
“Lessons Learned in Software Testing“です。
- Markさんが教えてくれました。
内容を見た限り、テスト以外にもQAとして活動していくにあたって重要な原則が並んでおり、これはQA版の『プリンシプルオブプログラミング』と言っても過言ではないのではと思い、本記事のタイトルとしました。

“Lessons Learned in Software Testing“

“Lessons Learned in Software Testing“について、日本語で鉄則だけ確認したいならば日経BPさんの目次から読むことができます。
原著も邦訳も、鉄則部分のみであればAmazonからも確認することができます。
293も鉄則があり、原著と邦訳があればその293の鉄則部分や解説部分の日英の訳が比較できるわけです。

③目指すゴール

「英語力と野望のギャップを埋めつつ、
QAに関する原則(The Principles of QA)を学ぶこと」

野望

まだ日本語に訳されていないQA界隈の情報を得られるようになりたい！
そして社内外でそれに関心がありそうな人たちとワイワイ面白がりたい！

And more…！

そのうち“More Agile Testing“を読んでみたいと思いつつもAgile Testing関連で言うならばまずは“Agile Testing“と『実践アジャイルテスト』を参考にしながら“Agile Testing Condensed“を読むところからかなぁ。
- テスト設計コンテストのことも色々調べてみたいし、でもQA界隈の英語をぼちぼち拾い始めたいし、QAに関する原理原則のようなものも知りたい！

- であれば、まずは[“Lessons Learned in Software Testing“](https://www.amazon.co.jp/gp/product/8126506997/ref=dbs_a_def_rwt_bibl_vppi_i1)と[『ソフトウェアテスト293の鉄則』](https://www.amazon.co.jp/ソフトウェアテスト293の鉄則-Cem-Kaner/dp/482228154X/ref=sr_1_1?adgrpid=60120324664&gclid=CjwKCAiA5o3vBRBUEiwA9PVzamw36AzLV0bxcEefx08luSv29xjrPftyl2VkMV6IO028tHrGIHmJpxoCNbQQAvD_BwE&hvadid=338518119357&hvdev=c&hvlocphy=1009309&hvnetw=g&hvpos=1t1&hvqmt=e&hvrand=2341921792769584869&hvtargid=kwd-363155938284&hydadcr=27268_11561170&jp-ad-ap=0&keywords=ソフトウェアテスト293の鉄則&qid=1575208382&sr=8-1)の鉄則部分だけまとめたPDFを自分用として作って、それで電車などの隙間時間に眺めて覚えていくのはどうかと思い、実践中です。

まずはそれをもとに、**「既に日本語に訳されているQA界隈の英語で面白がりたい！」**から始めてみようかと！

④早く言います

引用しながら
- 「これは本当に『それな』って思いますね〜」
- 「なるほどですね〜」
- 「懐かしい単語や文法が出てきましたね〜」
- 「これはまだ私にはピンとこないですね〜」
などなどなにか早く言います。
網羅的ではありません。
間違えていたら「編集リクエスト」やコメントで教えていただけると幸いです。

「これは本当に『それな』って思いますね〜」

| 鉄則番号 | ソフトウェアテスト293の鉄則 | Lessons Learned in Software Testing |
|--:|:--|--:|:--|
| 005 | 重大なバグを素早く見つけよう | Find important bugs fast |

致命的なものは早く見つけたいですもんね〜みんなの手戻りや負担を減らしたい。

| 153 | 自らの誠実さと能力を示さずに技術的信頼関係など築けない | Your integrity and competence will demand respect |
|--:|:--|--:|:--|

integrityとcompetence持って生きていきたい。

「なるほどですね〜」

| 027 | テストとは探求することだ。 | To test, you must explore |
|--:|:--|--:|:--|

探索だいじ
- 探索的テスト関連でexploreはよく使われるのでしょうね。

| 038 | テストのアイデアがすぐ欲しいとき、経験則が役に立つ | Use heuristics to quickly generate ideas for tests |
|--:|:--|--:|:--|

野球で同じボールが二度と来ないのと一緒で、テストも全く同じテストをすることって二度となくて。
- でも、「目の前のこれはあのときのあれが役立つ」というストックを意識的に作れば過去に失敗したとしても今後に活きますね。
- 何かこう、副詞ってこう使うんだよって説明したいときのための位置にquicklyが居る感がありますね。

| 039 | 思い込みから逃れられなくても、上手く付き合うことはできる | You can't avoid bias, but you can manage it |
|--:|:--|--:|:--|

DUOとかに出てきそう。
この鉄則は下の40にも関連しますね。

| 040 | 騙されやすいと自覚することが騙されない秘訣 | You're harder to fool if you know you're a fool |
|--:|:--|--:|:--|

miwaさんの「違和感の捕まえかた」のお話に出てきたことと繋がるものがあるような。

| 046 | テスト技術者の成長もテストの成果の一つである | One important outcome of a test process is a better, smarter tester |
|--:|:--|--:|:--|

肝に銘じて日々成長していきたいですね。
- One important outcome of a test processまでが主部。

| 083 | 障害レポートはタイトルで決まる | The Summary line is the most important line in the bug report |
|--:|:--|--:|:--|

The Summary lineがthe most important lineなんですね。
確かに、タイトルや要約で「何がどうなっている」ではなくて「何をどうして欲しいのか」が明確になってたほうが読む側のコストを奪わないのだろうなということは最近考えますね。

| 114 | テストツールにもバグはつきもの | Test tools are buggy |
|--:|:--|--:|:--|

この前の神龍さんのTestCafeの話とも繋がるものがありますね。

| 184 | どのくらいテストをすればよいかという質問に解はない | There is no universal formula for knowing how much testing is enough |
|--:|:--|--:|:--|

この前のテスコンチュートリアルの話と繋がりますね。
考え抜けるかどうか。

| 185 | 「充分なテスト」とは「正しい状況判断を下すのに充分な情報を得られること」である | Enough testing means "enough information for my clients to make good decisions" |
|--:|:--|--:|:--|

チームみんなでああでもないこうでもないって知恵を振り絞って、これが現時点での私たちの充分であり、限界であるってとこまで考え抜けるかどうか。

| 276 | テストの進め方の指針をまとめたものがテスト計画である | The real test plan is the set of ideas that guides your test process |
|--:|:--|--:|:--|

単なる「それっぽい資料」ではない。

| 281 | テスト戦略はテスト項目より重要だと心得よ | Your test strategy is more than your tests |
|--:|:--|--:|:--|

「なぜこれをするのか」を明確に。

| 282 | テストの質は戦略に左右されると肝に銘じろ | Your test strategy explains your testing |
|--:|:--|--:|:--|

意図がないテストケースの羅列を作らないために。

| 286 | 「どうすればより良いテストができるか」を常に問い続けよ | At every phase of the project, ask yourself "what can I test now and how can I test it?" |
|--:|:--|--:|:--|

常に考え抜く。「常に」はAt every phase of the projectで、もう各フェーズで常時問い続けるってことなんですね。
- 後半はテスコンチュートリアルに書いてあることのオンパレードなんだなと気付きました。

「懐かしい単語や文法が出てきましたね〜」

| 036 | 「テスト」と「テストをする」ことを混同してはならない | Don't confuse the test with the testing |
|--:|:--|--:|:--|

confuse A with B「AをBと混同する」
- それをDon'tで禁止しているんですね。
confuseに関しては本当にDUOにAt times I confuse " curve" with "carve" として掲載されてるんですよね。
ということは、この本はQA版のDUOといっても過言ではないのかもしれませんね。
余談ですが(この記事自体余談ですが)、学生時代の国語の教科書の話や、「この問題集にはこの文脈でこの単語が出て来た」ということを割と今でも覚えていて、それは自分にとっては何かしらの礎になっている気がしています。また、そういうことを思っているのは私だけかな？と思いきや、最近割と同じような人に出会うことが多くなった気もしています。
大人になるにつれてバックグラウンドの共通項が少ない人と出会うことが増えた気がしますが、こういう礎的な部分の共通言語持ってると、話が早かったり単純に楽しかったりするなぁと感じました。
それならば、「学生時代の礎の切り崩し」ではなくて、社会人になってから新たに興味持った分野に共通項あったらば、そこの礎を見極めて自分のものにし、それを共有し、礎をお互い確固たるものにしたり広げたり見直したりするきっかけに出来れば、話が早くなるかも知れないし単純に楽しくなるかも知れないってことかもなぁと！なんかいいですねそういうの！

047	習うだけではテストの達人にはなれない	047	You can't master testing unless you reinvent it

reinventが「再発明」
- 「車輪の再発明」はreinventing the wheel
- 「そんな単語知らなかったや。」と思ったかた、よくみて見るとこれ、re + inventなんです。
  - reって繰り返すイメージあるかと思います(リサイクルとか)、それとinvent「発明」がくっついて単語を作っているんですね。
  - これで言うところのreにあたるものを接頭辞と呼びます。
  - こうした接頭辞を頭に入れておくと、単語を頭にしまいやすくなることもあります。
  - 頭の中が部屋だとして、そこに単語がダ～！ゴチャゴチャ！足の踏み場ない！単語覚えるの大変！自分の記憶力に落ち込む！って感じになっている場合に、こうした接頭辞とか接尾辞とか語基とかを意識すると、その部屋の中に引き出しや仕切りが導入されてしまう場所が少しずつ分かってきて整理されるし、部屋自体も不思議と広くなる(ように見えるだけかも？)気がします。
  - 「へ〜そうなんだ〜接頭辞とか気軽に知りたいな〜！」というかたには『英単語の語源図鑑』がオススメです。

「これはまだ私にはピンとこないですね〜」

| 037 | 複雑なテストは速攻の繰り返しでこなせ |When testing a complex product: plunge in and quit |
|--:|:--|--:|:--|

plungeが「踏み出す」感じのニュアンスだとして、やってみながらスピード感持って改良していこうねって感じですかね？
困難は分割して分割した一個一個に対して走りながら考えていこうね〜みたいな。

| 283 | 多様的ほどほどの原則でテストする | Apply diverse half-measures |
|--:|:--|--:|:--|

網羅性をだいじにしようということですかね？
この2つ以外にも、「自分がピンと来てないことにさえもまだ気付けてない鉄則」はたくさんありそうです。

⑤さいごに

「293もあれば全部網羅されてるだろう！」と盲信するのはなんだか危険な気はします。「完全なもの、完璧なもの」が存在すると思わずに、基礎として自分のものにしつつも不足部分に気付く。そして気付いた部分をチームで共有して「共通認識」を増やすことができれば、早期に気付ける・掴める何かが増えていくのではと考えています。
ただ、「基礎として自分のものに」を疎かにしたまま不足部分を探しに行ったところでreinventing the wheel感が強くなってしまうため、まずは293個の鉄則ひとつひとつを自分の頭で考えてみることから始めたほうが良さそうです。
できれば、「自分の頭で」だけでなく、社内外の色んなチーム、ポジションの人たちとこの鉄則囲んで議論(議論というほどかしこまらなくてもいいかも)をしてみたいです。
邦訳が出ている本を補助輪にして技術系の洋書に手を伸ばしてみるのは面白いなと思ったので、これからも続けてみます！それで感覚を掴んだら補助なしに乗り換えて、色んな知識に手を伸ばしてみます！