품질보증팀 출범

얼리기의 「스타트업」기업이나 「벤처」기업이 어느 정도, 조직으로서 커지면, 사내에 「QA팀」 빌딩 구상이 표면화합니다.

빌딩 이유로

1.規模拡大によるサービス品質保証
2.IPOを計画する上でのサービス品質保証
3.不具合レベル策定やリリースの計画
4.社内エンジニアに対してQAの啓蒙活動
5.社内のどのサービスも一定の品質を担保
6.テストフローとリリース基準よる品質保証

우선 처음에 조직 구축이나, 현상 조사, 인원 확보로부터 착수합니다.
QA 팀을 구축하는 것으로 무엇을 요구할까.

보고 예

1.常に資料を作成（アウトプットは定常的に）
2.QAチーム立ち上げ前と立ち上げ後の品質についてまとめ
3.不具合の数が減ったことを上層部にアピールする（※レベルの高い不具合検出をアピール）
4.エンジニアの品質に対する意識
5.上流からの品質改善（仕様バグ）

QA 체제를 구축하는 이점

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.テスト実施案件がない場合のタスク確保