QA 엔지니어로 일할 때 알았으면 하는 6가지

고객의 손에 들어오기 전에 시장에 나와 있는 모든 제품은 테스트 를 거쳐 프로세스 중에 파손되지 않고 제대로 작동하는지 확인합니다. 개발 회사의 "생산 라인"에서 최종 제품의 우수성을 담당하는 사람은 품질 보증 엔지니어입니다.

QA라고도 하는 품질 보증 엔지니어 는 최종 제품에 문제가 없고 모든 것이 원활하게 작동하는지 확인합니다. 이를 위해 생산의 모든 단계에서 지속적인 수동 및 자동 테스트를 수행합니다.

그러나 QA는 단순히 소프트웨어 테스터나 분석가가 아닙니다. 제품의 최고 성능을 보장하려면 고객의 비즈니스, 아이디어 이면의 논리 및 제품 목표에 대한 명확한 그림이 있어야 합니다. 그들은 최종 사용자의 프로필에 대해 생각해야 할 뿐만 아니라 개발 주기의 단계와 프로세스에 대한 깊이 있는 지식을 가지고 있어야 합니다.

그리고 그것은 당신이 졸업장을 받을 수 있는 것이 아닙니다. QA로 시작하기 위해 특정 배경이나 교육이 필요하지 않을 수도 있지만 특정 기술 세트는 확실히 도움이 될 것입니다. 당신이 융통성 있고 다재다능하고, 세부 사항에 주의를 기울이고 틀에서 벗어나 생각한다면, 당신이 팀 플레이어이고 항상 배우고 향상할 준비가 되어 있다면 이것이 당신에게도 올바른 경력 경로일 것입니다.

그래서 제가 어떻게 품질 보증 엔지니어가 되었는지 이야기를 해 보겠습니다.

원천

이 모든 것은 2014년 여름에 시작되었으며 인생의 대부분의 좋은 일들과 마찬가지로 순전히 우연의 일치였습니다. 그 당시 나는 바텐더로 일하고 있었고 핵화학 석사 학위를 막 졸업했습니다. (네, 그때 제가 어떤 "폭발적인 칵테일"을 흔들고 있었는지 상상할 수 있습니다.)

어느 화창한 날, DevriX의 CEO Mario Peshev가 나에게 회사의 프로젝트 테스트를 도와달라고 요청했습니다. 조용히 앉아서 마우스를 클릭하고 여기저기에 값을 추가하고 소프트웨어가 작동하는지 확인하는 것은 쉬운 일입니다. 그때 내가 얼마나 순진했는지.

어쨌든 저는 테스터라는 직책을 수락하고 지난 6년 동안 QA 전문가로 일하고 있습니다. 상상할 수 있듯이 소프트웨어 테스팅은 내가 기대한 것이 아니었습니다. 하루 종일 앉아서 마우스로 클릭하는 것이 아닙니다. 그 이상이며 때로는 우리가 실제로 하는 일을 말로 표현하기조차 어렵습니다.

이제 잠시 동안 주위에 있었고, 내가 QA로 시작할 때 알았더라면 좋았을 6가지 필수 사항이 있다는 것을 깨달았습니다. 같은 길을 가고 있다면 계속 읽으십시오. 내 실수에서 한두 가지를 배울 수 있습니다. 그렇지 않다면 너무 자만하지 마십시오. 스스로 실수할 시간이 충분합니다. 이것이 우리가 배우고 우리가하는 일에서 최고가되는 방법이기 때문입니다.

1. 쉬운 일이 아니다

원천

요즘 떠오르는 트렌드가 있는데, 눈에 띄지 않을 수 없습니다. 많은 사람들이 자신의 안전지대를 떠나 진로를 바꾸고 IT 분야로 뛰어들고 있습니다.

그리고 이들 중 많은 사람들이 QA 경력이 가장 쉬워 보이기 때문에 QA 경력을 시도하기로 선택합니다.

그 어떤 것도 진실에서 멀어질 수 없습니다. 실제로 성공적인 QA 엔지니어가 되려면 소프트웨어 개발자가 되는 데 동일한 시간과 노력을 투자해야 합니다. 배워야 할 필수 기술 기술 이 많이 있지만 더 중요한 것은 적시에 적절한 기술을 선택하는 능력을 숙달해야 한다는 것입니다. QA 엔지니어는 많은 역할을 결합하고 그들의 업무에는 전체 개발 주기와 비즈니스 목표에 대한 이해가 필요합니다. 버그를 찾고 이것이 작동하지 않는 것을 지적하는 것은 아닙니다.

