클라이언트는 소프트웨어 테스터에게 실제로 무엇을 기대합니까?

what do clients really expect from software testers

오늘의 기사에서는 고객 위치에서 일상적인 대면 상호 작용을 통해 일한 경험을 바탕으로 고객이 실제로 우리에게 기대하는 바에 대해 몇 가지 생각을 공유하겠습니다. 해외 협력 이메일이나 전화를 통해.

IT 서비스는 소프트웨어 산업에서 중요하고 필수적인 부분이며 성공하기 위해서는 고객 만족이 중요합니다. 각 클라이언트 / 조직은 프로세스가 다를 수 있으며 다른 프로토콜을 따를 수 있으며 다른 유형의 비즈니스를 처리 할 수 ​​있습니다.

그러나 다음 요소는 일반적으로 모든 사람에게 공통적이며 중요합니다.

(영상 src )

학습 내용 :

• 클라이언트가 소프트웨어 테스터에게 기대하는 5 가지 :
• # 1) 비용 이점
• # 2) 작업 품질
• # 3) 비즈니스 이해
• # 4) 가용성
• # 5) 개선 범위
• 결론
• 추천 도서

클라이언트가 소프트웨어 테스터에게 기대하는 5 가지 :

# 1) 비용 이점

무언가를 팔거나 사는 것을 생각할 때 비용은 중요한 역할을하며 종종 중요한 결정 요소 중 하나입니다. 우리 모두 블랙 프라이데이, Flipkart Billion Day 세일 또는 Amazon의 멋진 쇼핑 축제를 간절히 기다리지 않습니까? 우리는 판매 기간 동안 미친 구매자가됩니다. 우리 돈에 대한 권리 또는 추가 가치를 기대하는 것은 단순한 인간 행동입니다.

회사와 고객은 다르지 않습니다. 비용 이점은 고객-서비스 관계를 향상시키고 서비스 회사가 더 낮은 견적 경쟁자로 인해 입찰을 잃는 경우가 드물지 않습니다.

이제 가장 큰 질문은 고객에게 비용 이점을 어떻게 보여줄 수 있습니까?

다음 사항이 도움이 될 수 있습니다.

• 그들에게 돈의 가치를 보여줘 . 귀하의 근거를 정당화하고 제공하십시오. 견적 .
• 지출을 절약 할 수있는 창의적인 방법을 생각하십시오.
• 견적을 조정하십시오. X 금액의 비용이 드는 표준 프로세스를 고수하는 대신 더 저렴한 대안을 제공하십시오. 예를 들면 : 전체 시스템 테스트 대신 중요 경로 테스트를 제안합니다.
• 경쟁사 파악 . 가격 모델 시장의 관련성을 유지하는 데 중요한 비용으로 다른 서비스 회사가 고객에게 제공하는 내용에 대한 빠른 현실 확인.

# 2) 작업 품질

작업의 질과 양은 매우 다른 두 가지입니다.

생산성 또는 품질 지표에 사용 된 테스트 사례 또는보고 된 결함의 수는 지났습니다. 더 이상은 아닙니다.

상황은 아래 이미지와 더 비슷합니다.

A) '아니오'라고 말할 때를 아십시오.

우리는 모두 초과 근무, 주말에 통화 중이거나 늦은 밤 또는 이른 아침 통화에 참석하는 등의 장소에있었습니다. 그러나 상황이 계속 악화되면 아니오라고 말할 수 있다는 사실을 깨닫지 못합니다. 아니오라고 말하기 일의 질과 온전함을 그대로 유지할 수있는 유일한 방법입니다.

그렇게 할 때 미리 우려 사항을 제기하고 품질을 옹호하십시오.

다음은 제가 처한 상황이며 이것이 제가 말하는 것에 대한 더 나은 아이디어를 제공 할 수 있습니다.

내 회사는 새 로고를 받았으며 이전 회사에서 내 회사로 마이그레이션하는 과정에서 지식 이전 세션이 계획되었습니다. 우리 6 명으로 구성된 팀이 클라이언트 사이트를 방문했습니다. 소개 후 첫날 KT 계획을 공유했습니다. 내 이름이 여러 모듈에 대해 태그가 지정된 것을 발견했습니다. 그 기술을 몰랐기 때문에 그 모듈 중 하나는 완전히 제 범위를 벗어 났어 야했습니다. 내 실력에 맞지 않습니다.

