Qualidade

O que é Selenium?

Quando se fala de qualidade de software, sabemos que a etapa de teste é imprescindível. O software deve fazer o que o cliente precisa de maneira confiável, segura, eficiente e flexível. Porém realizar testes de forma manual gasta tempo e dinheiro, por isso devemos dar a devida importância de se realizar os testes automatizados.

Para nos auxiliar, existem as ferramentas de automação, que simulam a interação que um usuário teria, realizando os testes automaticamente quantas vezes forem necessárias. Uma dessas ferramentas é o Selenium, tema deste artigo.

Selenium é um conjunto de ferramentas de código aberto multiplataforma, usado para testar aplicações web pelo browser de forma automatizada. Ele executa testes de funcionalidades da aplicação web e testes de compatibilidade entre browser e plataformas diferentes. O Selenium suporta diversas linguagens de programação, como por exemplo C#, Java e Python, e vários navegadores web como o Chrome e o Firefox.

Selenium - Testes Automatizados com TestNG
Curso de Selenium - Testes Automatizados com TestNG
CONHEÇA O CURSO

O ecossistema do Selenium é bem completa, sendo:

Selenium IDE

Selenium IDE é um ambiente integrado de desenvolvimento para scripts de testes automatizados, onde permite o usuário criar testes de forma muito rápida. Essa ferramenta te permite gravar os scripts, funcionando como um recorder, gravando as ações do usuário.

Esse script gerado você pode parametrizar e executar quantas vezes você quiser. O Selenium IDE inclui o Selenium Core , permitindo que você facilmente possa gravar e reproduzir os testes no ambiente real que será executado. O IDE é voltado para testes rápidos, com rápidos feedbacks.

É importante ressaltar que o Selenium IDE funcionava até a versão 55 do Firefox – e somente no Firefox. Porém, em 2018 eles voltaram com o projeto, ainda em “alpha”, mas agora disponível para Firefox e Chrome.

Selenium WebDriver

O Selenium WebDriver usa o próprio driver do navegador para a automação. É a forma mais moderna de interação atualmente, pois cada browser possui o seu respectivo driver, permitindo a interação entre o script de teste e o respectivo browser.

Esta versão é indicada para testes mais elaborados e por usuários familiarizados com a ferramenta. Geralmente usa-se o Selenium IDE para testes básicos, exporta-se o script e depois edita-se o script para realizar testes mais elaborados.

Selenium Grid

No Selenium Grid, você lança seu script sobre diferentes navegadores. O Grid é voltado para clusterização, permitindo você realizar os testes em máquinas diferentes de forma remota.

Segundo o site oficial do Selenium, o Selenium Grid leva o WebDriver a outro nível, executando testes em muitas máquinas ao mesmo tempo, reduzindo o tempo necessário para testar em vários navegadores e sistemas operacionais. Utilizando o Selenium Grid você ganha na escala, onde executamos o mesmo teste em centenas de configurações diferentes.

Considerações finais

A pressão do mercado pela qualidade dos softwares faz com que essa tecnologia esteja cada vez mais presente, e consequentemente, a procura por profissionais da área de testes cresça cada vez mais.

O que é XP – Extreme Programming?

Seguimos nossa série de artigos de metodologias, abordando hoje mais uma metodologia ágil: XP (Extreme Programming). Lembrando que já abordamos diversas metolodogias aqui, como Crystal, RAD, RUP, e AUP.

O XP (Extreme Programming ou Programação Extrema) é uma metodologia focada no desenvolvimento de software que possui valores e princípios, onde são fundamentados por um conjunto de práticas.

É uma metodologia leve que pode facilmente ser adotada por diferentes níveis de desenvolvedores (experientes ou não) e em qualquer tamanho de equipe. É uma excelente metodologia por se adaptar a requisitos que às vezes podem mudar rapidamente.

O XP pode ser utilizado de forma complementar ao Scrum, pois ele acaba focando mais em processos de engenharia e desenvolvimento de software.

Scrum - Planejamento e Desenvolvimento Ágeis
Curso de Scrum - Planejamento e Desenvolvimento Ágeis
CONHEÇA O CURSO

Princípios, valores e práticas

Como vimos acima, o XP possui um conjunto de princípios e valores, onde os princípios tendem a ser mais concretos que os valores. O conjunto de valores servem como um critério que norteiam as pessoas envolvidas no desenvolvimento do software, além de se complementarem. São eles: comunicação, simplicidade, feedback, coragem e respeito.

