Numa empresa em que estávamos habituados a testar as entregas de uma forma mais manual, o crescimento contínuo e a evolução para entregas contínuas (continuous delivery) ditou a alteração do mindset do tester.

A forma de fazer testes mudou devido às novas necessidades impostas pela alteração do processo de entrega, onde a necessidade de validação cada vez mais rápida do número crescente de entregas sem perder a confiança na entrega é um ponto chave.

Adoptamos a estratégia "shift left" para os testes, que em conjunto com o investimento em automação, veio a revelar-se como sendo a receita perfeita para suportar as entregas contínuas. Começamos a utilizar uma série de estágios organizados em pipelines onde exercitamos diferentes partes do software produzido de uma forma incremental de forma a diminuir as validações manuais.

Foi necessário pensar em que tipos de testes deveríamos utilizar para validar uma user story e pensar em que níveis da pipleine deveríamos utilizá-los, isto veio desafiar a forma de pensar dos testers que tiveram de adaptar a esta nova forma de fazer testes.

Por isso, se estão curiosos sobre o tipo de “equipamento” necessário para escalar a pirâmide de testes num ambiente em que se utilizam entregas contínuas, venham ver esta sessão que irei partilhar convosco.

A uma equipa típica de ASP.NET deram o desafio de correr um sistema de envio de emails internos que corresse em máquinas pequenas de Linux, sendo a escolha de linguagem algo típico como Java ou uma tecnologia ainda verde sem grandes casos de sucesso e falta de conhecimento do funcionamento interno disseminado... Toda a gente escolheu a última opção. Iremos falar sobre os problemas encontrados com o novo .NET Core, com Kestrel e o choque na migração de conhecimento, enquanto corremos tudo em Docker.