Como são feitos os testes de software nas startups de tecnologia?

Eu já vi muitos artigos de pesquisa e blogs de tecnologia que apresentam os benefícios dos testes de software. Eu tenho convencido disso. Mas como todas as pesquisas de teste de software são conduzidas por grandes empresas de software, não acredito que elas realmente se apliquem a startups. Desde que as startups têm necessidades e restrições diferentes em comparação às grandes empresas de software.

Então, isso levantou as questões. As startups de tecnologia devem escrever testes automatizados? Em caso afirmativo, eles são feitos da mesma maneira que as grandes empresas de software? (teste de fumaça, teste de regressão, etc.) É melhor que você possa consultar alguns artigos de pesquisa sobre esse assunto ... desde que eu não consegui encontrar nenhum por conta própria.

(Devo admitir que, embora ainda esteja no início da minha carreira, mas ainda não vi uma startup que esteja seriamente comprometida em escrever testes automatizados)

Sempre há um conflito entre o que deve ser feito e o que realmente temos tempo. Sim, muitas startups renunciam ao desenvolvimento orientado a testes e testes automatizados para economizar um tempo para colocar um projeto em funcionamento.

Os sites de redes sociais e as empresas de aplicativos móveis são as grandes bolhas agora e são ferozmente competitivas. Às vezes, a diferença entre ir ao ar em 4 meses versus 5 meses significa que você perde.

O tempo de colocação no mercado é fundamental e, se o sucesso acontecer, é hora de escalar, e haverá tempo de sobra para refatorar o software não testado, que não vale a pena, em algo que vale a pena.

Teste de software não é uma religião. É apenas uma ideia muito boa.

Você diz que não tem mão de obra para escrever testes agora? OK, tudo bem. Daqui a seis semanas, você terá a mão de obra para encontrar o bug que está travando seu aplicativo, que seria encontrado imediatamente se você tivesse os testes adequados em prática?

Muitos testes podem atrasar o desenvolvimento. Muito pouco teste também pode retardá-lo. Você precisa encontrar o equilíbrio certo, e geralmente é difícil dizer onde está. E nada disso é específico para grandes ou pequenas empresas.

Por muitos anos, enquanto trabalhava em pequenas empresas e start-ups, fiquei com a má compreensão de que "não tinha tempo suficiente para escrever testes de unidade para o meu código" .

Quando escrevi testes, eles estavam inchados, coisas pesadas que só me incentivaram a pensar que só deveria escrever testes de unidade quando soubesse que eram necessários.

Recentemente, fui encorajado a usar o Test Driven Development e achei uma revelação completa .

Agora estou firmemente convencido de que "não tenho tempo para não escrever testes de unidade" .

Na minha experiência, desenvolvendo com testes em mente, você acaba com interfaces mais limpas, classes e módulos mais focados e, geralmente, mais código SOLID testável.

Toda vez que trabalho com código legado que não possui testes de unidade e preciso testar algo manualmente, fico pensando "isso seria muito mais rápido se esse código já tivesse testes de unidade" . Toda vez que tenho que tentar adicionar a funcionalidade de teste de unidade ao código com alto acoplamento, fico pensando "isso seria muito mais fácil se tivesse sido escrito de maneira desacoplada" .

Se há uma coisa que eu descobri ao longo dos anos, se você está trabalhando em uma empresa iniciante, precisa ser ágil , e não apenas no sentido da metodologia de desenvolvimento de software . Para mim, o TDD é uma ferramenta importante que permite iniciar e manter a agilidade .

Não se trata de quem deveria fazer testes de software. Testes de software são uma espécie de filosofia de desenvolvimento de software. Os testes de software estabelecem a base de uma boa qualidade de software e, em uma startup, a qualidade de software é um bônus quando a aquisição por uma grande empresa está chegando;)

As práticas recomendadas são de todo o setor, esteja você transformando a avó em um site ou criando o sistema de orientação para um satélite. Eles sempre devem ser seguidos por aqueles que querem se considerar profissionais, por isso são chamados de MELHORES práticas.

Sim, as startups às vezes cortam cantos e não implementam testes adequados. Às vezes, isso é apropriado (para projetos pequenos o suficiente ou quando tempo / dinheiro são críticos)

Isso não é exclusivo para startups. Um de nossos fornecedores contratados de TI ainda possui um ambiente de teste. Tudo é feito diretamente para viver e esta é uma grande empresa multinacional de software (assustadora!)

Eles deveriam? Sim. Eles fazem isso na prática, não com a frequência que deveriam.

O motivo mais comum é a falta de recursos, que inclui o tempo do desenvolvedor, o custo da contratação de um testador dedicado ou em período parcial, o custo da configuração de um ambiente de teste e assim por diante. Você pode até encontrar essas desculpas em grandes configurações corporativas, bem como em pequenas empresas iniciantes.

Observando de outra maneira, o teste é uma das coisas mais fáceis de cortar em um cronograma de desenvolvimento, especialmente um com pressão de tempo muito apertada e / ou pressão de custo para produzir resultados visíveis. Juntamente com o trabalho de design detalhado, ele é considerado 'fofo' por muitos gerentes e o primeiro lugar que eles dizem "cortá-lo para que possamos fazer nosso cronograma e orçamento funcionarem", seguido por "Por que você não está codificando?".

Em algumas empresas, haverá alguém que faz testes por push. Normalmente, este será o desenvolvedor contratado e, em geral, será alguém com experiência e provavelmente alguém com algum tipo de participação financeira na empresa. Uma empresa que começa com esse "DNA" provavelmente fará testes desde o início.