アーリー期の「スタートアップ」 企業や エクスパンションの「スタートアップ」 企業がある程度、組織として大きくなると、社内に 「QAチーム」 ビルディング構想が表面化します。
1.事業規模拡大による提供サービス品質保証（IPO計画する上でのサービス品質保証）
2.不具合レベル策定やリリース基準/リリース判定の計画
3.現状の不具合に対しての調査や不具合分析活動
4.社内の複数プロダクト一定の品質を担保やリリースフロー策定・改善
5.社内のエンジニアに対してQAの啓蒙活動
まず初めに 「組織構築」 や、「現状調査」、「人員確保」 から着手します。
※開発・SRE・CSチームとの品質意識が大事になり、QAの一方通行が一番良くない。
「QAチームを構築」 することで何を事業品質として提供できるかが大事になります。
1.常に資料を作成（リリース基準・テストフローなどのアウトプットは定常的に）
2.QAチーム立ち上げ前と立ち上げ後の品質についてまとめ
3.不具合の数が減ったことを上層部にアピールする
（※レベルの高い不具合検出をアピール）
4.開発やインフラ・SREエンジニアに対して品質意識付け
5.仕様品質改善（仕様バグ）
1.開発側だけのテストでは不具合が収束せず、専任チームがいることでの品質の向上
2.スピードと品質、両方大事であり、専任チームがあることで開発側の負担が無くなる
3.過去起きた障害を分析し、把握対処することに時間をかけることができる
4.QAチームの情報を開発側にも提供でき開発チームのテストへの意識が高まる
5.リリース判断をQAチームに委ねることにより、品質の最終ジャッジができる
6.不具合の改修確認を勝手にディレクター、開発者がすることなく、QAに最終権限
次に、どこの所属になるのかで多少は変わります。
システム開発部（開発チーム）の下なのかビジネス部（企画チーム）なのか。組織は大事です。
ま、ちょっと考えて見ましょう。
私の考えでは、企画チームは 「QAチーム」。開発チームは 「テストチーム」 と位置付けております。
システム開発部(開発チーム）だと、開発エンジニアは、テストチーム＝テストまるごとと思う方も少なくありません。
なので、作成したコードかけばあとはよろしくってなことになってしまいます。
開発エンジニアが、単体テストもしない。いやテストをやらない。
まずは、開発エンジニアが単体テストを実行し、ある程度担保された品質で、テストチームが
結合テスト、システムテストをします。
開発エンジニアに、テストというものをレクチャーすることも仕事かもしれません。
テストは、現場によって様々なのでどう説明するか。
ビジネス部は、組織全体を見ています。
ビジネス部のQAチームはこんな流れで作業します。みたいな作業マニュアルをまずは作成。
それで、QAチーム内でレビューし、他部署に展開する。開発側だけではなく運用側も対象になる。
1.社内プロダクトメンバーとの連携
2.メンバーの採用、教育、配置、外注管理。
3.テスト計画からテスト実行、報告まで。報告内容からのリリース判定
4.自動化できる案件のテスト自動化対応
5.QAチームのパフォーマンス（存在意義）
QA組織立ち上げ（ビルディング）開始時、必須となる項目
1.組織図（どんなチームを何名？とのように）
2.QAマネージャー（組織に必ず置きましょう。QA側の決定権と予算を持つ人間）
3.全体スケジュール作成と共有
4.上層部へグループ方針を伝える
5.リリースフローやテストフロー図、不具合レベル指標（責任範囲や、チームの作業タスクを決めるため）
6.ドキュメント用意（テスト計画書、テスト設計書、テスト仕様書、不具合起票方法）
7.正社員とテストベンダー社員のタスク（正社員は何をすべきか、またベンダーには何をしてもらうか）
8.サービス仕様の確認、不具合チケットの確認
9.作成したフローや指標を元に、稼働してみる
10.課題点は都度チーム内で共有し、フローや指標を見直す（これを繰り返しながらチーム運営する）
予算も考え、外部テストベンダーを使うことも考えましょう。
現場のテストにもよりますが、下記の契約となります。
直接指示をしたい場合は、「派遣契約」テストベンダーに作業を依頼し報告だけもらいたい場合「請負契約」
1.派遣契約
2.請負契約
3.準委任契約
外部テストベンダーデメリットもあります。
※やはり、自社のQAテスターも常時必要である。知識や質を常時確保するにも。また教育という点でも。
1.実施メンバーの交代によるテストの質の低下
2.スキルシートに見合わないメンバーのアサイン
3.テスト実施案件がない場合のタスク確保