버그가 프로덕션에 도달하면 누군가 테스트 실행을 잊어버린 것이 원인이 아닌 경우가 많습니다. 요구 사항에 대해 의문이 제기되지 않았거나, 테스트 데이터가 잘못되었거나, “완료”의 의미에 아무도 동의하지 않았다는 것입니다. 소프트웨어 테스트 수명 주기는 첫 번째 요구 사항부터 최종 보고서까지 명확한 구조를 테스트하여 이러한 문제를 해결합니다.

이 가이드에서는 각 단계를 설명한 다음 모든 단계에 걸쳐 한 가지 예시 기능, 즉 5번의 시도 실패 후 계정을 잠그는 로그인 페이지를 따릅니다. 소스는 단계 수에 대해 완전히 동의하지 않습니다. 7~8개의 모델이 표시되지만 대부분 동일한 작업을 다르게 분할합니다. 우리는 널리 알려진 6단계 버전을 사용합니다.

STLC란 무엇인가요?

STLC는 소프트웨어가 요구 사항을 충족하는지 확인하기 위해 수행되는 정의된 일련의 테스트 활동입니다. 각 단계에는 목표, 입력 및 출력이 있으므로 테스트는 마지막에 즉석에서 수행되기보다는 계획되고 추적 가능합니다.

이점은 실용적입니다. 테스터는 결함을 수정하는 데 비용이 적게 드는 초기에 참여합니다. 노력은 가장 높은 위험을 초래합니다. 그리고 관리자가 “출시할 준비가 되었나요?”라고 물으면 팀은 증거를 제시하여 대답할 수 있습니다.

6개의 STLC 단계 개요

진입 기준은 단계가 시작되기 전에 충족되어야 하는 조건입니다. 종료 기준은 종료되기 전에 충족되어야 하는 조건입니다. 예를 들어 팀이 손상된 빌드에 대해 테스트를 실행하여 하루를 낭비하는 것을 방지합니다.

1단계: 요구사항 분석

테스터는 테스트할 수 있는 것과 불분명한 것을 알아내기 위해 요구 사항을 연구합니다. 질문 비용이 프로덕션 수정 비용보다 훨씬 저렴하기 때문에 이곳은 버그를 예방할 수 있는 가장 저렴한 장소인 경우가 많습니다.

• 항목: 요구사항 문서 또는 사용자 스토리를 사용할 수 있습니다.
• 활동: 기능적 및 비기능적 요구 사항을 식별하고, 질문하고, 위험을 평가하고, 자동화할 수 있는 항목을 결정합니다.
• 종료: 공개 질문에 답변하고 요구사항 추적성 매트릭스(RTM)가 시작됩니다.
• 제공물: 테스트 가능한 요구 사항 목록 및 RTM.

로그인 예. “5번의 시도 실패 후 계정을 잠급니다”라는 이야기가 있습니다. 좋은 테스터는 이렇게 묻습니다. 5는 어느 기간에? 어떻게 잠금이 해제되나요? 로그인에 성공하면 카운트가 재설정되나요? 어떤 메시지가 표시되나요? 각 답변은 테스트 가능한 것이 됩니다.

2단계: 테스트 계획

팀은 범위, 접근 방식, 사람, 도구, 일정 및 위험을 결정합니다. 테스트 리드는 일반적으로 이 단계를 소유합니다.

• 항목: 요구 사항 및 초기 위험 평가를 분석했습니다.
• 활동: 범위를 정의하고, 노력을 추정하고, 도구를 선택하고, 역할을 할당하고, 이후 단계에 대한 종료 기준을 설정합니다.
• 종료: 테스트 계획이 검토되고 승인됩니다.
• 제공물: 테스트 계획 및 예상 노력입니다.

로그인 예. 범위 내: 웹 및 모바일의 잠금 규칙, 재설정 및 오류 메시지. 범위 외: Single Sign-On이 다른 팀에서 처리됩니다. 가장 큰 위험은 실제 사용자를 차단하여 가장 많은 관심을 끄는 것입니다. 계획이 전략과 어떻게 다른지 잘 모르겠으면 테스트 계획과 테스트 전략을 읽어보세요.

3단계: 테스트 케이스 개발

테스터가 자세한 테스트 사례, 자동화 스크립트 및 테스트 데이터를 작성하는 곳입니다.

• 진입: 승인된 테스트 계획과 안정적인 요구 사항.
• 활동: 테스트 사례 작성 및 검토, 데이터 준비, 자동화된 검사 스크립트 작성 및 RTM 업데이트.
• 종료: 테스트 사례와 데이터가 검토되고 준비되었습니다.
• 제공물: 테스트 사례, 스크립트 및 테스트 데이터.

TC-01과 TC-02는 경계 값 분석에서 바로 나온 한계의 양쪽을 테스트합니다. 이를 잘 작성하는 방법에 대한 자세한 내용은 테스트 케이스 작성 방법을 참조하세요.

4단계: 테스트 환경 설정

테스트를 실행하려면 적절한 서버, 데이터, 계정, 브라우저 및 네트워크 액세스 등 현실적인 곳이 필요합니다. 이 단계는 3단계와 병행하여 실행되는 경우가 많으며 개발자나 DevOps 팀이 처리할 수 있습니다.

• 항목: 테스트 계획, 아키텍처 개요 및 환경 요구 사항입니다.
• 활동: 하드웨어 또는 컨테이너 설정, 데이터 로드, 액세스 구성 및 빌드 설치.
• 종료: 환경이 준비되었으며 연기 테스트를 통과했습니다.
• 제공물: 작업 환경 및 연기 테스트 결과.

