QA가 엄격하게 블랙 박스 관점에서 테스트해야합니까?
https://stackoverflow.com/questions/164170
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
단위 테스트가 개발에 의해 처리된다고 가정하면 QA가 제품의 작동 방식에 대한 세부 사항에 대한 지식을 갖는 이유가 있습니까? 이것은 배경에서 무슨 일이 일어나고 있는지 알아야하고 일반 UI를 사용하지 않고 제품 세그먼트를 테스트해야합니까? 예를 들어, 테스터가 데이터베이스에 들어가서 값을 수동으로 변경하여 어떤 일이 일어날 지 확인하는 것이 합리적입니까?
편집하다:
비 개발자가 사용할 응용 프로그램으로 작업하고 있다고 가정 해 봅시다. 우리는 API가 첨부 된 작업을 수행하지 않는다고 가정 해 봅시다.
해결책
그것은 당신이 작성하는 접근 방식과 소프트웨어의 종류에 따라 다릅니다. QA에는 다른 종류가 있습니다. 소프트웨어가 결함에 관찰되어야하는 경우 QA는 결함을 시뮬레이션해야합니다. 또한 제품의 작동 방식을 아는 것은 QA가 잠재적으로 문제가있는 경우를 생각하고 더 철저하게 테스트하는 데 도움이 될 수 있습니다.
반면에, 제품의 작동 방식을 아는 것은 QA가 사용자의 관점에서 완전히 테스트하는 것을 방해 할 수 있습니다. 따라서 먼저 기본 테스트는 내부를 알지 못하고 잠재적 인 문제를 기반으로 더 심층 테스트를 설계해야합니다.
다른 팁
확실히 그것은 아키텍처에 달려 있습니다. DB 계층이 다른 건물의 완전히 별도의 팀이 개발, 관리 및 테스트 한 프로젝트에서 작업했습니다. 그들의 QA는 절차, 쿼리 등이 다양한 테스트 조건에서 실행되는지 확인하기 위해 데이터를 사용하여 분명히 주위에 휩싸였습니다.
UI 끝에있는 경우 두 가지 레벨이 있습니다. 하나는 QA가 응용 프로그램에 대한 실무 지식이 필요하지 않은 간단한 기능 테스트입니다 (및 모든 것이 자동화되어야 함). 해야 할 일을합니다. 두 번째 종류의 경우 QA 팀이 작동 방식을 알고 있다면 실제로 도움이됩니다. 시작을 위해 바보 같은 버그를 거부하는 데 많은 시간이 절약되지만, 더 중요한 것은 사용자처럼 행동해야하며 더 복잡한 오버레이 시나리오를 시도하는 최종 최종 사용 사례가 있어야합니다. 그러한 테스트를 설계하려면 응용 프로그램에 대한 좋은 지식이 있어야합니다.
테스터가 소프트웨어 구현에 대해 가능한 한 많이 아는 것은 절대적으로 의미가 있습니다. 그것은 그들이 더 잘 테스트하는 데 도움이 될 것입니다.
블랙 박스 테스트는 유용하고 필요한 기술이지만 후드 아래에서 일어나는 일에 대해 조금 알면 정말 흥미로운 테스트 사례를 더 쉽게 정의 할 수 있습니다.
모든 화이트 박스 테스트 요구에 대한 개발자의 단위 테스트에 의존하는 문제는 개발자가 특히 작성한 코드와 관련하여 개발자가 철저한 테스터가 아니라는 것입니다.
내가 참여한 프로젝트에서 QA는 사용자의 관점에서 테스트했으며 테스트는 회의 요구 사항의 관점에서 나왔습니다. 그들의 테스트는 블랙 박스 테스트였습니다. 흰색 상자 테스트는 Devs에 의해 수행되었습니다. QA 담당자가 DB 쿼리 도구를 열고 수동으로 값을 변경할 것으로 기대하지 않았습니다. 이것은 Dev의 단위 테스트의 책임이었습니다.
QA 팀이 주어진 프로젝트에서 수행하는 역할에 달려 있다고 생각합니다. 데이터베이스에 존재하는 특정 값에서 발생하는 상황은 테스트 사례로 표시되어야하며, 그러한 방식으로 표현할 수 있다면 개발자는 해당 상황에 대한 단위 테스트를 작성해야한다고 주장 할 수 있다고 생각합니다. .
또한 코드 검사를 사용하여 결함을 식별하고 수정하는 경우 QA를 무대 뒤에서 무엇이든 노출시킬 필요가 없을 수도 있습니다. 사용자 경험 이외의 코드를 테스트하는 데 도움이 될 수있는 프로젝트가 있다고 생각하지만 아마도 화이트 또는 클리어 박스 테스트보다는 검은 색 테스트를 위해 QA 팀을 사용할 것입니다.
하이브리드 접근 방식이 잘 작동한다고 생각합니다. 화이트 박스 테스트 (단위 테스트)와 블랙 박스 테스트의 조합을 사용하는 경우 더 나은 범위가 나옵니다. 각각은 장단점을 가지고 있지만 다른쪽에는 부분적으로 약점을 다룹니다.
코드의 내부 작업을 이해하면 특정 방식으로 테스트를 수행하게됩니다. 이는 항상 특정 문제를 발견하는 가장 좋은 방법은 아닙니다.
나는 QA 사람이 ~ 아니다 응용 프로그램의 작동 방식에 대한 내부 지식이 있습니다. QA 직원은 대상 고객과 거의 같은 수준의 컴퓨터 역량을 가져야합니다.
그 이유는 간단합니다. QA 사람이 응용 프로그램이 어떻게 구축되는지에 대해 알수록 일반 사용자가 실행할 정상적인 유용성 문제를 피할 가능성이 높아집니다.
QA는 응용 프로그램이 작동하는지 테스트하는 것이 아닙니다. 또한 평균 사용자가 이해할 수 있는지 여부를 테스트하고 실제로 사용할 수 있는지 테스트해야합니다.
업데이트
이것은 댓글 상자에 맞지 않기에는 너무 길어졌습니다.
@testerab의 질문에 관해.
QA를 1. 비즈니스 요구 사항을 충족시킬 책임이있는 사람 또는 그룹으로 정의합니다. 그리고 2. 해당 요구 사항과 관련하여 응용 프로그램의 기능은 오류가 없습니다. 따라서 모니 커 "품질 보증". 내가 믿는 세 번째 항목은 QA에 속한다고 단순히 유용성입니다.
비즈니스 요구 사항을 이해해야합니다. 즉, 비즈니스 분석가 및 최종 사용자 (사용 가능한 경우)와 함께 일해야합니다. 내가 함께 일한 최고의 QA 회원은 그 영역에서 고용되었습니다. 내가 본 최악의 QA 회원은 개발자 였거나 그와 같은 훈련을 받았습니다. 기술 지원에서 이사 한 사람들은 또한 최종 사용자가 시도 할 쓰레기의 유형을 정확히 알고 있기 때문에 좋은 QA 회원을 만드는 경향이 있습니다.
다양한 클래스의 응용 프로그램이 있습니다. 가장 일반적인 것은 영광스러운 데이터 입력입니다. 정보를 입력하고 버튼을 누르는 일부 화면이 있습니다. 그런 다음 정보가 저장 및/또는 가야 할 때마다 저장 및/또는 라우팅됩니다. MS Word에서 CRM에 이르기까지 모든 것이이 범주에 속합니다.
따라서 QA 사람의 작업은 먼저 앱이 원하는 입력을 수락하고 원하는 기능을 수행하는지 확인하는 것입니다. 보조 단계는 잘못된 입력을 제출하고 앱이 원하는 방식으로 응답을 확인하는 것입니다. 예를 들어 폭발하거나 나쁜 정보를 통과하지 못합니다. 자동화 된 테스트 도구는 이러한 경우에 효과적입니다. 마지막 부분은 해당 기능이 세 가지 메뉴 레벨을 깊게 묻어야하는지 또는 더 쉽게 얻을 수 있어야하는지 결정하는 것입니다.
위의 어느 것도 QA 담당자가 비트와 함께 코드 또는 Twiddle을 읽도록 요구하지 않습니다.
일부 시스템에는 UI 구성 요소가 없습니다. 이를 위해 QA 팀이 데이터를 제출하고 결과를 검토 할 수있는 테스트 하네스를 제공하는 것은 개발자에게 달려 있습니다. 여기에는 웹 서비스와 상상할 수있는 모든 유형의 EDI가 포함됩니다.
다른 시스템은 API 자체입니다. 이들은 API 호출을 구현하거나 개발자가 쉽게 전화를 걸고 결과를 기록 할 수있는 방법을 제공하기 위해 충분히 지식이있는 QA 사람이 필요합니다. 이 경우 QA 팀은 자체 프로그래밍을 수행 할 수 있지만 다시 기본 코드에 액세스 할 수 없습니다.
실제 코드를 검토하는 데있어 문제는 사람이 자신이보고있는 것에 집중하는 경향이 있다는 것입니다. 이것은 나쁘다. 대신 그들은 인공적인 한계가 정신적으로 없어야하므로 숫자 항목을 기대하는 텍스트 상자에 "ABC"를 맹목적으로 입력 할 수 있습니다.
테스트 할 내용을 알기 위해 코드를 "보고"하는 한, 이것은 완전히 다른 문제이며 코드 검토 설정에서 숙련 된 개발자가 더 잘 해결하는 문제입니다. 여기서 목적은 가능한 오류, 모범 사례, 보안 장애 등을 식별하는 것입니다. QA 사람들은 누군가가 활발한 개발자가 필요하기 때문에 이러한 수준의 분석을 거의 할 수 없습니다.
SDET과 관련하여 : 귀하의 제품에 다른 물건을 구축하는 데 DEV가 사용하는 API 또는 기초가있는 경우 일반 QA 그룹을 지원하기 위해 주변의 소프트웨어를 구현하는 데 전념하는 한 명 이상의 사람들을 원할 수 있습니다. 나는이 역할의 필요성에 관해 울타리에 있으며 그것이 프로젝트 결정에 의해 프로젝트 일 수 있다고 믿는다.
API를 테스트 할 수있는 자격이있는 두 그룹이 있다고 생각합니다. 이들은 이미 구현중인 최종 사용자 및 회사를 구축 한 회사의 다른 개발자입니다. 개밥은 이제 일반적인 관행이며 매우 비용 효율적입니다. 결국, 작동하지 않으면 빠르게 고정 될 수 있습니다. 최종 사용자의 경우, Dev 팀이 반응하는 실제 대화로 보는 한, 그들은 당신을 위해 그것을 행복하게 "테스트"할 것입니다.
나는 세 가지 상황 모두에 있었고 최종 사용자로서 원래 개발자에 액세스하는 것은 문제를 해결하는 데 큰 도움이된다고 생각합니다. 특히 제품을 사용하는 경우. 이러한 프로젝트와 일반적으로 관련된 QA 사람들에 대한 오해의 양은 끔찍합니다.
요약하면, 나는 모든 종류의 QA 사람들과 함께 일했습니다. 그들이 어떻게 일할 수 있었는지 궁금한 사람들로부터 앱을 질식시키는 코너 케이스를 찾는 데 능숙한 슈퍼 스타로 일할 수있는 방법을 궁금해했습니다.
최고의 특성은 다음과 같습니다. 1. 결코 프로그래머가 아니 었습니다. 2. 사업을 이해했다. 3. 최종 사용자가 매일 무엇을했는지 정확하게 이해했습니다. 4. 정직하게 소프트웨어를받는 사람들에 대해 신경을 썼습니다.
최악의 특성의 특성은 다음과 같습니다. 1. 프로그래머 였거나 생각했다. 2. 사업을 이해하지 못했습니다. 3. 최종 사용자를 만난 적이 없습니다. 4. "바보"라는 단어를 너무 자주 사용했습니다. 5. 그것이 사용 가능한지 대신 어떻게 작동했는지에 대한 역학을 따라 잡았습니다.
