Análise exploratória e por correlação sobre o impacto dos testes de acessibilidade em projetos de desenvolvimento de software para PC

ARTIGO ORIGINAL

ALMEIDA, Hugo Leonardo Nascimento ^[1], CORREIA, Walter Franklin Marques ^[2], ALMEIDA FILHO, Adiel Teixeira de ^[3]

ALMEIDA, Hugo Leonardo Nascimento. CORREIA, Walter Franklin Marques. ALMEIDA FILHO, Adiel Teixeira de. Análise exploratória e por correlação sobre o impacto dos testes de acessibilidade em projetos de desenvolvimento de software para PC. Revista Científica Multidisciplinar Núcleo do Conhecimento. Ano. 08, Ed. 03, Vol. 03, pp. 45-62. Março de 2023. ISSN: 2448-0959, Link de acesso: https://www.nucleodoconhecimento.com.br/ciencia-da-computacao/software-para-pc, DOI: 10.32749/nucleodoconhecimento.com.br/ciencia-da-computacao/software-para-pc

RESUMO

O trabalho é composto por uma introdução teórica que conceitua engenharia de software, desenvolvimento de software, testes, defeitos escapados, experiência do usuário, usabilidade e acessibilidade. Com o objetivo de realizar uma pesquisa na área de testes voltados para a acessibilidade, foi proposta uma análise de projetos reais. Foram realizadas entrevistas com gerentes de projetos de software que já se encontram no mercado, extração de dados provenientes dos mesmos projetos, análise exploratória dos dados, testes de correlação e estruturação dos resultados encontrados. Ao fim da pesquisa, observou-se a relevância de alguns dados e a significância da relação entre eles. A partir dos resultados obtidos, conclui-se a relevância da construção de casos de testes para acessibilidade, bem como os fatores que contribuem para que as equipes deem a devida atenção aos testes de acessibilidade, como composição da equipe e colaborações externas.

Palavras-chave: Teste de Software, Acessibilidade, Projeto de Desenvolvimento.

1. INTRODUÇÃO

Há uma discussão sobre o conceito de engenharia de software. Alguns associam engenharia de software à ciência, outros à engenharia. Esta questão evidencia o caráter duplo do software, de maneira geral. Enquanto a engenharia de software considera o processo de software, que se configura em um processo de criação de produto, ficam explícitas as características de produção, ou seja, características de engenharia propriamente dita. Mas, por outro ponto de vista, o caráter competitivo e comercial, que expõem a necessidade de melhorias contínuas e sequenciais da qualidade do processo de software e do produto, revelam o contexto científico no qual a engenharia de software se apresenta (TRAVASSOS; GUROV; AMARAL, 2002).

Na área de engenharia de software, existem metodologias específicas que estabelecem a base de engenharia e de ciência. Existem quatro métodos importantes que auxiliam na condução de experimentos na engenharia de software, são eles: o método científico, o analítico, o de engenharia e o método experimental (WOHLIN et al., 2000).

Com o objetivo de desenvolver uma base de evidências para conhecimento e intervenção científica no processo de desenvolvimento de software, a engenharia de software possui a experimentação como forma de validar o processo (TRAVASSOS et al., 2008). Em uma análise na área de engenharia de software experimental (SJOBERG, DYBA; JORGENSEN, 2007), foram apontados alguns desafios a serem enfrentados na década seguinte, visando, assim, a importância da experimentação no contexto de software.

Em meio aos desafios mais específicos, há uma preocupação dos pesquisadores sobre a necessidade de planejar estudos experimentais com mais rigidez, principalmente na ampla consideração dos detalhes de design das estratégias de estudo, denominados, também, de métodos experimentais aplicáveis.