성공적인 QA 엔지니어가 되려면 소프트웨어 개발자가 되는 것과 같은 시간과 노력을 투자해야 합니다.

성공적인 QA 엔지니어가 되려면 다음을 이해해야 합니다.

• 시간을 더 잘 관리하는 방법
• 귀하에게 할당된 요청을 처리하는 방법
• 작업의 우선 순위를 지정하는 방법

동시에 위의 모든 것은 프로젝트 관리자 역할의 일부입니다.

QA 는 테스트 또는 스테이징 서버 환경을 구축하거나 SysAdmin/DevOps 역할 의 일부인 손상된 서버를 배포하거나 수정할 수 있는 능력도 개발해야 합니다.

동시에 데이터 분석가 역할의 일부인 Google Analytics(GA) 또는 기타 데이터 에서 필요한 정보를 읽고 이해할 수 있어야 합니다.

그래서 QA-ing 은 능동적 이고 끊임없이 새로운 영역을 배우고 탐구하는 것을 요구합니다.

2. 코딩 언어를 알 필요는 없습니다(하지만 도움이 됩니다)

원천

서두에서 읽으신 것처럼 저는 QA 엔지니어가 되기 전에 바텐더였습니다.

내 코딩 기술과 모든 프로그래밍 언어에 대한 지식 기반은 0 이었습니다. 네, 모든 테스트는 블랙박스였습니다. 네, 많은 창의적 사고와 노력으로 이를 보완하고 제 일을 할 수 있었습니다.

그러나 프로젝트가 커지고 기능이 복잡해 지면서 테스트 시간이 두 배로 늘어났습니다. 그리고 위에서 언급한 "방법"은 비용 대비 효과가 없었고 스트레스를 많이 받았습니다.

그래서 현명한 결정은 PHP를 배우기 시작한 것입니다. 왜 PHP인가? DevriX는 Enterprise WordPress Agency이며, 아시다시피 WordPress는 PHP로 작성된 CMS입니다. 따라서 커밋에서 개발자의 논리를 확인하고 이해하려면 개발자의 언어(코드)를 이해해야 했습니다. 이 접근 방식은 테스트 시간을 크게 줄였습니다. 게다가 코드 검토 과정에서도 문제가 포착되는 경우가 많았다.

내 요점은 예, 코딩 언어 없이도 테스터가 될 수 있지만 이것은 당신의 삶을 악몽으로 만들 것이라는 것입니다. 생각해보세요.

3. 고객과 비즈니스 목표를 이해해야 합니다.

원천

좋은 QA가 되는 것은 좋은 일입니다. 그러나 훌륭한 QA 엔지니어 가 되려면 클라이언트의 비즈니스 목표를 이해해야 합니다. 귀하의 직업은 코드 작성 및 테스트에만 있는 것이 아닙니다. 비즈니스 가치를 창출하는 것입니다.

소프트웨어 QA 엔지니어로서 코드를 테스트하고 비즈니스 목표를 이해하는 것은 모든 사람이 하는 일에 대한 더 큰 그림을 보기 위해 한 발 물러서서 볼 수 있는 방법입니다. 이를 통해 최종 제품에 추가 가치를 제공할 수 있습니다. 당신은 아이디어를 가지고 그것을 뒤집고 다시 뒤집고, 결점과 약점을 찾기 위해 그것을 해체하고 재구축합니다. 당신은 클라이언트의 관점에서 생각해야 하지만 또한 최종 사용자의 입장에서 1마일을 걸어 그들이 제품을 처리하고 경험을 개선할 방법을 예측해야 합니다.

고객의 비즈니스를 이해하면 결정을 내리고 작업의 우선 순위를 지정하거나 시간을 보다 효율적으로 관리하는 데 자신감을 가질 수 있습니다. 개발 팀 의 잘못된 구현이나 요구 사항에 대한 오해를 방지하는 데 도움이 될 수 있습니다.

따라서 QA는 실제로 게임에 집중하고 현장에 있어야 합니다.

4. 지속적으로 학습

정보 기술은 빠르게 변하고 우리의 미래는 아무도 모릅니다. 새로운 기술, 프레임워크, 언어 및 디자인 기술을 따라잡기가 어렵습니다. 자신의 기술을 최신 상태로 유지하지 않는 QA 엔지니어라면 최고의 직업 기회를 얻을 수 없을 것입니다. 솔직히 말해서 전혀 얻지 못할 수도 있습니다. 팀은 가장 약한 유닛만큼 강합니다. 기술을 확장하면 조직 내에서도 기회가 확장됩니다.

