소프트웨어 엔지니어가 일정 기간 동안 품질 보증 엔지니어로 일하는 것이 좋은 생각이라고 생각하십니까? [닫은]

나는 그것을 믿는다. 왜?

1. QA 엔지니어보다 우수하다고 생각하는 많은 소프트웨어 엔지니어를 만났습니다. QA 엔지니어가 한동안 일을한다면이 신념을 소멸시키는 데 도움이 될 수 있다고 생각합니다.

2. 소프트웨어 엔지니어가 자체 프로그램을 더 잘 테스트할수록 나머지 소프트웨어 개발 수명주기 동안 코드를 작성하는 데 걸리는 시간이 줄어 듭니다.

3. 소프트웨어 엔지니어가 프로그램이 중단 될 수있는 방법에 대해 더 많은 시간을 투자할수록 이러한 사례를 개발할 때 이러한 사례를 더 자주 고려하여 최종 제품의 버그를 줄입니다.

4. "완료"에 대한 소프트웨어 엔지니어의 정의는 항상 흥미 롭습니다. 만약 QA 엔지니어로서 시간을 보낸다면이 정의는 소프트웨어 디자이너와 더 밀접하게 일치 할 것입니다.

참고 나는 누군가가 고용 한 직책이 아닌 직책에서 일하는 것이 개발자를 잃는 레시피라는 것을 알고 있기 때문에 작은 제안을 염두에두고 위의 제안을합니다.

당신은 어떻게 생각하세요?

1. QA 엔지니어보다 우수하다고 생각하는 많은 소프트웨어 엔지니어를 만났습니다. QA 엔지니어가 한동안 일을한다면이 신념을 소멸시키는 데 도움이 될 수 있다고 생각합니다.

우수한 소프트웨어 엔지니어링은 테스트, 메트릭 및 통계를 포함하여 품질에 대한 배경 지식이 있습니다. 모든 종류의 소프트웨어 개발을하는 사람은 품질 소스 코드를 유지하고 효과적인 테스트 사례를 생성 / 유지하는 것을 알고 있어야합니다. 시간이 지남에 따라 소프트웨어 개발자는 코드 품질, 이식성, 유지 관리 성, 테스트 가능성, 유용성, 신뢰성, 효율성 및 보안과 같은 품질의 다양한 측면을 이해하게 될 것입니다.

소프트웨어 엔지니어는 라이프 사이클의 특정 측면 (요구 사항 엔지니어링, 아키텍처 및 디자인, 구성, 테스트 및 유지 관리)에 중점을 둘 수 있습니다. 그러나 (직업 또는 프로젝트의 현재 단계에서) 초점에 관계없이 품질을 기억하는 것이 중요합니다.

2. 소프트웨어 엔지니어가 자신의 프로그램을 더 잘 테스트할수록 나머지 소프트웨어 개발 수명주기 동안 코드를 작성하는 데 걸리는 시간이 줄어 듭니다.

사실 일 수도 있습니다. 그러나 일부 문제는 나중에 개발에서 가장 잘 나타납니다. 예를 들어, 성능 및 효율성 문제는 통합 될 때까지 보이지 않을 수 있습니다. 우수하고 견고한 코드와 효과적인 단위 테스트는 시작에 불과합니다. 품질은 요구 사항으로 시작하고 유지 보수 활동을 통해 철저하게 따라야합니다.

3. 소프트웨어 엔지니어가 프로그램이 중단 될 수있는 방법에 대해 더 많은 시간을 투자할수록 이러한 사례를 개발할 때 이러한 사례를 더 자주 고려하여 최종 제품의 버그를 줄입니다.

그것은 완전히 진실한 진술입니다. 그러나 요구 사항에 충돌이 없는지 확인하고 설계자가 실제로 요구 사항을 해결하는지 확인하는 설계자 등도 요구 사항 엔지니어에게 달려 있습니다. 모든 사람은 자신의 작업에 구멍을 뚫고 적절한 사람들과 협력하여 멋지게 단단히 묶어야합니다.

4. "완료"에 대한 소프트웨어 엔지니어의 정의는 항상 흥미 롭습니다. 만약 QA 엔지니어로서 시간을 보낸다면이 정의는 소프트웨어 디자이너와 더 밀접하게 일치 할 것입니다.

"완료"는 요구 사항에 대해서만 측정 할 수 있습니다. 요구 사항이 충족되고 프로젝트가 완료되었거나 요구 사항이 불완전하며 프로젝트가 완료되지 않았습니다. 다른 완전한 측정 방법은 쓸모가 없습니다.

프로그래머가 자신의 코드에 대해 책임을 지도록하고 자신의 버그를 수정하도록 요구하면이를 처리 할 수 ​​있습니다. 보너스 및 / 또는 직업 상실.