Diferentes questões de arranjo são consideradas devido à condução de estratégias de estudo, fazendo com que todas as questões sejam específicas do tipo da estratégia escolhida. A validade do estudo pode ser ameaçada por falta de observação dos principais detalhes de design pertinentes à estratégia selecionada. A resolução deste tipo de desafio requer explicitação do conhecimento sobre as diferentes estratégias de estudo existentes e disponibilização adequada do conhecimento ao pesquisador, para que ele possa ser auxiliado nas diferentes tomadas de decisão comuns nesta etapa de validação (SJOBERG, DYBA; JORGENSEN, 2007).

Dentro da engenharia de software, o desenvolvimento de software é um assunto que envolve bastante competitividade no que diz respeito ao mercado. Quanto mais qualidade um sistema apresenta, mais espaço no mercado as empresas que o desenvolve terão. Sendo assim, as empresas, de modo geral, estão investindo muito para garantir a qualidade dos seus produtos e a satisfação do cliente. Processos de engenharia de software, como o RUP (Rational Unified Process®) (KRUCHTEN, 1998), são usados durante o desenvolvimento dos produtos, com o propósito de garantir qualidade, organização e mais produtividade. Uma parte da engenharia de software que já foi apontada como de essencial importância é a disciplina de testes (PATTON, 2005; PAN, 1999), que será o principal objeto de estudo no presente trabalho.

O foco dos testes de software é encontrar defeitos no produto, de modo que a correção seja feita em tempo hábil, para que o produto chegue ao cliente. Testes levam em conta a especificação, e, através da elaboração dos casos de testes, é possível a revelação de erros ainda não identificados. Os projetos estudados nesta publicação são programas para PCs fabricados por uma grande multinacional, contendo as etapas de testes no ciclo de desenvolvimento. Sabendo que defeitos expostos aos clientes são algo bem custoso, a busca por soluções preventivas é feita através de testes, e seu objetivo é descobrir o máximo de erros possível. Dentro deste contexto, surge o conceito de escaped defects (VANDERMARK, 2003). Escaped defect (defeito escapado) é um defeito que, por diversos motivos, não foi encontrado pela equipe de testes durante alguma etapa do processo. Este trabalho propõe justamente a realização de uma análise dos dados dos projetos para PC, levando em consideração os trabalhos dos times de teste, de maneira a mitigar ao máximo o número de defeitos escapados nos projetos.

Em meio à suíte de testes da equipe de qualidade, existem testes específicos que abordam usabilidade e acessibilidade dos aplicativos desenvolvidos. Usabilidade e acessibilidade, quando bem implementadas, resultam em projetos mais eficientes e mais eficazes, que geram uma maior satisfação por partes dos clientes e um maior alcance de um público que perceba, opere e entenda sistemas interativos, independentemente da capacidade das pessoas inseridas neste público e do grau de deficiência que elas possam ter.

O caminho para o sucesso de um sistema interativo pode ser facilitado de acordo com as práticas acerca da usabilidade, acessibilidade e experiência do usuário. O conjunto desses fatores pode ser organizado e avaliado através de intervenções e estudos.

A compreensão plena de que a usabilidade pode ser especificamente um elemento de aumento de eficácia, eficiência e de satisfação dos usuários, e de que a acessibilidade possui ligação direta sobre a capacidade das pessoas com vários graus de deficiência perceberem, operarem e entenderem sistemas interativos, implicará o adequado aprofundamento do trabalho proposto.

As disciplinas de design, acessibilidade, usabilidade e experiência do usuário fornecem subsídios importantes para que novas técnicas e ferramentas possam ser aplicadas com o objetivo de incrementar e melhorar sistemas interativos. O estudo destas técnicas e ferramentas irão permitir que profissionais como desenvolvedores, designers, projetistas, entre outros, possam avaliar os sistemas interativos com critérios em mãos.

A experiência do usuário desperta um crescente interesse da comunidade da Interação Humano-Computador (IHC). Mesmo apesar de a IHC aparentar aceitar que apenas funcionalidades ou os princípios de usabilidade não são mais suficientes, não há um entendimento coerente sobre o que é, de fato, a experiência do usuário (HASSENZAHL, 2003). A ISO 9241-210 propõe definir experiência do usuário como todos os aspectos da experiência do usuário ao interagir com um produto, serviço, ambiente ou facilidade.