로그인 예. 스테이징은 테스터가 기다릴 필요가 없도록 단축된 잠금 타이머와 함께 알려진 상태의 테스트 계정을 가져옵니다. 빠른 스모크 테스트를 통해 전체 실행이 시작되기 전에 로그인이 로드되는지 확인합니다. 컨테이너는 Docker Compose 튜토리얼에 표시된 것처럼 환경의 일관성을 유지하는 데 도움이 됩니다.

5단계: 테스트 실행

테스터는 계획된 테스트를 실행하고 실제 결과와 예상 결과를 비교하고 결함을 보고합니다. 수정된 버그는 다시 테스트하고, 관련 부분은 회귀 테스트를 받습니다.

• 항목: 테스트 사례가 준비되고 환경이 작동하며 빌드가 제공되었습니다.
• 활동: 테스트 실행, 결과 기록, 결함 기록, 수정 사항 재테스트 및 RTM 업데이트.
• 종료: 계획된 테스트가 실행되고 결함이 수정되거나 공식적으로 승인됩니다.
• 제공물: 테스트 결과 및 결함 보고서.

로그인 예. TC-04 실패: 두 개의 브라우저를 사용하면 카운터는 4개에만 도달합니다. 테스터는 버그 보고서 작성 방법에 설명된 대로 명확한 단계와 증거를 사용하여 버그를 기록합니다. 문제가 해결되면 TC-04가 다시 실행되고 관련 로그인 확인이 회귀 체크리스트를 거칩니다.

6단계: 테스트 종료

이 단계는 일반적으로 건너뛰는데, 이는 팀이 발전하는 방법이기 때문에 안타까운 일입니다. 팀은 주기를 평가하고, 작업을 보관하고, 배운 내용을 기록합니다.

• 입력: 실행이 완료되었으며 결함 상태가 알려졌습니다.
• 활동: 종료 기준 확인, 결함 추세 분석, 테스트 자산 보관 및 회고전 개최.
• 종료: 폐쇄 보고서가 승인되었습니다.
• 제공물: 종료 보고서 및 교훈.

로그인 예시. 보고서에 따르면 한 번의 수정 후 5건 모두 통과된 것으로 나타났습니다. 교훈은 동시성이 늦게 테스트되었기 때문에 카운터가 있는 향후 기능은 설계 중에 해당 시나리오를 추가한다는 것입니다.

STLC 대 SDLC

SDLC(소프트웨어 개발 수명 주기)는 전체 제품 구축을 다룹니다. STLC는 테스트에 중점을 두고 함께 실행되는 부분입니다.

SDLC의 요구 사항 분석은 STLC의 요구 사항 분석을 제공하고 개발은 테스트 실행에 빌드를 제공합니다. 테스트는 코딩이 끝날 때까지 기다릴 필요가 없습니다. 일찍 시작하는 것은 사람들이 “왼쪽으로 이동”을 의미하는 것입니다.

Agile 및 DevOps의 STLC

단계는 길고 단방향 프로세스처럼 들릴 수 있지만 반드시 그럴 필요는 없습니다. Agile에서는 동일한 활동이 각 스프린트 내에서 축소되고 반복되며, 몇 주가 아닌 몇 시간 내에 발생하는 경우가 많습니다.

• 요구사항 분석은 사용자 스토리에 대한 질문을 통해 백로그 개선 과정에서 발생합니다.
• 계획은 긴 문서 대신 간단한 메모를 사용하여 스프린트 계획에서 발생합니다.
• 테스트 설계는 코딩과 함께 이루어지며, 종종 승인 기준 및 자동화된 테스트로 수행됩니다.
• 환경 설정은 컨테이너와 코드형 인프라를 통해 자동화됩니다.
• 실행은 CI/CD 파이프라인에서 지속적으로 실행됩니다.
• 종료는 스프린트 검토 및 회고의 일부가 됩니다.

유용한 것은 유지하고 위험에 맞게 서류 작업을 확장하세요. 소규모 내부 도구에는 짧은 체크리스트가 필요할 수 있으며, 은행 시스템에는 규제상의 이유로 공식적인 승인이 필요할 수 있습니다.

일반적인 실수

• 테스터를 늦게 데려옵니다. 요구 사항에서 발견된 버그는 릴리스 후에 발견된 버그보다 훨씬 저렴합니다.
• 모호한 종료 기준. 종료 기준이 없으면 마감일이 결정을 내립니다.
• 열악한 환경에서의 테스트. 잘못된 데이터 또는 구성으로 인한 실패는 시간을 낭비하고 신뢰를 약화시킵니다.
• 종료 건너뛰기. 그런 다음 팀은 다음 주기에서 동일한 실수를 반복합니다.
• 너무 엄격하게 따라갑니다. STLC는 가이드입니다. 무거운 문서가 자동으로 품질이 좋아지는 것은 아닙니다.

마무리

소프트웨어 테스팅 라이프사이클은 단순히 여섯 가지 질문에 대한 체계적인 답변입니다. 무엇을 테스트하고, 어떻게, 어떤 사례로, 어디서, 무슨 일이 일어났고, 무엇을 배웠습니까? 다음 기능을 살펴보고 팀에서 일반적으로 건너뛰는 질문이 무엇인지 확인하세요. 그 한 가지 격차를 해결하면 아마도 가장 큰 이득을 얻을 수 있을 것입니다.

자주 묻는 질문

계속 학습하세요