Além desses valores, existe um conjunto de princípios que deve ser seguido por equipes que forem usar XP em projetos, sendo o feedback rápido, presumir simplicidade, abraçar mudanças, trabalho de alta qualidade, pequenos passos, melhoria, diversidade, reflexão.

As práticas consistem no núcleo principal do processo. Elas evidenciam os valores que nos ajudarão a ter sucesso no projeto. São elas:

  • Cliente presente: O cliente deve participar ativamente do processo de desenvolvimento. Tudo precisa da comunicação com o cliente. Ele deve receber o melhor resultado possível a cada semana, ver o progresso no sistema, ser informado de mudanças de planos, etc. Escute, para que saiba qual é o problema a ser resolvido.

  • Planejamento: O desenvolvimento utilizando o XP é feito em iterações. Uma iteração é um período curto de tempo (1 ou 2 semanas) onde a equipe desenvolve um conjunto de funcionalidades. Sendo assim, no início da semana, desenvolvedores e clientes se reúnem para priorizar as funcionalidades. Essa reunião chama-se jogo de planejamento e nela já devem estar criadas as estórias. Se uma estória for muito grande, ela deve ser dividida em tarefas com duração máxima de alguns dias. Essas estórias devem ser escritas pelo cliente, pois assim ele consegue pensar melhor em cada funcionalidade. O planejamento é importante para que você sempre faça a coisa mais importante a ser feita.

  • Stand Up Meeting: São reuniões feitas em pé e de curta duração – mas muito produtiva, para que o time se mantenha alinhado, para saber o que cada um está fazendo exatamente, em que ponto está o projeto e se alguém está tendo problemas para executar suas tarefas. Ainda que apareça algum problema, essa reunião não tem o propósito de pensar em soluções.

  • Programação em par: É uma programação em par (dupla) em um único computador. Como é apenas um computador, o software sempre é revisto por duas pessoas diminuindo assim a possibilidade de falhas. Busca-se sempre a evolução da equipe melhorando a qualidade do código fonte. Ela é uma das práticas primordiais do XP, pois dois programadores fazendo o trabalho juntos acaba agregando muito para o trabalho em equipe.

  • Testes constantes: É utilizado o Desenvolvimento Orientado a Testes (Test Driven Development), o conhecido TDD. Primeiro crie os testes unitários e depois crie o código para que o teste funcione, essa abordagem é complexa no início, mas os testes unitários são essenciais para que a qualidade do projeto seja mantida.

  • Refatoração: É um processo que permite a melhoria contínua da programação, o mínimo de introdução de erros e mantendo compatibilidade com o código já existente. Refatorar melhora a clareza, leitura do código e facilita a manutenção. Além disso, o código fica mais coeso e você tem um melhor aproveitamento, evitando duplicação no código fonte.

XP - Extreme Programming
Curso de XP - Extreme Programming
CONHEÇA O CURSO
  • Código coletivo: Diz que o código fonte não tem dono e ninguém precisa solicitar permissão para poder modificar o mesmo. O objetivo é fazer a equipe conhecer todas as partes do sistema.

  • Padronização do código: Como todo mundo trabalha no desenvolvimento do mesmo software, a equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir essas regras, assim parecerá que todo código fonte foi digitado pela mesma pessoa. A padronização de código também é muito importante, porque o XP preza isso, o trabalho em equipe, se uma pessoa faz de um jeito e a outra faz de outro, isso fica muito confuso e futuramente pode ter problemas na revisão deste código.

  • Design simples: Essa prática se encaixa no princípio da simplicidade e é basicamente seguir o que o usuário está pedindo, por conta disso o design do software acaba sendo mais simplista. Além disso, o software acaba ficando mais fácil de ser alterado. Com essa metodologia você consegue alterar o código quando precisar, sem comprometer a qualidade.

  • Metáfora: Procura facilitar a comunicação com o cliente, entendendo qual a realidade dele. É preciso traduzir as palavras do cliente para o significado que ele espera dentro do projeto.

  • Ritmo sustentável: Manter um ritmo de trabalho com qualidade, onde eles estejam atentos e dispostos.

  • Semana de 40 horas: É trabalhar com qualidade buscando ter um ritmo de trabalho saudável, 40h por semana, 8h por dia, sem horas extras.

  • Integração contínua: Sempre que for produzido uma nova funcionalidade você nunca deve esperar uma semana para integrar com a versão atual do sistema. Isso só aumenta a possibilidade de conflitos e possibilidade de erros no código fonte. Integrar de forma contínua permite saber o status real da programação.

  • Releases curtos: As liberações de pequenas versões funcionais do projeto auxiliam muito no processo de aceitação por parte do cliente que já pode testar uma parte do sistema. As versões chegam ainda ser menores que as produzidas em outras metodologias incrementais, como o RUP. Os releases são pequenos pedaços do produto que são entregues ao cliente antes do tempo, assim o cliente não precisa esperar o produto todo ficar pronto para ver.

