Carreira em testes de software: como iniciar?

Olá Pessoal,

Esses dias eu recebi um e-mail, pelo formulário de contatos aqui do blog, e decidi escrever um post sobre o assunto pois obviamente fiquei animada 😃😃😃. A pessoa me perguntou como fazia para iniciar a carreira na área de testes, deu uma breve descrição sobre sua formação e trabalho e perguntou se era isso mesmo. 

Show né? Vou tentar explicar para vocês. Vamos do início então:

Que formação devo ter para iniciar a carreira de testes?

Conheço várias pessoas com faculdade e sem faculdade trabalhando nessa área de testes de software. Existe um caminho único? Claro que não! 

As faculdades das áreas de tecnologia/informática são as mais comuns. Os testadores com formação em TI são conhecidos como testadores mais técnicos por eles não terem medo de "mexer no computador". Com o tempo eles adquirem experiência em negócio. Nas faculdades de Sistemas de Informação e Análise e desenvolvimento de Sistemas é comum ter uma matéria de Testes de Software.

Mas isso não quer dizer uma uma faculdade como Psicologia, Recursos Humanos, Contabilidade e Administração, entre outras, não possam gerar testadores. Muito pelo contrário. Eles sabem como ninguém o negócio das mais variadas áreas, pois estudaram a fundo o tal "negócio". Exemplo: a pessoa que cursa ou está cursando Recursos Humanos sabe como ninguém como se calcula uma folha de pagamento de funcionário nas mais variadas situações. Por isso, essas pessoas são chamadas de testadores de negócio.

Independente da formação superior escolhida, as especializações e os MBA's específicos de testes ou engenharia de software normalmente não requerem formação superior na área de TI. O mesmo vale para certificações técnicas.

Como iniciar a carreira de testes numa empresa?

As empresas que contratam pessoas para a área de testes normalmente querem que o candidato tenha experiência em testes ou que conheça o negócio da empresa em questão. As vezes, na sorte mesmo, aparecem vagas de estágio de testes para quem não tem experiência com testes nem negócio. Mas essas vagas de estágio em testes são raras.

Como iniciar a carreira de testes se não tenho experiência?

O caminho mais comum é iniciar trabalhando com suporte. Suporte ao usuário, suporte ao sistema, tanto faz aqui. Isso vai te dar experiência no negócio.

O que é esse "negócio"?

O "negócio" que você vai adquirir experiência é uma linha de produto que você vai atender. Por exemplo: se você presta suporte à usuários de ERP, com o tempo você adquire conhecimento em algum módulo dele (financeiro, contábil, produção, manufatura, logística, etc.). Esse conhecimento adquirido é o conhecimento em negócio.

Fora a faculdade, o que você recomenda estudar?

Hoje a área de testes está indo cada vez mais para linha de automação de testes. Então sugiro você estudar sobre frameworks que consigam automatizar processos. Os mais conhecidos são os que gravam tela ( Selenium é o mais famoso, e TestComplete. Outra ferramenta legal e bem fácil de usar é o Katalon). Onde eu trabalho estamos usando o CodecepJS que usa o Selenium de forma embarcada.

Outra coisa legal é que quase todas as empresas (de Startup a grandes empresas) criam APPS para tudo. Então ter a expertise de "fuçar" aplicativos mobile também é legal.  

Certificações na área de testes também são legais por N motivos:

1. Você não precisa ter curso superior para tirar;
2. Você aprende muito;
3. Algumas tem validade internacional.

Além disso, não posso deixar de falar nos cursos de especialização e MBA que existem e abordam sobre testes de software.

Você possui outro caminho? Entra em contato para incrementar o post! 😄

Espero que tenham gostado, até mais! 😃

Testes de software no modelo cascata e no modelo agil

Quando o modelo de desenvolvimento muda numa empresa, é possível ouvir muitas pessoas dizendo "Isso não vai dar certo" ou então "Sempre funcionou assim, para que mudar?". A transição de um modelo para outro não é fácil.

Saindo de um modelo cascata para o SAFe (framework ágil, veja outros posts sobre SAFe AQUI) foi possível observar como o processo de desenvolvimento influencia diretamente na maneira de como os testes são efetuados, e durante esta transição pode-se perceber como a qualidade do teste aumentou com a adoção dos processos ágeis. Isto devido a uma maior participação dos analistas de testes em vários níveis do desenvolvimento, e não apenas na execução como também no planejamento.

