5 Ways to help SW Quality evaluate

Tom(Inkwon Park)·2022년 6월 19일
2

(ENG) 5 Ways to help SW Quality evaluate

Could we persuade stakeholders with only comments that the planned QA schedule or test has been completed? Could we say that we did our part? I think the engineer who is part of Quality should know how to write their own thoughts about the product. These days, there are many startup companies and QA team is emerging. Unlike traditional organizational types, it is a good opportunity to grow if you continue to practice expressing opinions and evoking quality in an environment that aims for self-organization. In this time, I will share the way to evaluate SW quality based on my experience with you here.

First, the Metric formula based on data

Our quality part is able to collect and manage various data than other teams. Like the number of test cases, test coverage, resource ROI, etc. How about making a formula using two parameters that you already got? You can get an insight moment in formula and it would help improve your team.

e.g. QA/Test metric

Second, QA/Test Exit Criteria

By the time the planned QA Plan is completed, we will notify you that the QA has been ended and the next process should be run. At that time, we can check the criteria to go next process. I list up to two types of criteria in this time.

a) AND/OR conditions according to individual metrics
- Does it meet whether there are less than #N unresolved bugs
- Does it meet whether the crash instance is identified and all modified
e.g. Test Entry/Exit Criteria

b) Level/Rating Method
- The method of developing and managing the level by subdividing the method used in ‘a)’
- Management through color such as traffic lights
e.g. Health monitoring, Sign off level, Quality status

Third, Compare with Quality Goals

There should be a target or goal set initially if we want to check and manage the quality of the product periodically. This is similar to the OKR that the team performs. If you are in a long-term project at the moment, how about you make a high goal and feedback on the current comparison results every cycle.
These activities will improve our release cycle and make the current status clearer.

e.g. 
- Issue reproduction rate compared to regression test
- API, TTFB Response Time Trends
- Bug Trends compared to release

Fourth, Visualization Chart

Try to use a chart UI provided in Git, JIRA, and confluence. Their software is providing the chart plugin like a burndown chart based in a variety of metrics. If you attach these, it can be a great result. Personally, you can practice analyzing a metric for the overall project, Externally, you can give the stakeholders another interpretation. Sometimes, one graph chart would be good rather than multiple writing to present a milestone in a good direction.

e.g. Jira Chart macro, Bug trend, visualization chart

Fifth, qualitative/quantitative evaluation

It’s kind of a research activity that lists the factors that affect the software and calculates the value. It's a word and a concept that covers what we've covered in this text. The output is representative of the quality evaluation model. It is worth it when we try to evaluate the SW quality, it would prevent value-biased situations and align with more systematic SW engineering ideology. I think it would be good to use it properly in a situation where systematic quality assurance of public institutions, national projects, or large-scale projects is required.

e.g. qualitative/quantitative evaluation, ISO/IEC, IEEE, quality evaluation/measurement

In this time, I wrote down how to evaluate SW quality and practiced writing QA comments. “If you can not measure, you can not manage.” as the saying goes. It is clear that if we try to do our best thinking about visualizing the quality, more valuable products will be delivered to our customers. In addition, no matter how good feedback and various activities are, I think our feedback would be effective if we build truth with our colleagues and had a consensus in our team.

The end.

(KOR) SW 품질 평가에 도움 되는 활동 5가지

우리가 계획된 QA 일정 혹은 테스트가 완료되었다는 코멘트만으로 이해관계자를 설득시키고, 품질에 대한 역할을 다했다고 할 수 있을까요. 품질 엔지니어라면 참여하고 있는 프로젝트 혹은 담당 Product의 품질에 대해 평가할 수 있고, 본인의 생각을 집필할 줄 알아야 한다고 생각합니다. 특히 요즘 시대에 많은 신생 기업 중 스타트업에도 QA 조직이 생겨나고 있는데요. 전통적 조직 유형과 달리 self-organization을 지향하는 환경 속에서 품질에 대한 의견을 내세우고 환기시키는 연습을 지속한다면 이는 성장할 수 있는 좋은 기회로 보입니다. 이에 제 경험을 바탕으로 품질 평가를 연습할 수 있는 방법을 공유합니다.

첫째, 테이터에 기반한 메트릭

우리 품질 파트는 다른 포지션에 비해 상대적으로 다양한 데이터를 수집하고 관리할 수 있습니다. 테스트 케이스 개수, 커버리지, 리소스 ROI 등과 같은 데이터에 대해서 말이죠. 이러한 유형의 데이터 중 두 가지 이상의 인자를 두고 다양한 계산식을 만들어보면 어떨까요. 결과값을 토대로 우리가 미처 놓치고 있는 부분을 찾아 개선하고, 앞서 나아가 방향을 제시할 수 있는 인사이트 모멘트를 얻을 수 있습니다.