Considerações finais

Como pudemos ver o XP é dinâmico e flexível, nos ajudando a ter rapidez, qualidade e flexibilidade no desenvolvimento de um software. Se você quer conhecer ainda mais a fundo e principalmente ver o XP funcionando na prática, confira nosso curso de Extreme Programming.

O que é RUP – Rational Unified Process?

Metodologias são práticas que oferecem técnicas e rotinas criadas para aumentar a produtividade e dar mais coesão e coerência para o desenvolvimento de software. Continuando com a série de artigos sobre metodologias, essas que nos ajudam a ter mais qualidade e agilidade no desenvolvimento de software, vamos abordar neste artigo a metodologia RUP. Caso você queira ver outras metodologias, já abordamos aqui as metodologias Scrum, Crystal e RAD.

RUP (Rational Unified Process)

RUP (Rational Unified Process), traduzido em Processo Unificado Rational ou comumente falado “Processo Unificado” foi criado pela Rational Software Corporation, mas em 2003 foi adquirida pela IBM.

A metodologia RUP utiliza uma abordagem de orientação a objetos em sua concepção e é projetado e documentado utilizando o UML para ilustrar os processos. Tem como principais características ser incremental e iterativo. Incremental significa que aquele software é construído e entregue em pedaços, constituindo um conjunto de funcionalidades completas.

Através de pequenos ciclos de projetos – que correspondem a uma iteração – o software é melhorado através da adição de mais detalhes, o que resulta em um incremento no software. Iterações referem-se a passos e incrementos a evolução do produto.

RUP - Rational Unified Process
Curso de RUP - Rational Unified Process
CONHEÇA O CURSO

O RUP organiza o desenvolvimento em 4 fases bem direcionadas, contendo em cada uma delas no mínimo uma iteração, ou seja, um ciclo de vida, são nessas iterações que são mostradas ao cliente o andamento da produção para que ele possa validar e assim liberar a continuação do desenvolvimento. São elas:

  • Concepção: define o escopo do software. É uma fase preliminar, é nessa etapa que se concentra o levantamento de requisitos, define preços e prazos da entrega do sistema e onde se avalia os possíveis riscos.

  • Elaboração: plano do projeto, especificação de características e arquitetura. Aqui todas as análises de riscos são aprofundadas, como também os custos.

  • Construção: ocorre a codificação do software.

  • Transição: implantação do software, assegurando que ele esteja disponível aos usuários finais. Nesta fase está incluída os testes e o treinamento dos usuários.

Outra característica do RUP é que ele possui atividades lógicas, chamadas de disciplinas, sendo estas muito bem trabalhadas e desenvolvidas. Essas disciplinas são:

  • Modelagem de negócios
  • Requisitos
  • Análise e Design
  • Implementação
  • Teste
  • Implantação
  • Gerenciamento de configuração e mudança
  • Gerenciamento de projeto
  • Ambiente

As quatro fases que vimos acima e as disciplinas se interagem. As disciplinas e modelos existem para isso, para ficar organizado e que se consiga ter mais controle sobre o software final.

Considerações finais

Pudemos ver que o RUP tem o objetivo de garantir a produção de software de alta qualidade que atinja as necessidades dos usuários, dentro de um cronograma e orçamento previsível. Com ele podemos obter qualidade de software, produtividade no desenvolvimento e manutenção, controle sobre desenvolvimento dentro de custos, prazos e qualidade, estimativa de prazos e custos com maior precisão.

Geralmente ele costuma ser indicado para projetos com grandes equipes de desenvolvimento e projetos extensos, que requerem muita documentação e muito detalhe, que não necessitam de uma entrega tão imediata.

Se você ficou curioso em saber mais sobre o RUP de maneira mais aprofundada, temos um curso específico de RUP, onde você consegue ver inclusive como o RUP funciona na prática. Até lá =)

Por que escrever testes automatizados?

Quando se fala de qualidade de software, sabemos que a etapa de testes é imprescindível. O software deve fazer o que o cliente precisa de maneira confiável, segura, eficiente e flexível. Porém, durante o desenvolvimento, é normal aparecerem alguns erros. Por isso, é de extrema importância identificar os possíveis erros antes de colocar a aplicação em produção.

“Prevenir erros é mais fácil do que corrigi-los.”

