my unexpected journey becoming software tester
'성공적인 삶을 ... 한 번에 하루 ...'
소프트웨어 테스터로서의 여정은 예기치 않게 시작되었습니다.
나는 그것이 개발 기회라고 가정하고 초기 인터뷰 라운드에 나타났습니다. 솔직히 말해서 다른 모든 컴퓨터 과학 졸업생과 마찬가지로 나는 테스팅을 진행하는 데 약간 회의적이었습니다.
그러나 마침내 나는 그것을 시도하기로 결정했습니다. 호기심 많은 성격이이 분야에서 저를 도울 수 있기를 바랍니다.
이 질문을하지 않고는 제안을 수락 할 수 없었습니다. 테스트에 관심이없는 경우 개발로 전환 할 기회가 있습니까? :).
저를 믿으세요. 그 후에 테스팅을 떠날 생각조차하지 못했습니다.
예제와 함께 자바 8 새로운 기능
테크니컬 라운드에 출전했을 때 나는 소프트웨어 테스팅의 기본 개념 . 저를 이끈 유일한 것은 제가 이론적으로가 아니라 논리적으로 평가되고 있다는 생각이었습니다. '
이것은 테스팅에서 처음으로 배운 것이 었습니다. 신입생 )이 평가되었습니다.
오늘날에도 팀을 위해 신입생을 채용하는 동안 비슷한 기술을 사용합니다. 나는 다른 무엇보다 그들의 논리, 끈기 및 문제에 대한 접근 방식을 확인합니다.
추천 읽기 => QA 테스트 관리자로서의 여정에서 배운 4 가지 중요한 사항
QA 연수생으로 Zycus에 입사하여 3 일 또는 4 일에 제품을 할당 받았습니다. 그것은 회사에서 가장 크고 (당시 개념이었던) 가장 야심 찬 제품 중 하나였습니다. 처음 몇 주 동안 안정을 취한 후에는 되돌릴 수 없었습니다.
우리는 두 명으로 구성된 QA 팀으로 시작했고 몇 달 후 테스트 작업을 주도한 유일한 사람이었습니다. 초기 2 ~ 2.5 년 동안 기능, 성능, 보안, UI, 사용성, 다국어 , 멀티 테넌시 등
테스팅 팀에 새로 추가되기 전 상당한 시간 동안 저는 강력한 15-16 명의 멤버 개발 팀과 맞섰습니다. 추가 후에도 QC : Dev 비율은 그다지 건강하지 않았으며 테스트, 전달 및 처리 한 모든 것을 고려할 때 성공적인 여정이라고 자랑스럽게 말할 수 있습니다.
여기서 강조하고 싶은 중요한 점은 이 모든 것은 이론뿐만 아니라 실제 테스트에 대한 이해에서 나온 것입니다.
나는 거의 6 년 동안 소프트웨어 테스팅 분야에 종사해 왔습니다. 매우 다양한 경험과 많은 유익한 학습이있는 놀라운 여정이었습니다.
현재 저는 5-6 개의 제품과 모듈을 관리하는 선임 QA 관리자로 일하고 있습니다. 하지만 저에게 진정한 기쁨과 행복을주는 것은 30 명 이상의 행복하고 열정적 인 테스터로 구성된 팀을 이끌고 있다는 것입니다.
물론 많은 사람들이 내 학습에 기여했지만 대부분의 경험과 지식이 어려운 길 (그리고 아마도 가장 좋은 방법 일 것입니다), 즉 스스로 학습 / 해결했다고 말할 수 있습니다.
“경험은 최고의 선생님입니다.”
이 말을했지만 소프트웨어 테스팅에 대해 문서화 된 이론을 배우거나 따르는 것으로부터 혜택을받지 못할 것이라고 말하는 것은 아닙니다. 내가 믿는 것은이 모든 것이 반드시 도움이 될 것이지만 핵심 개념을 이해하고 문제에 대담하게 직면하는 것보다 나은 것은 없습니다.
문서화 된 내용은 당신을 가르치지 않을 것이라고 믿습니다 실제 테스트 , 비록 그것은 당신에게 어떤 방향을 줄 수 있고 당신은 당신 자신입니다. 적어도 제 경우에는 정확한 문제를 해결하기 위해 문서화되지 않은 문제가 있거나 제때 찾을 수 없었습니다. 나의 유일한 선택은 핵심의 문제 / 상황을 이해하고 내가 옳다고 생각한 접근 방식으로 대응하는 것이었다.
예 – 다른 상황에서 어떻게 접근했는지
내가 반대했던 문제 / 상황의 도움으로이를 설명하고 어떻게 접근했는지 설명하겠습니다.
# 1) 비즈니스 이해는 테스트 이해보다 한 단계 더 높습니다.
글쎄, 당신은 모두 이것을 알고 있습니다. 테스트는 단지 몇 가지 검증을 테스트하고 검증하는 것이 아닙니다.
테스터로서 우리는 가능한 모든 시나리오를 시각화해야합니다. 심지어 가장 드문 시나리오라도 실패없이 시각화해야합니다. 실제 사용자가 사용할 수있는 모든 가능한 테스트 데이터를 고려해야합니다.
이 모든 것을 위해 우리는 사업을 최대한 이해해야합니다.
비즈니스 분석가만큼 또는 그 이상으로 비즈니스 및 사용자 기반을 이해해야한다고 말하면 잘못된 것은 아닙니다.
나는 비슷한 가능성에 직면했다.
나는하기로되어 있었다 복잡한 비즈니스 시나리오 이해 조달 영역에서 새로운 요구 사항을 브레인 스토밍하고 사용자 관점에서 평가합니다. 나는 내 사례를 해결해야 할뿐만 아니라 각 반복의 요구 사항 및 설계 단계에도 기여해야했습니다. 여기에서도 내 생각과 추론 능력 외에는 준비된 참조가 없었습니다.
비즈니스를 더 잘 이해하고 시나리오 / 사례를 더 잘 설계하려면 펜과 종이처럼 작동하는 것은 없습니다.
또한 읽기 => 테스터가 삶을 더 쉽게 만들 수있는 비 테스트 도구 5 가지
가기 전에 요구 사항 논의 회의에서 나는 가능한 의심 / 수정 / 불명확 한 점을 미리 적어 두곤했다. 테스트 케이스를 작성하거나 시도하고 싶은 시나리오를 적어 두었습니다. 때로는 시나리오를 그리는 것도 매력처럼 작동합니다.
글을 쓰거나 그릴 때 더 명확하게 마음에 들어 오면 마음이이 정보에 대해 작업하고 더 많은 시나리오를 생성하고 더 명확하게 제공합니다. 이것은 당신이 DONE의 느낌을 얻을 때까지 계속됩니다!
# 2) 확률과 압력에 맞서 수행
저는 30 명의 엔지니어로 구성된 팀이 3 년 동안 지속적으로 작업하여 판매 가능한 수준에 도달 할 수있을만큼 거대하고 복잡한 제품을 작업하고있었습니다.
대부분의 초기 단계에서 저는 주니어, 중급, 시니어 레벨에 이르는 15-20 명의 개발자로 구성된 팀에 맞서거나 (솔로) 한 명 또는 두 명의 다른 테스터를 동반했습니다. 그들은 모두 제품에 끊임없이 새로운 기능을 추가하고 있었기 때문에 테스트 측면에서 동등하고 동시에주의를 기울여야했습니다.
요구 사항 회의의 일부, 사례 작성, 실행, 탐색 라운드, 서버 유지 관리, 배포 등은 선택 사항이 아닙니다.
그때까지는 어떤 방법론도 몰랐고 모범 사례 , 코스 또는 책에서 그러한 문제에 대한 해결책을 보여줄 수 있습니다. 오늘도 지상 현실과 맞서 싸우는 데 도움이 될만한 것이 있는지 잘 모르겠습니다.
내가했던 것은 공격적이고 신속한 탐색 테스트 (그때까지 이름을 몰랐습니다) 각 기능에서 하나씩 반복합니다. 이 솔루션은 순전히 생각과 프레임 상황 / 시나리오를 얼마나 빨리 바꿀 수 있는지에 따라 작동합니다.
물론 이것은 정말 빠르고 공격적인 작업을 요구했지만 저에게는 효과적이었습니다.
공격적인 라운드가 의미하는 바는 당신은 한 번에 하나를 목표로 (한 번에 양식의 한 요소를 말하십시오) 그리고 다른 링크 된 요소 / 사물과 관련하여 독립적으로 테스트하십시오.
추천 읽기 => 생산성 중독자가되는 방법 (특히 테스터)
예 : 텍스트 상자를 테스트하는 방법.
여기서 테스트 할 수있는 것은 다음과 같습니다.
- 데이터를 그대로 받아들이고 저장하는지 여부
- 데이터 유형 유효성 검사
- 최대 길이 확인
- 특수 문자 취급
- XSS 처리
- 다국어 데이터 처리
- 빈 공간 / 데이터 없음 처리
- 탭 및 Enter 키의 동작
- 오류 처리 (브라우저 간)
- UI 정렬 (브라우저 간)
- 붙여 넣기 데이터 / 드래깅 링크 데이터를 텍스트 상자에 복사
- 가장 중요한 것은이 필드의 동작입니다. 기타 연결된 요소 (이 필드의 데이터를 기반으로 다른 필드에 무언가를 채우는 것과 같이이 필드에 연결된 모든 비즈니스 기대)
위의 테스트에 대해 생각하면이 분야에서 큰 문제가 될 수 없다는 확신이 있습니까?
글쎄요, 한 번에 한 가지를 목표로하는 것은 항상 저에게 효과적이었고 저도 일부 작업을 완료했습니다.
# 3) '예상치 못한'에 맞설 때
한 번도 해본 적이없는 일을해야하는데 어느 책이 갑자기 '방법'에 도움이 될 것이라고 생각하십니까?
구체적으로 말하면-없음.
제품 리드가없는 상태에서 다른 주니어 및 중급 멤버와 함께 처음으로 데모 인스턴스에 애플리케이션을 배포해야했던 때를 기억합니다. 우리 제품의 최초 데모에 매우 중요했습니다.
글쎄, 우리는 해냈지만 많은 시행 착오를 겪었다. 이유는 우리 중 누구도 Linux 및 쉘 스크립팅 . IT 부서가 당시 관리자에게 프로덕션 서버에서 잘못된 명령을 실행하는 것에 대해 우려를 제기 한 것을 기억합니다. 아마도 이것은 촉매제 였고 셸 스크립팅 / 리눅스가 당연한 관심사 였지만 그 후 얼마 지나지 않아 5 ~ 6 개의 환경을 동시에 유지하고 업그레이드하는 책임을지게되었습니다.
Shell과 Linux는 내 관심을 아주 잘 잡아서 곧 내부 교육 세션을 시작하게되었습니다.
# 4) 성과를 측정 할 때 경험은
1과 3 사이의 C ++ 난수
제 경력 초기에 저는 매우 발전하고 경험이 많은 테스터들과 비교하고 측정했습니다. 많은 분들이 비슷한 상황을 경험 하셨을 것이며 이러한 추가 기대가 여러분에게 어떤 영향을 미치는지 알고 계실 것입니다.
여기서 해결책은 나 자신을 밀어 & 진화 .
앞으로 나아갈 수있는 유일한 방법은 내가 얼마나 느리게 / 빠르게 성장 / 배워야 하는지를 측정하는 세계 표준에 제한을 두지 않고 내가 얼마나 경험이 적은지 생각하지 않는 것입니다. 리더를 시작해야하는 시간과 시작하기 전에 필요한 제목에 대한 World의 기준에 제 자신을 제한하지 않습니다.
글쎄,이 시점에서 나는 당신이 속한 분야에 관계없이 Robin Sharma의 The Leader Who Had No Title을 읽는 것이 좋습니다. 그것은 당신이 당신 안에있는 것을 풀어내는 데 도움이 될 것입니다. 자신 외에는 아무도 당신을 막을 수 없다는 것을 알려줄 것입니다.
내 경험을 몇 문장으로 묶어야한다면 다음과 같이 진행됩니다.
“당신의 호기심, 세부 사항에 대한 관심, 규율, 논리적 사고, 일에 대한 열정, 사물을 분석하는 능력은 파괴적이고 성공적인 테스터가되기 위해 중요한 것입니다. 그것은 나를 위해 일했고 나는 그것이 당신을 위해 일할 것이라고 강력하게 믿습니다. 이러한 자질이 있다면 효과가있을 것입니다.”
글쎄, 당신이 내가 더 깊은 이론적 지식보다 기본적인 인간의 자질을 장려하고 있다고 생각한다면 여기까지 읽으면 완전히 사실이 아닙니다. 나는 무언가로 시작하고 성공을 맛보기 위해 배운 정보보다 내재 된 자질에 약간 더 의존한다고 믿습니다. 그러나 어느 분야에서나 멀리 가려면 교훈, 원리, 경험을 배워야합니다.
제 경우에도 경력을 쌓으면서 용어, 개념, 이론을 어느 정도 배워야했습니다. 이유는 테스터로서 당신은 그러한 용어로 이야기 할 여러 사람들과 상호 작용해야하고 당신은 그것을 이해하게되었습니다.
리드 또는 공동 테스터는 사실, 정의 및 용어에 대한 자신의 지식을 보유한 세계 일부 지역에서 새로운 테스터를 확보하게됩니다. 여기에서도 이러한 일에 수동적으로 머물 수 없습니다. 당신은 거기에서 사용 / 말한 최대 가능한 것들에 대한 사전 지식이 있어야합니다.
학습은 불가피합니다.
다양한 유형의 테스트, 실행 방법 및 적절한 단계에서 팀원에게 설명하는 방법에 대해 더 많이 배워야했습니다. 새로운 아이디어와 도구를 평가하고 구현해야했습니다. 새로운 개념과 방법론을 배우는 것은 사다리를 올라 갈수록 똑같이 중요해집니다.
더 읽기 => 최고의 자동화 선택에 대한 A to Z 가이드
결론
내가 몇 년 동안 배운 모든 주요 및 세부 사항을 기록하는 것은 거의 불가능하지만, 이것은 글 머리 기호 목록으로 요약하려는 나의 시도입니다.
- 테스트는 정의하기 매우 어렵습니다. 누군가는 훌륭한 테스트를 할 수 있고 그것을 말로 정의하지 못할 수도 있습니다. 보시는 바와 같습니다.
- 누구나 자신의 테스트 정의를 가질 수 있습니다. 내 것은 간단했다. '당신은 무언가를 받았습니다 – 결점을 찾아 더 좋게 만드십시오.'
- 파괴적인 테스터가되기 위해 반드시 큰 이론, 복잡한 행렬 또는 ISTQB가 필요한 것은 아닙니다. 당신은 궁금한 집중적이고 열정적이며 논리적으로 생각하고 해부 할 수 있습니다. 그러나 여분을 아는 것은 해를 끼치 지 않지만 핵심을 잃는 대가를 치르지 않습니다.
- 전통적인 접근 방식 / 개념도 그 자체의 중요성을 가지고 있으며, 그것이 정당한 필수품 인 세계의 좋은 부분이 있다는 사실을 고려할 때 나는 그들에 대해 동등하게 존경합니다. 테스트만으로는 발전 할 수 없습니다. 이를 위해 주변 환경도 진화해야합니다.
- 테스터로서 새로 배우다 앞으로 나아가는 도구, 기술 및 방법론 . 테스트 계획, 다양한 유형의 테스트를 수행하는 더 나은 접근 방식, 상황 별 테스트 등이 있습니다.
- 테스트가 유동적이므로 올바른 적합성에 대한 정의도 조직마다 크게 다릅니다. 파괴적이거나 우수한 테스터가되는 것은 운이 좋으면 급여 수표를 받기에 충분할 수도 있고 전통적인 회사에서 테스트가 어떻게 작동하는지에 대한 추가 지식이 필요할 수도 있습니다. 둘 다 자신의 위치에 있습니다.예 :나는 시험에 대한 정의에 따라 사람들을 고용합니다 (물론 후보자 경험과 프로필에 따라 약간 씩 다릅니다).
- 코딩, 운전, 요리 스타일이 있기 때문에 테스트 스타일도 있습니다. 자신의 방식으로하지 않으면 즐기지 못할 수도 있습니다. 내 말은 테스팅은 가이드 라인을 가질 수 있지만 마이크로 프로세스에 구속되어서는 안된다는 것입니다.
- 효과적인 리드 팀이 배정보다는 작업을 선택하도록해야합니다. 그는 제품의 향상을 위해 때때로 그것을 변경할 수 있습니다.
- 사람들이 관심 분야와 교육을 받기를 원하는 곳에서 사람들을 교육 시키십시오. 팀의 생각과 노력을 최종 목표 인 '최고의 품질'에 맞추십시오.
- 사람들을 관리하려고하지 말고 그들을 인도하십시오. 친절하고 접근하기 쉬워야 작업이 훨씬 쉬워집니다.
- 팀의 모든 구성원은 자신이하는 일을 사랑하고 제품에 대한 애착을 가지고 주변 사람들에게 애정을 가져야합니다. 그러면 그들 중 가장 좋은 것만 나올 것입니다.
- 테스트 세계는 진화해야합니다. 세계의 상당 부분이 탐색 적 테스트, 컨텍스트 기반 테스트 (많은 사람들이 그 사실을 모르고 수행)와 같은보다 실용적인 접근 방식으로 이동하고 있으며, 다른 사람들도 다음과 같은 더 많은 기술을 시도하고 개발해야합니다.
- 더 많은 테스트 커뮤니티가 형성되어야하고 같은 생각을 가진 사람들이 더 큰 규모로 모여야합니다. 공유하고, 배우고, 적응하고, 혁신 할 것이 너무 많습니다.
내 경험과 발견이 더 나은 테스터가되거나 테스트를 더 잘 이해하는 데 도움이되기를 바랍니다.
추가 읽기 => 초보자부터 전문가까지 : 테스트 전문가의 성공적인 여정을위한 완벽한 가이드
저자 정보 : 이 기사는 STH 팀원 인 Mahesh C가 작성했습니다. 그는 현재 여러 복잡한 제품 및 구성 요소에 대한 테스트를 주도한 경험이있는 선임 품질 보증 관리자로 일하고 있습니다.
다시 듣고 싶어요. 여기에 댓글을 달거나 Google에 문의하세요. 읽어 주셔서 감사합니다.
추천 도서
- 최고의 소프트웨어 테스트 도구 2021 [QA 테스트 자동화 도구]
- 소프트웨어 테스팅 QA 어시스턴트 작업
- 소프트웨어 테스팅 과정 : 어떤 소프트웨어 테스팅 기관에 가입해야합니까?
- 경력으로 소프트웨어 테스트 선택
- 소프트웨어 테스팅 기술 콘텐츠 작성자 프리랜서 작업
- 몇 가지 흥미로운 소프트웨어 테스트 인터뷰 질문
- 소프트웨어 테스팅 과정 피드백 및 리뷰
- 완벽한 소프트웨어 테스트 이력서 가이드 (소프트웨어 테스터 이력서 샘플 포함)