Segundo a ISO 9241-11, a usabilidade pode ser definida como a capacidade de um produto ser usado por usuários específicos para atingir objetivos específicos com eficácia, eficiência e satisfação em um contexto específico de uso. Seguindo este conceito, a usabilidade possui três princípios que a define. O primeiro princípio é a eficácia. Um sistema é eficaz quando permite que os usuários atinjam os seus objetivos. O segundo princípio é a eficiência, que é o esforço feito para realizar uma tarefa no sistema. O terceiro princípio diz respeito à satisfação do usuário (DIAS, 2003).

A acessibilidade é definida como possibilidade e condições de alcance para utilização, com segurança e autonomia, dos espaços, mobiliário e equipamentos urbanos, das edificações, dos transportes e dos sistemas e meios de comunicação por pessoas portadoras de deficiência ou com mobilidade reduzida. A acessibilidade compõe o conceito de cidadania, no qual os indivíduos têm direitos assegurados por lei que devem ser respeitados (LAMÔNICA et al., 2008).

A compreensão dos conceitos listados e o estudo das técnicas e métodos de avaliação das áreas apresentadas devem ser levadas em consideração para a formulação de novos métodos de avaliação. Os métodos de avaliação de interface diferem entre si em vários aspectos. É preciso entender as diferentes características de cada método, para se definir qual deles é o mais apropriado para se avaliar a interface de um software em um determinado contexto. As principais diferenças entre os métodos são a etapa do ciclo de design do software em que devem ou podem ser aplicados (durante o ciclo de desenvolvimento ou após ter o produto pronto), a técnica utilizada para coletar os dados (desde entrevistas até experimentos em laboratórios), os tipos de dados coletados (quantitativos ou qualitativos), e, ainda, o tipo de análise feita (o avaliador pode prever potenciais problemas ou interpretar os dados obtidos) (PREECE et al., 1994).

Desta forma, pretende-se, neste trabalho, utilizar-se das técnicas de engenharia de software experimental para estudar e extrair dados de projetos de softwares reais comercializados, focando nos testes de acessibilidade encontrados na base de dados dos projetos e em todas atividades e recursos que permeiam a atividade de testes, através de entrevistas, análise exploratória e testes estatísticos.

2. MATERIAIS E MÉTODOS

Nesta seção, serão descritos todos os passos traçados e executados durante a pesquisa, detalhando cada etapa conforme foi realizada.

A linha de pesquisa na qual se insere este trabalho é voltada para a acessibilidade de produtos digitais. Na busca por fornecer um modelo heurístico avaliativo para apoiar decisões em acessibilidade de produtos de software, considerando esta uma fase inicial do trabalho, procurou-se documentar achados qualitativos e quantitativos de projetos reais para poder comprovar a importância dos cuidados com a acessibilidade e poder sustentar hipóteses que relacionam quantidades de casos de testes, bugs e tarefas abertas dentro dos projetos.

Na metodologia da pesquisa, seguiu-se a aplicação de testes paramétricos e não-paramétricos, correlacionando os dados quantitativos com os dados qualitativos extraídos de entrevistas com os gerentes dos projetos analisados. Após isso, foi feita uma análise dos resultados e uma síntese de conclusões. Foi feita uma solicitação de avaliação e autorização de submissão dos achados pelas empresas participantes.

O foco da pesquisa foram os projetos para PC, dos quais serão apresentadas a extração e adaptação dos dados, um levantamento de questões de pesquisa, localizada na seção 2.1 deste artigo, e as entrevistas com os gerentes. Foi mantido o sigilo do nome dos projetos analisados, descrevendo a base de dados tomando os devidos cuidados e fazendo uma análise exploratória dos dados de maneira quantitativa. Não há interesse em expor os projetos. Desta forma, foi conseguida a autorização para ter acesso às atividades abertas de todos os projetos PC desenvolvidos pelas empresas analisadas, o que garantiu o prosseguimento da presente pesquisa.

