Como você integra testes de sistema em um processo ágil?[fechado]

Question

As descrições clássicas de desenvolvimento ágil possuem código liberável no final de uma iteração.Se houver mais testes e validações necessários para criar um produto lançável, como você integra isso ao processo?

Answer 1

O que o impede de fazer seu próprio processo?Se você encontrar algo pode ser melhor...apenas faça.Se funcionar, persevere.se não, tente outra coisa.Não existe um processo definido se você deseja agilidade.
O termo mais utilizado é 'entregável'código no final de cada iteração.O que significa que você pode fornecê-lo ao usuário final (como um monte de DLLs para copiar um compartilhamento ou entregar pessoalmente um CD/DVD) e ele obterá valor ao usá-lo.Esse código passou em todos os testes de unidade (desenvolvedores) e testes de aceitação (clientes/QA/Analistas) que foram considerados necessários para que seja "feito!" Os testes de aceitação são simulações de cenário de cliente de ponta a ponta.

Não tenho certeza do que você quer dizer com 'mais testes e validação'.Posso pensar em outras atividades de 'pré-lançamento'

• certas atividades como "Conferências de Treinamento" e criação de conteúdo relacionado.
• Demonstrações ou implantação em sites beta por um mês antes do lançamento se as implantações do cliente forem raras ou inviáveis ​​de serem feitas com frequência.
• Clientes/especialistas/serviços em potencial dando uma espiada prática no novo produto sobre o qual estão ouvindo.

Você apenas empilha no final do ponto final da última iteração (se você for particularmente pessimista como eu.pegue médias históricas..se você liberar mais cedo.Oba!) Então, se a empresa decidiu que a Iteração nº 14 delimita um bom conjunto de recursos que podem ser um lançamento.É apenas 'Adicionar n semanas' após o final da Iteração # 14.nenhuma matemática complexa ou incerteza nesse ponto.O ponto chave é que se você tiver envolvido as partes interessadas/clientes regularmente, incorporando feedback e mantendo um nível aceitável de qualidade, não deverá haver surpresas de última hora.

Se necessário, você pode até faça um começo contínuo..ou sejaa equipe de treinamento começa a trabalhar quando a equipe de desenvolvimento entra na Iteração #13.Isso lhes dá um mês, assumindo uma iteração de 2 semanas.e espero que você não tenha muitos recursos entrando na última iteração.Portanto, no máximo 2 semanas após a Iteração nº 14 e sujeito a todos os alinhamentos celestes/organizacionais, você deverá ter uma liberação e uma pausa bem merecida.

Answer 2

Primeiro reconheça que a largura/amplitude dos testes dos quais você fala aumenta à medida que o projeto avança e o software ganha escopo e/ou complexidade.Tentar colocar esse esforço em uma iteração não funciona depois de uma ou duas iterações por causa disso.A regra de bem-estar para iterações é um nível constante de trabalho em cada uma, conforme determinado pela velocidade do projeto.

As soluções para isso podem seguir um de dois caminhos:com ou sem automação.A automação nos níveis de teste mais altos reduziria o esforço para executar os testes, fazendo com que o trabalho se ajustasse novamente à iteração, uma vez que cada iteração se concentraria apenas nos aumentos incrementais de escopo/complexidade.Isto nem sempre é possível em todos os contextos de projeto, mesmo que seja isso que desejamos.Supervalorizar a automação de testes de alto nível é uma armadilha que você deve levar a sério, em outras palavras, evitar subestimar o que um testador exploratório razoavelmente experiente traz para a mesa.

Sem automação, o problema passa a ser baseado no gerenciamento de testes.Iterações de testes paralelas e deslocadas no tempo são uma solução candidata.Por exemplo, você pode optar por estabelecer um backlog de teste para tarefas de teste do sistema que seja gerenciado com a mesma cadência das iterações de desenvolvimento, mas que seja atrasado ou alterado no tempo em até uma iteração completa.Isso permite que os testadores trabalhem holisticamente em novos lançamentos em seu próprio sandbox e de acordo com suas próprias prioridades.

Eu defenderia que os backlogs de iteração de teste sejam construídos em colaboração com os desenvolvedores, assim como eu defenderia que os backlogs de iteração dos desenvolvedores fossem construídos em colaboração com os testadores.Eu também defenderia uma equipe de teste com experiência em automação para que possam automatizar o tédio e trabalhar de forma mais exploratória.Seu portfólio de testes automatizados deverá aumentar a cada iteração.Eles também devem ter acesso aos testes de unidade do desenvolvedor e poder executá-los em versões na sandbox de testes.

Trabalhar fora de fase dessa forma não elimina o problema crescente de escopo/complexidade do teste, mas fornece um mecanismo para gerenciar essa complexidade, já que a equipe está criando itens de backlog, ajustando prioridades, automatizando alguns, criando listas de verificação, etc.com base no que eles coletivamente pensam que deveriam fazer a seguir.Provavelmente, eles atingirão os itens grandes.

Preservar a capacidade dos testadores de trabalharem de forma holística e de desenvolverem a sua compreensão e de partilharem o seu conhecimento sobre o sistema através de testes automatizados, parece valer a pena lutar.

Answer 3

O teste automatizado após cada construção automatizada leva você a pelo menos parte do caminho.

Answer 4

Adicione testes de sistema ao backlog do sprint (no Scrum) ou equivalente.

O mesmo vale para a documentação do usuário.

Answer 5

A execução dos testes do sistema geralmente é muito lenta para ser totalmente integrada ao desenvolvimento ágil.(Há exceções a isso, por ex.um conjunto bem projetado de testes de navegador não pode ser executado muito mais lentamente do que os testes de unidade típicos.)

Uma forma de integração é ter uma compilação noturna ou contínua, que roda o tempo todo e pode levar várias horas para construir e executar todos os testes.Se uma compilação passar em todos os testes (teste de unidade + testes de sistema), ela se tornará liberável, você poderá entregar esse binário ou o instantâneo do código-fonte.A ideia é ter x versões de seus binários/instantâneos de código, verificá-los de forma assíncrona e entregar as compilações verdes.Isso deve funcionar tanto com testes de sistema automatizados quanto manuais.