Pular para o conteúdo principal

Sim, estamos de volta!

Depois de um hiato de quase nove anos e muitos acontecimentos, o QA House está de volta. 

Durante esse tempo, muita coisa aconteceu: estamos vivendo em tempos pandemia - que está perto do fim, assim espero -, o desenvolvimento tecnológico ocorreu de forma muito rápida, principalmente no último ano, diante das necessidades impostas pela pandemia de COVID-19. 


Evolução Tecnológica e QA

Mesmo diante dessa evolução em tempo recorde, a área de QA e Testes não foi esquecida ou tampouco perdeu a importância: estamos cada vez mais presentes e mais fortes no dia-a-dia de grandes empresas, principalmente porque o profissional de QA evolui, e evolui muito!

Estamos presentes, atuantes e, por vezes, somos os principais responsáveis por áreas como DevOps (criando infraestrutura para suportar nossos testes), Desenvolvimento de Frameworks (utilizando conceitos de arquitetura de software, clean code, reusabilidade, entre outros) e também na área gerencial, sendo cada vez mais vital nas decisões de times de TI.


Novas Ferramentas e Melhoria das Existentes

As ferramentas de testes automatizados também evoluíram de forma fantástica, ao mesmo tempo que novas ferramentas surgiam. 

Não vou me alongar nesse assunto porque pretendo fazer posts mais detalhados sobre essas ferramentas no futuro. Mas vou ressaltar aqui três ferramentas que você já deve conhecer muito bem:

  • Selenium 4
  • Cypress.io
  • Postman


Selenium 4

Depois de uma evolução impressionante na sua versão de número 3, o Selenium promete bastante para a versão 4. Até o momento desse artigo, o mesmo encontrava-se disponível para download apenas na versão alpha.

Para se manter atualizado sobre as últimas versões, é só acessar: https://www.selenium.dev/downloads/

Alguns pontos que achei interessante nessa versão 4 do Selenium:

  • Relative locators que permitem uma forma mais amigável de encontrar os elementos da página baseados em sua posição em relação a outros elementos (geralmente mais fáceis de serem localizados);
  • Maior número de exceções, o que permite que erros e falhas sejam melhores descritos nos testes;
  • Novo CromiumDriver que vai permitir interação não somente com o Chrome, mas também com o Microsoft Edge;
  • Um melhor controle de janelas e abas na automação dos testes;
  • Uma nova interface para a Selenium IDE que promete ser clara e prática, além de mais robusta. A Selenium IDE será muito mais útil para o processo de automação, principalmente em relação aos localizadores;
  • Uma nova command line interface, que vai ajudar na hora de testarmos os testes que serão executados no processo de Integração Contínua.

Vou parar por aqui porque a lista está ficando muito longa. E como eu disse anteriormente, isso é papo para outro post. 

Cypress.io

O Cypress é uma grata surpresa para testes automatizados E2E para web. 

Aliás, o Cypress pode ser descrito como uma solução de testes completa. Um framework de automação de testes em JavaScript com tudo pronto. Ainda por cima, é veloz, robusto e está em constante evolução.

Se deseja mais informações, tem muito material para explorar no site deles: https://www.cypress.io

Mas fique tranquilo, vou explorar bastante essa ferramenta por aqui.

Postman

Ah, o Postman... que ferramenta maravilhosa!

Eu uso o Postman para teste de APIs e ele nunca, nunca me decepcionou. 

Além disso, eu posso automatizar os meus requests e criar suites de testes. Além de conseguir rodá-los via CLI (em breve escreverei sobre como isso funciona).

O link para saber mais sobre o Postman é esse daqui: https://www.postman.com

Mas, novamente, não se aperreie, falarei muito do Postman por aqui.


Fique ligado

Não perca o site de vista! Teremos muitas novidades, muita informação e, espero, muito debate saudável sobre TI, engenharia de software e, principalmente, QA e Testes!

Grande abraço!

Comentários

Postagens mais visitadas deste blog

Testes no RUP (Parte 2)

Em muitas organizações, os testes começam muito tarde no processo de desenvolvimento de um software. Muitas vezes, começam tão tarde que o produto é lançado com uma quantidade irrisória de testes executados. Para solucionar esse problema, muitas empresas estão começando a adotar testes como um 'mal necessário'. Como contraste a esse panorama, o RUP modifica a abordagem de testes, distribuindo a mesma no decorrer do ciclo de desenvolvimento do software, agregando valor ao invés de arcar com custos excessivos decorrentes da ausência de testes. No post anterior , justificamos a pergunta 'por que testar cedo e com frequência?' com o gráfico de custos. A seguir vocês podem ver um gráfico similar, retirado do site da IBM (detentora da metodologia RUP): Muitas pessoas ainda veem a disciplina de Testes como algo secundário, por que isso acontece? Talvez porque não esteja diretamente ligado ao desenvolvimento do software e por isso é muitas vezes deixado para o final, depois do

O + do FURPS+

Segue a continuação do assunto FURPS: Posteriormente à definição do modelo FURPS, notou-se a necessidade da inclusão de mais atributos para encorpar e aumentar a cobertura do modelo. A partir dessa extensão, o acrônimo passou a ser mais comumente chamado de FURPS+ . Quais são os atributos do “+”? O + do FURPS refere-se a especificação de restrições que definirão determinados limites que deverão ser atendidos quando construímos um sistema. O + é composto dos seguintes requisitos não-funcionais: Design constraints – restrições de design: design nesse caso refere-se ao projeto, diretrizes e não a layout. A definição da utilização um banco de dados relacional no projeto é uma restrição de design, por exemplo. Implementation constraints – restrições de implementação: relacionado a limites impostos a código e construções. Como exemplo podemos citar a linguagem de programação que será utilizada para a codificação de um sistema. Interface constraints – restrições de interface: diretamente l

FURPS

Olá! Nesse post, pretendo falar um pouco sobre o modelo FURPS para ilustrar atributos que estão envolvidos em Qualidade de Software : Vamos começar pela sigla FURPS: o que significa cada uma dessas letras? Do F temos Functionality, traduzimos como Funcionalidade: Representa basicamente os requisitos funcionais do sistema. Do U temos Usability, traduzimos como Usabilidade: Representa basicamente a interface sistema-usuário. Do R temos Reliability, traduzimos como Confiabilidade: Representa basicamente a eficiência e o índice de falhas do sistema. Do P temos Performance, traduzimos como Desempenho: Representa basicamente tempos de resposta e capacidade de processamento do sistema. Do S temos Supportability, traduzimos como Suportabilidade: Representa basicamente esforços necessários para manutenção e configuração do sistema. As definições acima representam o básico de cada uma das letras que compõem a sigla FURPS. A seguir entraremos em detalhes sobre cada uma das categorias, não ante