2.1 ENTREVISTAS COM O GERENTE DE PROJETOS

Com o pensamento de que os projetos de software, em geral, possuem mais qualidade e alcance quando dispõem de elementos de acessibilidade, foi necessário fazer entrevistas com os gerentes dos projetos de softwares de uma empresa real. Foram escolhidos todos os projetos da empresa que já haviam sido lançados no mercado, por questões de sigilo e a pedido da empresa, que não queria expor projetos ainda em desenvolvimento. Além das entrevistas, foi possível observar de dentro de uma das equipes de um dos produtos analisados com o intuito de entender o pensamento dos stakeholders ao lidarem com a acessibilidade.

Na etapa de observações, foram feitas anotações de contexto, que acabaram sendo corroboradas com o que foi dito nas entrevistas. Na etapa de entrevistas, foi necessário entrar em contato com as pessoas que gerenciavam as equipes que trabalhavam diretamente com os produtos. Uma diferença notada entre as observações e a entrevista é que, ao observar, as anotações são relacionadas a todo o contexto da equipe, sobre a abordagem usada pela própria equipe em relação aos artefatos do produto. Na entrevista especificamente com os gerentes, o contexto pode parecer um pouco diferente, pois é a única e exclusiva visão do gerente como agente naquele meio.

Nesta entrevista, os gerentes foram perguntados sobre a quantidade de cada tipo de profissional no projeto, a dinâmica da equipe, reuniões, mudanças durante o desenvolvimento do produto, o próprio processo de desenvolvimento e os padrões de projeto utilizados. Foram entrevistados gerentes de 5 projetos.

Houve uma preocupação em estruturar a entrevista de modo que as respostas fossem bem direcionadas para o que o entrevistador propôs. Com base nisso, foi criado um guia para interação com os gerentes.

Devido às limitações de informações que podem ser dadas e a confidencialidade das empresas envolvidas, será considerado apenas a localidade das empresas, para efeitos de citação (Pernambuco – PE e São Paulo – SP). Ambas as empresas trabalham com o desenvolvimento de soluções para PC de alta tecnologia em um ambiente de desenvolvimento distribuído.

As perguntas das entrevistas foram:

1 – Qual a quantidade de pessoas na equipe do projeto?

2 – Quantos desenvolvedores têm? Quantos são da empresa em PE e quantos são da empresa em SP?

3 – Quantos testers? Quantos são de PE e quantos são de SP?

4 – Quantos designers? Quantos são de PE e quantos são de SP?

5 – Quais os outros participantes/stakeholders do projeto? Quantos são de PE e quantos são de SP?

6 – Como funciona a dinâmica da equipe? Seguem algum tipo de heurística?

7 – Quantas e quais são as reuniões do projeto?

8 – O projeto possui quantos estagiários? Quantos são de PE e quantos são de SP?

9 – O projeto possui quantos bolsistas? Quantos são de PE e quantos são de SP?

10 – O projeto possui quantos residentes? Quantos são de PE e quantos são de SP?

11 – Quais mudanças ocorreram dentro da equipe ao longo do projeto?

12 – Como é o processo de desenvolvimento? Quais as fases?

13- Existe algum padrão de projeto incorporado?

2.2 DESCRIÇÃO DA BASE DE DADOS UTILIZADA

Para uma análise quantitativa e qualitativa do impacto dos testes de acessibilidade em projetos de desenvolvimento de software para PC, foram coletados, de uma grande empresa de desenvolvimento de software, dados de todos os projetos com estas características e que tinham uma atenção institucionalizada em relação a acessibilidade durante o desenvolvimento.

Ao todo, foram considerados enquadrados nas características supracitadas 5 projetos da empresa investigada. Na Tabela 1 abaixo, consideram-se informações relevantes levantadas durante a coleta dos dados, que foi feita de maneira manual a partir da autorização dada para a mesma.

