프로그래머는 자급 자족해야합니까?


28

현재 직장에는 테스터가 없습니다. "테스터가 있다면 자신의 코드를 전혀 테스트하지 않을 것"이라는 경영진의 이론적 근거가 있습니다. 이런 종류의 사고는 코드를 테스트하는 동안 시스템 내부를 알고 사용 방법을 모른다는 사실만으로 놓칠 수있는 많은 것들이 있기 때문에 제품 품질에 해로운 것 같습니다. "잘못"입니다. 블랙 박스 테스트는 전담 테스터가 끼치는 함정을 무의식적으로 피하므로 실제로 작동하지 않습니다. 많은 시간이 프로덕션 코드로 미끄러 져 최종 사용자가 발견 한 버그를 수정하는 데 사용됩니다.

해당 시스템은 크지 만 나만 개발했습니다. 이로 인해 일정 정의 및 사양 작업과 같은 일부 관리 업무가 내 무릎에 떨어졌습니다.

이런 종류의 작업이 내 책임이어야합니까? 나는 나 자신을 프로그래머로 본다. 그리고 이것이 나의 책임이라면, 어느 정도입니까? 프로젝트가 너무 커서 테스터가 필요한시기는 언제입니까? 프로그래머가 사양을 수정하거나 프로젝트 관리에 대해 걱정하거나 고객 지원을 제공해야합니까?

노트

일부는 내가 책임을 넓히는 것에 반대하는 인상을 받았을 수도 있습니다. 그러나 더 많은 관리 업무가 필요한 역할을 수행하기를 간절히 원하지만 현재는 내 업무 설명에 없습니다. 내가 공식적으로 고용되거나 추가 급여가 내 월급에 표시 될 때까지 나는 스스로를 '프로그래머'라고 생각할 것이다. 불행히도, 주니어 개발자로서 관리 업무로의 전환은 곧 일어나지 않을 것입니다.

지금까지의 훌륭한 답변입니다. 추가 할 내용이나 공유 할 개인적인 경험이 있다면 계속 오십시오!


4
아, 좋은 "테스터로서의 사용자"시나리오. 잘 알았습니다.
Matt Ellen

