접근성 테스트를 한 단계 업그레이드한 방법

액세스 기능 여정의 초기에, 저희는 일반적으로 액세스 기능 테스트를 자동 및 수동의 두 가지 카테고리로 분류했습니다. 전자는 알고리즘으로 감지할 수 있는 쉬운 문제를 빠르게 포착하기 위한 것이고, 후자는 찾기 위해 더 많은 시간과 관심이 필요한 다른 모든 것을 위한 것입니다. 자동화된 테스트는 지속적 통합(CI)과 같은 신속한 프로세스에 적합한 반면, 수동 테스트는 자동화된 도구로 처리할 수 없는 모든 사항을 다루기 위해 숙련된 테스터와의 신중한 조정이 필요했습니다.

이 과정에서 우리는 실제로 이 두 가지 접근 방식 사이에 최적의 지점이 있다는 것을 발견했습니다. Assistiv Labs와 파트너십을 맺고 더 나은 프로세스와 엔드투엔드 서비스 테스트를 결합하여 자동화와 수동을 재정의하는 테스트 워크플로를 만들었습니다. 자동화된 범위를 획기적으로 늘리고 수동 조정 오버헤드를 줄이는 하이브리드 접근 방식인 중간 단계입니다.

이제 몇 주가 아닌 몇 시간 만에 명확하고 쉽게 해결할 수 있는 문제를 포착할 수 있습니다. 새로운 프로세스를 통해 긴급한 문제를 자동으로 파악하고 올바른 팀에 전달하며, 해당 팀은 일반적으로 며칠 내에 문제를 해결합니다.

기술적 측면과 문화적 측면 모두에서 좋은 결과를 얻었습니다. 접근성 피드백을 훨씬 더 빠르게 제공하고, 팀이 버그를 더 빨리 해결하며, Asana 전체의 엔지니어들이 접근성 문제에 대해 다르게 생각하기 시작했습니다.

접근성 버그의 우선순위를 지정하기 위한 프로세스 구축

Asana의 규모에서는 프로세스와 거버넌스 원칙에 의해 뒷받침되는 강력한 우선순위 지정 프레임워크가 필수적입니다. 팀은 백로그에 언제 무엇을 예약해야 하는지, 지금 주의를 기울여야 하는 것이 무엇인지 파악해야 합니다.

하지만 접근성 버그에 우선순위를 지정하는 것이 얼마나 어려운 일인지 쉽게 과소평가하기 쉽습니다. 우선순위는 보조 기술, 브라우저, 영향을 받는 사용자 그룹, 사용자 피드백, 제품 영역, 수정 난이도, 해결 방법, WCAG 준수, 과거 맥락 등 고유한 요소를 고려한 복잡한 매트릭스를 기반으로 합니다. 일부 버그는 오랫동안 존재했을 수 있지만, 최근에야 발견되었을 수 있습니다. 다른 버그는 새로운 기능과 함께 나타납니다. 그리고 일부는 회귀입니다. 즉, 이전에는 액세스할 수 있었지만 지금은 액세스할 수 없는 기능입니다.

프레임워크를 만들기 위해 다양한 유형의 접근성 버그를 공식적으로 정의하여 각 버그에 대한 간소화된 워크플로를 설계할 수 있었습니다. 필수 단계는 무엇이 퇴보에 해당하는지, 무엇이 그렇지 않은지 정의하는 것이었습니다.

재발 (n)

이전에 작동했지만 현재는 작동하지 않는, 문서화된(이전에 작동했던 기록(이전 버그, 댓글 스레드, 스크린샷 또는 화면 녹화 동영상)이 있는가?), 재현 가능한(동료가 설명된 단계를 사용하여 재현할 수 있는가?) 문제.

회귀는 자연스럽게 높은 우선순위를 받을 수 있습니다. 누구도 접근성 저하를 원하지 않기 때문입니다. 이로써 많은 경우에 우선순위 정을 크게 간소화할 수 있습니다.

하지만 한 가지 문제가 있습니다. 회귀는 전후 스냅샷에 의해 정의됩니다. 예를 들어, 이전 스냅샷은 기능이 작동하는 동영상일 수 있으며 이후 스냅샷은 새로운 문제 결과의 동영상일 수 있습니다. 버그에는 당연히 후 스냅샷이 있습니다. 그러나 이전 스냅샷을 찾으려면 보통 심층 조사가 필요합니다.