Tabela 1 – Dados dos projetos selecionados

Fonte: elaborada pelos autores.

Para manter o sigilo dos projetos analisados, está sendo considerada uma letra aleatória para identificar e diferenciar os dados. As informações relevantes extraídas são: atividades cadastradas na ferramenta de gestão de projetos, bugs registrados pela equipe, bugs que contêm a identificação de acessibilidade dentro de si, funcionalidades a serem desenvolvidas (estórias do usuário), funcionalidades que contêm a identificação de acessibilidade dentro de si, casos de teste e casos de teste voltados para a acessibilidade.

As atividades cadastradas dizem respeito a qualquer tipo de esforço localizado e registrado relacionado ao projeto analisado, podendo ser uma atividade de desenvolvimento de software, de testes, de DevOps, de design, etc. Os bugs registrados pela equipe são defeitos encontrados durante a implementação e validação das tarefas. Os bugs que foram identificados como bugs de acessibilidade foram registrados com uma tag que assim os identificassem. São bugs que implicam na percepção, operação e entendimento das pessoas com vários graus de deficiência ao terem contato com o produto. As funcionalidades são todas as ações possíveis dentro do programa desenvolvido, portanto, as funcionalidades identificadas com a tag de acessibilidade dizem respeito a opções de acompanhamento de pessoas com deficiência no contexto do software. Já os casos de testes são as atividades dos testadores no projeto, logo, todo teste de acessibilidade é um teste relacionado a essas funcionalidades de acessibilidade.

Na Tabela 2 a seguir, estão descritas as informações coletadas nas entrevistas com os gerentes dos projetos, para endossar as informações quantitativas extraídas na ferramenta de gestão de projetos e fazer relações no cruzamento entre todos os dados. Nesta tabela estão sendo consideradas informações mais voltadas à equipe (composição, dinâmica, comentários).

Tabela 2 – Características das equipes dos projetos analisados

Fonte: elaborada pelos autores.

2.3 ANÁLISE EXPLORATÓRIA DE DADOS

Na análise exploratória dos dados obtidos dos projetos, foram feitas algumas observações relevantes, que são compartilhadas aqui. Para uma melhor observação das análises, foram destacados por cor, na Figura 1, os dados que foram considerados ponto chave para os comentários. A Figura 1 consiste na junção dos dados apresentados nas tabelas anteriores com a adição de colunas ilustrando o percentual dos valores bugs em relação ao total de issues, bugs de acessibilidade em relação a todos os bugs, estórias do usuário voltadas à acessibilidade em relação ao total de estórias e casos de teste de acessibilidade em relação ao total de casos de teste criados pelas equipes.

Figura 1 – Junção dos dados coletados por projeto

O projeto (P) que tem, proporcionalmente, mais funcionalidades e testes voltados para a acessibilidade é o projeto que registra maior índice de bugs de acessibilidade. Ou seja, quanto mais se preocupa com a acessibilidade, mais oportunidades de correções são identificadas. Aqui é possível discorrer sobre a importância da atenção com os testes de acessibilidade, pois, sem eles, a quantidade de defeitos que podem passar pela equipe sem ser identificados e, consequentemente, corrigidos tende a aumentar. Curiosamente, este foi o projeto que teve mais incremento de colaboradores na equipe durante o desenvolvimento (coloração verde).

A equipe (W) que contém menos desenvolvedores e testers, proporcionalmente, é a equipe que registra menos atividades no geral, mas, ainda assim, abre bugs voltados para a acessibilidade numa taxa maior que a média dos projetos analisados, mostrando que não há uma consequência direta entre a quantidade de desenvolvedores, testers ou equipe técnica e a taxa de bugs de acessibilidade encontrados. Esta foi a única equipe que citou a realização de sessões de compartilhamento entre os colaboradores (coloração azul).

