Neste trabalho foi apresentada uma metodologia de ensino de programação orientada a problema e testes para disciplinas de introdução a programação, chamada POPT (do inglês: Problem Oriented Programming and Testing). Esta metodologia é apoiado por uma ferramenta chamada TestBoot, também desenvolvida no contexto deste trabalho. A ferramenta TestBoot foi implementada em C++ e que implementa os conceitos de tabelas FIT (FitNesse) para capacitar os alunos iniciantes na definição de casos de testes de maneira simples. Os casos de testes são representados na forma de dados de entrada e saída de casos de testes em uma simples tabela, não exigindo portanto que os alunos aprendam APIs de frameworks de teste ou alterem a estrutura do programa para permitir o uso de assertivas embutidas no código (como proposto por outras abordagens, como iniciativas de aprendizado orientadas a teste (Janzen e Saiedian, 2006a, 2008a; Hilton e Janzen, 2012) – e que podem dificultar a adoção de testes por alunos novatos.
Com o objetivo de avaliar a eficácia da metodologia proposta, este trabalho apresenta um estudo de caso e um experimento controlado usando o design Quadrado Latino.Nestas avaliações o POPT foi comparada com uma metodologia tradicional baseada em teste cego (Briggs e Girard, 2007), muitas vezes utilizado para a classificação de exercícios dos alunos em cursos de programação. Tanto o estudo de caso quanto o experimento foram realizados em disciplinas de introdução a programação (IP) do programa de Ciência da Computação e Tecnologia da Informação da Universidade Federal do Rio Grande do Norte, durante os períodos 2012.1 e 2013.1 respectivamente. Estes estudos puderam apresentar evidências preliminares da eficácia da metodologia POPT.
O estudo de caso 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 grupos receberam um problema e desenvolveram uma solução para ele. Eles poderiam enviar várias versões do código, dentro de um
81
período de 3 horas. 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 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.
A qualidade de cada versão foi avaliada através da execução de um conjunto pré-definido de testes (i.e., um conjunto de testes definidos pelo professor). O número de testes pré-definidos que passavam no código do aluno correspondeu à métrica de qualidade usada no estudo. Através da análise desta métrica e do tempo gasto em cada versão, alguns resultados foram consistentemente detectados através deste estudo:
Em média 60,74% dos testes passaram das primeiras versões enviadas pelos alunos POPT, enquanto apenas em média 22,60% dos testes passaram quando executados nas primeiras versões enviadas pelos alunos não POPT.
Os alunos POPT passaram mais tempo para submeter à primeira versão, quando comparados aos alunos não POPT. Alunos não- POPT levaram, em média, 45.58 minutos (após receber o problema mal definido) para submeter à primeira versão, enquanto que os alunos POPT levaram, em média, 100.41 minutos para submeter à primeira versão. As medianas foram 32.47 minutos e 98.08 minutos para alunos não POPT e alunos POPT, respectivamente.
O número de versões submetidas por alunos não-POPT foram, em média, o dobro do número de versões submetidas pelos alunos POPT. Alunos não-POPT submeteram em média 13,75 versões (desvio padrão = 5,52), enquanto os alunos POPT submeteram em média 7,08 versões (desvio padrão = 5,37).
82
Considerando-se apenas a última versão submetida, em média , 78,04% dos testes passaram quando executados nas versões POPT, enquanto 82,45% dos testes passaram quando executados contra as versões não-POPT. As medianas da métrica foram 92,31% e 94,23% para POPT e não-POPT, respectivamente.
Apesar de, no final do estudo, os valores finais de qualidade para os dois grupos terem sido equivalentes, além de implementar o programa, cada aluno POPT implementou em média cerca de 16 casos de testes. Além disto os alunos POPT (i) apresentaram menos versões que alunos não-POPT, e (ii) passaram mais tempo para apresentar a primeira versão, alcançando nesta primeira versão uma maior qualidade quando comparados aos não-POPT. Esta observação leva-nos a crer que POPT estimula os alunos a pensar melhor sobre o problema proposto e sobre a solução. Uma vez que o grupo de controle não pôde desenvolver seus próprios casos de teste, quando o sistema de submissão alertava que o programa submetido continha falhas (ou seja, quando no momento da submissão da versão os testes do professor eram executados na versão submetida), eles tinham pouca informação sobre a(s) causa(s) da falha. Como conseqüência, como eles não sabiam como os testes foram criados não entendiam por que seus programas não passaram nos testes, portanto, não entendendo como poderiam melhorar a versão submetida. Como resultado, pudemos observar alguns os alunos não-POPT fazerem alterações sem qualquer raciocínio por trás deles, diminuindo drasticamente o percentual de testes bem sucedidos entre uma versão e outra.
Por outro lado, o grupo POPT pode desenvolver as habilidades de testador dos alunos, estimulando-os a desenvolver entradas e saídas nos casos de teste, o que, consequentemente, ajudou-os a desenvolver software de melhor qualidade , já na primeira versão submetida. As habilidades de teste são estimuladas por POPT são ainda mais valiosas quando o aluno enfrenta um verdadeiro cenário de desenvolvimento, em que não há nenhuma ferramenta de teste para confiar.
83
O experimento controlado foi realizado no período 2013.1. Um total de 40 alunos participaram do experimento. Todos alunos de da disciplina introdutória de programação do curso de Bacharelado em Tecnologia da Informação da Universidade Federal do Rio Grande do Norte. Neste estudo utilizamos o design Quadrado Latino e foi possível realizarmos testes estatísticos para avaliar a influência da metodologia e dos demais fatores nos resultados obtidos. Aplicamos o ANOVA, e considerando o p-valor como elemento indicador da influência das metodologias nos resultados apresentados e seguindo a convenção de se considerar como sendo um fator significativo para a variável resposta quando p <0,05 (Box, Hunter e Hunter), podemos concluir que a metodologia POPT influencia ou positivamente na qualidade dos programas gerados pelos alunos com relação à abordagem Teste Cego (p=0,00162). Os demais fatores (problema, réplica, e replica:aluno) não tiveram influencia significativa no estudo p>0,05. Este foi um resultado bastante positivo deste segundo estudo, que pode ser utilizado para suportar os resultados do estudo de caso, no que diz respeito à qualidade dos testes gerados através da metodologia POPT.
8.1 Trabalhos Futuros
Considerando as contribuições alcançadas, podemos destacar vários desdobramentos para o nosso trabalho. Trabalhos futuros podem ser desenvolvidos tanto no contexto da abordagem proposta, quanto às ferramentas envolvidas, ou em estudos experimentais. Podemos citar os seguintes trabalhos que podem evoluir a partir deste:
Replicações do experimento:
Com o objetivo de melhor avaliar os benefícios do POPT, pretendemos replicar o experimento na UFRN e outras instituições de ensino.
Realização de experimentos em disciplinas mais avançadas: Em geral os conceitos de teste são vistos no quarto período do curso, seria interessante avaliar os benefícios da metodologia quando aplicada a alunos mais experientes.
84
Avaliação da qualidade dos testes submetidos:
Podemos adicionar a ferramenta de submissão uma nova funcionalidade para analisar o conjunto de testes desenvolvidos pelos alunos. Assim podemos reforçar a prática de testador com atividades exclusivas de elaboração de casos de testes.
Tratamento para outras linguagens e outros tipos de interface: A ferramenta TestBoot pode evoluir para avaliar mais linguagens de programação além de C/C++. Hoje a ferramenta é utilizada através de linha de comando. Podem ser desenvolvidas interfaces Web ou stand- alone (baseadas em janelas), ou mesmo integradas a IDEs de desenvolvimento (e.g., Plugin para Eclipse).
Estender a ferramenta para teste de cada método:
Atualmente o TestBoot avalia dados de entrada e saída do console, em outras palavras, cada célula possui um valor a ser lido ou escrito no console. Seria interessante modificá-lo para considerar valores de parâmetros de métodos e valores de retorno nas células da tabela criada pelo aluno.
85