1.
Geek news에 올라온 You are never taught how to build quality software입니다. 무척이나 공감가는 글입니다. 프로젝트를 할 때 QA와 관련한 업무를 비용으로 생각하였던 제가 떠올랐습니다. 비용이 아니라 소프트웨어의 품질을 위해서도 필요한 일입니다. 알고리즘과 관련한 가이드라인에 Software Quality가 나오는 이유는 버그 등으로 인하여 발생할 수 있는 매매손실때문이 아닐까 합니다.
2.
아래는 DeepML 번역입니다.
중요한 품질 보증 조치가 누락된 소프트웨어 프로젝트에 참여한 적이 있으신가요? 여러분은 혼자가 아닙니다. 놀라울 정도로 많은 기업과 프로젝트에서 이런 일이 발생합니다. QA라는 것이 있다는 것을 알고 있고 이를 수행해야 한다는 것을 알고 있더라도 모든 노력은 일반적으로 릴리스 직전에 대규모 QA 스프린트로 이어집니다. 스트레스로 인해 소프트웨어가 간신히 작동할 뿐입니다. 물론 이 모든 혼란은 다음 릴리스 주기에도 반복됩니다. 개선은 없습니다.
대학에서 배우는 것(What uni teaches You)
문제는 컴퓨터 공학을 공부한다고 해서 소프트웨어의 품질 표준을 보장하는 방법을 배우지 않는다는 것입니다. 대부분의 시간은 알고리즘, 컴퓨터 작동 방식, 일부 언어 및 개념의 역사 등에 소비됩니다. 또한 적어도 제가 공부할 때는 프로젝트 관리 접근 방식과 스크럼에 관한 한 학기가 있었습니다. 이 모든 것이 훌륭하지만 QA는 완전히 빠져 있습니다. 전체 학생의 90% 이상이 학위를 마친 후 회사에서 일하기 때문에 QA를 소홀히 하는 것은 부끄러운 일입니다. 제때에 버그 없는 소프트웨어를 제공해야 하기 때문입니다.
기업이 제시간에 거의 납품하지 못하는 방법(How companies deliver barely on time)
수없이 많이 보았습니다.예산상의 이유로 프로젝트에서 가장 먼저 잘려나가는 것이 바로 QA 표준과 조치입니다.프로젝트 막바지에 계획하는 경우가 많지만, 개발이 더 오래 걸리거나(실제로 종종 발생하고) 범위가 늘어나면(항상 발생하고) 더 이상 QA를 할 시간이 부족해집니다.결국 최소한의 비정형 테스트만 수행하고 벽이 부서지기 쉬운 디지털 카드 집을 출시하게 됩니다.
일부 회사나 팀에서는 특정 QA 표준이 마련되어 있습니다.일반적으로 팀의 선임 멤버가 나머지 팀원들에게 이러한 기준을 적용하는 경우가 많습니다.아마도 그들은 QA가 없으면 모든 것이 훨씬 더 어려워진다는 것을 뼈저리게 깨달았을 것입니다. 안타깝게도 표준을 마련하는 것만으로는 충분하지 않습니다. 팀이 단순히 프로젝트 관리 지표를 충족하기 위해 테스트를 작성하는 경우가 종종 발생합니다.
햄스터 휠에서 벗어나는 방법(How to get out of the hamster wheel)
프로젝트에서 누락된 QA 조치에 대해 말할 수 있는 경험과 자신감을 쌓는 데는 수년이 걸렸습니다. 관리자와 논쟁하고, 릴리스에 쫓기며, 프로덕션 시스템 장애를 처리하고, 모니터링이 누락된 부분을 찾아야 했죠. 재미가 없죠. 예를 들어 리팩터링과 같이 관리자가 직접 볼 수 없는 코드 베이스나 프로젝트의 다른 개선 사항도 상황은 비슷합니다. 하지만 QA의 경우 어떤 조치를 취하지 않으면 제대로 된 방법을 배우지 못하기 때문에 항상 특히 어려웠습니다. 목소리를 내고 토론을 반복해서 제기하는 것만이 햄스터 휠에서 벗어날 수 있는 첫걸음을 찾는 데 도움이 됩니다.
비용에 대해 이야기하기(Speak about money)
어느 순간 저도 올바른 논거를 사용하고 있지 않다는 것을 깨달았습니다.소프트웨어가 ‘더 안정적’이거나 ‘유지보수가 훨씬 쉬워질 것’이라고 설명하는 것은 코드베이스에서 직접 일하지 않는 사람에게는 와 닿지 않습니다.우리는 비용에 대해 이야기해야 합니다.개발자로서 우리는 QA를 수행하지 않았을 때의 비용에 대해 이야기해야 합니다. 이것은 일반적으로 비즈니스와 관리자의 언어입니다. 저는 항상 다음과 같은 예시를 들어 QA 대책을 설명하려고 노력합니다: ‘지금 하지 않으면 4개월 후 개발 노력과 비용이 15% 증가할 것이다’ 또는 ‘모든 기능에 대해 단위 테스트를 구현하지 않으면 릴리스 안정화 단계가 매번 더 오래 걸릴 것이다. 매번 모든 부작용을 수동으로 테스트해야 하기 때문에 우리가 구축하는 모든 기능과 직접적으로 관련이 있습니다. 이렇게 되면 릴리스할 때마다 진척도가 떨어지게 됩니다.
제 경험에 비추어 볼 때, 이 전환은 요점을 명확히 하는 데 도움이 됩니다. 결국 여러분의 노력이 모두의 삶을 개선할 수 있습니다. 하지만 아직 모든 사람이 그것을 아는 것은 아닙니다.
최소한의 유효 용량(Minimal effective dose)
현실적으로 볼 때, 막대한 초기 투자로 QA 조치를 과도하게 설계하지 않는 것이 중요합니다.프로젝트 전체의 진행을 방해해서는 안 되며, 이러한 접근 방식으로는 모든 이해관계자로부터 필요한 동의를 얻을 수도 없습니다.항상 애플리케이션에서 가장 중요한 부분을 찾는 것이 좋습니다.일반적으로 전체 애플리케이션의 기반이 되는 특정 사용 사례, 기능 또는 무언가가 있습니다. 소프트웨어가 고객에게 가치를 제공하기 위해서는 반드시 올바르게 작동해야 하는 핵심 기능이 있습니다. 이를 테스트하세요. 이것이 항상 예상대로 작동하는지 확인하기 위한 조치와 방법을 마련하세요.
저는 ‘최소 유효 용량(MED)’이라는 용어를 좋아합니다. 원하는 결과를 얻을 수 있는 최소한의 용량입니다. QA에서는 수동 테스트 계획, 파이프라인의 자동화된 테스트 또는 다른 것일 수 있습니다. 시작하기에 적절한 수준입니다. 핵심 기능이 보장되면 점차 안정성을 확장할 수 있습니다. 즉, 모든 새로운 기능에 대해 단위 테스트를 추가합니다. 또한 제어할 수 없는 정보 소스에 대해서도 생각해 보세요. 외부 API나 사용자 입력 같은 것들 말이죠. 오용으로 인해 소프트웨어가 충돌할 수 있는 더 분명한 장소인 만큼 이를 검증할 방법을 찾아보세요. 반복과 증분. QA에서도 마찬가지입니다.
내가 주의하는 것들(Things I look out for)
저는 새로 시작하거나 참여하는 프로젝트마다 QA 개념을 살펴봅니다.아무리 작은 프로젝트일지라도 팀원들은 이에 대해 생각해 보았어야 합니다.
무엇을 출시할 것인가?
무엇이 제대로 작동하는지 확인해야 할까요?
어떻게 할 것인가?
어떤 조치 중에서 의도적으로 제외할 수 있으며 그 이유는 무엇인가요?
이에 대한 서면 문서와 테스트 계획은 소프트웨어가 발전할 수 있는 훌륭한 토대입니다. 이는 팀 전체가 진행 방식에 대해 고민했음을 보여줍니다. 다시 말하지만, MED 관점에서 생각해야 합니다. 또한 선택한 접근 방식을 정기적으로 검토하는 것이 좋습니다. 즉, 분기에 한 번씩요.
새 코드를 작성할 때는 TDD를 사용하지 않지만, 소프트웨어를 작성할 때 테스트를 작성하는 것을 강력히 권장합니다. 지금이 바로 테스트를 작성하기에 적절한 시기입니다. 기능을 구현하면서 테스트를 작성하면 실제로 테스트할 수 있는 방식으로 코드를 구조화할 수 있다는 이점이 있습니다. 기존 소프트웨어에 대한 테스트를 작성하다 보면 특정 코드가 지나치게 상호 의존적이거나 단일 책임 원칙을 위반한 경우가 종종 있습니다. 테스트를 통해 원하는 동작을 이해하고 모든 것이 예상대로 작동하는지 확인했음을 설명하세요. 이는 일종의 코드 문서화라고도 할 수 있습니다.
여러분이 목소리를 내면 주변 사람들은 여러분이 프로젝트에 관심을 갖고 있다는 것을 알게 될 것입니다. 품질에 대한 토론을 제기하고 가능한 해결책을 제안하면 개발자로서의 영향력이 더욱 확대됩니다. 이는 프로젝트뿐만 아니라 개인적으로도 도움이 될 수 있습니다. 개발자와 관리자의 삶의 질이 높아집니다. 확실히 눈에 띌 것입니다.
QA 조치가 있어야만 프로젝트가 건강한 속도로 성장할 수 있습니다.
더 나은 프로젝트를 위한 변화(Changing projects for the better)
프로젝트에 이미 QA 조치를 사용하고 계신가요, 아니면 모든 것이 매우 취약한 상태인가요? 개발자 기술을 확장하고 고품질 소프트웨어 작성으로 인정받는 사람이 되고 싶으신가요?
작게 시작하세요. 프로젝트의 MED에 대해 생각해 보세요. 주인의식을 갖고 팀에서 더 나은 방향으로 변화시킬 수 있는 목소리를 내세요. 모든 사람이 QA 홍보대사가 될 필요는 없지만, 솔선수범하여 주변 사람들에게 필요한 접근 방식을 가르칠 수 있습니다. 토론을 촉발하세요.