As duas equipes com mais colaboração externa (P e M) são as únicas que possuem testes de acessibilidade. Essa informação leva a crer que há uma influência positiva externa quanto aos cuidados com a acessibilidade para esta empresa que participou da pesquisa (coloração dourada).

Os dois projetos (S e G) que contêm mais colaboradores são os únicos que citaram a utilização de padrões de projeto, porém, têm, proporcionalmente, menos bugs de acessibilidade registrados. Aqui percebe-se que o conhecimento técnico e a abordagem de técnicas de programação e arquitetura de software que foram utilizados não têm relação direta com a acessibilidade (coloração laranja).

2.4 TESTES PARAMÉTRICOS

Em continuidade às análises dos dados, foi proposta a realização de testes estatísticos para a extração de correlações entre os dados dos projetos. O teste escolhido para medir a relação estatística entre as variáveis foi o coeficiente de correlação de Pearson.

Em estatística descritiva, o coeficiente de correlação de Pearson, também conhecido por coeficiente de correlação do momento do produto de Pearson, é denotado com a letra ρ, para um parâmetro populacional, e com r, para uma estatística amostral. Ele é usado quando ambas as variáveis que estão sendo estudadas são normalmente distribuídas. Este coeficiente é afetado por valores extremos, que podem expandir ou amortecer a força da relação (MUKAKA, 2012). A fórmula para calcular o coeficiente de correlação da amostra de Pearson é apresentada na Figura 2.

Figura 2 – Fórmula de coeficiente de correlação da amostra de Pearson

Foram feitas associações entre bugs, estórias de usuário e casos de teste atrelados à acessibilidade e ao percentual de desenvolvedores, testers e designers nos projetos estudados. Das observações feitas, a principal está na correlação entre os bugs e os casos de teste e entre as estórias de usuários e os casos de teste, indicando que casos de testes se constituem como fator central em relação à quantidade de atividades que envolvem acessibilidade. Outro ponto interessante são as correlações com os designers, que se destacam estatisticamente, mostrando mais relevância nas equipes em relação aos outros grupos de colaboradores.

Numa tentativa de complementar os testes com outro tipo de teste, desta vez, um teste de hipótese não paramétrico, não foram achados resultados significativos. Entretanto, a análise qualitativa trouxe resultados mais expressivos, que podem ser corroborados e complementados com as correlações estatísticas apresentadas.

Segue abaixo, na Figura 3, o resultado das correlações através do teste de relação de Pearson, representada pela matriz de dispersão dos valores associados. Os valores destacados com %1, %2 e %3 representam os valores das colunas de mesmo nome nas colunas da Figura 1. São as porcentagens de bugs de acessibilidade, user stories de acessibilidade e casos de teste de acessibilidade, respectivamente.

Figura 3 – Matriz de dispersão dos valores associados

3. QUESTÕES LEVANTADAS SOBRE OS PROJETOS 

Com o objetivo de fornecer um modelo heurístico avaliativo para apoiar decisões em acessibilidade de produtos de software, se fez necessário documentar achados quantitativos de projetos reais. Foi delimitado o foco em projetos para PC, dos quais foram apresentadas a modelagem, adaptação dos dados e o processo de decisão. Isto levou à compilação de uma série de questões de pesquisa para orientar na análise dos resultados, para poder comprovar a importância dos cuidados com a acessibilidade e sustentar hipóteses que relacionam quantidades de casos de testes, bugs e tarefas abertas dentro dos projetos.

Estas questões de pesquisa, que não estão classificadas de acordo com a sua importância, são apresentadas listadas abaixo:

1 – Quais características das equipes influenciam na quantidade de bugs aberto?

2 – Que técnicas utilizadas para minimizar os bugs tiveram os melhores resultados?

3 – O impacto dos testes de acessibilidade é significativo?

4 – É possível prever abertura de bugs para acessibilidade em relação a quantidade de casos de teste de acessibilidade do projeto?