신뢰할 수 있는 이전 스냅샷 소스가 없으면 버그를 회귀로 우선순위를 지정할 수 있는지 조사하는 데 시간을 투자할 가치가 없는 경우가 많았습니다. 이때 새로운 유형의 자동화가 매우 도움이 되었습니다.

엔드 투 엔드 접근성 자동화

완전 자동화 테스트는 접근성 테스트나 Asana에 있어 새로운 것이 아닙니다. 지금까지는 axe DevTools와 React용 jsx-a11y가 광범위한 수평적 범위를 제공해 주었습니다. 하지만 이는 표면적인 것입니다. 업계 전반에 걸쳐 자동화된 테스트에 대한 토큰 30% 추정치가 우리가 달성하고 있는 WCAG 기준에 상당히 가깝다고 느꼈습니다. 제한된 범위로 인해 수동 테스트를 통해 자동화된 도구가 놓친 버그를 여전히 발견하고 있었습니다.

우리는 더 깊이 파고들 수 있는 도구가 필요했습니다. 당사의 사용자 조사 및 거버넌스 원칙과 더 밀접하게 연관된 도구였습니다. 이것이 바로 Assistiv에서 찾은 것입니다. Assistiv 엔드투엔드 서비스의 테스트는 당사가 제공하는 사용자 흐름과 테스트 매개 변수를 기반으로 Assistiv 엔지니어가 처음부터 작성합니다. 이 제품군에는 단축키, 실제 화면 낭독기, 브라우저, Assistiv Labs 클라우드 기반의 머신 비전이 포함되어 있습니다. 그 결과는 단순한 시뮬레이션 그 이상으로, 이벤트가 인간 사용자와 동일한 방식으로 기계로 전송되어 WCAG 및 더 광범위한 접근성 문제의 범위를 극대화합니다.

엔드투엔드 접근성 자동화는 기존의 자동화와는 근본적으로 다릅니다. Asana와 상호 작용하여 수동 테스터가 수행하는 것과 동일한 방식으로 작업을 수행합니다. 테스트 시나리오에 따라 WCAG 기준의 최대 75%를 충족할 수 있습니다. 그리고 여전히 실시간으로 비판적 사고 전문가들이 모든 것을 지켜보고 있습니다. Asana와 Assistiv의 직원들이 대표적인 사용자 동작을 설계하고 결과를 검토하는 데 참여하여 범위, 빈도, 정확성 측면에서 자동화된 테스트의 기준을 대폭 높입니다.

힘을 합치다

강력한 우선순위 지정 프레임워크와 소수의 버그를 찾는 것에서 대다수의 버그를 찾는 것으로 전환한 새로운 자동화를 통해 강력한 우선순위 지정 워크플로를 구현했습니다.

먼저, 자동화된 테스트가 Asana의 기존 엔지니어링 파이프라인과 동기화됩니다. 새로운 문제가 거의 실시간으로 감지되고, 이를 일으켰을 가능성이 있는 코드 변경 사항과 연관됩니다.

다음으로 Assistiv 엔지니어가 검토하여 오탐을 필터링하고 Asana의 백로그에 사용자 영향과 개선 지침이 포함된 이슈를 작성합니다. 자동화된 테스트가 지속적으로 실행되기 때문에 이전 스냅샷을 쉽게 이용할 수 있으며, 리그레션을 손쉽게 분류할 수 있습니다. 문제를 올바른 팀으로 전달하는 자동화된 Asana 워크플로를 유지합니다.

실제로는, 이는 일반적으로 배포 후 24시간 이내에 퇴보가 표시되고 접근성 관련 배경 지식이 없는 엔지니어가 쉽게 이해할 수 있는 방식으로 문서화된다는 것을 의미합니다. 이를 통해 접근성 팀은 퇴보 문제를 해결하기 위한 SLA를 설정하고 제품 팀에 맡길 수 있습니다. 어떤 퇴보가 첫 번째, 두 번째 또는 마지막인지 아무도 설명할 필요가 없습니다. 그냥 주의가 필요한 버그일 뿐입니다.

