Eu tenho um aplicativo PHP que é muito grande. Geralmente, existem 2-3 desenvolvedores trabalhando nisso em período integral e estamos chegando ao ponto em que estamos fazendo alterações e criando bugs (recursos de tosse!). O software não é complexo, por exemplo, há muita coisa acontecendo (35 ~ controladores, aproximadamente os mesmos modelos, etc).

Mesmo sendo cuidadoso, é fácil para uma alteração nessa exibição (ajustar um ID em um elemento) destruir uma consulta ajax que ocorre sob alguma condição especial (desconectada enquanto está em um pé).

Os testes de unidade são as primeiras coisas que vêm à mente, mas tentamos isso em outro aplicativo, e é tão fácil esquecê-los / ou passar mais tempo escrevendo testes do que fazendo testes. Temos um ambiente de teste no qual o código é verificado antes de ser liberado.

Talvez precisemos de uma pessoa Q / A de meio período?

Alguém tem alguma sugestão / pensamento.

Sim, você precisa de uma equipe de Q / A. Algumas das muitas razões incluem

• Um testador dedicado custa dinheiro, mas geralmente menos dinheiro que um desenvolvedor, portanto, o benefício de não gastar seu tempo é maior que a despesa adicional.
• Um testador dedicado sabe como testar as coisas, principalmente as que não são óbvias como automatizar. A realização de testes automatizados para interagir com um sistema por meio de um navegador é uma disciplina um tanto complicada, mas bem estabelecida. Se você conhece alguém que já sabe como fazê-lo, não precisa gastar mais tempo aprendendo boas ferramentas e configurações.
• Um testador profissional sabe como realmente encontrar defeitos. É muito mais provável que eles pensem como um usuário do aplicativo pensará e, portanto, exercitem os estados do sistema que realmente aparecerão em produção, o que significa que os erros que se tornam altamente visíveis tendem a ser encontrados anteriormente , economizando seu embaraço e custos com patches ultra-urgentes.
• Generalizando isso, um testador não pensa como um desenvolvedor . É difícil transmitir quanta diferença isso faz se você não tiver experimentado. Conscientemente ou não, um desenvolvedor não deseja encontrar defeitos. Eles sabem como o sistema funciona e tendem a evitar as entradas ou dados típicos sem sentido (para eles) que causam problemas na vida real. Se algo funciona de maneira inesperada, eles sabem como contorná-lo e tendem a não ver isso como um defeito. Eles nuncatêm dificuldade em entender o que as respostas do sistema significam, porque as escreveram, mesmo que essa seja uma das principais causas de problemas em quase todos os sistemas reais. Em resumo: os programadores tendem a ser ruins em ter os problemas típicos que os usuários têm, porque são especialistas altamente treinados. Um testador tem muito mais facilidade para executar os testes mais relevantes.

Dito isto, nada supera a cooperação produtiva entre um desenvolvedor e um testador para impulsionar a qualidade do sistema através do telhado. Um desenvolvedor geralmente percebe os sintomas de que algo está errado antes do testador. Um desenvolvedor geralmente pode aconselhar um testador como reproduzir um problema com muito mais eficiência e como escrever um relatório de problema adequado, ou seja, incluir os detalhes que são realmente necessários para descobrir o problema. Mas tudo isso requer pelo menos um testador com o qual você possa trabalhar.

Provavelmente você precisa de mais ou melhores testes de regressão (não especificamente testes unitários ). Que tipo de testes você deve ter para se analisar, mas eles devem detectar os bugs dos quais você está falando. Sugiro que você comece a fazer um plano de teste e priorize esses testes - e quando fizer isso, inicialmente não pense muito em automação de testes.

Depois, pergunte a si mesmo se você pode automatizar alguns ou a maioria dos testes com um esforço razoável. Se a resposta for sim, você deve programá-las. Se a resposta for "não" e você achar que a "pessoa com Q / A em período parcial" é mais barata, deve-se evitar o que você precisa. Na maioria dos casos, é uma boa idéia ter os dois - uma pessoa de Q / A para testes manuais e inventar novos testes, e muitos testes de regressão automatizados também.

Contrate um controle de qualidade profissional

Isso deve ser feito se você estiver desenvolvendo um projeto comercial. Ter um produto pronto sem uma estratégia de teste robusta custaria mais com correções de bugs. Além disso, conquistar novos clientes ou retê-los também dependerá da qualidade da sua aplicação testada.

De maneira geral, o teste de unidade deve ser aplicado à sua base de código, no entanto, o teste de integração e o manual não devem ser descartados.

O teste de unidade é uma boa ideia, especialmente se o seu projeto estiver crescendo. Se escrever testes de unidade se tornar um hábito, facilitará muito o seu trabalho. Há um vídeo no youtube sobre como escrever código limpo, mais fácil de manter e testar.

O engenheiro de controle de qualidade também é obrigatório. Um bom testador de controle de qualidade não apenas encontrará erros na funcionalidade, mas também testará se o aplicativo é fácil de usar (o que é quase impossível de testar por si mesmo). Aqui está um bom artigo explicando como a equipe de controle de qualidade economizará tempo e dinheiro e ajudará a fornecer um software melhor.

15 controladores e modelos não são muito grandes. Leva algum tempo para tornar o teste de escrita um hábito, chutar um ao outro em direção a ele (de uma maneira amigável primeiro) ajuda muito.

Existem ferramentas que podem controlar a cobertura do teste até certo ponto. Ferramentas de cobertura de código para PHP