Introduzindo um (novo) método de teste para uma equipe [fechado]

4

Um par de meses atrás eu fui contratado em um novo emprego. ( Estou acabado de sair do meu mestrado em engenharia de software )

A empresa consiste principalmente de consultores de ERP, mas fui contratado em seu departamento de Web relativamente pequeno (6 desenvolvedores), nossa principal tarefa é a integração de ERP / ecom ( web shops integradas ao ERP ). / p>

O departamento está crescendo, e recentemente meu gerente me pediu para começar a pensar em introduzir testes para a equipe , eu amo um desafio, mas francamente estou com um pouco de medo (eu sou o menos membro experiente da equipe).

Atualmente, o método de teste é clicar na loja on-line e perguntar ao cliente se os produtos estão lá, se parecem bem e se os pedidos são enviados corretamente para o ERP.

Estamos recebendo muitos casos de suporte em projetos anteriores, nos quais um cliente ou cliente de um cliente encontrou erros, o que, suponho, é o motivo pelo qual meu gerente deseja testes mais estruturados.

Pensando em algumas melhorias (óbvias?), como observar a especificação de requisitos, ter um rastreador de problemas, permitir que os membros da equipe registrem seu tempo em uma linha de "testes" sobre o orçamento, e para distribuir tarefas entre os membros da equipe.

