Resumo

De Stoq Wiki
Ir para: navegação, pesquisa
Reunião realizada no dia 20/01/2006, com os resultados da pesquisa feita por Rudá Filgueiras e Grazieno Pellegrino, para melhor adaptar a suíte de testes à realidade do desenvolvimento da plataforma stoq.

Reunião iniciada às 09:40 e terminada às 11:20.

Características iniciais sobre teste de software levantadas por Rudá:
<verbatim>
10:45 < ruda_porto> primeiro: um bom teste é aquele que encontra o maior número de bugs
10:45 < ruda_porto> Testar para alguns é mostrar que um programa não contém bugs
10:46 < ruda_porto> Porém a postura correta é: Testar é a tarefas de descobrir os bugs existentes em um software
10:47 < ruda_porto> E disso implica que não se deve testar apenas com dados válidos e esperados, mas também com dados inválidos e nesperados
10:48 < beyond> procurar verificar os dados invalidos com toda certeza nos remeterá a analises de areas do sistema que muitas vezes podem comportar de forma obscura
10:48 < ruda_porto> Outra coisa importante: É impossível testar completamente um programa e garantir que ele não contenha erros
</verbatim>


A meta principal da equipe de testes pode ser resumida abaixo:
<verbatim>
10:52 < ruda_porto> Como é impossível testar de forma completa, a postura de encontrar o maior numero de bugs é que traz retorno como objetivo
10:54 < ruda_porto> Mas a implicação economica de que não se pode testar tudo é a seguinte: devemos ter uma estratégia de escrever testes que tenham maior retorno em relação ao que é mais crítico e que descubra mais problemas o quanto antes
10:58 < ruda_porto> Mas só pra fechar um conceito sobre teste: Garantir que o software faça o que ele foi projetado para fazer e mais do que isso, não faça nada além, ou seja, não gere efeitos colaterais.
</verbatim>

Considerações sobre a qualidade dos testes:
<verbatim>
10:54 < jdahlin> ruda_porto: o numero de linhas num test não é propercional para quantas linhas ele testa
10:55 < ruda_porto> Isso é a implicação economica: tempo e recurso para focalizar em quais testes devem ser priorizados e qual o foco deles
10:55 < jdahlin> ruda_porto: os gui tests é bem pequenas mas teste muito codigo
10:56 < ruda_porto> jdahlin, ele executa muitos código, mas o que ele testa mesmo? Ou seja, executar é um teste, mas isso não garante muitas coisas
10:56 < ruda_porto> Garante que o código roda.
10:57 < beyond> estou de acordo com esse ponto de vista: devemos focar em testar o maximo possivel de rotinas criticas e também aquelas usadas com maior frequencia mas isso tambem implica em cuidarmos da qualidade do codigo de testes
</verbatim>

Testes para a parte gui
<verbatim>
10:58 < beyond> primeiro: verifica se as interfaces nao quebram, o que já é bastante teste
10:59 < beyond> segundo: ao finalizar ao abrir um dialogo, avancar num passo de um wizard, ou mesmo finalizar um dialogo, estamos testando um numero imenso de rotinas nas classes de dominio, interacoes com kiwi e base de dados. Se todo o processo é finalizado sem quebra já temos um bom passo inicial assegurado
11:00 < ruda_porto> beyond, Eu concordo que testa muita coisa, mas estou apenas querendo qualificar mais como podemos verificar também as coisas e não achar que o fato de não quebrar nada é suficiente para que o sistema esteja integro e atendendo aos requisitos
11:01 < beyond> ruda_porto, claro, é como eu disse, é um bom passo inicial mas precisamos de mais. O ultimo ponto que voce destacou com certeza é de grande importancia nesse processo
</verbatim>