No processo cascata os testes acontecem apenas ao final de todo o ciclo de desenvolvimento, tornando assim o papel do analista de testes mais reativo. Por outro lado, em um processo ágil o analista de teste se torna mais proativo, pois está diretamente envolvido com a evolução do sistema, trabalhando junto tanto na análise da demanda como ao lado dos desenvolvedores na execução da mesma. Com isto um dos principais benefícios foi poder antecipar as possíveis falhas do que apenas se limitar a encontra-las ao final do ciclo, conforme imagem abaixo:

Modelo cascata e modelo ágil.

E então, já passaram por alguma mudança no modelo de desenvolvimento? Conta como foi!

Até mais, 😊

Referências:

CABRAL, Samuel Pierri. FERNANDES, Anita Maria da Rocha. Teste de Softwares Utilizando um Framework Ágil Escalável. UNIVALI, Florianópolis, SC, Brasil.

Teste de ponto a ponto dos sistemas pelo System Team

O System Team por vezes faz jus à expressão "pau para toda obra". Ja falei bastante sobre o System Team no post anterior AQUI, mas vamos listar aqui algumas de suas atribuições. Depois veremos se não chegamos todos a uma conclusão assim. 😉

• Participamos das releases plannings de todas as equipes onde atuamos, auxiliando no refinamento do backlog para definir a os testes das histórias;
• Criamos novos cenários de testes automatizados;
• Estendemos os cenários de testes para conjuntos maiores de dados;
• Organizamos os casos de testes construídos pelos times individualmente em suítes ordenadas;
• Realizamos teste manual e executamos testes automatizados para novas features e histórias;
• Eealizamos o teste dos requisitos não funcionais do sistema.
• Auxiliamos a identificar problemas e gargalos do produto.

Pensem comigo, nós do System Team temos que conhecer muito sobre os produtos e sistemas que testamos para poder fazer as atividades acima.

O cenário de atuação do System Team

Após os testes efetuados nas equipes de desenvolvimento, entra a equipe de homologação do System Team que realiza o teste de aceitação baseado nos critérios de aceite da feature. Os critérios de aceite já foram previamente definidos pelos analistas de sistemas. Assim é testado e validado se todas as histórias sincronizadas no mesmo código fonte atendem aos critérios de aceite da feature, conforme imagem abaixo. 

Times responsáveis pelos diferentes níveis de teste.

Após a homologação realizada o System Team, através de uma outra equipe de analistas de testes, executa um teste de regressão completo ponto-a-ponto no sistema onde o objetivo é verificar se após a sincronização de todas as features no mesmo branch o sistema continua funcionando como deveria, conforme imagem abaixo.

Teste ponto-a-ponto do System Team.

Nesta etapa o System Team torna-se responsável por documentar e criar casos de testes para áreas do sistema nunca antes mapeadas, gerando assim um grande valor de conhecimento para todos que trabalham com teste na empresa. Na prática, a equipe do System Team torna-se referência na integração dos produtos (fazendo jus à expressão "pau para toda obra"). Outro tipo de teste que o System Team é responsável é o teste de integração com outros sistemas a fim de validar se as novas versões desenvolvidas continuam compatíveis com outros sistemas.

Com a estruturação da equipe para se adaptar ao SAFe onde uma equipe de testes (os QAs) que está junto aos desenvolvedores testa as histórias do usuário, e outra que está junto ao System Team testa as features, a qualidade do teste e a identificação de bugs foi elevada consideravelmente, pois conseguimos detectar defeitos em vários níveis diferentes do processo.

Concordam? Discordam? Comenta aí! 😀 

Referências:

CABRAL, Samuel Pierri. FERNANDES, Anita Maria da Rocha. Teste de Softwares Utilizando um Framework Ágil Escalável. UNIVALI, Florianópolis, SC, Brasil.

Quem é o System Team dentro do Ágil?

Trabalho a pouco mais de 5 meses no System Team. Entrei no time no final da primeira release (iteração) planejada, participei da segunda release inteira e agora estou na terceira release no time do System Team. Já tive altos e baixos, mas vou tentar explicar tudo sobre esse time neste post.

Onde começou o System Team?

No framework ágil SAFe, Times Ágeis não são unidades stand-alone. Pelo contrário, eles são uma parte integral do Trem de Release Ágil (ART/TREM), onde eles coletivamente têm responsabilidade por liberar mais valor. Pense na release como um trem, onde cada vagão é uma equipe. Times operam no contexto do trem, contribuindo para sua visão, colaborando com outros times, e participando em cerimonias chave do TREM. Os times e o trem são inseparáveis; o todo é maior que a soma de suas partes.