A automação de testes é de grande valia e deve ser considerado em todos os projetos de desenvolvimento de software. E, de fato, para um software ser testado corretamente, esse processo deve ser automatizado com o auxílio de ferramentas com esta finalidade.

Os testes automatizados vêm como uma forma de poupar tempo de detecção de erros e de aumento de confiabilidade com relação aos testes em si. A execução de um teste manual é eficaz, porém, conjuntos maiores de teste com muitas repetições acabam se tornando uma tarefa muito cansativa e com tendência a erros, já que, de maneira inconsciente, as pessoas que testam o software em questão começarão a o utilizar de maneira em que este não falhe. Paralelizar este processo de teste, colocando várias pessoas para executar as rotinas de teste também pode não ser a melhor solução, já que isso pode ser caro e não irá garantir a qualidade do teste. Por estes motivos, testes automatizados vêm se mostrando cada vez mais como uma excelente alternativa para que os ciclos de teste de software possam ser executados de maneira independente do tamanho e da complexidade do software em questão.

Ainda existe mais um ponto que justifica a adoção de testes automatizados. Imagine o seguinte: uma equipe está focada nos testes de forma manual. No final dos testes, um erro foi encontrado. Esse erro deve ser resolvido pelos desenvolvedores. Porém, depois de resolvido, a equipe de testes deverá começar os testes do zero para garantir que a alteração feita não ocasione nenhum erro em outra parte do sistema. Nessa situação, mais uma vez, caímos no ciclo vicioso do teste de software manual: a ocorrência de muitos processos repetitivos e cíclicos, o que vai nos levar novamente à situação onde nós, se começarmos a repetir as coisas em uma carga alta, começaremos a executar estas ações no “automático”, prejudicando o processo de teste. E ainda existe a questão da quantidade de tempo gasto nesse processo todo, quantidade esta que certamente é enorme. E já sabemos: “tempo é dinheiro”… Se gastamos tempo “à toa”, estamos gastando dinheiro à toa e produzindo um software muito menos competitivo no mercado.

Com testes automatizados, nós podemos pelo menos evitar uma boa parte desse ciclo vicioso dos testes manuais, produzindo resultados com um grau de confiabilidade bem mais alto e em um período de tempo muito mais curto!

Selenium - Testes Automatizados com TestNG
Curso de Selenium - Testes Automatizados com TestNG
CONHEÇA O CURSO

Alguns tipos de teste…

Testes de software são de fato um assunto muito sério. Teste de software é algo tão complexo que existe até mesmo uma norma ISO para normatizar os procedimentos de teste: a ISO/IEC 9126. Em cima das métricas pregadas por esta norma ISO, alguns tipos de teste acabaram por surgir. Cada um destes grupos possui um conjunto de ferramentas de automação para atender a avaliação das métricas envolvidas.
Os tipos de teste de software mais comuns são:

Teste de Unidade

O teste de unidade verifica a menor parte testável do software – que é chamada de unidade. Neste tipo de teste, essa unidade é testada de forma isolada para garantir que tenha o comportamento esperado. Como esse teste é focado em um trecho específico do software, os erros são encontrados facilmente, diminuindo o tempo gasto com depuração. O conceito de “unidade” de software acaba sendo um pouco subjetivo, mas você pode pensar como sendo um método de uma classe sua, por exemplo. Este método, se puder ter suas entradas, comportamentos e saídas devidamente testados e validados, pode ser considerado como uma unidade de software.
Algumas ferramentas que auxiliam no processo de teste de unidade (ou teste unitário) são o jUnit, o xUnit.NET e o PHPUnit.

Teste de Integração

O teste de integração verifica se uma unidade tem o comportamento esperado quando funciona de maneira integrada a outros elementos de software, como chamada de serviços, APIs e banco de dados. Aqui, a unidade de software em si não é avaliada, mas sim a sua integração com outras unidades. Algumas ferramentas que auxiliam no processo de teste de integração são o Selenium, o Mockito e o MSTests.

Testes e2e (fim-a-fim)

Neste tipo de teste, é feita uma simulação das ações de um usuário real interagindo com o software, como por exemplo, o preenchimento de um cadastro, uma opção que foi selecionada ou um clique do mouse. Como o nome entrega, este tipo de teste visa garantir o fluxo correto dos dados entre todas as camadas que fazem parte da solução de software.
Alguns exemplos de ferramentas para testes e2e são o Protactor, o Selenium e o Cypress.

JavaScript - Testes automatizados com Jasmine
Curso de JavaScript - Testes automatizados com Jasmine
CONHEÇA O CURSO