나는이 but..your 관리 :( 바보의 전체 당신 얘기를 해 미안 해요
박사 한니발 렉터

1
당신이 일하는 회사의 규모는? 테스터를 고용했다면 풀 타임으로 바쁘게 지낼 수있는 충분한 일이 있습니까? 그들이 프로젝트 관리자를 고용했다면, 그들이 풀 타임으로 바쁘게 지내기에 충분한 일이 있습니까? 제가 저와 같은 것을 관리해야했던 작업은 다른 직원이 그 역할을 수행 할만큼 정당하지 않은 회사였습니다.
Carson63000

@ Carson6300, 현재 우리는 모두 과로하고 같은 양의 그래픽 디자이너 인 7 명의 프로그래머를 보유하고 있습니다. 우리는 또한 최소한의 단어 어떤 의미에서, 프로젝트 관리자가 있습니다. 내가 말했듯이, ' .. 일부 관리 업무를 일으켰 습니다 ..'; 대부분의 관리는 여전히 프로젝트 관리자가 수행합니다. 전담 테스터를 정당화 할만큼 충분히 크다고 생각합니다.
Tatu Ulmanen

아마, 당신은 당신의 관리의 다음 문서 표시해야합니다 : 소프트웨어 버그에 의해 조건화을
하기 Vaibhav Garg를

답변:


19

당신은 테스터를 가지고있다. "최종 사용자"라고합니다. 이것은 당신이 묘사하는 모든 이유로 인해 해 롭습니다. 코더가 얼마나 양심적이든 상관없이, 코드가 어떻게 "포합"되어 문제를 해결할 수 있는지에 대한 자신의 선입견을 극복 할 수있는 충분한 일을 할 수 없을 것입니다. .

관리와 함께이 문제를 다시 열어야합니다. 이 시점에서 귀하의 사례를 뒷받침 할 하드 데이터가있는 것처럼 들립니다. Quality Assurance에 대한 현재의 실제 접근 방식은 시간을 낭비 하고 사용자 경험을 손상시킵니다. 이것을 제시하는 방법에주의를 기울여야합니다. 이것이 구조적 문제이며 "테스트 할 때 짜증나"의 경우가 아니라는 것이 분명 하지만, 논의가 필요한 것 같습니다.

이 고용주와 갈림길에 온 것 같습니다. 프로그래머가 아닌 다른 사람을 유지하려는 의도가 있다면, 다시 밀기 시작하고 새로운 사람을 데려가거나 다른 사람을 데려 와서 관리 업무를 수행하는 데 필요한 도움을 요청해야 할 수도 있습니다. 기존 동료의 책임 확장. ( "이것은 당신이 저를 고용 한 것이 아니며,이 과제는 사라지지 않습니다.이 일을 잘못하는 데 걸린 시간은 내가 잘하는 것에 소비 하지 않는 시간 입니다.") 현실적이지 않다. 그들이 당신이 일을 올바르게 수행하는 데 필요한 자원과 권한을 주면 더 관리적인 역할로 옮겨 갈 수 있다고 생각하십니까?

테스터가 필요하기 전에 프로젝트가 얼마나 커야하는지에 대해서는 해당 라인을 정확하게 정의하는 방법을 모르겠지만 확실히 넘어갔습니다. 실제 사용자로부터 오는 버그 보고서를 수정하는 것보다 더 많은 시간을 소비하고 있습니다. 나에게 그것은 버그가 사용자에게 처음으로 도달하는 것을 막기 위해 더 많은 노력을 기울일 시간이다.


크게 말했다, 나는 보스가 개발자가 소프트웨어를 테스트해야한다고 생각한 많은 곳에서 일했다. 회사에 테스터가 없다면 소프트웨어 개발의 기본 사항을 파악하지 못하거나 싼 놈이다. , 다른 직업을 찾아야합니다
jonathan

13

예. 이 경우 에, 당신은 당신의 코드를 테스트 할 수 있어야합니다. (나는 단위 테스트가 아니라 수용 테스트 등을 말합니다.)

없음 . 테스터는 귀하보다 테스트에 능숙합니다. 교정하는 것처럼 자신의 실수를 알아내는 것은 매우 어렵습니다. 여분의 안구가 있으면 프로그램 품질에 큰 영향을 미칩니다.

다른 질문이 많이 있습니다. 하나만 대답하겠습니다.

프로그래머가 사양을 수정해야합니까?

예! 사양을 구현해야하므로 사양이 실제로 구현 가능한지 확인해야합니다. 또한 명확한 사고, 정밀성 등으로 훈련 된 프로그래머로서 사람들이 실제로해야 할 일을 발견하고 모호하거나 논리적으로 결함이있는 요구 사항을 제거하는 데 도움을 줄 수 있습니다.


5

그들이 말하는 것과 현실은 아마도 두 가지 다른 것입니다. 아마도 이론적 근거는
"프로그래머가 이중 의무를 수행 할 수 있도록 할 때 왜 테스터의 급여를 지불해야합니까?"

물론, 그들은 그런 말을하지 않을 것이며 합리적이라고 생각하는 모든 종류의 변명을 구성 할 것입니다. 나는 그들의 요점에 대한 몇 가지 반박을 생각할 수 있지만 솔직히 그들은 도움이되지 않습니다. 나는이 싸움을 계속해서 보았고, 당신이 그들의 현재 추론을 파헤칠 때마다 그들의 접근 방식을 바꿀 것입니다. 결국 그들은 포기하고 어쨌든 그것을 지시하고 불만 제기 자로 표시됩니다.

내가 생각할 수있는 가장 좋은 방법은 품질 관점에서 문제를 해결하는 것입니다. 경영진은 문제가 생길 때까지 결코 가치가없는 것처럼 보이지만 비용 관점에서는 문제가되지 않습니다. 테스터는 프로그래머보다 저렴한 것으로 인식됩니다. 이중의 의무를지게되면 덜 비싼 자원 (테스터)이 달성 할 수있는 작업을 수행하기 위해 더 높은 유료 자원 (프로그래머)을 지불하고 있음을 상기 시키십시오. 따라서 그들은 프로그래밍 기술에서 추출하는 가치를 최대화하지 않습니다.

이 접근 방식은 급여를 받으면 무너지는 단점이 있지만, 그들은 당신이 더 많은 시간을 초과 근무를하지 못하게 만드는 것에 대한 징계는 없지만, 가치가 있습니다.


당신이 월급을 받고 더 많은 무급 초과 근무를하게 된 것에 대한 징계가 없다면 이제 그만 둘 시간입니다.
glenatron

의무 미지급 초과 근무가 모든 곳에서 법으로 제정되지 않았 음을 감사드립니다.
Steven Evers

3

해당 시스템은 크지 만 나만 개발했습니다. 이로 인해 일정 정의 및 사양 작업과 같은 일부 관리 업무가 내 무릎에 떨어졌습니다.

충분합니다.

이런 종류의 작업이 내 책임이어야합니까?

그것은 궁극적으로 당신의 결정에 달려 있습니다.

나는 나 자신을 프로그래머로 본다.

아마도 당신은 잘못된 직업에있을 것입니다. 많은 사람들이 추가 책임을지는 것을 좋아합니다.

그리고 이것이 나의 책임이라면, 어느 정도입니까?

경영진이 그렇게 말한다면 그렇습니다.

프로젝트가 너무 커서 테스터가 필요한시기는 언제입니까?

개발자가해야 할 다른 일이 너무 많을 때. 이 시점에서 경영진은 전담 테스터를 고용할지, 아니면 테스팅에 대한 위험을 감수 할 것인지 결정해야합니다. (궁극적으로 개발자는 많은 것을 할 수 있습니다.)

헌신적 인 테스터를 보유하면 확실한 이점이 있지만 추가 직원 고용 비용 외에도 단점도 있습니다.

프로그래머가 사양을 수정해야하는 경우

필요하다면 그렇습니다. 실제로, 사양을 수정해야하고 다른 사람이 작업하지 않으면이 작업을 수행하지 않으면 프로젝트가 실패 할 수 있습니다.

프로젝트 관리에 대한 걱정

필요하다면 그렇습니다.

또는 고객 지원을 제공합니까?

필요하다면 그렇습니다.

당신이 과로하고 압력에 반응하는 것처럼 들립니다. 이것은 문제입니다. 그러나 "X, Y, Z를하는 것이 당신의 일이 아니다"라는 입장을 취하는 것은 도움이되지 않습니다. 더 나은 계획은 당신이 할 수있는 일이 너무 많음을 분명히하고, 이것이 기한을 놓칠 수 있고 품질이 떨어지고 고객 지원이 열악해질 수 있음을 지적하는 것입니다. 그러나 그 과정에서 건강, 관계 등을 손상시키지 않고 어쨌든 최선을 다하십시오.


그것은 경영에 관한 것이 아니며, 또한 그의 인수와 적절한 보상이 있습니다. OP가 자신의 책임과 보상에 만족하지 않으면 기대치가 현실에 더 가까운 것을 발견하기위한 기준을 세우는 것이 합리적입니다.
jmoreno

3

테스터가 있습니다. 나는 그들 없이는 일하고 싶지 않습니다. TDD를 사용하여 단위 테스트를 작성하고 모든 코드에 대해 자동 통합 테스트를 수행하지만 테스터는 여전히 매우 유용한 기능을 가지고 있습니다.

  1. 그들은 고도로 숙련되어 있으며 프로그래머들에게는 다른 기술을 가지고 있습니다.
    1. QA 테스트를 수행하는 방법에 대해 많은 경험과 지식을 보유하고 있으며, 생성 된 코드가 사용자의 기대와 실제 사용자 행동과 실제로 일치하는지 확인하는 방법에 대해 알고 있습니다.
    2. 이들은 많은 버그를 경험했으며 소프트웨어를 손상시킬 수있는 상황을 잘 알고 있습니다.
    3. 그들은 냉소적이고 체계적인 경향이 있습니다. 프로그래머가 종종 훨씬 더 낙관적이라는 것을 알았습니다.
  2. 유용성에 대한 귀중한 조기 피드백을 제공합니다. 예를 들어 최근에 REST API를 만들 때 QA 테스터가 쉽게 이해할 수없는 영역은 사용자가 만족하지 못하는 영역을 잘 나타냅니다.
  3. 실제 환경, 실제 하드웨어, OS 등의 많은 구성을 테스트합니다.
  4. 대규모의 현실적인 테스트 베드를 구축하고 성능,로드 및 스트레스 테스트를 수행하는 방법을 알고 있습니다.
  5. 그들은 나쁜 릴리스가 나오지 않도록하는 데 중점을 둡니다. 프로그래머는 코드를 공개하는 데 집중하는 경향이 있습니다. 프로그래머가 기본적으로 코드를 해제하는 것과 거의 비슷하지만 QA 테스터는 해제해야 할 이유가 필요합니다 (작동하는 것으로 표시됨).

0

"테스터가 있다면 자신의 코드를 전혀 테스트하지 않을 것입니다"

" 자동차에 안전 벨트가 있다면 항상 충돌 할 것입니다! "

이런 종류의 작업이 내 책임이어야합니까? [...] 그리고 이것이 나의 책임이라면, 어느 정도입니까?

이에 대한 대답은 "의존"입니다. 내가 이해 한 바에 따르면, 고용주는 귀하를 "일인 IT 부서"로 간주합니다. 이 경우, 그렇습니다 (귀하의 책임). 절대적으로 미워하고 피해야 할 책임이 있다면 IT 부서가 더 큰 회사 내에서 직책을 찾으십시오.

프로젝트가 너무 커서 테스터가 필요한시기는 언제입니까?

그것은 올바른 질문이 아닙니다. "회사의 제품 / 이미지 품질이 너무 중요하여 테스터가 필요할 때"라고 묻는 것이 좋습니다.

프로그래머가 사양을 수정해야 할 경우 [...]

물론 이죠 대부분의 경우 개발자 / 구현자가 필요로하는 것과 고객이 사양으로 제공하는 것 사이에는 큰 차이가 있습니다.

기술적으로 불가능하거나 모순되는 요구 사항 등 (특히 유일한 개발자 인 경우)을 알아 차리고 지적하기 위해 회색 / 지정되지 않은 영역을 찾고 올바른 질문을하는 것은 많은 경우에 귀하에게 달려 있습니다.

[...] 프로젝트 관리에 대해 걱정하거나 고객 지원을 제공합니까?

그것은 당신이 입장했을 때 받아 들인 책임에 달려 있습니다. 예를 들어 일부 직책에서는 고객에게 직접 연락해야합니다. 다른 모든 것들이 평등하다면, 나는 그러한 입장을 피하려고 노력할 것입니다 (그러나 그것은 당신에게 달려 있으며 많은 직업 선택이 없을 수도 있습니다).


0

우선 Quality Assurance 테스트는 애플리케이션을 클릭하여 기능성을 테스트하는 것만이 아닙니다. 품질 보증은 프로세스 에 관한 것 입니다. 오류를 찾기 위해 응용 프로그램을 테스트 할뿐만 아니라 개발자가 오류를 처리하지 못하게해야합니다.

  1. 제품 사양 + 사용 사례
    모든 사람이 제품 기능을 알고 있거나 생각한다고해도이를 기록해야합니다. 명확한 사양이 없으면 응용 프로그램을 테스트 할 수 없습니다. 사양은 올바른 동작과 버그를 정의합니다.
  2. 단위 테스트, 통합 테스트
    UI를 통해 테스트하기 어려운 내부 테스트, 예외적 인 애플리케이션 상태. 이것은 더 큰 시스템마다 필수적입니다. 두 가지 유형의 테스트에는 또 다른 흥미로운 속성이 있습니다. 코드의 모든 부분을 다시 통과하게하여 이전에는 본 적이없는 버그 / 아키텍처 문제를 깨닫게됩니다.
  3. 코드 품질 및 코딩 표준
    QA가 수행해야하는 작업 중 하나는 코드 복잡성을 측정하는 것입니다. 복잡성이 낮은 코드는 오류 가능성을 줄입니다 (버그 방지).
  4. 코드 검토
    프로젝트가 주어진 크기에 도달하거나 많은 사용자가 사용하는 경우 코드 검토는 필수입니다. 다른 프로그래머는 항상 놓친 코드 문제 / 버그를 찾습니다. 프로그래머는 때때로 자신의 코드에서 명백한 버그에 대해 눈을 멀게합니다.
  5. 문서
    코드와 아키텍처를 문서화하면 가능한 결함 (내 경험)을 실현하는 데 도움이됩니다.
  6. 테스터
    테스터는 UI를 클릭하는 원숭이가 아닙니다. 테스터는 사양 및 사용 사례를 가져 와서 테스트 사례를 만듭니다. 그런 다음 하나씩 테스트합니다. 최종 사용자가 버그를보고하면 테스트 케이스를 추가해야합니다.

프로그래머는 절대 사양을 만들지 않아야합니다 (1). 당신은 기능을 결정하기 위해 거기에 없습니다. 일반적으로 최종 사용자와 대화하고 그래픽 디자인 등을 만들어야합니다. 시간이 많이 걸리는 작업입니다. 프로그래머가 기능을 결정하면 일반적으로 "괜찮지 만 내일까지이 창에서 모든 것을 변경할 수 있습니까?" "이것은 내가 원하는 것이 아니다" "작동하지만 사용하기 어렵다" "우리가 실제로 필요한 유일한 기능이 없습니다".

프로그래머가 달성 할 수있는 것은 2, 3 및 5입니다.

4 명의 다른 프로그래머가 필요합니다. 대규모 IT 프로젝트를 수행하고 매우 위험한 상황에 시스템 단계를 아는 한 명의 개발자 만있는 회사.

시간이 충분하지 않으면 테스트 사례를 작성하지 않아도됩니다 (5). 시간이 많이 걸리기 때문에 보통 헌신적 인 사람이 필요합니다. 테스트 사례가 없으면 테스트는 농담입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.