5 – Há uma relação entre a quantidade de desenvolvedores, testers ou equipe técnica e a taxa de bugs de acessibilidade encontrados?

6 – Há uma influência quanto aos cuidados com a acessibilidade em projetos que recebem mais colaboração externa?

7 – O conhecimento técnico e a abordagem de técnicas de programação e arquitetura de software têm relação direta com conhecimento em acessibilidade?

As questões foram formuladas com o propósito de buscar entender a correlação entre os resultados dos dados quantitativos e as informações colhidas com os gerentes.

4. ANÁLISE DOS RESULTADOS

Esta pesquisa apresentou a análise dos resultados obtidos a partir das entrevistas com os gerentes dos projetos selecionados; extração manual de informações relevantes dos projetos, diretamente da ferramenta institucional de gestão e apoio das equipes participantes; exploração dos dados, de modo a fazer observações qualitativas das informações; e aplicação de teste paramétrico aos dados recolhidos. No total, 16535 atividades de desenvolvimento de software foram catalogadas dentro de 5 projetos reais de programas desenvolvidos para PC, envolvendo 113 profissionais. Com base na apresentação dos resultados, o conjunto de perguntas de pesquisa foi verificado.

A característica das equipes que influencia na quantidade de bugs abertos é: o número proporcional de desenvolvedores e testers, ou seja, uma presença percentual maior de designers no projeto indica um menor registro de atividades e, consequentemente, bugs abertos.

Não há uma indicação de técnicas utilizadas para minimizar os bugs, pelo contrário, o projeto que proporcionalmente apresenta mais funcionalidades e testes voltados para acessibilidade é o projeto que registra maior índice de bugs de acessibilidade. A pesquisa mostra que quanto mais atenção é dada a acessibilidade, mais defeitos são identificados e corrigidos pela equipe antes de ir para o mercado. Outro resultado relevante é a indicação de que um aumento na equipe gera um maior engajamento para registrar mais bugs e atividades no geral.

O impacto dos testes de acessibilidade é significativo, tendo em vista que quanto maior a quantidade de testes focados em acessibilidade, maior a quantidade de defeitos de acessibilidade encontrados e, consequentemente, corrigidos no projeto. Este fator foi encontrado via análise exploratória, e é possível percebê-lo no teste paramétrico.

Com base nos resultados, fica possível prever a abertura de bugs para acessibilidade em relação a quantidade de casos de teste de acessibilidade registrados para o projeto, por conta desta relação proporcional.

Conforme os resultados, percebe-se que não há uma consequência direta entre a quantidade de desenvolvedores, testers ou equipe técnica e a taxa de bugs de acessibilidade encontrados, pois a equipe que contém menos desenvolvedores e testes. Proporcionalmente, é a equipe que registra menos atividades no geral, mas, ainda assim, abre bugs voltados para acessibilidade numa taxa maior que a média dos projetos analisados.

Para responder a mais uma pergunta de pesquisa levantada, basta perceber que as equipes com mais colaboração externa são as únicas que possuem testes de acessibilidade. Essa informação denota que há uma influência positiva externa quanto aos cuidados com a acessibilidade para esta empresa que participou da pesquisa.

O conhecimento técnico e a abordagem de técnicas de programação e arquitetura de software que foram utilizados não têm relação direta com acessibilidade, pois os gerentes que citaram a utilização de padrões de projeto gerenciam os projetos que registraram menos bugs de acessibilidade proporcionalmente.

5. CONCLUSÕES

Através da pesquisa realizada, consegue-se inferir qualitativamente algumas conclusões. Uma primeira conclusão diz respeito à composição das equipes de desenvolvimento de software: o número de bugs registrados tende a diminuir na medida em que as equipes possuem, proporcionalmente, menos desenvolvedores e testers.

Uma segunda conclusão é a crescente onda de oportunidades de correções que podem ser identificadas a partir de uma maior atenção em relação a testes de acessibilidade. Desta forma diminui-se a taxa de defeitos escapados.