Mas, a meu ver, temos três desafios principais:

  1. testes gerais de sites . (testes de integração javascript, c #, asp.net e cms)
  2. (ao vivo) teste de integração de ERP (os clientes raramente querem pagar por ambientes de teste).
  3. adotando um método na equipe

Eu gosto da responsabilidade, mas estou com medo de estar um pouco acima da minha cabeça.

Espero que meu gerente espere que eu configure um tipo de workshop para a equipe em que apresento algumas técnicas e ideias e onde nós (a equipe) podemos encontrar algumas soluções em conjunto.

O que eu aprendi na escola foi principalmente testes unitários e verificação de programas, e não muitos testes em vários sistemas e aplicativos.

O que eu estou procurando aqui, é referências / conselhos / ponteiros / anedotas; qualquer coisa que possa me ajudar a ficar mais inteligente e melhorar o método atual da minha equipe.

(TL; DR: leia as partes em negrito)

    
por jolt 08.09.2012 / 17:11
fonte

4 respostas

6

Evoluindo a cultura da equipe

Esta pode ser a parte mais difícil de implementar processos de teste na sua organização. Cada equipe reage à mudança de maneira diferente. Algumas pessoas abraçam a oportunidade de tentar algo novo, e algumas são perfeitamente felizes em seus caminhos e não vêem razão para mudar. Eu posso te dizer isto: ninguém gosta de um fascista . Forçar as pessoas a fazer as coisas de uma certa maneira provavelmente gerará mais resistência.

Veja algumas dicas para apresentar mudanças em sua organização:

  • Forneça evidências empíricas, como "Recebemos o bug X antes de entregá-lo ao cliente e levamos oito horas para corrigi-lo. O cliente detectou um bug Y um mês depois da entrega e levou uma semana para corrigir isto." Editar: vejo que você mencionou que seu cliente pode estar preocupado com os custos de um site de teste. Veja se você pode provar que pegar os bugs antecipadamente economizará o dinheiro do cliente.
  • Mostre aos desenvolvedores como as novas ferramentas funcionam. Muitos de nós somos desenvolvedores porque pensamos que a tecnologia é divertida. Tente compartilhar novas ferramentas / processos de teste, como novos brinquedos para jogar.
  • Não coloque seu coração em uma única solução. Deixe a equipe experimentar várias tecnologias. Para o teste automatizado de interface do usuário, você pode usar o TFS, o Selenium, passar manualmente por scripts de teste ou outras opções. Manter a porta aberta para diferentes tecnologias permite que a equipe descubra quais ferramentas são boas, e também incentiva um processo democrático que promova uma propriedade compartilhada da tomada de decisões. Incentive discussões abertas com a equipe de desenvolvimento.
  • NÃO espera que tudo mude de uma só vez. Tente se concentrar em uma coisa de cada vez. Aqui está um exemplo de quebra de mudança em etapas menores:
    1. Escreva alguns testes de unidade para o código do servidor que verificam se a funcionalidade crítica do sistema funciona conforme pretendido
    2. Crie uma VM de teste que duplique o ambiente operacional de seu produto
    3. Documentar casos de uso que podem ser usados para testar a GUI
    4. Combine o código do servidor e o código do cliente em um único repositório no TFS para que a versão mais recente seja facilmente identificável, testável e capaz de ser implementada
    5. Iniciar a execução do teste de caso de uso sempre que novos componentes forem confirmados (automatizados ou manualmente)

Estas são apenas algumas tarefas de exemplo. Pode levar semanas para chegar onde você quer estar; isso pode levar meses. Como exatamente a sua equipe adota os processos de teste dependerá da sua cultura. Por último mas não menos importante,

  • NÃO desista, mas seja educado e amável sobre isso. Se você continuar sugerindo maneiras de aprimorar os processos de teste, a equipe de desenvolvimento pode tentar algumas de suas sugestões em um dia lento, apenas por curiosidade.

Solução técnica

Eu gostaria de poder fornecer algumas informações melhores sobre soluções técnicas para sua situação. Eu trabalho em tempo parcial em uma loja .NET, e posso dizer que usamos exclusivamente o TFS para integração contínua, ou seja, controle de versão para código cliente (EXTJS com ASP.NET MVC 3) e código de servidor (C # w / Entity Framework ), UI automatizada e testes de unidade no ramo de release, e implantação automatizada em um site de teste e um site de demonstração (que será o nosso site de produção eventualmente). Como mencionei acima, sua (s) solução (ões) técnica (s) específica (s) dependerão em grande parte da cultura da sua organização.

Boa sorte!

    
por 08.09.2012 / 22:36
fonte
5

Você tem várias opções, mas é aqui que eu começaria. Lembre-se, eu venho do mundo de java, mas um site deve ser um site, na verdade.

  1. Teste de sites: O Selenium é uma ferramenta fantástica para testes de scripts contra sites.
  2. Virtualize: você pode duplicar seus ambientes no VMware ou no VirtualBox e salvá-los. Quando você quiser fazer seus testes de sistema / integração, carregue o ambiente apropriado e execute os testes.
  3. Metodologia: Teste ágil: um guia prático para testadores e equipes ágeis tem vários bons conselhos sobre isso frente. Eu sugeriria começar com algo bem simples, ver como funciona e revisar adequadamente.
por 08.09.2012 / 20:31
fonte
4

Acho que a primeira pergunta aqui é o que você espera sair do teste. Eu uso testes como uma ferramenta de design - código que é fácil de testar é geralmente um bom código - e como uma rede de segurança. Parece que o que você quer é uma rede de segurança.

Se você quiser uma rede de segurança, você deve ter um ambiente de teste. Você não quer executar testes em seu ambiente de produção. Por um lado, isso significa que você está implantando código que você acha que pode ser quebrado em produção. Por outro lado, você não pode controlar os dados ou controlar o acesso também. Para outro ainda, significa que você está implementando código que você acha que pode ser quebrado em produção . Isso é loucura, pura e simples, e há maneiras melhores.

A próxima pergunta é o que testar. A equipe precisa ter uma estratégia de teste e, quando algo é implementado, deve haver uma compreensão de quais testes precisam ser escritos. Uma das razões pelas quais eu sou fã do Test Driven Development é que os testes são escritos simultaneamente com o código, então os testes não são vistos como um tipo de sobrecarga que todo mundo tem que suportar, e você tem alguma garantia de que o que precisa ser testado é testado porque tudo é testado. Você pode considerar se é plausível implementar o TDD em sua loja ... é possível que seus colegas desenvolvedores considerem isso se escrever e executar testes fosse fácil?

Anedotamente, eu fui capaz de convencer uma equipe a ir com TDD e CI simplesmente apontando algumas coisas: Primeiro, todos nós fazemos TDD o tempo todo, de qualquer maneira. Antes de escrever código, você tem a intenção e depois de escrever o código, você geralmente verifica se ele corresponde a essa intenção. TDD é o processo de colocar sua intenção em teste para que você saiba que o código que você escreve amanhã não viola a intenção que você teve ontem. Segundo: é possível evitar que seu gerente / cliente peca em você por quebrar algo simplesmente por ter um ambiente de teste. Isso elimina muitos problemas de sua vida quando essas pessoas não estão reclamando o tempo todo.

Se você tiver tempo / espaço para isso, considere a possibilidade de configurar um ambiente de IC adequado para demonstrar ao grupo. Saber que eles podem fazer isso não é tão legal quanto saber que você pode fazê-lo para .

No que diz respeito aos detalhes da implementação, parece que você pode se beneficiar da leitura da "Integração contínua em .NET no " da Manning Publications e talvez este post do codebetter em teste de selênio com .net Para TDD, confira " Desenvolvimento Orientado a Testes no Microsoft .net "da Microsoft.

    
por 08.09.2012 / 20:05
fonte
4

Acho que o maior obstáculo que você enfrentará (e enfrentará constantemente por algum tempo) é a resistência. Anos atrás eu introduzi compilações noturnas e lançamentos automatizados internamente e impedi que os desenvolvedores checassem os binários compilados e tentavam desencorajá-los de mover o código diretamente para os sites dos clientes. Fiquei surpreso com o quanto eles reclamaram sobre a espera pelo código ser testado pelo QC, a relutância em escrever qualquer tipo de teste de unidade básico e como eles continuam contornando os processos e movendo o código manualmente. Pode ser desanimador ver como as pessoas relutantes podem migrar para um processo que é realmente melhor para a estabilidade do produto. Mas você tem que ficar com o seu plano. Mover código manualmente e não verificar mudanças é uma loucura.

Se a administração tiver a sua volta, você só precisa prosseguir com uma coisa de cada vez. Primeiro, faça com que eles verifiquem todas as alterações em um único repositório e tenham tudo compilado a partir desse repositório. Sério, tudo deveria estar sob controle de versão. Tudo deve ser compilado por um servidor. Depois de criar construções, introduza testes automatizados.

A pergunta é emoldurada com a ajuda de testes que ainda estou aprendendo, mas parece que você nem sequer tem um processo adequado de criação e lançamento. Apenas uma pequena parte do nosso produto usa qualquer tipo de teste automatizado e esse é o nosso material Java. Uma tarefa de IC é executada e envia um email para o último desenvolvedor para confirmar se um IC falhar. Além disso, não há outro tipo de teste automatizado.

Portanto, construir e liberar é algo com o qual tenho experiência. Eu tive que escrever do zero um processo de compilação e release para uma loja que verificaria os binários compilados e os scripts sql para o VSS e, em seguida, passaria esses binários ou scripts manualmente para os clientes. Eu usei NAnt w / NAntContrib para compilar vb6 e .Net e depois Ant para o nosso material Java. VSS foi despejado para SVN. Inicialmente, eu tinha o CruiseControl.NET para gerenciar o CI, mas recentemente mudei para o Jenkins. O CC.Net não estava lidando com CI muito bem e eu mudei de frustração. Eu usei NAnt para implantar o código para nossas áreas de dev e QC internamente com builds noturnos. WiX (Windows Installer XML) para instalar / atualizar clientes.

Eu me deparei com um livro que eu vou ler apenas para obter algumas idéias, chamado How Google Tests Software, de James Whittaker. Eu realmente quero fazer testes automatizados na minha empresa também e com todo o trabalho que tenho que fazer é um processo contínuo. Boa sorte para você cara!

(Ah, e nós usamos o JIRA para rastreamento de problemas e já estávamos usando o Serena TeamTrack. Nem me surpreende, mas acho que nosso material do JIRA não está implementado corretamente)

    
por 09.09.2012 / 05:41
fonte