이러한 분산화는 보다 지속 가능한 프로그램과 보다 포용적인 최종 사용자 경험으로 직접적으로 이어집니다. 우리는 끊임없이 급한 불을 끄는 것이 아니기 때문에 훨씬 더 많은 권한과 영향력을 가지고 있으며, 창의성을 발휘할 수 있는 여지가 많습니다. 이는 결국 우리가 더 행복하고 효율적이라는 것을 의미합니다.

더 빠른 피드백 루프의 ROI

몇 주 또는 몇 달 동안 발견되지 않은 버그는 수정 비용이 많이 듭니다. 누군가 해당 버그를 분류하여 적절한 팀으로 전달하고 우선순위가 지정되도록 해야 합니다. 버그를 배정받은 엔지니어는 버그를 일으킨 엔지니어와 같지 않을 가능성이 큽니다. 그럴지라도, 잊혀진 맥락을 찾아내거나, 방향을 전환하거나, 다른 팀과 협력하여 그 사이에 몇 주 또는 몇 달 동안 발생한 기술적 부채를 해결하기란 어렵습니다.

이 문제에 숫자를 적용한 경우, 인용이 많은 IBM 연구에 따르면 프로덕션에서 버그를 발견하는 데 드는 비용은 설계 단계에서 발견하는 것보다 30배 더 높은 것으로 나타났습니다. 그것은 사실입니다.

엔지니어들이 아침에 업데이트를 배포하면 일반적으로 업무 일과가 끝나기 전에 리그레션의 증거가 나타나기 시작합니다. 피드백 루프가 너무 짧아서, 화면 낭독기나 키보드 탐색에만 국한되지 않는 일반적인 UI 버그에 대해 여러 차례 엔드 투 엔드 테스트를 통해 가장 먼저 경고를 받았습니다.

엔지니어들이 엔드투엔드 테스트를 통해 더 빠른 피드백을 받기 시작하면서, 우선순위 지정과 관련된 인지적 오버헤드가 줄어드는 것을 확인할 수 있었습니다. 모호성이 사라졌습니다. 엔지니어들은 “오늘 아침에 배포한 것이므로 이에 대한 책임은 나에게 있다. 어제는 작동했는데 오늘은 고장났습니다. 지금 바로 고쳐야 합니다.” 접근성 버그를 수정하는 것은 근육 기억과 같습니다.

Asana에서 접근성 버그는 그저 버그일 뿐입니다. 그리고 해결됩니다.

접근성을 자동화하는 더 나은 방법

엔드투엔드 접근성 테스트를 채택하기 전에, 저희 접근성 팀은 상당한 진전을 이루었습니다. 운영 측면에서, 디자인 및 엔지니어링 팀은 검토 프로세스, 회귀 정의 및 SLA를 문서화했습니다. 테스트와 관련하여 신속하지만 심도 없는 보고서를 위한 자동화된 솔루션과 철저하지만 시간이 많이 소요되는 감사를 위한 수동 QA가 있었습니다.

엔드투엔드를 통해 기존 작업량을 보완하고 그 위에 놓이는 기술 솔루션을 확보할 수 있었습니다. 회귀는 더 빨리, 더 자세한 세부 정보로, 더 많은 증거와 함께 문서화되고 있습니다. 실행이 불가능하거나 재현이 불가능한 버그 보고서에 시간을 낭비하는 사람은 사실상 없습니다.

이제 어떤 버그가 신규 버그인지, 어떤 버그가 기존 버그인지, 어떤 사용자 흐름에 영향을 미치는지, 누가 수정 작업을 담당하는지 명확하게 파악할 수 있습니다. 우리는 시대를 앞서 나가고 향후 Asana의 접근성에 대한 비전에 집중할 수 있습니다.

작성자 소개:  Cameron Cundiff(기술 리드)와 Jiaxin Zheng(기술 프로그램 매니저)는 모두 개발자가 아이디어를 신속하고 견고하며 만족스럽게 프로덕션에 적용할 수 있는 도구를 제공하는 데 전념하는 개발 라이프사이클 그룹의 구성원입니다.