Big Picture SAFe - System Team

Afinal, o que é o System Team?

Existe um time específico para a execução dos testes de regressão e integração, criado a partir da implantação do SAFe: o System Team. Esse time tem como função fazer a homologação do sistema após a finalização das features (conjunto de histórias) criadas pelos outros vagões do trem. Ele é composto por analistas de testes mais experientes e com conhecimento aprofundamento do sistema (em teoria). 

Como ocorre a criação desse time durante a transição para o ágil?

Quando o ágil está sendo implementado, é comum começar com a equipe sem ter planejado a estrutura necessária para o trabalho do System Team. Lembre-se de que o System Team trabalha testando os sistemas de forma integrada, como é utilizado pelo cliente e precisa de máquinas boas para os seus testes. Também é comum formar mais de um time de System Team pois as equipes podem ser grandes de acordo com os sistemas e integrações, mas ambos devem testar seus produtos de forma integrada. Os times de System Team auxiliam com a integração de sistema e solução e ajudam a demonstrar a solução evoluindo à medida que ela se desdobra.

Conforme falei neste post aqui, ocorre uma cerimônia chamada de System Demo. Na System Demo é apresentado, de forma integrada, todo o desenvolvimento dos vagões ágeis durante a release. Como o System Team já possui o ambiente de forma integrada, é comum este ambiente ser utilizado para a validação dos produtos para os Product Owners ao final da release. Falo mais sobre System Demo mais abaixo neste mesmo post.

Descrição do Papel System Team

O System Team é um time ágil especial no trem, que possui grande conhecimento nas soluções e por vezes é procurado para fornecer assistência na construção e uso do ambiente de desenvolvimento e testes. Este time executa testes nas soluções de forma integrada e de ponta a ponta. Por este motivo pode fornecer um feedback de forma rápida sobre como está a integração dos sistemas.

Responsabilidades do System Team

... sobre a infraestrutura:

• Pode criar e manter a infraestrutura das soluções integradas, incluindo integração contínua, builds automáticas e automatização de testes;
• Pode criar plataformas e ambientes de demonstração da solução, como podem utilizar o ambiente já existente para tal;
• Pode facilitar os aspectos técnicos de colaboração, tais como prover dados ou serviços, facilidades de hosting, etc. para outras equipes de desenvolvimento do trem.

... sobre integração de sistemas:

• Participa das reuniões de release planning e no refinamento do backlog para definir integração e testes de capacidades e funcionalidades;
• Determina e ajuda a manter decisões e políticas para apropriar modelos de branch;
• Pode participar das dailys de outros times no apoio à atividades diárias.

... sobre testes ponta a ponta e de performance:

• Cria novos cenários de testes automatizados;
• Organiza casos de testes desenhados por times individuais em suítes ordenadas;
• Executa testes manuais e roda testes automatizados para novas funcionalidades e estórias;
• Prioriza testes demorados, refatorados, e roda suítes de testes reduzidas onde aplicável;
• Ajuda os times a criar suítes reduzidas de testes que eles mesmos podem rodar;
• Testa performance da solução contra requisitos não funcionais e ajuda a equipe de Engenharia de Sistema e Solução a identificar falhas e gargalos.

Como o System Team atua nas Demos dos Sistemas e Soluções (System Demo)?

Ao final de cada release os times (vagões do trem) precisam demonstrar a solução desenvolvida no período da release. Normalmente o System Team apoia as outras equipes e ajuda a assegurar que os ambientes de demonstração estão adequados.

Como o System Team atua na liberação dos produtos?

O System Team estabiliza as versões de liberação e possui o conhecimento necessário para testar as integrações dos produtos. O System Team normalmente entendem o que é, o que faz, e quão bem cada entrega atende os requisitos desejados, pois participa das Reviews e, as vezes, das plannings dos demais times ágeis/demais vagões. Nesta perspectiva, o System Team está diretamente envolvido no suporte da liberação, trabalhando com os DevOps e fazendo o que for necessário para ajudar o TREM a preparar, empacotar e liberar a solução. Lembrando que o System Team não faz o trabalho de manutenção de liberar versões que já estão no mercado. O System Team libera versões que ainda não estão no mercado.