e.g. QA/Test metric

둘째, QA/Test Exit Criteria

계획된 QA Plan이 마무리될 시점이면 우리는 ‘QA가 종료되었음’을 알리고 다음 프로세스를 이행해야 하는 순간이 찾아옵니다. 우리는 다음 단계로 넘어가기 위한 조건들을 점검할 수 있는데요. 이러한 경우 크게 두 분류의 기준을 마련하고 따를 수 있습니다.

a) 개별 메트릭에 따른 AND/OR 조건 만족 여부
- 미해결 버그 개수 n개 이하를 만족하는가
- crash instance 식별되고 모두 수정되었는가
e.g. Test Entry/Exit Criteria

b) Level/Rating 체계
- 1번에서 활용한 방식을 좀 더 세분화하여 레벨을 마련하고 관리하는 방식
- 신호등과 같은 Color를 통한 관리 방법 
e.g. Health monitoring, Sign off level, Quality status

셋째, 품질 목표치에 따른 비교

Product의 품질을 지속적으로 관찰하고 비교하려면 우리는 초기에 설정한 목표가 있어야 합니다. 이는 마치 조직에서 수행하는 OKR과 비슷한 맥락으로 볼 수 있는데요. 장기 타임라인을 갖고 있는 프로젝트에 참여 중이라면 조금은 거창해 보일 수 있는 목표를 세워보고 매 사이클마다 현재를 비교한 결과치를 피드백해 보세요. 이러한 활동은 목표에 따른 현재 상태를 투명하게 전달하고, 앞으로의 릴리즈 여정을 보완해 주는 역할을 할 수 있습니다.

e.g.
- 회귀테스트 대비 이슈 재현율
- API, TTFB 응답시간 추이
- 릴리즈 대비 시스템 버그 검출율

넷째, Visualization Chart

깃, 지라, 컨플루언스 등에서 제공하는 차트 UI를 적극 활용해 보세요. 해당 소프트웨어 내에는 백로그, 번다운차트 등 다양한 메트릭에 기반한 차트 플러그인을 제공하는데요. 이를 첨부하여 피드백을 함께한다면 훌륭한 결과물이 탄생할 수 있습니다. 개인적으로는 프로젝트 전반에 관한 주요 지표를 분석하는 연습을 할 수 있고, 외부적으로는 이해관계자의 또 다른 해석의 여지를 줄 수도 있습니다. 때로는 여러 줄의 글보다 한 컷의 도표가 우리가 보다 나은 길로 갈 수 있는 이정표 역할을 할 수 있을 것입니다.

e.g. Jira Chart macro, Bug trend, visualization chart

다섯째, 정성/정량평가

소프트웨어에 미치는 요소를 나열하고, 척도로 값을 계산하는 일종의 연구에 가까운 활동이라 볼 수 있는데요. 지금껏 본문에서 다룬 내용을 포괄하는 단어이자 개념이라 말할 수 있습니다. 산출물로써는 품질평가 모델을 대표할 수 있습니다. 이러한 활동은 대개 우리가 품질에 대한 평가를 매길 때, 가치 편향적인 상황을 예방하고 보다 체계적인 SW 공학 이념에 부합하는 데에 의의가 있습니다. 공공기관, 국책과제 혹은 스케일이 큰 프로젝트의 체계적인 품질관리가 요구되는 상황에서 적절히 활용해 보면 좋지 않을까 생각됩니다.

e.g. 정성평가, 정량평가, ISO/IEC, IEEE, quality evaluation, measurement

이번에는 소프트웨어 품질 평가를 어떻게 할 수 있고 어떤 방식으로 연습해 보면 좋을지에 대해서 작성해 보았습니다. ‘측정할 수 없으면 관리할 수 없고, 개선시킬 수도 없다’라는 명언이 있듯이. 품질을 가시화할 수 있는 다양한 방법과 고민을 늘 지속하고, 노력한다면 보다 가치 있는 제품이 고객에게 전달될 것임은 분명합니다. 또한, 아무리 청산유수의 피드백과 다양한 활동을 할지라도 무엇보다 팀원 간의 신뢰 자산이 쌓이고 컨센서스가 있어야 품질을 향한 우리의 피드백이 더욱 효과적으로 작용할 것이라 생각합니다.

끝.

profile
Quality Explore, Dream, Discover

0개의 댓글