software testing documentation guide
소프트웨어 테스팅 경력에서 사람들이 소프트웨어 테스팅 문서에 대해 많이 이야기하는 것을 들어 본 적이 없습니다. 테스트 문서에 대한 일반적인 의견은 자유 시간이있는 사람이라면 누구나 테스트 케이스, 테스트 계획, 상태 보고서, 버그 보고서, 프로젝트 제안 등과 같은 문서를 작성할 수 있다는 것입니다.
문서에 대해 더 많이 강조하지는 않았지만 모든 데이터를 흑백으로 배치하고 다른 사람들에게도 업데이트하는 것이 제 습관이라고 말할 수 있습니다.
학습 내용 :
내 경험
내 경험을 당신과 공유하고 싶습니다.
우리는 고객 중 한 명 (화난 고객)에게 프로젝트 (알 수없는 문제가 있음)를 전달했습니다. 그리고 그들은 우리에게 매우 나쁜 상황이었던 클라이언트 측에서 문제를 발견했으며 평소와 같이 모든 책임은 QA에있었습니다.
문제는 한 웹 사이트의 호환성과 관련된 문제였습니다. 제게 왔을 때 웹 사이트의 호환성도 확인해야한다는 요구 사항 문서를 얻지 못했다는 증거가있었습니다. 내가 안전 해 주셔서 감사합니다.
그것이 저에게 교훈이었고 문서의 중요성을 깨달았고 그날부터 문서 작업을 시작하고 테스트 계획, 테스트 사례, 온 전성 테스트 체크리스트, 버그 보고서 등과 같은 테스트 문서를 작성했습니다.
'잉크는 최고의 기억보다 낫다'– 중국 속담
테스트 문서 : 그게 뭐죠?
우리는 모두 테스트 기술과 방법에 대한 다양한 기사를 읽었지만 문서에 대한 기사를 본 사람은 몇 명입니까? 문서가 중요하지 않은 것은 의심의 여지가 적습니까? 아니요,하지만 문서의 중요성을 아직 인식하지 못했기 때문입니다.
하지만 우리가 관찰하면 사실은 모든 문서가있는 프로젝트는 성숙도가 높습니다.
대부분의 회사는 소프트웨어 개발 프로세스에 제공하는 것만 큼 문서에 약간의 중요성을 부여하지 않습니다. 웹에서 검색하면 다양한 유형의 문서를 만드는 방법에 대한 다양한 템플릿을 찾을 수 있습니다. 그러나 실제로 조직이나 개인이 얼마나 많이 사용합니까?
사실은 주의 깊은 문서화는 조직의 시간, 노력 및 비용을 절약 할 수 있습니다.
모든 유형의 인증을 진행하면서 문서화에 스트레스가있는 이유는 개인과 조직에 클라이언트와 프로세스의 중요성을 보여주기 때문입니다. 제품이 아무리 좋아도 사용자에게 편한 문서를 만들 수 없다면 아무도 받아들이지 않을 것입니다.
제 경험입니다. 우리는 하나의 제품을 소유하고 있는데 약간 혼란스러운 기능이 있습니다.
작업을 시작했을 때 관리자에게 도움말 문서를 요청했고 '아니요, 문서가 없습니다'라는 답을 얻었습니다. 그런 다음 QA로서 누구도 방법을 이해할 수 없기 때문에 문제를 제기했습니다. 문서 나 교육없이 제품을 사용하십시오. 그리고 사용자가 만족하지 않으면 그 제품으로 어떻게 돈을 벌 수 있을까요?
'문서 부족은 수용에 문제가되고 있습니다.'– Wietse Venema
사용자 설명서에도 동일한 내용이 적용됩니다. Microsoft의 예를 들어, 그들은 적절한 문서로 모든 제품을 출시합니다. 심지어 Office 2007의 경우에도 우리는 그러한 문서를 가지고 있습니다. 이는 모든 사용자에게 매우 설명적이고 이해하기 쉽습니다. 그것이 모든 제품이 성공한 이유 중 하나입니다.
리눅스가 Windows보다 나은 점
소규모 회사에서는 '제안 또는 시작 단계에서 프로젝트가 거부된다'는 말을 항상 들었습니다. 이는 제안서 문서에 간결하고 표현적인 언어가 부족하고 조직의 능력을 보여주기 때문입니다.
중소기업이 양질의 프로젝트를 제공 할 수 없다는 것이 아니라 능력을 표현할 수 없다는 것입니다. (저는 또한 80 명의 직원으로 구성된 소규모 조직에서 일하고 있는데 이렇게 많이 들었습니다.)
저는 개인적으로 품질이이를 가능하게 할 수있는 유일한 부서라고 생각합니다. 우리는 이것에 대해 논쟁 할 수 있고 우리 조직에 성공적인 미래를 제공 할 수있는 유일한 부서입니다.
모든 토론을 품질 측면에서 몇 가지 요점으로 정리해 보겠습니다.
– 품질 목표 및 방법 명시
– 작업에 대한 명확성과 성능의 일관성 보장
– 클라이언트 작업에서 내부 조정 보장
– 예방 조치에 대한 피드백 제공
– 계획주기에 대한 피드백 제공
– 품질 관리 시스템의 성능에 대한 객관적인 증거 생성
테스트 문서화 목표를 달성하는 데 도움이되는 10 가지 팁
이전 게시물에서 언급했듯이 일반적으로 소프트웨어 테스트 문서에 대한 이해는 '자유 시간이있는 사람 만 수행 할 수 있습니다'입니다. 우리는이 사고 방식을 바꿔야합니다. 그러면 우리는 프로젝트에서 문서화 능력을 활용할 수 있습니다.
문서화를 올바르게 수행하는 방법을 모른다는 것이 아닙니다. 우리는 그것이 중요하다고 생각하지 않습니다.
모든 사람은 테스트 전략, 테스트 계획, 테스트 사례 및 테스트 데이터에서 버그 보고서에 이르기까지 모든 종류의 문서에 대한 표준 템플릿을 가지고 있어야합니다.
이것들은 단지 몇 가지 표준 (CMMI, ISO 등)을 따르기위한 것이지만 실제 구현과 관련하여 우리가 실제로 얼마나 많은 문서를 사용합니까? 품질 프로세스를 문서 표준 및 조직의 다른 프로세스와 동기화하면됩니다.
모든 종류의 문서를 따르는 가장 간단한 방법 프로젝트 역학, 영역, 목표 및 기술을 이해하는 시작 단계의 사람을 프로젝트에 참여시키는 것입니다. 그리고 이것에 대해 QA 사람보다 더 나은 사람 (물론이 작업을 수행하는 기술 작성자가 있지만 기술 작성자가없는 소규모 회사의 일반적인 시나리오를 고려).
테스트 및 문서화라는 목표를 달성하려면 몇 가지 사항에 집중해야합니다.
다음은 테스트 문서화 목표를 달성하는 데 도움이되는 10 가지 팁입니다.
#1) QA는 QA와 문서화가 함께 작동하도록 프로젝트의 첫 단계에 포함되어야합니다.
#두) QA에서 정의한 프로세스는 기술 인력이 따라야하며, 이는 초기 단계에서 대부분의 결함을 제거하는 데 도움이됩니다.
#삼) 생성 및 유지 소프트웨어 테스팅 템플릿 충분하지 않다면 사람들이 사용하도록 강요합니다.
# 4) 문서를 만들고 그대로 두지 말고 필요할 때마다 업데이트하십시오.
# 5) 변경 요구 사항은 프로젝트의 중요한 단계입니다. 목록에 추가하는 것을 잊지 마십시오.
# 6) 모든 것에 버전 제어를 사용하십시오. 이렇게하면 문서를 쉽게 관리하고 추적 할 수 있습니다.
# 7) 모든 결함을 문서화하여 결함 수정 프로세스를 더 쉽게 만듭니다. 결함을 문서화하는 동안 결함에 대한 명확한 설명, 재현 단계, 영향을받는 영역 및 작성자에 대한 세부 정보를 포함해야합니다.
# 8) 작업을 이해하는 데 필요한 것이 무엇인지, 그리고 필요할 때마다 이해 관계자들에게 무엇을 생산해야하는지 문서화하십시오.
# 9) 문서화에는 표준 템플릿을 사용하십시오. 모든 엑셀 시트 템플릿 또는 문서 파일 템플릿과 마찬가지로 모든 문서 요구 사항에 충실하십시오.
# 10) 모든 프로젝트 관련 문서를 단일 위치에서 공유하고 모든 팀원이 참조 용으로 액세스하고 필요할 때마다 업데이트 할 수 있습니다.
단계를 적용하면 갑작스런 결과가 나온다는 말이 아닙니다. 이 변화가 하루나 이틀 안에 일어나지 않을 것임을 알고 있지만, 최소한 이러한 변화가 천천히 일어나도록 시작할 수 있습니다.
결국 '문서에는 문서가 필요합니다'. 그렇지 않습니까?
소프트웨어 개발 및 테스트 수명주기에 사용되는 수백 개의 문서가 있습니다.
중요한 소프트웨어 테스트 문서
다음은 정기적으로 사용 / 유지해야하는 몇 가지 중요한 소프트웨어 테스트 문서입니다.
1) 테스트 계획
2) 테스트 설계 및 테스트 케이스 사양
3) 테스트 전략
4) 테스트 요약 보고서
5) 주간 상태 보고서
6) 사용자 문서 / 매뉴얼
7) 사용자 수락 보고서
8) 위험 평가
9) 테스트 로그
10) 버그 리포트
열한) 테스트 데이터
12) 테스트 분석
또한 소프트웨어 테스터는 정기적으로 다음 문서를 참조해야합니다.
1) 소프트웨어 요구 사항 사양
2) 기능 문서
결론
소프트웨어 테스팅 문서는 항상 프로젝트 개발 / 테스트 단계에서 중요한 역할을합니다. 따라서 가능한 한 항상 문서화하십시오. 구두 의사 소통에 의존하지 마십시오. 항상 안전한 편에 서십시오.
문서화는 귀하를 구할뿐만 아니라 장기적으로 교육에 수천 달러를 절약하고 개발 및 테스트 문서 부족으로 인해 발생하는 문제를 해결하는 데 더 중요한 역할을합니다.
손가락으로 가리 키지 않기 위해 문서화하지 마십시오.하지만 문서화 습관은 테스트 프로세스에 체계적인 접근 방식을 가져 와서 임시 테스트를 뒤처지게 할 것입니다.
저자 정보 : 이 기사는 STH 팀원이 작성했습니다. 테자스 위니. 그녀는 조직에서 QA 관리자로 일하고 있습니다.
일상적인 테스트 활동에서 유지 관리하는 다른 문서는 무엇입니까?
추천 도서
- 소프트웨어 테스트 주간 상태 보고서 작성 방법
- 최고의 소프트웨어 테스트 도구 2021 (QA 테스트 자동화 도구)
- 소프트웨어 테스팅 QA 어시스턴트 작업
- 소프트웨어 테스팅 과정 : 어떤 소프트웨어 테스팅 기관에 가입해야합니까?
- 경력으로 소프트웨어 테스트 선택
- 소프트웨어 테스팅 기술 콘텐츠 작성자 프리랜서 작업
- SoftwareTestingHelp의 최고의 QA 소프트웨어 테스트 서비스
- 소프트웨어 테스트 유형 : 세부 정보가있는 다양한 테스트 유형