테스트의 근본적인 문제

소개

안녕하세요, 하브로프스크 주민 여러분. 방금 저는 핀테크 회사의 QA 리드 공석에 대한 테스트 과제를 해결하고 있었습니다. 전기 주전자 테스트를 위한 전체 체크리스트와 테스트 케이스 예시가 포함된 테스트 계획을 작성하는 첫 번째 작업은 간단하게 해결할 수 있습니다.

• GOST 7400-81. 가정용 전기 주전자 및 전기 사모바르. 사양(개정 번호 1-8 포함)
• GOST IEC 60335-1-2015 가정용 및 유사한 전기 제품. 안전. 1부. 일반 요구사항
  완전한 체크리스트를 갖춘 더 나은 테스트 계획을 생각하는 것은 어렵습니다.

그러나 두 번째 부분은 "모든 테스터가 더 효율적으로 작업하는 것을 방해하는 공통적인 문제가 있습니까?"라는 질문으로 밝혀졌습니다.

가장 먼저 떠오른 것은 테스트 중에 직면했던 다소 눈에 띄는 문제를 모두 나열하고, 작은 것들을 제거하고, 나머지를 요약하는 것이었습니다. 그러나 나는 귀납적 방법이 "모든 사람"에게 적용되는 것이 아니라 기껏해야 "대부분"의 테스터에게만 적용되는 질문에 답할 수 있다는 것을 빨리 깨달았습니다. 그러므로 나는 다른 측면에서 연역적으로 접근하기로 결정했고 이것이 일어났습니다.

정의

새로운 문제를 해결할 때 제가 보통 가장 먼저 하는 일은 그것이 무엇인지 이해하려고 노력하는 것입니다. 그러기 위해서는 문제를 제기하는 단어의 의미를 이해해야 합니다. 이해해야 할 핵심 단어는 다음과 같습니다.

• 문제
• 시험 장치
• 테스터 작업
• 테스터 효율성

Wikipedia와 상식을 살펴 보겠습니다.
문제 (고대 그리스어 πρόβλmetμα) 넓은 의미에서 - 연구와 해결이 필요한 복잡한 이론적 또는 실제 문제입니다. 과학에서 - 현상, 대상, 과정을 설명할 때 반대 입장의 형태로 나타나고 이를 해결하기 위해 적절한 이론이 필요한 모순된 상황입니다. 인생에서 문제는 사람들이 이해할 수 있는 형태로 공식화됩니다. "무엇을 알아요, 어떻게 해야 하는지 모르겠어요", 즉 무엇을 얻어야 하는지는 알지만 어떻게 해야 하는지는 알 수 없습니다. . 늦게부터 옵니다. 위도 문제는 그리스어에서 나온 것입니다. πρόβλnμα "앞으로 던져진, 앞에 놓인"; προβάλλΩ에서 “앞으로 던지고, 당신 앞에 놓으세요. 탓하다".

사실 "문제" = "처리해야 할 모든 것"은 별 의미가 없습니다.
시험 장치 - 구성 요소 또는 시스템 테스트에 참여하는 전문가(모든 테스터에 관심이 있으므로 유형을 구분하지 않음), 그 결과는 다음과 같습니다.
테스터의 작업 — 테스트와 관련된 일련의 활동.
능률 (lat. effectivus) - 달성된 결과와 사용된 자원 간의 관계(ISO 9000: 2015).
결과 - 질적 또는 양적으로 표현되는 일련의 행동(결과) 또는 사건의 결과입니다. 가능한 결과에는 이점, 불이익, 이득, 손실, 가치 및 승리가 포함됩니다.
"문제"와 마찬가지로 의미는 거의 없습니다. 작업의 결과로 나온 것입니다.
자원 - 개인 또는 사람들의 활동을 수행할 수 있는 정량적으로 측정 가능한 가능성 원하는 결과를 얻기 위해 특정 변환을 사용할 수 있는 조건입니다. 테스터는 사람이며 필수 자원 이론에 따라 각 사람은 네 가지 경제적 자산의 소유자입니다.
현금(소득)은 재생 가능한 자원입니다.
에너지(생명력)는 부분적으로 재생 가능한 자원입니다.
시간은 고정되어 있고 근본적으로 재생 불가능한 자원입니다.
지식(정보)은 재생 가능한 자원이며 성장하고 파괴될 수 있는 인적 자본의 일부입니다.[1].

우리의 경우 효율성의 정의가 완전히 정확하지는 않다는 점에 주목하고 싶습니다. 더 많은 지식을 사용할수록 효율성이 낮아지기 때문입니다. 그러므로 나는 효율성을 “달성된 결과와 소비된 자원의 비율”로 재정의하고 싶습니다. 그렇다면 모든 것이 정확합니다. 작업 중에 지식이 낭비되지 않지만 테스터의 근본적으로 재생 불가능한 유일한 자원인 시간의 비용이 줄어듭니다.

결정

그래서 우리는 작업의 효율성을 저해하는 테스터의 글로벌 문제를 찾고 있습니다.
테스터의 작업에 소비되는 가장 중요한 자원은 그의 시간이며 (나머지는 어떤 식 으로든 줄일 수 있음) 올바른 효율성 계산에 대해 이야기하려면 결과도 시간으로 줄여야합니다 .
이를 위해 테스터가 작업을 통해 실행 가능성을 보장하는 시스템을 고려하십시오. 이러한 시스템은 팀에 테스터가 포함된 프로젝트입니다. 프로젝트 수명주기는 대략 다음 알고리즘으로 나타낼 수 있습니다.

1. 요구사항 작업
2. 기술 사양의 형성
3. Разработка
4. 테스트
5. 프로덕션으로 출시
6. 지원(항목 1로 이동)

이 경우 전체 프로젝트는 동일한 수명 주기를 갖는 하위 프로젝트(기능)로 반복적으로 나눌 수 있습니다.
프로젝트의 관점에서 볼 때 소요되는 시간이 적을수록 구현이 더 효과적입니다.
따라서 우리는 프로젝트의 관점에서 테스터의 가능한 최대 효율성을 정의하게 되었습니다. 이는 테스트 시간이 0일 때의 프로젝트 상태입니다. 모든 테스터의 공통적인 문제는 이 시간을 달성할 수 없다는 것입니다.

이 문제를 어떻게 처리할까요?

결론은 매우 분명하며 오랫동안 많은 사람들이 사용해 왔습니다.

1. 개발과 테스트는 거의 동시에 시작하고 끝나야 합니다(이 작업은 일반적으로 부서에서 수행함). QA). 이상적인 옵션은 개발 중인 모든 기능이 준비될 때 이미 자동 테스트로 처리되고 일종의 일종의 도구를 사용하여 회귀(및 가능한 경우 사전 커밋) 테스트로 구성되는 것입니다. CI.
2. 프로젝트에 기능이 많을수록(더 복잡할수록) 새 기능이 기존 기능을 손상시키지 않는지 확인하는 데 더 많은 시간이 소요됩니다. 따라서 프로젝트가 복잡할수록 더 많은 자동화가 필요합니다. 회귀 테스트.
3. 프로덕션에서 버그를 놓치고 사용자가 이를 발견할 때마다 우리는 지점 1(요구 사항 작업, 이 경우 사용자)부터 시작하여 프로젝트 수명 주기를 진행하는 데 추가 시간을 소비해야 합니다. 버그가 누락된 이유는 일반적으로 알 수 없으므로 최적화 경로는 하나만 남습니다. 사용자가 발견한 모든 버그는 회귀 테스트에 포함되어 해당 버그가 다시 나타나지 않도록 해야 합니다.

출처 : habr.com