Por que dos altos e baixos na equipe do System Team?

Como foi possível compreender após toda a explicação do que o System Team faz e quais são suas responsabilidades, é também possível imaginar o tanto de cobrança que a equipe do System Team tem e qual o seu trabalho. Nós liberamos uma versão nova dos produtos/sistemas a cada fim de release (isto não é uma regra, mas é como funciona onde trabalho hoje). A semana de liberação costuma ser conturbada, pois ainda não finalizamos as estabilizações e cada equipe do trem quer preparar sua apresentação para a posterior aprovação dos Product Owners. Isso quando o ambiente não dá algum problema.

Apesar dos testes serem integrados, temos que testar as funcionalidades novas integradas com as velhas. Aqui temos que deixar claro que NÃO é função do System Team testar as funcionalidades novas desenvolvidas pelos times de desenvolvimento, mas temos que testar impactos e integrações.

Por mais que haja pressão, é comum as equipes de desenvolvimento liberarem seus produtos com testes sem ver seus impactos. Também já vi acontecer de equipes não planejarem seus tempos de testes e testarem seus produtos durante a estabilização do System Team.

Se a equipe do System Team não for forte, acompanhar TUDO, comunicar qualquer deslize e não aceitar algumas liberações, as liberações viram playgrounds e os testes das sprints ficam impossíveis de serem executados!

Referências

System Team Abstract - SAFe. Disponível em: <http://www.scaledagileframework.com/system-team/>. Acesso em: 17 de maio de 2017.

SAFe - um Framework ágil

A sigla SAFe significa Scaled Agile Framework, que em tradução livre seria um framework para

escalonamento ágil. Ele é um framework de desenvolvimento criado pela IBM para permitir às empresas de grande porte a utilização de práticas ágeis. De acordo com o site do framework, ele serve para abranger toda a organização, operando nos níveis de portfólio, programa e time.

Mas por que não colocam o Scrum numa empresa de grande porte, em vez de um framework ágil? 

Essa pergunta é fácil de ser respondida. Empresas de grande porte possuem controle, indicadores (para particição de lucros por exemplo), acionistas e , normalmente, certificações ISO. As certificações ISO requerem um processo que todas os colaboradores da empresa conheçam. Só assim a empresa consegue a recertificaçao.

Como funciona o SAFe?

Retirada do site do framework, a Big Picture do SAFe (abaixo) resume em um fluxograma os processos abrangidos pela metodologia. Nessa figura é possível observar os principais elementos trabalhados pelo framework SAFe, incluindo os conceitos de time, programa e portfólio, que serão detalhados a seguir.

Big Picture SAFe

Partindo do menor nível, temos o conceito de time dentro da metodologia. Esse fluxograma pode ser observado na parte debaixo da figura. Os times são formados por um número médio de sete a dez pessoas, incluindo desenvolvedores, testadores, scrum master (SM) e product owner (PO). O formato de trabalho, dentro dos times, é similar ao conceito de scrum, por meio de sprints. São realizadas entregas em curtos períodos que, somando com as entregas dos demais times, formam um incremento de programa, que agrega valor para o cliente. Além disso, o framework se baseia na utilização das metodologias ágeis Kanban, Scrum e XP para a realização de sprints de desenvolvimento.

O conceito de programa é justamente esse conjunto de vários times trabalhando para realizar as entregas para o cliente. Essa entrega maior é chamada, dentro da metodologia do SAFe, de trem (Agile Release Train), e é composta por 5 ou 6 sprints dos times. Na figura da Big Picture SAFe, essa etapa pode ser observada no fluxograma central. Os papéis que compõe esse processo são o RTE, Product Management, System Architect e Business Owners. Esses atores fazem o controle do backlog de programa, definindo prioridades e encaminhando as demandas para cada time, a nível de Feature. As entregas realizadas pelos times ocorrem por meio da cerimônia de Sprint Demo – apresentação dos itens desenvolvidos a serem aprovados pelo PO.

Já o nível de portfólio é composto por membros que devem ter a visão estratégica da organização. Eles são responsáveis por definir prioridades com o cliente, alocar as demandas no backlog dos times, a nível de Épico (iteração maior), organizar entregas, encaixar as necessidades dos clientes nas demandas para o desenvolvimento, etc.

Referências

Scaled Agile Framework – SAFe. Disponível em: <http://www.scaledagileframework.com/>. Acesso em: 16 de maio de 2017.