이 경험이 도움이되지는 않지만이 사고 방식으로 얼마나 멀리 갈 수 있습니까? 기술 지원, 판매, 베타 사용자는 화장실을 문지릅니다 (이것은 겸손한 경험이 될 것입니다).

"... 품질 관리 엔지니어로 일해야합니다 ..."? 당신은 그것이 적대적이거나 형벌처럼 들리게합니다.

저는 소프트웨어 개발자입니다. QA 부서가 있지만 QA 엔지니어이기도합니다. 특정 작업을 수행하는 소프트웨어를 제공하는 것이 저의 임무입니다. 그렇게하려면 단위 테스트를 작성하여 소프트웨어가 통과하는지 확인해야합니다.

QA 부서와 제휴하고 있습니다. 저의 목표는 자신이해야 할 일을하는 소프트웨어를 제공한다는 목표를 달성함으로써보다 쉽게 ​​일을 할 수 있도록하는 것입니다. 단위 테스트를하는 것처럼 두 번째 눈과 다소 안전망을 고려합니다.

소프트웨어를 개발하기로 선택하고 소프트웨어를 개발하고 싶습니다. 일부 관리자가 저에게 와서 그렇게 할 수없고 QA를해야한다고 말하면, 내가 거기에서 일하지 않기 때문에 새로운 소프트웨어 개발자와 QA 담당자를 찾아야한다고 말했습니다. 내 코드와 마찬가지로 항문이지만 창조적 인 프로세스와 프로그래밍 퍼즐 / 도전은 나에게 매우 중요합니다. 창의력을 발휘하지 않고 회사 환경에 있고 나에게 절대적으로 지옥이 될 수있는 방법에 도전하기 때문에 코드를 작성할 수 없다면 지게차 운전으로 돌아가고 싶습니다.

일반적으로 당신이 제시하는 옵션은 매우 적대적이며 일부 끔찍한 개발자와의 경험이 정말 좋지 않은지 궁금합니다. 내 생각에 개발자는 항상 품질 문제와 테스트에 대해 알고 있어야하며 공식 QA 부서에서 사용하는 것과 같이 단위 테스트에서 엄격한 테스트를 통과 할 때까지 완료되지 않은 작업에 대해 자부심을 가져야합니다. 내가 동료를 가지고 있거나 팀에서 기술을 주도하고 QA에 대한 '조언'을 보여준 개발자를 보유한 경우 그는 태도 교정을 위해 그를 끌고 갔다. 소프트웨어 제공 코인의 양쪽이 협력 할 수없고 팀으로 활동할 수 없다면 실제 문화 문제가 있습니다. 나는 그곳에서 일하고 싶지 않으며 HR과 고위 경영진이 함께 참여해야합니다.

프로그래머가 QA 엔지니어로 일하도록하는 것은 최고의 개발자를 잃는 레시피입니다. 프로그래밍과 QA에는 다른 기술과 사고 과정이 필요합니다.

그러나 프로그래머가 QA 팀에 전달하기 전에 자신의 작업을 테스트하고 검증하는 기술에 능숙해야합니다. 개발자와 QA는 다양한 도구, 지식 및 기술에 액세스 할 수 있습니다. 개발자는 예상치 못한 동작을 찾는 코드, 경계 조건에 대한 단위 테스트, 경쟁 조건을 찾는 스레드 코드 강조 등 개발자의 관점에서 테스트하는 데 능숙해야합니다.

품질 관리는 사용자 관점에서 테스트를 수행합니다. 다른 유형의 사용자처럼 생각하고 이상한 경우를 발명하고 모호한 문제를 재현 할 수있게 만드는 것이 QA 기술입니다.

반드시 그런 것은 아닙니다. 프로그래머와 테스터 모두 서로 다른 기술을 가지고 있어야합니다. 당신이 좋은 프로그래머라고해서 좋은 테스터가 될 수있는 것은 아닙니다.

훌륭한 테스터는 실제로 끔찍한 기술을 보유하고 소프트웨어가 설계하지 않은 작업을 수행 할 수 있어야하지만 사용자가 실제 세계에서 할 것을 기대할 수 있어야합니다. 기술, 인내심, 어디에서 무엇이 잘못 될 수 있는지 볼 수있는 능력, 사용자의 정신에 대한 이해 및 기타 많은 요소가 필요합니다.

필자는 프로그래머와 테스터라는 단어를 사용하지만 소프트웨어 엔지니어이고 아직 프로그래머 또는 테스터가 될지 여부를 결정하지 않은 경우이 두 가지를 모두 포함하므로 적어도 경험이 있어야합니다. 결정을 내리기 전에 인생의 처음 몇 년 동안.

그렇다고해서 숙련 된 프로그래머를 고용하고 QA 엔지니어가 얼마나 열심히 일하는지 이해하기 위해 잠시 테스트를하게되는 것은 아닙니다.

다음은 제안서에서 볼 수있는 몇 가지 잠재적 인 문제입니다.

