品質保証とは何か
個人的には品質保証の活動というのは他の領域バックエンド、フロントエンド技術よりクリティカルで、専門性がかなり必要な分野だと感じています。（そもそもそれらを一緒にして良いのかはわかりませんが。）
テスターからQAエンジニアになる。と言う話は聞きますが、QAとしての活動はテスト実行やテスト設計に限らないということを覚えていただければ幸いです。
QA（品質保証）
QM（品質マネージャー）
QC（品質管理）
品質についての範囲や考え方に関しては下記URLで詳しく述べられています。
https://qualab.jp/qualityengineer/
ISO9000に関して調べてみるのも良いかもしれません。
https://ja.wikipedia.org/wiki/ISO_9000
QAに必要な知識、経験を備忘録的に章ごとにまとめたいと思います。長くなりそうであれば別記事にするかもしれません。
プロダクト品質向上のためのコミュニケーションスキル
QAに必要なコミュニケーションについて述べます。
よくQAエンジニアの採用要件に以下のことが書かれていることがあります。
プロジェクトマネージャ、UI/UX、バックエンド、フロントエンド等とチームの枠を超えたコミュニケーションができること
どうして書かれているのかというと、全体プロダクト品質を押し上げる為に必要だからです。
品質を担保するということは、各ラインで作られたものがどのように作られているか、仕様に沿って作られているかをしっかり見ていかなければいけません。
これをしっかりやらないと、やらなくてよかったテストが生まれて余計な工数が発生したり、致命的なバグや急な仕様変更の多発でリリースの計画に多大な影響をもたらす可能性があります。
仕様をきちんと伝えたり、相手にわかりやすく伝える力
自分が思っているより相手に伝わっていないケースがこの業界は本当に多いです。余計なコミュニケーションコストを産まないためにも自分自身も注意したいです。
論理的説明、進捗が追いやすく、わかりやすくて簡潔な報告
リリーススケジュールから逆算して、今どの程度品質が担保できているのかをわかりやすく、簡潔に報告しないといけません。
テストケース数に対しての不具合率を報告したり、テストの進捗に影響がありそうな事柄がある場合にどれくらい検証がずれ込みそうなのか、全体スケジュールに対しての影響は本当にないのかを精査しないといけません。
これができると開発を安心させることができる貴重なQAになれると思います。
コード品質（静的解析）
コード品質に対する考え方を述べます。
コード品質が最悪なことによって、リリースのためのリードタイムが低下したり、不具合の温床になることがあります。
コード負債と呼ばれたりもします。
コード品質の考え方で品質を測る９つの特性等があります
1.可読性
2.信頼性
3.保守性
4.効率性
5.移植性
6.一貫性
7.再利用性
8.ドキュメント
9.セキュリティ
基本的には各プログラミング言語にはコード品質のリファレンスというものがあります。
Java：Code Conventions for the Java TM Programming Language
コードを書く人によって、書き方にはどうしても差が出てきます。開発環境や使ってるツールによっての差も出ると思います。
それを合わせる為には、コーディング規約を作る必要などもありますが、大体は使われなくなったり、古くなって陳腐化するのではないかと思います。
その為に静的解析ツールを導入して、上記9つのうち、セキュリティを担保しよう。とか、命名規則等合わせやすいものに関してはドキュメント化する。そもそもクリアしていないとプッシュやデプロイされない等の仕組みに落とし込む。
開発の人が辛くなるコーディング規約を作らないのが継続するコツだと思います。
ある程度これだなと思うことがあればスケールさせてチーム内外に共有して文化として落とし込むのもありだと思います。
CI/CD
CI：継続的インテグレーション（主に開発者向けの自動化プロセスを指す言葉）
RedHatの記事にはこのような記述があります。:https://www.redhat.com/ja/topics/devops/what-is-ci-cd
CI/CD の「CI」は継続的インテグレーション (Continuous Integration) を指すのが常で、開発者向けの自動化プロセスを意味します。CI が正常に機能すると、アプリケーションへの新しいコード変更が定期的にビルド、テストされ、共通リポジトリに統合されます。CI は、同時に生じるブランチが多すぎて互いに競合するというアプリケーション開発の問題を解決します。
CD：継続的デリバリー
継続的デリバリーは一般に、開発者によるアプリケーションへの変更に対して、バグがないか自動的にテストし、リポジトリ (GitHub やコンテナレジストリなど) にアップロードします。ここで、変更が運用チームによって本番環境に導入されます。開発チームとビジネスチームとの間における可視性とコミュニケーションの不足という問題に対する解決策です。したがって、継続的デリバリーの目的は、新規コードの導入作業の負担を最小限にすることです。
品質保証と関連があるのかと思われるかもしれませんが、実際に開発や本番リリース等で不具合があったら困るので、品質保証の観点から関わっていく必要が必ず発生する。
運用設計
運用設計に関してはISO9000系に準拠した運用にする必要があるとされてます。この辺りは記事にしていきたいです。
ISO 9000の示す品質マネジメントモデルを導入することでの、個々の企業や事業体の活動への効果については議論になることもあるが、それでも顧客はISO 9001の認証をサプライヤーに要請し続けている[26]。特にEUの様に非関税障壁めいて、ISO 9001の認証が事実上市場で活動するための条件になっているというビジネス環境が理由で、ISO 9001の認証を目指すというのは、事業体がISO 9001の認証を得る動機の一つである。業界によっては必ずしもISO 9001の認証が必要なところばかりではないが、新規顧客の獲得、従来の顧客の維持、ISO 9001の品質マネジメントモデルを導入している事実をセールスポイントにするといったマーケティング上の利益を期待してISO9001の認証を得る場合もある
品質担保の基準を策定する
ソフトウェア品質特性に則って、ソフトウェア品質を担保する基準の策定、リリースする必要がある。
外部品質
ソースコード実行時の振る舞いや、実際にシステム利用時の品質にあたる。
内部品質
ソフトウェアの内部的な特徴のことで、 ソースコードや、仕様書、設計書が対象になる。
６つの特性
■機能性：
きちんと機能として使用できるかどうか。処理としてきちんと動くかどうかの能力
■信頼性：
動作し続け、故障が起きにくいかどうかの能力
■使用性：
ソフトウェアを指定された条件のもとで動作するとき、利用者が理解、習得、利用がスムーズにおこなえる能力
■効率性：
与えられたリソースに対して、適切な性能を発揮する能力
■保守性：
できたソフトウェアの修正のしやすさの能力
■移植性：
別な環境へ移すことになった際に、容易に移せる能力のこと。
QAとして仕事を進めるのであれば、これらの基準を明確化、測定、分析ができることは必須だと思われる。
各特性の基準や測定、分析の仕方については別途記事を書きたい。
不具合やテストの結果から分析する
こちらに関してはメルカリさんの記事がとても良いと思いました。
https://engineering.mercari.com/blog/entry/20211222-6d545e2c99/
具体的にはデザインによる不備なのか、フロントやバックエンドの実装が起因しているか、どのバージョンや端末でバグが出ているのか、不具合の重要度ごとに分類して週次や月ベースでどの程度改善されたか等の振り返りができるととても良いと思います。
（ステークホルダーや幹部にも見せやすい）
管理コストを考えるとJIRA使ってみたい。スプレッドシートの関数でこれらを管理するのはなかなか骨が折れそう。
分析手法に関しても別途記事を書いていきたい。
パフォーマンス測定
パフォーマンス測定に関する指標を元に、開発をすることは大事だと思います。
現代ではアプリのレスポンスの速さはかなり重要視されています。
https://webtan.impress.co.jp/u/2018/07/30/30083
ある程度作り終える前にパフォーマンスに関する検証をいれることは非常に重要だと感じます。
パフォーマンスを落とすのであれば制限をつけたり、要件を落とすことも考えられます。
一番考えなければいけないのは使用性をクリアするかどうかだと思います。
（画面描画で１０秒や２０秒かかるアプリは誰も使わない）
この辺も、パフォーマンスチューニングを生業としてる方にいろいろ聞いてみたいです。
耐久テスト、負荷テスト
画面への一斉アクセスやAPIを一気に同時で叩いてダウンしないかどうかをテストする。
指標や考え方については下記のオラクルの記事が参考になりそう。
https://www.oracle.com/jp/technical-resources/article/ats-tech/tech/useful-class-8.html
これはソフトウェア品質特性の信頼性の担保になると思います。
セキュリティ
IPAがセキュリティに関しての資料を展開している。
開発側と連携して、できるだけセキュリティが担保されるようなテストシナリオを作成して実行する必要がある。
この部分を外部委託する会社もある。
https://www.ipa.go.jp/security/vuln/websecurity.html
1．1 SQLインジェクション
1．2 OSコマンド・インジェクション
1．3 パス名パラメータの未チェック／ディレクトリ・トラバーサル
1．4 セッション管理の不備
1．5 クロスサイト・スクリプティング
1．6 CSRF（クロスサイト・リクエスト・フォージェリ）
1．7 HTTPヘッダ・インジェクション
1．8 メールヘッダ・インジェクション
1．9 クリックジャッキング
1．10 バッファオーバーフロー
1．11 アクセス制御や認可制御の欠落
まとめ
かなり横断的に、かつ柔軟的に見れるQAエンジニアが求められているのではないかと最近感じています。
経験によって、できることにかなり幅があることも特徴的だと言えます。
市場価値はかなり今後高まっていきそうです。