2.2 Drill Bits
2.2.1 PDC design review
Com o objetivo de facilitar o registro das submissões de versões e validação através da execução dos testes por parte dos alunos foi criado um sistema Web utilizando linguagem PHP para realizar um simples cadastro de testadores e oferece acesso a uma lista de problemas POPT e não-POPT.
A arquitetura do sistema de submissão representada na Figura 17 apresentada às dependências entre as diversas páginas php e a comunicação com um banco de dados MySQL através do componente connect.php que disponibiliza acesso ao banco de dados aos principais recursos do sistema:
48
cadastro (checkRegister.php), acesso (checkEnter.php) e submissão de código e teste (result.php).
Figura 17 Arquitetura do sistema de submissão
O banco de dados criado registra dados básicos para testador, problema e resposta enviada. A Figura 18 representa o diagrama entidade- relacionamento das tabelas criadas para o banco de dados de submissão.
49
Figura 18 Base de dados TestBoot
Como pode ser observado, cada problema pode ser classificado como POPT e não-POPT pelo atributo POPT da entidade problema que pode receber quaisquer quantidade de respostas dos testadores. A entidade resposta além de possui atributos para armazenamento do código e planilha de testes registra a data e hora para posterior análise de tempo decorrido entre as versões enviadas.Segue-se uma lista de figuras que apresentam as principais telas de interação com o sistema Web.
Figura 19 opening.php - página inicial
50
Figura 21 register.php - página de cadastro
Figura 22 homePage.php - lista de problemas POPT e não-POPT
51
52
5 Estudo de Caso
Este capítulo apresenta um estudo de caso que foi realizado para avaliar a eficácia da abordagem proposta. Na seção 5.1apresentamos o contexto em que o estudo foi realizado. Na seção5.2, descrevemos a sistemática do estudo e seus resultados. Por fim, na seção 5.4realizamos o fechamento do capítulo.
5.1 Organização do Estudo
De acordo com o processo proposto por Wohlin et al. (2000), o objetivo do nosso estudo pode ser definido de acordo com o modelo GQM, como segue:
Comparar às abordagens POPT e a abordagem de teste cego,no contexto de disciplinas de introdução a programação, com relação: ao tempo gasto para implementar os programas; a qualidade de cada programa (i.e número de testes que passam na execução do programa) e o esforço para identificar e corrigir falhas antes de submeter versões.
A partir do objetivo definido anteriormente, podemos derivar as seguintes perguntas e métricas associadas:
RQ1. POPT pode ajudar os alunos a obter implementações mais corretas do que a abordagem tradicional baseada em teste cego? Métrica: # TP - O número de casos de teste (definido pelo professor)
que passou contra o programa submetido pelo aluno na ferramenta de teste cego.
RQ2. Os alunos que adotaram POPT desprendem mais esforço para identificar e corrigir falhas antes de submeter versões?
Métrica: # VS - Número de versões submetidas por aluno.
RQ3. Os programadores POPT gastam mais tempo para entregar a implementação do que os programadores tradicionais?
Métrica:Tempo - O tempo gasto entre (i) o aluno receber uma especificação mal definida e (ii) o aluno submeter um programa para o sistema de teste cego.
53 5.1.1 Participantes
Este estudo foi realizado em uma turma iniciante do curso de Ciência da Computação da Universidade Federal do Rio Grande do Norte, durante o primeiro Semestre de 2012. Os alunos foram divididos em dois grupos, e apenas um grupo foi exposto aos novos conceitos de POPT e TestBoot. Ambos os grupos receberam um problema mal definido e desenvolveram uma solução para ele. Eles poderiam enviar várias versões do código, dentro de um período previamente estabelecido.
Como em nosso estudo, foi necessário comparar duas metodologias de ensino (ou seja POPT contra Teste Cego), optou-se por dividir aleatoriamente os alunos em dois grupos. A fim de avaliar a experiência de cada grupo, foi aplicado um questionário em anexo no apêndice G. Os resultados mostraram que ambos os grupos de alunos iniciantes tinham experiência equivalente. Um total de 30 alunos foi inicialmente previsto para participar neste estudo, mas como o estudo de caso foi conduzido em dias de aula regulares, alguns alunos não assistiram às aulas em que o estudo foi realizado. Resultando em 12 alunos do grupo POPT e oito alunos do grupo de testes cego efetivamente participaram do estudo. Na seção 5.3 discutiremos as conseqüências desta diferença de participantes em cada grupo.
5.1.2 Problema Alvo
Uma decisão importante sobre a definição do estudo de caso foi o desenvolvimento do problema alvo. Ele deve estar no mesmo nível de complexidade que os alunos foram submetidos e não deve requer qualquer conhecimento específico para ser resolvido. O problema alvo escolhido foi o seguinte: Tendo em conta a altura e peso de uma pessoa, o programa deve calcular e retornar o Índice de Massa Corporal (IMC) e com base no IMC calculado e a categoria no MixedMartialArts (MMA) que a pessoa pode tomar parte. Uma especificação mal definida para este programa omitiu como o Índice de Massa Corporal (IMC) deve ser calculado e as categorias de peso.
A complexidade do problema a ser resolvido foi semelhante a problemas propostos ao longo do curso. Para definir esse período nós levamos em consideração a quantidade de tempo disponível para a aula (3 horas), então
54
propusemos um problema que poderia ser resolvido em tal quantidade de tempo. Para determinar esse tempo, três alunos (com habilidades equivalentes aos alunos participantes do estudo) foram convidados a resolver o problema antes da experiência, e levaram aproximadamente 2hs para resolvê-lo.
Considerando o tempo dos alunos convidados para avaliação do problema alvo, foi estabelecido um período total de 3hs para resolução do problema.
5.1.3 Casos de Teste
Neste estudo dois conjuntos de casos de teste foram considerados: (i) o conjunto de testes definido por alunos POPT, e (ii) o conjunto de testes definido pelo professor para avaliar a qualidade externa dos programas submetidos pelos alunos POPT e não-POPT.
Para avaliar a qualidade das soluções implementadas pelos os alunos a este problema, foi desenvolvido um conjunto de testes funcionais. Para construir o conjunto de testes foi aplicado o particionamento de equivalência e a analise dos valores limites. Estes critérios foram usado para selecionar casos de teste representativos do problema, tentando cobrir os requisitos funcionais da especificação. Como resultado obteve-se 52 casos de teste (especificado como uma tabela de entrada e saída esperados para a ferramenta TestBoot como ilustrado no capitulo 2).
Como já referido, os alunos POPT foram estimulados a construir os casos de teste, a fim de esclarecer a especificação mal definida do programa. Como o objetivo principal do desenvolvimento de testes é o de melhorar a qualidade final do produto, independentemente do número de ensaios desenvolvidos, e uma vez que os alunos utilizando a abordagem de teste cego não desenvolveram testes, medimos a eficácia de POPT considerando os testes desenvolvidos pelo professor contra cada versão submetida pelos alunos. Embora seja também interessante
Avaliamos a qualidade e o número de testes desenvolvidos por cada aluno POPT. Para avaliar a qualidade das tabelas de testes submetida pelos alunos, submetemos 10 programas mutantes com diferentes erros no código e verificamos quais foram detectados com falhas. A Tabela 10 apresenta a
55
quantidade de testes submetidos juntos com a última versão e a quantidade de códigos que tiveram erros detectados por cada uma das tabelas de testes submetidas pelos alunos para os 10 programas mutantes.
Tabela 10 Quantidade de testes e códigos com erros detectados
Podemos observar que nem sempre uma maior quantidade garante uma maior cobertura para avaliação de código. Pois o aluno a25 possui um total de 18 testes que detectaram falhas em apenas 4 códigos mutantes em relação à tabela de testes do aluno a26 que detectou falhas em todos os 10 códigos mutantes.
O único aluno que não detectou falha em nenhum código mutante foi o aluno a34, este resultado refletiu diretamente no resultado negativo no código submetido pelo aluno que passou em apenas 1 teste.
Desta forma, apesar dos alunos terem realizados testes com algum certo grau de qualidade, é perceptível a necessidade de realizar atividades para elaborar tabelas de testes para adquirir habilidades de um testador.
5.2 Resultados do Estudo
As Tabelas 11, 12, 13 e 14 apresentam alguns dos dados recolhidos durante este estudo empírico para alunos POPT e não-POPT. As tabelas 11 e 12 ilustram todos os tempos de envio (tempo) e os números de Testes que passaram de cada versão (# PT) por sujeito (por exemplo, a29 representa um ID de um aluno). As Tabelas 13 e 14 apresentam os tempos de envio para a
56
primeira, a segunda, a terceira, e a última versão, e a percentagem de Testes que passaram (ver coluna % PT) para auxiliar a análise. As Tabelas 11 e 12 referem-se a alunos POPT enquanto que as tabelas 13 e 14 referem-se aos alunos não-POPT.
Tabela 11 POPT: tempo x testes.
57
Tabela 13 POPT: versões x testes x tempo
Tabela 14 Não-POPT: versões x testes x tempo
As Tabelas 13 e 14 também mostram a percentagem de Testes que passaram para cada versão - tais testes são os definidos pelo professor e cegamente executados depois o envio de cada versão. Estas tabelas também ilustram o número de versões submetidas por todos os alunos (ver coluna # SV). A média e a mediana relacionada com as versões submetidas são mostrados na Tabela 15.
58
Tabela 15 Versões: POPT x Não-POPT
Nas próximas seção,elaboramos respostas para as questões de pesquisa indicados anteriormente por meio da análise dos dados recolhidos durante este estudo. Resultados de medição adicionais a respeito dos testes desenvolvidos por alunos estão disponíveis nos anexos.
5.3 Discussões
A. Pode POPT ajudar os alunos a obter implementações mais corretas do que a abordagem tradicional baseada em teste cego?
Se considerarmos apenas a primeira versão submetida, que elimina o efeito do feedback fornecido pela ferramenta de teste cego, podemos observar que implementações POPT alcançaram em média, mais que o dobro de qualidade do que implementações não-POPT (considerando-se o número de testes que passaram como uma métrica para qualidade). Em média, 60,74% dos testes passaram quando executados contra as primeiras submissões POPT, enquanto apenas, em média, 24,49% dos testes passaram quando executados contra as primeiras submissões não-POPT.
No entanto, ao longo de sucessivas submissões pudemos observar que a diferença entre os programas POPT e não-POPT diminui. A Figura 25 ilustra a percentagem de testes que passaram durante as submissões dos alunos POPT e não-POPT.
59
Figura 25 Testes x Tempo: (a) primeira versão (b) última versão
Para nossa surpresa, na última versão dos programas, os alunos não- POPT conseguiram uma qualidade ligeiramente superior (expressa pelo número de testes que passaram) quando comparados aos alunos POPT. No entanto, essa qualidade só pode ser alcançada, porque eles estiveram usando a ferramenta teste cego como uma forma de estar constantemente avaliando a qualidade do seu código. Podemos perceber que este foi um problema ocasionado pelo design do estudo que permitiu aos alunos receberem feedback da ferramenta de submissão para qualquer versão submetida. Esta característica levou a um comportamento inesperado (alunos realizando um número excessivo de submissões, em média 16 versões) que não havia sido contemplado durante a fase de design: alguns alunos utilizaram a ferramenta de teste cego para descobrir se seus programas estavam corretos.
No entanto, a abordagem de teste cego não permitiu aos alunos desenvolverem seus próprios casos de teste, quando o programa apresentava falhas, eles só tinham pouca informação sobre a(s) causa(s). Como conseqüência, eles não entendiam como os testes foram criado ou porque seus programas não passavam e, portanto, não sabiam quais mudanças eram necessárias, mesmo tendo o mesmo retorno de erro dos testes cegos que os
60
alunos POPT, estes tinham as suas próprias tabelas de testes para orientar o desenvolvimento de sua solução. Como resultado, pudemos observar que os alunos faziam mudanças sem qualquer raciocínio por trás deles, fazendo com que o percentual de testes que passava entre uma versão e outra declinasse bruscamente. A Figura 26 ilustra a forma como a percentagem dos testes que passavam evolui ao longo do tempo. Podemos ver que, em alguns casos, as alterações feita por alunos não-POPT causava uma diminuição brusca do número de testes que passavam (esses casos são ilustrados pelo tracejado nas linhas dos alunos não-POPT). No caso mais extremo, um aluno submeteu códigos quase idênticos mais de 15 vezes, na esperança de passar nos testes. Exigir que os alunos criassem seus próprios testes poderia evitar ou mesmo reduzir tais erros.
Figura 26 Testes x versão: (a) Não-POPT (b) POPT.
B. Os alunos adotando POPT submetem menos versões do que os que utilizam abordagem tradicional?
Da Tabela 15, podemos ver que o número de versões submetidas por alunos não-POPT é em média duas vezes maior que o número de versões
61
submetidas por alunos POPT. Alunos não-POPT submeteram, em média, 13,75 versões (desvio padrão = 5,52), enquanto que os alunos POPT submeteram, em média, 7,08 versões (desvio padrão = 5,37).
Essa observação apóia o argumento que os alunos POPT gastam mais tempo pensando sobre os valores esperados para o programa, a fim de melhor compreender o problema e consequentemente implementar um código de melhor qualidade.
C. Os programadores POPT gastam mais tempo para entregar a implementação do que programadores tradicionais?
Da Tabela 16, podemos observar que os alunos passam POPT gastam mais tempo para submeter à primeira versão do que os alunos não-POPT. Alunos não-POPT levaram, em média, 45,98 minutos para submeter à primeira versão, enquanto os alunos POPT levaram, em média, 100,51 minutos para submeter à primeira versão. As medianas foram 32,47 minutos e 87,05 minutos para alunos não-POPT e POPT, respectivamente. No entanto, apesar de gastar mais tempo para submeter à primeira versão, os alunos apresentaram maior qualidade nas implementações, tal como apresentado anteriormente.
Tabela 16 Tempo x testes: POPT x Não-POPT
Considerando todos os argumentos, os alunos passaram quase o mesmo tempo, para proporcionar um programa com qualidade equivalente. Alunos POPT gastaram, em média, 153,92 minutos até a última versão, enquanto os alunos não-POPT gastaram em média 136,07 minutos. Tais valores de tempo foram limitados pelo espaço de tempo dedicado para a turma, cerca de 3 horas e a complexidade do problema proposto que permitiu uma aproximação dos testes que passaram para ambos os grupos.
62