Considerações de Grazieno sobre a pesquisa:
<verbatim>
11:05 < grazieno> o q eu li tem mais a ver com a qualidade do software
11:05 < grazieno> e como definir processos q podem geridos, medidos e melhorados para testar software
11:06 < grazieno> das pesquisas, vi q boas organizacoes gastam 80% do tempo em prevencao
11:06 < grazieno> e q mas organizacoes gastam 90 % do tempo corrigindo os sintomas
11:06 < grazieno> temos q atacar a doenca e nao os sintomas delas
11:08 < grazieno> pude perceber q a qualidade do software depende '''muito''' da qualidade do processo em q ele foi definido
11:08 < grazieno> e mesmo esses processos podem e devem ser melhorados
11:08 < grazieno> ruda sugeriu documentar todos os modulos de dominio com arquivos .dia
11:08 < beyond> não creio que falte muito para chegarmos num nível de qualidade satisfatorio de nossos testes.
11:09 < grazieno> para entedermos melhor o q esta acontecendo e realmente ter uma documentacao tecnica boa a respeito
11:09 < beyond> 1- continuar com os estudos sobre testes e verificarmos o quanto podemos aprimorar nosso processo e a qualidade dos testes escritos e
11:10 < beyond> 2- escrever mais testes, revisarmos mais codigo com maior frequencia e capturarmos um numero cada vez maior de bugs em nossa suite de testes
11:10 < beyond> por isso acho que essa uniao entre: estudo, discussao, documentacao e codigo vai nos fazer muito bem
11:10 < grazieno> um processo imaturo de processo de qualidade eh ad hoc, improvisado, indisciplinado e fortemente dependente das pessoas q fazem eles
11:10 < ruda_porto> henrique, quem não sabe o que quer pode ir a qualquer lugar
11:11 < grazieno> um processo maduro eh um processo conhecido por todos, em q todos concordem, e tem o apoio dos  gestores
11:11 < grazieno> tem papeis e responsabilidades claramente definidos
11:12 < grazieno> enfim, adorei essa ideia de embasarmos melhor a parte de teste da suite stoq, acho q estamos no caminho certo
</verbatim>

Diferenças entre o processo criativo de produção e o processo destrutivo de teste de software:
<verbatim>
11:14 < ruda_porto> O processo de testar deve ser encarado como um processo destrutivo
11:17 < ruda_porto> Um exemplo de teste, é o que o INMETRO faz com brinquedos, jogando por alto para ver se quebra e a criança então poderia comer ou se machucar com os pedaços
11:17 < ruda_porto> Então de certa forma temos que expor o código a provas
11:18 < ruda_porto> Um bom teste, seria aquele que encontra os problemas, pois como se sabe, não existe software livre de bugs
</verbatim>

10 Príncipios dos testes de software:

Principio 1)
<verbatim>
11:20 < ruda_porto> 1) É necessário definir no test case o resultado esperado ou a saída de dados esperada.
11:20 < ruda_porto> - descrição dos dados de entrada
11:20 < ruda_porto> - descrição da saída correta para esse conjunto de dados
11:21 < ruda_porto> Esse pode ser um erro comum, pois sem definir como deveria ser a saída, o teste fica sem ter como avaliar o resultado final
</verbatim>

Principio 2)
<verbatim>
11:22 < ruda_porto> 2) Quem escreve o código deve evitar de escrever os testes para o seu próprio código
11:23 < ruda_porto> - Como criar código necessita de uma postura construtiva, é difícil mudar de postura e passar a ter uma postura destrutiva
11:24 < ruda_porto> - Se o código contém erros por falta de entendimento das especificações, o mesmo vai se repetir nos testes
11:25 < ruda_porto> - O programador pode inconsientemente não querer encontrar erros por receio dos parceiros, chefe ou cliente
11:26 < ruda_porto> Não é totalmente impossível ou inviável você testar seu próprio código, apenas isso implica que é mais efetivo se outra pessoa o fizer.
</verbatim>

Principio 3)
<verbatim>
11:56 < ruda_porto> 3) Uma empresa de desenvolvimento não deveria testar seu próprio software.
11:57 < ruda_porto> - Esse seria o idel, ou seja, seria o mais efetivo, e está muito relacionado com a forma de desenvolvimento do software proprietario
11:58 < ruda_porto> - Existe um conflito entre prazos e custos que podem ser controlados num projeto
11:58 < ruda_porto> - Mas é difícil prever a qualidade do resultado
12:00 < ruda_porto> - Os testes e o que eles geram de necessidade, podem ser vistos como um problema para manter os prazos e os custos do projeto, e assim não serem aplicados da forma mais aprofundada
</verbatim>