1) 신기술 소프트웨어 엔지니어를 QA 부서에 간략하게 소개 할 것을 제안하는 경우, 그 반대의 효과가 있습니까? -그들은 당신이 초보자 일 때 QA가 당신이하는 일이라고 가정 할 수 있습니다. 그리고 당신은 당신이하고있는 일을 이해하지 못합니다.

2) 한동안 아주 나쁜 테스터가된다고해서 반드시 가치있는 것을 가르쳐주지는 않습니다. 그러나 나중에 테스트 할 수없는 경우가 있습니다. 그들은 한 번에 테스트 부서에서 6 주를 보냈기 때문에 지금 은 모든 테스트에 대해 알고 있다고 가정 하기 때문입니다 .

3) 그들이 단지 짧은 시간 동안 만있을 것이며 QA 부서는 이것을 알게 될 것이므로, 감독이나 이해가 거의 필요하지 않지만 상대적으로 바쁘지 않은 비교적 까다 롭고 쉬운 작업 만받을 것입니다 . 이것은 1과 2 만 강화할 것입니다.

4) 1, 2 및 3을 피하려면 테스트 부서에 테스트에 관심이없는 사람을 가르치고 감독하는 데 엄청난 양의 에너지를 투자 할 가치가 있다고 테스트 부서에 어떻게 설득 하시겠습니까? ( 시험 적성에 따라 선정되지 않은 사람과 함께 일하는 데는 엄청난 시간과 에너지 가 필요합니다. 테스트 팀에 몇 주 동안 추가 리소스를 제공하지 않습니다. '몇 주 동안 가장 경험이 많은 사람들 중 한 명을 잃어 버리고 초보자를 가르치라고 요청합니다).

모든 것을 말했듯이, 새로운 소프트웨어 엔지니어의 테스트에 대한 이해를 높이는 귀하의 전반적인 목표는 정말 환상적이라고 생각합니다. 나는 Greg의 제안이 그것을 달성 할 가능성이 더 높다고 생각합니다. 개발자 및 QA 팀이 서로 긴밀하게 협력하고 팀 간의 장벽을 무너 뜨릴 수 있도록 노력하십시오. (현재 테스터와 프로그래머가 같은 팀에 속해있는 회사에서 일하고 있습니다. 정말 훌륭하고 별도의 팀에서 다시 일하고 싶지 않습니다.)

그래도 프로그래머가 QA에 악영향을 미치도록하려는 경우 여기에 제안이 있습니다. 먼저 가십시오. 아마도 팀의 구성원이 이미 좋은 때 할 수있는 일을하고 매주 약간의 시간을 겹치는 영역 (테스트, DBA 등)을 전문으로하는 다른 팀과 함께 보내면 더 많은 우위를 얻고 싶을 것입니다. 그런 식으로 선물하면 더 많은 성공 기회를 얻게됩니다.

나는 당신이 일반적으로 보는 것과 반대되는 경력 경로를 정렬했습니다. 과학적으로 어려운 물리학에 대한 소프트웨어 지원으로 시작한 후 컴퓨터 회사의 아키텍처, 프로그래밍 및 알고리즘의 교차점에서 일했습니다. 그 후에는 몇 년 동안 주요 엔지니어링 코드의 성능 최적화를 수행했지만 그 작업조차도 끝났습니다. 이제 퇴직 연령이 가까워짐에 따라 동일한 코드에서 QA를 수행하고 있습니다. 도전과 준설의 조합입니다. 우리는 버그 수정에 100 % 일하는 정말 새로운 사람이 있고, 나는 그와 많은 작업을합니다. 도전적인 입장이며 많은 것을 배울 수 있습니다. 이 시점에서 직업 개발에 대한 나의 주요 관심은 sci 대학 신입생 인 쌍둥이 소년들입니다. 그래서 나는 그들의 경력, 특히 응용 수학과 관련이있는 학습 (또는 재 학습)에 새로운 관심을 가지고 있습니다. QA / 유효성 검증에 관심이있는 것은 사물에 대한 다른 관점을 가지고 있습니다. 지난 4 세기 동안 속도, 속도, 속도는 모든 비용이었습니다.

소프트웨어 테스팅은 건설적인 것이 아니라 파괴적인 과정입니다. 그러나 프로그래머는 제품을 제 시간에 예산에 맞게 완성 할 수 있도록 제품을 건설적으로 생각합니다. 소프트웨어 개발자가 자신의 제품을 파괴하는 것처럼 생각하면 누가 제품을 개발할 것인가. 따라서 소프트웨어 개발주기의 각 부분은 개발주기의 각 부분에 지정된 사람들이 수행해야합니다. 둘 이상의 분야에 종사한다면 프로그래머 또는 QA 또는 다른 옵션 중 하나를 수행하고 완벽하게 수행 할 수 있습니다.