Concluindo…

Dessa maneira, podemos notar que todo o tempo destinado na garantia da qualidade do software é válido, pois isso irá garantir a entrega de um software mais robusto e confiável, o que aumenta até mesmo a competitividade da solução em questão no mercado.
Com essas noções básicas sobre testes automatizados, você pode se aprofundar mais no assunto em um de nossos cursos e praticar!

Até a próxima 😊

Por que desprezar o teste do seu software pode ser uma auto-sabotagem?

O teste de software é umas das áreas de TI que muitas vezes não recebe o devido valor, mas que é fundamental para a entrega de um software com qualidade.

Sempre que adquirimos um produto, esperamos que ele tenha qualidade, ainda mais se tivermos investido um valor considerável nele. Por que então não podemos esperar a qualidade de um software? Veja nesse artigo, o por que você não deve se auto sabotar pulando as etapas de teste.

PMP/CAPM - Gestão das Aquisições
Curso de PMP/CAPM - Gestão das Aquisições
CONHEÇA O CURSO

Porque é importante testar?

A qualidade está diretamente ligada à satisfação do cliente. Quanto mais ele atende as expectativas, melhor é o grau de satisfação do cliente. Aliás, nenhum cliente gosta de receber um software que sempre dá erros ou não funciona.

A qualidade do software também implica, mesmo que indiretamente, na quantidade de usuários e clientes. Quando algo é muito bom, provavelmente seu cliente pode indicar para outras pessoas. Além disso, este cliente se tornará fidelizado. Por isso, o teste é super importante para o sucesso do negócio.

O que ele pode evitar?

O teste visa garantir que todos os requisitos estão sendo atendidos, que todas as funcionalidades estão sendo desempenhadas corretamente, que operações mais complexas estão sendo suportadas e que, obviamente, que não existe nenhum problema na aplicação.

Imagine que, depois da entrega do software, o cliente aponta um erro no sistema, que várias coisas não funcionaram como deveriam ou que até mesmo uma mensagem de erro apareceu. Com o teste de software adequado, você conseguiria verificar esta situação incorreta antes mesmo do cliente – o que é muito importante.

Por isso o teste deve acompanhar todo o ciclo de vida do software, desde sua concepção até sua manutenção.

Esse é um ponto importante para se levar em consideração. Quando esses bugs aparecerem, certamente será necessário reservar um tempo para a correção deste problema. Mas aqui é onde encontramos a armadilha: certamente, em um processo de desenvolvimento de software onde a etapa de teste não é algo “natural”, não existe tempo reservado para a correção de problemas.

O que acaba acontecendo, na maioria das vezes, é que o tempo que seria destinado para o desenvolvimento de funcionalidades acaba tendo que ser compartilhado com o tempo de correção do problema.

Com essa divisão, é fatal que uma situação incômoda ocorra: pelo pouco tempo, nem a correção do problema, nem o desenvolvimento das novas funcionalidades, serão desenvolvidos com a qualidade necessária, provocando uma cadeia sem fim de problemas e defeitos em geral no projeto de software em questão.

O mais interessante é que estes problemas que surgem não são simplesmente de ordem técnica: uma equipe que tem que estar sempre “correndo atrás do prejuízo” certamente será uma equipe estressada, instável e com alta rotatividade. Veja a bola de neve que pode acontecer pelo simples fato do desprezo pela etapa de teste de software.

“É melhor prevenir do que remediar”

É fato que, muitas vezes, o tempo é curto e você precisa entregar o mais rápido possível. Às vezes você até realiza a entrega consciente de que tem coisas para arrumar, mas que pelo menos cumpriu o prazo da entrega no dia certo e assim o cliente não irá reclamar. Aí, certamente você pensa: “na próxima entrega eu arrumo”. Mas isso muitas vezes acaba virando uma bola de neve, como vimos anteriormente: você tem que implementar novas funcionalidades, mas também tem que arrumar o que ficou pra trás na última entrega.

Por isso, não adianta simplesmente disponibilizar um pouquinho do tempo ou até aumentar os prazos de entrega para que você consiga verificar se o software está funcionando bem e com boa performance. É preciso que o processo de teste de software esteja integrado e fundido com o processo de desenvolvimento em geral. O teste de software precisa ser algo cultural.

Não sabe como realizar os testes no seu software? Aqui na TreinaWeb temos vários cursos desse segmento com muita prática. Então agora você não tem desculpas para não testar seu software, rs 😊

UML - Unified Modeling Language
Curso de UML - Unified Modeling Language
CONHEÇA O CURSO