지속적인 학습을 통해 혁신을 촉진하고 팀 성장을 촉진할 수 있습니다. 팀에 새로운 아이디어를 가져올 때 팀원들에게 새롭고 더 나은 작업 방식을 생각하도록 요구합니다.

최고의 소프트웨어 테스터는 제품의 비즈니스 및 기술 측면을 모두 이해합니다. 그들은 팀의 다른 역할을 가진 다른 사람들에게는 발생하지 않을 수 있는 고유한 질문을 제시합니다.

5. 좋은 질문하기

좋은 테스터는 좋은 질문을 해야 합니다!

새 작업이 할당되면 가장 먼저 물어봐야 하는 질문은 다음과 같습니다.
"무엇을 테스트해야 하는지 이해하려면 누구와 이야기해야 하나요?" 대답은 간단합니다. 가능한 모든 사람과 이야기하십시오!

새 프로젝트를 시작할 때 정보를 제공할 수 있는 모든 사람들의 목록을 만들어야 합니다. 까다로운 부분은 어떤 종류의 질문을 해야 하는지입니다.

내가 말하는 내용을 더 잘 이해할 수 있도록 다음 시나리오를 상상해 보겠습니다.

중요한 회의에 참여하고 있으며 팀과 흥미로운 새 프로젝트에 대해 논의하고 있습니다. 질문을 할 차례입니다. "무엇을 테스트해야 한다고 생각하세요?" 와 같은 질문을 던집니다. . 당신을 응시하는 사람들의 모습을 상상해보십시오!

방에 있는 거의 모든 사람들은 이렇게 말할 것입니다. “음, 여기 QA 엔지니어가 아닌가요? 모든 것을 테스트하십시오! 우리는 프로덕션 환경에서 어떤 버그도 원하지 않습니다!”

스스로에게 화를 내는 순간입니다.

이제 당신은 전체 제품을 테스트할 시간이 충분하지 않다는 것과 고위 경영진의 권위가 무너지고 제품 자체를 이해하지 못한다는 것을 깨닫기 시작합니다.

여기서 문제는 우리가 다른 사람에게 우리를 대신해 일을 하고 무엇을 언제 테스트해야 하는지 알려달라고 요청했다는 것입니다.

그래서 회의 시나리오로 돌아가서 테스트 작업에 대해 이야기하지 않고 질문을 해야 합니다. 사용자의 관점에서 또는 경쟁 분석을 기반으로 어떤 영역이 중요한지 이해하려고 합니다. 고객이 왜 우리 제품을 선택하고 왜 그렇게 독특한지 정보를 수집하십시오.

다음은 질문할 수 있는 몇 가지 질문입니다.

• 응용 프로그램의 가장 중요한 측면은 무엇입니까? 경쟁업체와 차별화되는 점은 무엇입니까?
• 제품의 어느 부분에 마케팅 캠페인에 집중할 것입니까?
• 잠재고객을 더 잘 타겟팅하는 데 도움이 되는 일부 Google Analytics 데이터(예: 브라우저, 운영 체제, 지역 등)가 있습니까?
• 제품과 관련된 지불 방식이 있습니까? 경험에 따라 어떤 지불 제공업체를 사용할 것입니까?

우리는 무엇을 테스트할지 묻지 않았지만 비즈니스에 중요한 것은 무엇인지 물었습니다.

6. 동료 QA와 경험 공유

원천

당신은 탁월한 재능을 지닌 QA 엔지니어가 될 수 있지만, 지식을 공유하지 않으면 좋은 사람도 훌륭한 직원도 될 수 없습니다.

나눔은 배려입니다!

좋은 블로그 게시물을 읽거나 새로운 기술이나 도구에 대해 알게 되면 공유하십시오! 이것을 팀과 공유함으로써 당신은 당신이 열성적인 학습자일 뿐만 아니라 그들이 배우고 팀 목표를 달성하도록 돕고 싶다는 것을 보여주고 있습니다.

자신의 지식과 나쁜 순간과 좋은 순간, 실수, 성취한 업적을 공유함으로써 강력한 팀의 기반을 다질 수 있습니다.

지식을 공유하는 방법에는 여러 가지가 있습니다.

• 직업이나 일과 관련된 블로그 게시물 작성
• 워크샵 준비 및 구성
• 다양한 교육을 개발하고 실시합니다.
• YouTube 비디오 또는 팟캐스트 녹화

마무리

위의 모든 사항은 귀하를 지원하는 훌륭하고 견고한 팀과 함께 슈퍼스타 QA 엔지니어가 되는 데 도움이 되며, 이는 회사에 가치를 제공합니다.