Principio 4)
<verbatim>
12:01 < ruda_porto> 4) Analisar de forma detalhada os resultados dos testes
12:02 < ruda_porto> - Nesse caso ele se refere a ter muita atenção ao analisar a saída gerada por um determinado teste.
12:03 < beyond> implica também em o revisor do codigo do teste ser o  competente o suficiente para saber se o teste é profundo o bastante
12:03 < ruda_porto> Nesse caso teríamos que ter uma forma de ver o que foi colocado como input e depois ver o que foi gerado como saida do processo, para poder verificar se o teste está corente, mesmo que esteja passando
12:04 < ruda_porto> beyond, isso também, a revisão vai precisar do entendimento dos requisitos e como assim entender se eles estão sendo mesmo avaliados no teste
12:06 < beyond> e teriamos tambem de aprimorar os criterios de revisao destes testes e aumentar o rigor da revisao
</verbatim>

Principio 5)
<verbatim>
12:08 < ruda_porto> 5) Os teste cases devem ser escritos para condições de entrada inválidas e inesperadas, assim como para aquelas válidas e esperadas
12:09 < ruda_porto> - Existe uma tendêcia de se testar apenas aquilo que dá certo
12:10 < ruda_porto> - Muitos erros são econtrados quando o programa é usado de forma nova e inesperada (coloque um usuário destruidor para usar o software) hehe
12:10 < ruda_porto> - os teste coases com dados inváldos encontram mais erros que aqueles com dados válidos
12:11 < beyond> henrique, mas ainda assim creio que seja boa ideia testarmos tambem nas classes de dominio. As vezes uma pequena mudança na interface pode abrir espaço para um bug em potencial
12:12 < ruda_porto> beyond, isso também é verdade, as classes de domínios e o próprio banco de dados devem ser consistentes e garantir essa consistência
12:12 < ruda_porto> beyond, então neste caso seria um teste na classe de domínio
</verbatim>

Sugestão de nova política de bugs:
<verbatim>
11:26 < beyond> Humm, percebo que já deveriamos ter definido uma politica de que para cada novo bug aberto, referente a feature nova, um bug de teste deverá ser aberto para o mesmo, associado a outra pessoa
11:27 < beyond> e acho até que os dois bugs deveriam ser resolvidos no mesmo planejamento para evitar sair release com bugs. henrique ? o que acha ?
11:29 < henrique> não sendo realmente o próprio autor do fix que implemente o teste, concordo
11:30 < henrique> e outra coisa que eu acho que eles deveriam levar em consideração é entender o fluxo completo de uma determinada execução... como cadastro de filiais, gerenciamento de estoque e etc etc etc
11:31 < ruda_porto> Ou seja, ao encontrar o bug, e ao ser definida o novo requisito, se escreve o teste que falha, e depois o código de fix é escrito para que o test passe?
11:31 < beyond> henrique, concordo, mas para isso teriamos de documentar um pouco mais sobre esses fluxos em nosso wiki ou em alguns casos no proprio bugzilla
</verbatim>

Considerações sobre como documentar melhor os bugs e realizar testes de acordo com essa documentação:
<verbatim>
11:32 < henrique> ruda_porto: nesse caso vocês estariam na nossa frente, desed que vocês teriam que implementar os tests pra só dps a gente escrever a implementação no stoq
11:32 < ruda_porto> beyond, guiado pelo teste, ou seja você primeiro sempre escreve o teste e depois o codigo
11:33 < ruda_porto> beyond, na verdade sobre documentar os fluxos, isso é uma necessidade para escrever testes funcionais ou black-box teste
11:33 < beyond> ruda_porto, isso fica meio complicado quando voce está implementando um wizard, um relatorio ou dialogo
11:33 < beyond> ruda_porto, e aumenta o tempo que gastaremos aqui pra resolver os bugs
11:33 < beyond> ruda_porto, sem falar que nossa equipe está um pouco mais reduzida agora com a saída do Bruno Garcia
11:34 < beyond> teremos de encontrar uma solução que não será excelente mas que nos atenderá bem
11:34 < ruda_porto> beyond, eu sei que isso não está documentado por falta de tempo, mesmo assim temos que pensar em como testar e já que temos que entender como deveria funcionar as coisas, acho que devemos aproveitar para documentar isso.
11:35 < ruda_porto> beyond, nesse caso acho que doc tests podem ser muito úteis
</verbatim>


