챗지피티야 고마워~

Open sidebar
프론트엔드 개발자의 단점

나의 단점은 성격이 급하고 개발 속도에 대한 불안감을 가지고 있어서 기획서를 보고 어느정도 이해가 됐다 하면 바로 작업을 시작해서 전체적인 로직을 먼저 작업하면서 점점 작업에 대한 이해도를 높여가는 식임.
그러다보니 세세한 것들를 놓치는 편이 많았음
충분한 시간을 들여서 기획서를 읽고 계획을 다 짠 다음에 들어가는 게 좋은 걸 알지만 작업을 받으면 먼저 어느정도 개발이 된걸 얼른 보여줘야겠다는 마음이 급해서 작업 먼저 들어가게됨 그래서 수정사항이 많이 나옴. 내가 qa팀이라면 화딱지 날 거 같아. 어떻게 개선하면 좋을까?

안녕하세요! 당신의 걱정을 이해합니다. 먼저, 당신이 인정한 것처럼 성격이 급하고 덜렁거리는 경향이 있다면, 이러한 습관들이 일을 더 어렵게 만들어질 수 있습니다. 하지만 이는 개선 가능한 부분입니다.

첫째, 좀 더 꼼꼼하게 기획서를 파악하는 습관을 길러보세요. 프로젝트를 시작하기 전에 시간을 내서 문서를 정독하고 모호한 부분을 파악하는 것이 중요합니다. 그렇게 하면 작업을 시작하기 전에 미리 수정이 필요한 부분을 파악하고 개선할 수 있습니다.

둘째, 일을 급하게 처리하는 습관을 개선해보세요. 일을 성급하게 처리하면 수정할 부분이 생길 가능성이 높습니다. 일정 계획을 세우고 작업을 시작하기 전에 충분한 시간을 가지고 고민해보는 것이 좋습니다.

마지막으로, QA팀과 소통을 잘 해보세요. QA팀은 코드 품질을 검증하고 문제점을 찾아내는 중요한 역할을 합니다. 따라서 QA팀과 소통을 잘 하여 수정할 부분을 미리 파악하고 개선하는 것이 좋습니다. 그렇게 하면 QA팀과 좀 더 원활한 협업이 가능해질 것입니다.

개선해야 할 부분이 있음을 인정하고 개선하려는 의지를 가지는 것이 중요합니다. 계속해서 발전하고 성장하는 개발자가 되어보세요!




Qa팀과 어떻게 소통해야 좋을까?

QA팀과의 소통은 프로젝트를 성공적으로 완료하는 데 매우 중요합니다. QA팀과의 원활한 소통을 위해서는 다음과 같은 방법을 고려해 볼 수 있습니다.

테스트 계획을 공유하세요.
QA팀과의 첫 번째 소통은 테스트 계획을 공유하는 것입니다. 이를 통해 QA팀은 개발자가 작성한 코드를 검증하고, 개발자는 QA팀이 어떤 테스트를 수행할 것인지 미리 파악할 수 있습니다.
버그 리포트에 대한 대처 방법을 논의하세요.
버그 리포트는 QA팀에서 자주 발생하는 이슈 중 하나입니다. 따라서 버그 리포트에 대한 대처 방법을 미리 논의하고, 개발자와 QA팀 간의 일관된 방식을 유지하는 것이 중요합니다.
회의를 주기적으로 개최하세요.
주기적인 회의를 통해 개발자와 QA팀 간의 소통을 원활하게 유지할 수 있습니다. 회의를 통해 QA팀이 발견한 문제점과 개선사항을 공유하고, 개발자는 이를 반영하여 코드를 수정할 수 있습니다.
툴과 시스템을 통합하세요.
코드 품질을 향상시키기 위해 툴과 시스템을 통합하는 것도 좋은 방법입니다. 예를 들어, 코드 리뷰 툴이나 버그 추적 시스템을 도입하면, 개발자와 QA팀 간의 소통을 더욱 효율적으로 할 수 있습니다.
서로에 대한 이해를 높이세요.
마지막으로, 개발자와 QA팀 간의 서로에 대한 이해를 높이는 것이 중요합니다. 개발자는 QA팀이 어떤 작업을 수행하는지, 그리고 QA팀은 개발자가 어떤 언어나 도구를 사용하는지 등을 파악하면 서로간의 협업이 원활해집니다.
위의 방법들을 활용하여 개발자와 QA팀 간의 소통을 원활하게 유지하면, 프로젝트의 품질을 높일 수 있습니다.