저는 지식 전환 책임자에게 가서 상황을 말했습니다.

• 너무 많은 작업 항목이 나에게 할당되어 세션에서 100 %를 캡처 할 수있는 능력과 품질이 저하됩니다.
• 계획된 항목에는 내 기술이 맞지 않는 영역이 있었고 내가 적합하지 않았기 때문에 전환하는 동안 100 % 이해하지 못할 수도 있습니다.

리드 문제를 이해하고 KT 계획을 수정했습니다.

Visual Studio Team Foundation Server 2015 자습서

이 정보가 다음 사항을 확인하는 데 도움이되기를 바랍니다. 접시에 무언가가 있다고해서 다 먹어야한다는 의미는 아닙니다. 특히 품질 저하를 의미하지 않습니다.

B) 테스트 케이스 완전성

여러분 중 얼마나 많은 분들이 우리가 테스트 케이스 작성 방식 개선 , 더 나은 품질로 연결됩니까?

다음은 대부분의 테스트 사례에서 흔히 발생하는 몇 가지 일반적인 실수입니다.

요약하면 설계 단계에서 작은 세부 사항을 고려하면 테스트 출력 품질이 훨씬 더 우수합니다.

# 3) 비즈니스 이해

이것은 고객이 테스터에서 찾는 가장 중요한 요소 중 하나입니다. 그러나 일부 테스터는 FRS를 기반으로 테스트 케이스를 작성하고 비즈니스를 이해하려고 노력하지 않는 것이 자신의 임무라고 믿고 있습니다.

먼저 비즈니스를 파악한 다음 기능을 살펴보십시오. 당신은 할 수 있습니다 고객의 요구 사항을 구상 그에 따라 더 많이 테스트하십시오.

여기에 예가 있습니다.– FRS는 'XYZ 보고서는 날짜, 이름 및 상태의 3 개 열로 생성되어야 함'이라고 명시합니다. 다음은이 요구 사항을 액면 그대로 받아 들일 때 끝낼 테스트 사례입니다.

• XYZ 보고서가 생성되었는지 확인
• 유효성 검사 보고서에는 날짜, 이름, 상태로 3 개의 열이 있습니다.
• 3 개 열의 데이터를 검증합니다.

그러나이 보고서의 비즈니스 적용 가능성을 염두에두고 다음을 테스트해야 할 수 있습니다.

• 이 보고서의 사업 목적은 무엇입니까?
• 이 보고서는 매일 생성됩니까?
• 이 보고서를보고있는 비즈니스 사용자는 누구입니까?
• 이 보고서의 데이터 소스는 무엇입니까?
• 사용 가능한 데이터가없는 경우 보고서를 생성해야합니까?

이것은 하나의 예일 뿐이지 만 비즈니스 인식과 전문성을 확보함으로써 더 나은 테스트를 달성 할 수 있다는 데 우리 모두 동의한다고 생각합니다.

# 4) 가용성

고객을 지원하는 개인이든 팀이든 항상 가용성을 확인해야합니다 ( ).

가용성이 24/7 지원을 의미하지는 않습니다. 휴가, 대체 계획 및 도달 가능하고 MIA에 가지 않는 것에 대한 명확하고 직접적인 의사 소통을 의미합니다.

다음은 서비스 산업이 따르는 몇 가지 모델입니다.

• 직원 확대 모델 – 직원 증강 모델에서 일하고 있고 회사의 유일한 대표자 인 경우 필요한 준비를 할 수 있도록 고객에게 근무 시간과 계획된 부재를 알리는 것이 좋습니다.
• 관리되는 프로젝트 모델 – 대규모 프로젝트 팀이 구성되고 제공 / 프로젝트 관리자가 이끄는 관리 프로젝트 모델에서 백업 리소스 계획을 갖는 것은 더 이상 고객의 책임이 아닙니다. PM의 관리 필요성 계획된 휴가와 계획되지 않은 휴가 모두. 이 모델에서는 PM이 팀에서 계획된 부재 데이터를 미리 수집하고 그에 따라 관리하는 것이 좋습니다. 고객이 주말 지원이나 연장 근무를 요청하는 경우가 있습니다. 이러한 경우는 자원 순환을 통해 계획해야합니다. 팀은 필요한 경우 서로 백업 할 수있는 구성원으로 구성되어야합니다. 계획된 세부 사항은 고객과 공유해야합니다.

