Hermit Under the Cliff

AI 기술이 빠르게 발전하면서, 자동화 및 인공지능 기반 QA (Quality Assurance) 엔지니어링에 대한 관심이 증가하고 있습니다. 그렇다면, AI가 QA 엔지니어의 영역을 대체할 수 있는 가능성이 있을까요? 우선, QA 엔지니어링은 소프트웨어 제품의 품질을 보장하기 위한 과정으로, 테스트, 검증, 검사 등의 작업이 포함됩니다. 이러한 작업은 소프트웨어 제품의 문제점을 발견하고 해결함으로써 제품의 안정성과 신뢰성을 높이는 것을 목적으로 합니다. AI는 이미 많은 분야에서 활용되고 있으며, 특히 QA 엔지니어링에서도 다양한 기술과 알고리즘이 적용되고 있습니다. AI를 활용한 QA 엔지니어링은 테스트 자동화, 결함 감지, 성능 테스트 등의 작업을 수행할 수 있으며, 이를 통해 효율성과 정확성을 높..

이직한 회사에서 입사전 개인 정보를 입력하는 단계에서 명패 문구를 적으라고 해서 조금 고민을 하다가 "해치지 않아요" 로 결정을 했습니다. 조금은 까칠해 보이는 저의 인상에 대한 오해를 풀 문구이기도 하였지만 자동화 엔지니어 측면에서도 다른 QA들에게 해가 되지 않는다는 그런 뜻도 있습니다. QA 조직내에서 자동화 구현을 하면서 지내온 시간들 중 가장 자주 들었던 말 중 하나가 "그래서 얼마까지 줄일 수 있는데?" 라는 윗 분들의 말과 "그러면 우리 일 없어지는 거에요?" 라는 동료들의 농담 섞인 말이었습니다. 물론 장난스러운 말로 "내가 다 자동화 해버려서 너님을 쓸모없게 만들어버리겠어!" 라는 말을 안해본 것은 아니지만 테스트 자동화의 목적은 리소스를 줄이고, 이에 따른 비용을 줄이는데에만 있지 않습..

우선 저는 회사에서는 QA로 분류가 되고 있는 직무에서 일을 하고 있지만 항상 SW Engineer라는 정체성을 가지기 위해 노력(?)하고 있는 사람입니다. 길다면 긴 저의 커리어의 대부분이 품질관련 팀에서 QA역할 혹은 QA를 보조하는 SET(Software Engineer in Test)의 역할이 었습니다. 처음에는 내가 작성한 코드가 실제 제품에 반영이 되어 많은 사람이 사용하게되는 소위 말하는 개발자의 역할을 원한 적도 있긴 했지만, 지금 돌이켜보면 QA의 직무로 SW Engineer의 역할을 수행하는데도 참 많은 장점들이 있는 것 같습니다. # 내가 원하는 대로 QA 조직내에서 SW Engineer의 특성을 계속 유지를 하게 되면 필연적으로 테스트 자동화의 업무를 맡게 됩니다. 테스트 자동화는 ..

BDD (Behavior Driven Development) 는 아래와 같이 Given, When, Then 을 이용하여 사용자 시나리오를 정의하는 것에서 부터 출발합니다. 이러한 사용자 시나리오를 바탕으로 Cucumber 등의 프레임워크를 이용해서 TDD에 사용될 Test case들을 만드는 등의 형태로 많이 설명이 됩니다. 개발과는 한발짝 떨어진, User Level의 End to End test를 하는 QA 입장에서 이런 BDD 방법론을 개발팀을 설득해서 도입하는 것 이전에 테스트에 도입을 할 만한 방안이 없을까 고민을 해 봅니다. User Level의 End to End Test의 경우 자동화된 테스트에서 Cucumber 등을 이용하여 BDD 형식을 도입을 하더라도 들인 시간 대비 얻는 이점이 그..

제가 C#을 처음 접한 것은 10여년전 쯤 이직과 함께 새로운 업무를 맡게 되면서 입니다. 그 전까지는 C# 코드들을 슬쩍 보면서 이거 완전 자바랑 비슷한데? 정도의 생각만을 가지고 있었죠. 10여년간의 시간동안 C#과 함께 하면서 (가끔 파이썬이나 코틀린, 러스트, 고 등으로 외도를 잠깐씩 하긴 했지만) 이제는 파이썬 같은 스크립트 언어로 작성을 할 것 까지 C#으로 커버를 할 때도 있을만큼 C#을 좋아합니다. 물론 제가 밥을 벌어먹고 사는 업무가 Windows 환경에서의 테스트 Tool 개발이다 보니 Windows의 UI를 가장 쉽고 빠르게 작성을 할 수 있는 언어가 C#이라서 더욱 좋아하는 점이 없진 않지만, Windows UI를 제외하고 나서라도 C#은 훌륭한 개발언어입니다. (물론 그 중 Vis..

회사 생활을 하다보면 Top-Down 방식으로 위에서 부터 내려오는 일들이 참 많습니다. 하지만 실제 일을 직접하는 입장에서는 이 탑다운으로 꽂히는 일이 반갑지 않고, 오히려 업무에 방해가 되는 경우도 있습니다. 실제 업무를 진행하는 사람들이 필요에 의해서 개선활동을 하고 이것이 Bottom-Up이 되어 하나의 문화를 만들어 가는것, 말은 정말 아름답지만 그렇게 쉽지만은 않습니다. (현실은, 개선아이디어 하나씩 제출해! 우리팀이 제일 꼴찌야!!) 테스트 자동화에 대해서 - 특히 QA 조직에서 - Top-Down으로 내려오는 지시중 하나가 테스트 자동화를 적용해서 얼마의 리소스를 줄여라. 이런 식인 경우가 많죠. 최악의 경우는 위에서 내려오는 숫자에 맞추려고 의미도 없는 숫자의 자동화 테스트 개발을 해서 ..

테스트만 전문적으로 하는 QA조직내에서의 테스트 자동화 업무로 밥을 벌어먹고 산지가 어느새 10년이 훌쩍 넘어버렸습니다. 다행히 나이만 먹은게 아니라 이 일을 계속해서 해나가면서 어느정도 통찰력이라는 것이 생기긴 하였습니다. 개발 조직내에서의 테스트 자동화는 그래도 요즘 개발 방법론에 따라서 Uint test, Integration test, System test 등을 잘 하고 있는 조직들도 있고 이런 것들을 하려고 노력하고 있는 곳들도 많이 있습니다. 빌드 시스템을 자동화하면서 CI/CD를 구축하거나 DevOps를 도입하거나 하는 식으로 자동화 테스트에 대한 요구와 필요성이 점점 대두되고 있는 느낌입니다. 하지만 QA조직에서는 (제 좁은 경험일지는 모르겠으나) 자동화 테스트의 인기가 개발 조직보다는 덜..