Qual a estratégia de documentação usar:
<verbatim>
11:36 < beyond> quanto a simplesmente documentar alguns bugs mais criticos isso eu já acho que seja perfeitamente possivel. Basta o autor de um patch anexar sempre um link para uma breve documentacao no wiki que será usado pelo desenvolvedor de testes
11:37 < beyond> mas nao creio que isso precise ser uma regra geral. Há bugs que são muito simples e possivelmente uma breve explicacao no corpo do bug, ou mesmo o comentario de abertura já seja util para quem for escrever o teste
11:37 < henrique> é mesmo necessário? o próprio bugzilla já não abre espaço pra documentação da implementação?
11:37 < ruda_porto> beyond, henrique, isso é um pouco diferente: existe o caso de um bug e o teste para ele
11:38 < ruda_porto> mas a suite em geral, deve focar em verificar se o sistema atende aos requisitos, mas não temos documentados os requisitos
11:38 < henrique> ruda_porto: para implementar o teste vc pode olhar na página de implementação do bug...
11:39 < beyond> henrique, eu disse para casos especiais, com complexidade elevada
11:39 < beyond> o wizard de venda é um tipico caso que precisaria de algo desse tipo
11:39 < beyond> uma documentacao wiki seria mais apropriada pois ficaria lá para qualquer visitante do site do projeto.
11:39 < ruda_porto> henrique, isso pode ser, mas depois é importante peneirar essa informação e consolidar em algo que apenas descreva como as coisas foram pensadas e deveriam funcionar
11:40 < beyond> "voce quer entender sobre as classes de pagamento? entao va no bugzilla, ache o bug do wizard de vendas e olhe os comentarios lá"
11:41 < henrique> beyond: não, todos esses bugs seriam reunidos para formar o wiki depois...
11:42 < beyond> henrique, ok, mas concorda que com um pouco mais de trabalho teriamos já algo definitivo ? e nao é pra tudo nao, fique frio
11:42 < ruda_porto> beyond, henrique mas abstraindo as classe e o código, existe o processo de pagamento e como o sistema se comporta nesse processo?
11:42 < henrique> beyond: a idéia é não ter que construir o wiki como faziamos.. e sim algo como: resolva o bug, explique sua idéia, discuta e feche-o... no final colamos tudo isso e temos o processo inteiro descrito
11:44 < henrique> beyond: por mim tudo bem... mas eu ainda acho que escrever sobre uma parte de um processo no wiki, vc o deixa inacabado... enquanto discutindo a estratégia no bugzilla, vc documenta a parte relevante e vc pode ir "juntando" tudo pra ter uma visão melhor do todo
11:45 < beyond> "ruda_porto> beyond, nesse caso acho que doc tests podem ser muito úteis" não para wizards, dialogos complexos e relatorios. Aí nesse caso creio que entra uma documentacao, seja via bugzilla ou wiki, e testes de gui depois
11:45 < beyond> henrique, voce até que esta certo. Poderiamos colocar tudo no wiki logo no momento de fechar o bug, pra mim tanto faz
11:45 < beyond> aí depois é só adicionar um link da pagina no bug
</verbatim>

Há necessidade de se documentar os processos que o software realiza, para realizar melhores testes:
<verbatim>
11:45 < ruda_porto> beyond, henrique: quando eu ou grazieno estamos escrevendo testes para determinado módulo, nós precisamos saber o que foi definido que aquele módulo faz ou deveria fazer, e como isso ainda não existe, a idéia é documentar esse processe e assim inclusive vai ser uma forma de formalizar o que se espera que o sistema faça ou não
11:46 < beyond> mas entenda que há casos que sao tao complexos que exigem uma documentacao inicial para que possamos começar a discutir num grau adequado de profundidade
11:46 < ruda_porto> beyond, o fato é que isso em alguns casos está em um bug e em outros em vários
11:47 < ruda_porto> beyond, exatamente, tem casos que é preciso ter uma noção incial para sair da estaca zero
11:48 < henrique> essa é a questão.. geralmente discutimos coisas antes de abrir o bug... e lá dentro vamos validando ela
</verbatim>