TC을 작성할 때 내가 확인하고 의견을 주는 게 좋을까?

TC(Test Case)를 작성할 때, 개발자가 확인하고 의견을 주는 것은 매우 중요합니다. 이를 통해 개발자는 자신이 작성한 코드가 TC를 만족하는지 검증하고, QA팀은 개발자가 생각하지 못한 케이스를 확인할 수 있습니다.

따라서 TC를 작성할 때는 다음과 같은 과정을 추천합니다.

TC를 작성하기 전에 요구사항을 잘 파악하세요.
TC를 작성하기 전에 요구사항을 자세히 파악하는 것이 매우 중요합니다. 요구사항에 대한 이해도가 낮은 상태에서 TC를 작성하면 불필요한 검증 작업이 추가될 수 있습니다.
TC를 작성하고 개발자에게 확인을 요청하세요.
TC를 작성한 후, 개발자에게 확인을 요청하세요. 이를 통해 개발자는 자신이 작성한 코드를 TC에 맞게 수정하거나, TC를 수정할 필요가 있는지 파악할 수 있습니다.
개발자의 의견을 수렴하세요.
개발자가 TC에 대한 의견을 제시하면, 이를 수렴하는 것이 좋습니다. 개발자가 제시한 의견을 고려하면, 보다 효율적인 검증 작업을 수행할 수 있습니다.
TC를 수정하고, QA팀과 공유하세요.
개발자와의 소통을 통해 TC를 수정한 후, QA팀과 공유하세요. QA팀은 수정된 TC를 기반으로 검증 작업을 수행할 수 있습니다.
검증 결과에 대한 피드백을 수렴하세요.
검증 작업이 끝난 후, QA팀으로부터 검증 결과에 대한 피드백을 수렴하세요. 검증 결과를 분석하면, 개발자는 코드 수정이 필요한 부분을 파악하고, 개선할 수 있습니다.
위의 과정을 따르면, TC를 작성할 때 개발자와 QA팀 간의 소통을 원활하게 유지할 수 있으며, 코드 품질을 향상시킬 수 있습니다.




보통 TC는 개발자가 개발에 들어가기 전에 작성해 아니면 개발이 끝나고 QA들어가기 전에 작성해?

일반적으로 TC(Test Case)는 개발자가 개발에 들어가기 전에 작성됩니다. TC는 개발자가 작성한 코드가 요구사항을 만족시키는지 검증하기 위한 목적으로 작성되며, 개발자가 코드를 작성하기 전에 TC를 작성하면 코드 품질을 향상시킬 수 있습니다.

TC를 개발자가 작성할 때, 개발자는 자신이 작성한 코드에 대한 자신감을 가질 수 있으며, QA팀은 개발자가 작성한 TC를 기반으로 검증 작업을 수행할 수 있습니다. 따라서 TC를 개발자가 작성하면 품질이 높은 코드를 개발할 수 있으며, 검증 작업을 보다 빠르고 정확하게 수행할 수 있습니다.

그러나 일부 경우에는 개발이 끝난 후 QA팀이 TC를 작성하기도 합니다. 이 경우에는 개발자가 작성한 코드를 기반으로 QA팀이 요구사항에 맞는 TC를 작성하며, 이후 검증 작업을 수행합니다. 이 경우에는 개발자가 코드를 작성할 때 요구사항을 충분히 이해하지 못했거나, 요구사항이 변경되었을 경우 등에 해당합니다.

따라서 TC 작성 시점은 프로젝트의 상황에 따라 다를 수 있으며, 보통은 개발자가 개발에 들어가기 전에 작성하는 것이 일반적입니다.