# 5) 개선 범위

이것은 소프트웨어 산업뿐만 아니라 모든 곳에서 바람직합니다. 개선을 가져 오는 것은 하루 일이 아닙니다. 개선 범위는 지속적으로 작업해야하며 다음과 같이 나눌 수 있습니다. 3 단계 –

또한 읽으십시오=> 테스트 기술을 향상시키고 경쟁에서이기는 방법

1 단계 : 식별

철저한 연구를 수행하고 개선 할 영역 / 범위를 식별합니다. 동일한 프로세스를 사용하여 동일한 기능을 여러 번 테스트하라는 요청을 받으면 프로젝트에서 벗어나고 싶거나 테스트 방식을 변경하고 싶다고 느낄 때가 올 것입니다. 그것이 우리가 기존 방법에 지루할 때 개선을 가져 오는 방법입니다. 우리는 변화와 개선을 생각합니다 .

2 단계: 개선 사항 가져 오기

수동으로 작업을 수행했다면 몇 가지를 자동화하려고 . 자동화라고 할 때 항상 자동화 된 도구를 구입하는 것은 아닙니다.

상황을 인용하겠습니다.

저는 데이터베이스 테스트 팀의 일원이었습니다. 우리의 일상적인 작업은 다른 매개 변수 세트를 사용하여 동일한 SQL 스크립트를 하루에 여러 번 실행하는 것이 었습니다. 프로젝트를 시작했을 때 우리는 이러한 단계에 문제가 없었지만 결국 시스템을 더 잘 이해했고 누군가가 수동으로 매개 변수를 업데이트하고 실행하는 대신 저장 프로 시저의 일부로 동일한 SQL 스크립트를 실행할 수 있다고 생각했습니다.

3 단계 : 개선 사항 평가

새 프로세스가 구현 될 때마다 예상대로 작동하고 부작용이 없는지 확인해야합니다. 이전 예제 인 저장 프로 시저 소개를 확장하여 새로 생성 된 자동화 방식의 출력과 수동 방식의 출력이 동일한 지 확인합니다.

다른 부분은 일정 기간 동안의 이점을 모니터링하여 절대적으로 확신하고 결과를 고객에게 제공하는 것입니다. 프로젝트에서 우리는 고객에게 테스트 실행 시간이 30 % 단축되어 비용이 절감되었음을 보여주었습니다.

결론

결론적으로, 저는 우리 각자가 타고난 재능을 가지고 있고 우리 모두는 고유 한 작업 스타일을 가지고 있으며 이것은 고객에게 더 나은 서비스 경험을 제공 할 수있는 몇 가지 팁에 불과하다는 것을 언급하고 싶었습니다.

저자 정보 : 이 멋진 기사는 STH 팀원 Priya R이 작성했습니다. 우리를 위해 글을 쓰고 경험을 공유하고 싶다면 여기에 알려주세요 .

C ++ 코딩 인터뷰 질문

이 기사를 읽고 유익한 정보를 얻으 셨기를 바랍니다. 공유 할 다른 경험이 있으면 알려주세요.

추천 도서

• 최고의 소프트웨어 테스트 도구 2021 (QA 테스트 자동화 도구)
• 글로벌 소프트웨어 테스팅 사업, 곧 288 억 달러에 도달
• 초보자 테스터를위한 소프트웨어 테스트 조언
• 소프트웨어 테스팅 QA 어시스턴트 작업
• 소프트웨어 테스터에서 동기 부여를 유지하는 방법은 무엇입니까?
• Zen과 소프트웨어 테스팅의 기술
• 소프트웨어 테스팅 과정 : 어떤 소프트웨어 테스팅 기관에 가입해야합니까?
• 경력으로 소프트웨어 테스트 선택