Procedimentos listados por Evandro para entendimento de módulos do sistema:
<verbatim>
11:48 < beyond> se vao começar um teste de uma parte do sistema cuja documentacao é inexistente entao procurem a gente e usem os seguintes procedimentos:
11:48 < beyond> 1- reunam informacoes relevantes perguntando pra gente via IRC
11:48 < beyond> 2- se via IRC nao resolve peçam uma descricao via e-mail
11:49 < beyond> 3- se via e-mail ainda não é bom, peçam que alguem responda a determinada duvida via bugzilla
11:49 < beyond> 4- se ainda assim a coisa tá feia peça a alguem daqui para adicionar documentacao sobre aquele feature no wiki
11:50 < beyond> em geral a opcao 4 será mais complicada pois estaremos muito ocupados aqui. Sugiro que coletem os dados com a gente e voces mesmos montem essa documentacao no wiki. Daí alguem daqui vai lá e avalia
11:51 < ruda_porto> só quero que esse trabalho de peguntar e entender vire algo depois, ou seja, que eu e grazieno vamos descrever o que entendemos ao coletar isso, assim vamos descobrir se entendemos direito ou não e vai ficar mais fácil apenas alterar quando algo mudar
</verbatim>

Questionamentos sobre o uso do kiwi, para validar a parte gui do stoq
<verbatim>
12:10 < henrique> temos que poder contar com a validação do kiwi em muitas partes para evitar que algo errado chegue nas classes de domínio para processamento
12:11 < ruda_porto> henrique, neste caso sim , já que o kiwi é que garante essa parte
12:12 < beyond> jdahlin, mas o Stoq fará uso do kiwi para validar isso
12:13 < henrique> beyond, jdahlin talvez até incluir suporte no kiwi para isso seja uma boa
12:13 < beyond> jdahlin, obviamente fornecendo o metodo de validacao da string
12:13 < beyond> henrique, suporte para que ? do cpf ?
12:14 < henrique> beyond: não só cpf, documentos de uma forma geral
12:14 < ruda_porto> henrique, isso sim, para cada campo onde se pode garantir uma entrada consistente
12:14 < beyond> henrique, cpf é totalmente especifico do Brasil, nao sei como poderiamos incluir isso no kiwi mas talvez alguma infra-estrura para validar documentos seja uma boa
12:15 < henrique> beyond: minha é incluir um "suporte" no kiwi e extender via stoq
</verbatim>

Idéias para implementações no kiwi:
<verbatim>
12:15 < henrique> algo melhor do que "callbacks de validação"
12:15 < ruda_porto> Isso inclui também algo como um lista de estados do brasil ou outro país ao invés de um campo string aberto
12:16 < jdahlin> beyond: funciona para validar é na stoq, mas o framework é no kiwi
12:16 < ruda_porto> mas não como classe de domínio? isso está apenas na interface?
12:16 < jdahlin> stoqlib ou stoq é melhor IMHO
12:16 < beyond> jdahlin, stoqlib
12:16 < henrique> jdahlin: o que estou falando tem bastante haver com o que te falei sobre entrymasks
12:17 < beyond> lembrando que Stoq em breve será um conjunto de "cascas"
12:19 < ruda_porto> henrique, em CityLocation, por exemplo, au acho que deveria ser uma FK para um model Country e State, na verdade isso apenas é uma idéia de como a modelagem pode estar garantindo a consistência ou não
12:19 < ruda_porto> Na verdade CityLocation -> State e State -> Country
12:23 < beyond> o que precisamos lá, confesso, é um pouco mais de verificação na base de dados de forma a nao deixar termos objetos com dados repetidos
12:23 < beyond> dois objetos city_location com country, city e state iguais. Verificamos isso hoje via interface
12:24 < beyond> mas isso é perfeitamente possivel de ser feito na propria classe CityLocation
12:25 < ruda_porto> Exatamente isso, mas também dois CityLocation um com state São Paulo e outro com state Sao Paulo
</verbatim>

Para a próxima reuniao ficou definido a discusão dos 5 últimos prícipios.