Em linhas gerais, pensa-se que quanto maior a quantidade de colaboradores na equipe durante o desenvolvimento, maior o esforço na criação dos testes e na contenção de defeitos escapados, porém, não há uma consequência direta entre a quantidade de pessoas e a taxa de bugs de acessibilidade encontrados. Paralelamente, outra conclusão é de que o conhecimento técnico e a abordagem de técnicas de programação e arquitetura de software não têm relação direta com acessibilidade.

Esta pesquisa retrata uma influência positiva externa quanto aos cuidados com a acessibilidade para os projetos analisados.

Por fim, percebe-se que a criação de testes de acessibilidade é benéfica e eficaz, e que quanto maior a quantidade de testes focados em acessibilidade, maior a quantidade de correções registradas internamente a serem feitas e menor a quantidade de defeitos de acessibilidade escapados.

Para trabalhos futuros, sugere-se uma amostragem maior, com projetos que já estão no mercado e projetos ainda não lançados, em processo de desenvolvimento, além de extrair dados de diferentes empresas para poder comparar e analisar as possíveis semelhanças e divergências e refletir a respeito da influência da cultura organizacional no desenvolvimento de testes de acessibilidade.

REFERÊNCIAS

DIAS, Sérgio Roberto (coord.). Gestão de marketing. São Paulo: Saraiva, 2003.

HASSENZAHL, Marc. The Thing and I: understanding the relationship between user and product. In: BLYTHE, Mark A. et al. Funology: from usability to enjoyment. Dordrecht: Kluwer Academic Publisher 2003.

KRUCHTEN, Philippe. The Rational Unified Process. Boston: Addison-Wesley, 1998.

LAMÔNICA, Dionísia Aparecida Cusin et al. Acessibilidade em ambiente universitário: identificação de barreiras arquitetônicas no campus da USP de Bauru. Revista Brasileira de Educação Especial, v. 14, p. 177-188, 2008.

MUKAKA, Mavuto M. A guide to appropriate use of correlation coefficient in medical research. Malawi Medical Journal, v. 24, n. 3, p. 69-71, 2012.

PAN, Jiantao. Software Testing. 1999. Disponível em: http://users.ece.cmu.edu/~koopman/des_s99/sw_testing/. Acesso em: 15 mar. 2023.

PATTON, Ron. Software testing. 2^nd ed. United States: Pearson Education, 2005.

PREECE, Jenny et al. Human-computer interaction. England: Addison-Wesley, 1994.

SJOBERG, Dag I. K.; DYBA, Tore; JORGENSEN, Magne. The future of empirical methods in software engineering research. In: International Conference on Software Engineering (ICSE), Minneapolis, p. 123-156, 2007.

TRAVASSOS, Guilherme Horta et al. An environment to support large scale experimentation in software engineering. In: 13th IEEE International Conference on Engineering of Complex Computer Systems, 2008.

TRAVASSOS, Guilherme Horta; GUROV, Dmytro; AMARAL, E. A. G. G. Introdução à engenharia de software experimental. Rio de Janeiro: COPPE/UFRJ, 2002.

VANDERMARK, Mary Ann. Defect escape analysis: test process improvement. In: Proceedings of the Software Testing Analysis and Review Conference, 2003.

WOHLIN, Claes et al. Experimentation in software engineering: an introduction. USA: Kluwer Academic Publishers, 2000.

^[1] Mestre. ORCID: 0000-0003-4467-0113. CURRÍCULO LATTES: http://lattes.cnpq.br/9433837114578364.

^[2] Doutor. ORCID: 0000-0002-6491-9783. CURRÍCULO LATTES: http://lattes.cnpq.br/3252289006108114.

^[3] Orientador. Doutor. ORCID: 0000-0001-6069-3601. CURRÍCULO LATTES: http://lattes.cnpq.br/9944976090960730.

Enviado: 26 de Janeiro, 2023.

Aprovado: 03 de Março, 2023.