CategoriesDev Blog,  Quality Assurance

Vou desenvolver um novo produto – quando devo envolver o QA?

Antes de mais nada, vamos elucidar o termo QA. QA é a abreviação de Quality Analyst, que é o profissional responsável por garantir a qualidade do produto final, mas também é o responsável por garantir a qualidade de todo o processo de desenvolvimento de software. É diferente do testador ou analista de testes (TA), que escreve os casos de testes e executa os testes manuais, mas não se envolve na qualidade do processo.

Agora vamos à resposta para a pergunta: Quando devo envolver o QA no desenvolvimento de um novo produto?

Independentemente do estágio do desenvolvimento, de o produto ser novo ou uma atualização em um já existente, a resposta é O quanto antes possível. Mas supondo que seja um produto novo, e que na sua equipe existam um ou mais QAs, esse envolvimento deve ser realmente ainda mais cedo, e vamos entender os motivos ao longo desse artigo. através de uma breve descrição da sua participação em cada fase da construção de um produto.

Na concepção do produto

Um QA pode ajudar no levantamento dos requisitos de DevOps, por exemplo, atuando na definição dos ambientes e das ferramentas necessárias para garantir a qualidade não apenas no nível funcional do software, mas em todo o processo de desenvolvimento. Um bom profissional irá ajudar na definição do fluxo de desenvolvimento, dos artefatos que devem ser gerados para a qualidade, como eles serão administrados, e em vários outros aspectos do desenvolvimento de software. A relação de responsabilidades e habilidades de um bom QA cabe facilmente em um outro artigo, mas muitos deles podem ser encontrados na literatura atual.

Ainda na fase de concepção do sistema, um QA experiente pode ajudar a equipe de análise de requisitos ou de UX (User eXperience) a definir os requisitos do produto e ajudar o cliente a entender quais suas reais necessidades, aproveitando sua vivência em diversos outros projetos /produtos em diferentes clientes.

Fase de análise

Depois, dentro de um contexto ágil, o QA pode (na verdade DEVE) ajudar o Product Owner a escrever os critérios de aceite das stories, e também a melhorar a qualidade dos artefatos, ajudando na tradução das necessidades dos clientes em uma visão facilmente compreendida por um desenvolvedor. A arte de converter requisitos em stories que o desenvolvedor compreenda de forma assertiva não é dominada tão facilmente, e devido ao fato do QA estar sempre próximo da equipe de desenvolvimento e do PO, muitas vezes consegue capturar as nuances que envolvem essa conversão melhor do que ninguém. Dessa forma, também é seu papel ajudar na qualidade dos artefatos gerados na fase de análise.

Desenvolvimento e testes

Nessa fase, o QA já deveria estar totalmente integrado ao time e ao produto, desempenhando, dentro do contexto ágil, suas atividades de analista de testes dentro das sprints: i) escrevendo os casos de testes; ii) executando os testes funcionais (e os outros que ele ache pertinentes); iii) coletando evidências; iv) relatando bugs; v) escrevendo os testes automatizados; e outros.

Caso esse não seja o cenário, e ele tenha sido envolvido no meio do desenvolvimento, terá que correr atrás do prejuízo durante as sprints. O primeiro passo será estudar as regras de negócio, executar testes exploratórios, escrever uma base de testes de regressão, executar os testes funcionais e abrir os muitos bugs que ele irá encontrar (seja em uma ferramenta ou em uma planilha, essa documentação é fundamental). Não menos importante, o QA precisa evangelizar o time nas práticas de qualidade, demonstrando o valor da qualidade a cada iteração.

Ao longo dos sprints, os bugs vão sendo priorizados e corrigidos, até que se chegue a uma estabilização do processo de desenvolvimento dentro da metodologia ágil.

Entrega e manutenção

Em muitas empresas, o QA é responsável por apresentar as entregas para os clientes, devido ao seu conhecimento das regras de negócio e a sua habilidade em manusear o sistema. Tem também a responsabilidade por manter a base de conhecimento não apenas dos produtos desenvolvidos, mas também toda a estrutura de documentação dos testes.

No entanto, se no desenvolvimento do seu novo produto, nenhum QA foi envolvido até agora, por favor não o coloque aqui nessa fase. Tenha compaixão.

Conclusão

Vimos nesse artigo a importância de envolver o QA (ou a equipe de QAs) no desenvolvimento de novos produtos, antes mesmo do início do desenvolvimento. Infelizmente a liderança de algumas empresas ou áreas tem a mentalidade de que o QA é apenas um bug finder, e que envolvê-lo próximo do marco de entrega, ao final de quase todo o ciclo de desenvolvimento do produto, é o suficiente para identificar os bugs e fechar o processo de validação.

A garantia da qualidade é obtida durante todo o ciclo de desenvolvimento, e é de responsabilidade de todo o time. Envolver um QA no final do processo é assumir um risco enorme de colocar no mercado um produto repleto de defeitos, que serão encontrados pelos usuários/clientes e terão de ser tratados pelo time de desenvolvimento ou pós-venda, de acordo com a cadência do time de desenvolvimento ou suporte.

Hoje em dia, em um mercado tão competitivo, é extremamente trabalhoso estabelecer uma relação de confiança entre cliente e fornecedor. Essa relação se inicia pela equipe comercial, passa por diversos níveis na empresa, e termina na manutenção pelo time de suporte do produto final que foi entregue. O vínculo criado durante todo esse processo pode até parecer ser o mais forte possível, mas se no final um produto cheio de defeitos for entregue, essa relação de parceria pode ser destruída em pouquíssimo tempo. Sendo assim, envolva o seu QA para ontem!

CategoriesDev Blog

What is Kafka and why I should consider using it?

Over the years, technological evolution is getting faster, all over the world, every year, we generate more data. Be able to deal with this scenario and extract the right information, may define the success of the companies.

Technological evolution has allowed us to have more connectivity and portability, which has resulted in a universe of possibilities to evolve our products. Today, we have social networks, IOT (Internet of Things), transaction data from our software and data ingestion from external systems etc. All of these sources bring us data all the time and to handle such a high volume of data, your software must be prepared to maintain, process, transform and produce new data in a safe and viable way for your business. Apache Kafka is a technology that makes it easier for us to deal with this complexity.

But anyway, what is Kafka?

Apache Kafka is an open-source distributed event streaming platform highly scalable, which aims to provide a platform with low latency for processing data in real time. Like other technologies used in modern systems such as Kubernetes and Cassandra, Apache Kafka is a distributed system, that is, its processing and its data are distributed in its nodes (brokers) that operate in cluster mode, guaranteeing the fault tolerance and data durability.

As a data streaming platform, Apache Kafka diverges from the old batch processing that was so common to work years ago and brings us a series of tools and solutions that allow us to deal with a continuous flow of data and to treat it, as soon as each record is generated in our system.

Apache Kafka consists of the following main elements:

Broker: Handles all interactions with clients (Producers, Consumers and Stream Apps) and maintains persisted data; Zookeeper: Maintains the status and settings of the nodes in your cluster;
Producer: Send records to brokers;
Consumer: Consume records from the broker;

Stream App: Application that reads and writes data in your cluster.

How Kafka deals with my messages?

In Apache Kafka, we refer to messages as records, to understand how these records are sent and consumed by Apache Kafka, it is necessary to know what topics, partitions and records are.

A topic is a particular data stream, in which records are published and consumed. Each topic is sub-divided into partitions, and each new record received is allocated to one of these partitions and is assigned a sequential code that we call offset.

The record is composed by key and value, every record sent with the same key to the same topic, will always be allocated in the same partition.

For each different consumer in our system, Apache Kafka tracks what was the last offset consumed for that topic/partition, so when that consumer gets new records, only the records he didn’t consumed are delivered.

The partition is what allows parallelism when consuming records from a topic by the same application, the maximum number of instances in parallel that you can have processing the topic records for the same application, is equal to the number of partitions in the topic.

In order for Apache Kafka to understand that different instances are part of the same application, they must be labeled with the same consumer group name and this is how the cluster will understand that it must balance the processing of partitions between the instances, as shown in the figure below:

As the consumer always handles the deviations of a partition sequentially and records with the same key are always sent to the same partition, Apache Kafka enables parallel processing, ensuring sequential processing of records with the same key.

Why should I consider using Kafka?

It is very difficult for our system to operate alone, it is necessary to perform integrations with other systems and, often, what we face is a scenario of integration between the systems, similar to the following figure:

This diagram illustrates how often the integration between systems in companies is confusing. The use of several implementations with different technologies for the integrations was the most common path to be followed, which led us to a chaotic scenario that made it impossible to evolve the systems. The situation was even worse due to the scalability limitations of traditional solutions, it was practically impossible to have a real- time integration between all of these systems.

Apache Kafka allows us to decouple data processing and systems, allowing for much more efficient integration. The idea is to centralize all asynchronous communication through Kafka, so that you don’t have so many different solutions. With Kafka, our scenario would look like this figure:

That way, when your data is inside Kafka, you can share it with any other system you want. As Apache Kafka operates in publisher and subscriber mode, we can publish an event from a given system and whoever is registered to handle this message can respond in real time. Thus, we can integrate our systems in a much more efficient way with communication through Apache Kafka.

Why Apache Kafka and not another solution?

Apache Kafka is an open source project that has a large active community and is maintained by Confluent that leverages the power of Kafka, extending its functionality.

Apache Kafka has been used on a large scale around the world, working with hundreds of applications and thousands of software engineers working independently in the same cluster, transmitting trillions of messages.

Adoption in the market is proof of the efficiency of Apache Kafka and that it can handle complex scenarios with high data throughput and deliver a real time processing.

More than 80% of all Fortune 100 companies trust, and use Kafka, below is the top-ten largest companies using Kafka, per-industry:

  • MANUFACTURING: 10 out of 10;
  • BANKS: 7 out of 10;
  • INSURANCE: 10 out of 10;
  • TELECOM: 8 out of 10.
CategoriesDev Blog,  Quality Assurance

Cypress: o novo conceito em testes automatizados

Atualmente o trabalho de um bom QA (Analista de qualidade) é desafiador, devido ao cenário complexo em que os sistemas são desenvolvidos. Tendo como base esse cenário dentro de um contexto ágil, torna-se moroso o trabalho do QA quando necessita realizar a mesma bateria de testes mais de uma vez, para garantir assim a qualidade do software que será entregue. Diante disso, a importância da automatização de testes aumenta exponencialmente, pois facilita o trabalho desses profissionais, tornando a execução de testes de regressão mais simples, rápida e com resultados imediatos. A garantia da qualidade também é maior, pois um teste End-to-End (E2E) automatizado pode ser rodado após a entrega de um pacote e encontrar bugs(defeitos) em features anteriores, facilitando e agilizando o trabalho não só do QA como do desenvolvedor.

Existem no mercado muitas ferramentas que auxiliam e facilitam na automação de testes de software, cada uma com suas características, vantagens e desvantagens, e nesse artigo vamos conhecer uma delas: o Cypress.

Os testes automatizados basicamente permitem simular o comportamento do usuário no sistema via navegador. Hoje o mercado faz uso do framework Selenium para criação de testes automatizados E2E, este é bastante difundido no meio por ser uma ferramenta livre e gratuita, que permite a criação de scripts de testes pelas principais linguagens de programação como Java, Python, Ruby, C# e outras, mas conta com uma curva de aprendizado íngreme.

Uma alternativa recente é a ferramenta Cypress, um novo framework de testes também de código aberto e de fácil configuração, sem a necessidade de baixar inúmeras ferramentas e bibliotecas separadas para configurar seu conjunto de testes. Esse novo executor de testes auxilia e facilita muito a criação de testes automatizados E2E de forma simples, prática e rápida. Sua curva de aprendizado é bem menor e seus scripts são escritos via JavaScript. O Cypress veio para revolucionar e contribuir para um desenvolvimento de testes automatizados de maneira mais ágil.

O que é o Cypress?

Cypress é uma ferramenta poderosa de última geração desenvolvida especialmente para engenheiros de controle de qualidade (analistas QA) e desenvolvedores, que podem usá-la para os testes unitários. Totalmente baseado em uma nova arquitetura isenta do Selenium, apresenta o próprio painel exibindo exatamente o que está acontecendo durante a execução dos testes. À medida que o script é escrito é possível acompanhar como será a execução do teste através desse painel, auxiliando o técnico em quais partes precisam de ajustes no teste.

O Cypress utiliza o Node JS como servidor e interpretador de sua linguagem JavaScript. Trabalhando juntos, cypress e Node JS estão em constante sincronização e comunicação para execução de tarefas, tornando a experiência da escrita e execução dos testes muito mais ágil, já que o Cypress também opera na camada de rede, na leitura e alteração de tráfego na web em tempo real.

Cypress contém uma completa documentação disponível em cypress.io que facilita a escrita dos testes tornando-os mais confiáveis, com dicas e exemplos que podem ser aplicados sem haver necessidade de perder tempo na busca pela web já que todo conteúdo se encontra concentrado nesse site.

Por que utilizar o Cypress?

Seu principal foco é o teste E2E. Dentre uma gama extensa de ferramentas que utilizam o Selenium para automatização de testes, operando-os fora do navegador e executando os comandos remotamente pela rede, o Cypress surge para criar uma nova forma de automatizar os testes. Ele executa todos os testes no mesmo ciclo de execução do sistema que está sendo testado, sem usar o controle remoto que o Selenium utiliza para acesso ao sistema. Seu principal diferencial é ter sido desenvolvido para que os testes aconteçam simultaneamente ao desenvolvimento da aplicação. Claro que depende muito do processo utilizado no desenvolvimento, mas o Cypress sendo simples contribui com o aumento de produtividade no quesito de escrita de testes e aumenta a qualidade do sistema final.

Há possibilidade de criar testes apenas de front-end e back-end, não só testes E2E. Como ele tem o controle nativo da aplicação controlando-a de cima para baixo, além de operar dentro da camada de rede, lendo e alterando o tráfego da web em tempo real.

Os logs de comandos são gravados para revisitar posteriormente os resultados. Eles são exibidos em tempo de execução dos testes, à medida que os testes são escritos e salvos o Cypress já executa a automação para que o técnico possa verificar se o que foi codado está aderente ao teste, facilitando e muito no debug da automação.

Captura de tela para testes falhos e gravação de vídeos de toda execução dos testes, sem configurações extras uma vez que o Cypress tem acesso nativo ao SO uma vez que ele todo é instalado localmente na máquina, e não utilizado de forma remota, além de possibilitar criação de relatórios de testes de forma mais simples que o Selenium.

Cypress vs. Selenium

Cypress tem controle e acesso nativo a toda aplicação, e com esse recurso torna o teste muito mais rápido e confiável para quem está automatizando. Isso possibilita a criação dos casos de teste automatizados de forma simultânea com o próprio desenvolvimento da aplicação. O Cypress controla a aplicação de cima para baixo, onde assim interpreta o que ocorre fora e dentro do navegador que está sendo testado, fornece ndo resultados muito mais consistentes do que o Selenium, por conta de a ferramenta ser capaz de compreender os eventos assim que eles acontecem . Além de operar dentro da camada de rede, a ferramenta interpreta e altera o tráfego da web em tempo real.

Já o Selenium controla a aplicação de forma remota, é necessário um suporte diferente para cada tipo de navegador que será testado, e sua curva de aprendizado é bem ígreme, sendo necessária a instalação e configuração de inúmeras ferramentas e bibliotecas para que o conjunto do teste possa funcionar corretamente, uma vez que não são instalados localmente na máquina usando tais recursos de forma remota. O Selenium também necessita de várias ferramentas para auxiliar no controle dos navegadores, mas também é bem mais livre no quesito de linguagens de programação, pois tem suporte para a maioria das linguagens usadas atualmente.

Iniciantes em automação de teste? Use o Cypress!

Sem muito esforço para preparar a máquina para instalar essa super ferramenta. Instale:

  • IDE VSCode com suporte a linguagem de programação
  • JavaScript; Node.js
  • Cypress via npm no seu terminal
npm install cypress

Pronto! Para executar é só passar o comando abaixo via terminal.

./node_modules/.bin/cypress open

Uma GUI com vários exemplos de testes é aberta para poder acompanhar o quão rápido e fácil é utilizar os testes com Cypress.

A estrutura do teste já é construída assim que que a interface do Cypress é aberta, com as pastas Fixtures, Integration, Plugins e Support.

Todos os testes (Ex: seu_teste.spec.js) devem ficar na pasta Integration, essa é a pasta com todos os arquivos apresentados dentro da
Interface do Cypress. Já a pasta Fixtures contempla os arquivos .json que auxiliam inserção de massa de dados aos testes, assim o Cypress sozinho já sabe onde buscar os dados para rodar nos testes, basta chamar o arquivo com o .json correspondente em Fixtures. Dentro da pasta S upport pode-se inserir todos os arquivos .js de comandos que possam ser úteis nos testes, códigos que podem ser colocados em funções e chamados dentro dos testes, sem a necessidade de repetição de código. Por fim, na pasta Plugins há um arquivo (index.js) que contém todos os plugins adicionais que serão utilizados nos testes. O principal plugin instalado é o Xpath , que auxilia no mapeamento de elementos das aplicações, semelhantes as ferramentas listadas (https://www.w3schools.com/xml/xml_xpath.asp).

Após as devidas apresentações basta começar a codar os testes. Na interface do Cypress, além do log de comandos apresentado à esquerda, temos o app preview à direita, que auxilia e muito no mapeamento de elementos. Com a ferramenta playground, basta selecionar e clicar no elemento que deseja mapear e pronto, na parte superior do app preview você pode simplesmente “copiar” o comando do mapeamento do elemento, inserir no seu código de teste e fazer os Assertions.

Como vimos, em virtude de tudo que foi mencionado, o Cypress é uma ferramenta poderosa, completa e fácil de utilizar, e mesmo sendo iniciante você consegue criar um teste automatizado de forma simples sem precisar de tantas configurações para ter em mãos um teste robusto e monitorado. Claro que algumas dúvidas podem surgir, mas basta recorrer ao cypress.io para encontrar um exemplo que te ajude de forma concisa na vasta documentação disponível.

CategoriesDev Blog,  Product Development

Sotware quality: the pillar of product development

In IT area, quality assurance, commonly called QA, is the name given to the process of analyzing how well a system or a product has been developed, according to its requirement and needs of the users.

QA’s mission is to reduce the risks of, in the final delivery, the product been delivered with defects and functionalities that affect the user experience, thus bringing losses to the company and rework of the development team. When there is a well-defined, efficient and fully-developed testing process, in addition a self-manageable test team, we have the fundamental pillars to ensure the product’s qualities are delivered before its production. It’s important to emphasize that the cost to fix bugs from a system in production is bigger that the cost to fix them in the development phase.

One of the main challenges of quality professionals is to define what quality is inside the context, considering variables such as deadline, budget, product knowledge, team among other challenges.

That’s why is always important to emphasize the significance of the quality process within the system development, being an essential part from the begining and being necessary in the end, so that the whole team realizes the added value to the product because when deliveries are made with bugs that implicate the operation of the system, the delivered value to the customer is equally compromised.

Choosing quality practices throughout the development of the product is to invest in failure prevention because once introduced in the work process, it is guaranteed that the product is dilevered with minimal errors. By running the tests with warranty, it’s possible to simulate the use of the system, making possible issues being avoided in the day to day life of the user.

System tests validate several conditions that may identify some issues. For this there are the Funtional Tests that validate the operation of the aplication according to the requirements defined by users, that is, they validate the functions in wich it was agreed to run, performing as planned and expected by the users. The Usability Tests valide how the users behaves using the system, validating if it is intuitive and usual, within the rquested requirements.

The Automated Tests are used to control the execution of tests through testing instruments, comparing if the final result is in accordance with the expected result. One of the main objectives of this test is to reduce time, since a large volum of tests can be performed in a short period of time without the need for manual events, another advantage is the possibility of repeating a controled suite of test cases several times (Regression Test) within the development cycle. This is one of the points that make it possible to guarantee (and not control) the quality of the software. Other important tests to run before a delivery are the Security Tests wich validates if the application is secure against supposed attacks, and Load and Stres and Performance Tests, validating the aplication’s capacity in relation to its response time, capacity of concurrent users using the system, amount of resouces in use (memory, disk and processing), among others. However, it’s important to emphasize that these tests creat costs and time to be developed and executed, so their executions must to be previously agreed and planned with the product requester.

However, to ensure that the tests are executed effectively and that the result is indeed satisfactory there are some practices that can be adopted to make the process easier, are they:

Who writes the test cases shouldn’t be the same person who developed the system – To write and run the test scenarios is necessary an expert tester, different from a developer profile, who will decode the system and will have dificulties to finding errors in your own code; and

Time available to run the tests – It’s known that in the ideal world all projects and development team would consider time for the test analyst to execute the scenarios, but that is not that way that it works. So it’s necessary to always consider the reality of the project being executed, so that the test being a essential part of the delivery; and

Maturity of testers – What’s the use of a well-specified and developed product with high tech if the final delivery doesn’t satisfy the customer? It’s there where the tester shows its value by ensuring the qualiy of the developed product, adopting the most effective models to perform tests and ensure the consistency of the system; and

Test scenarios are infinitie – There’s always a funcionality or a scenario that can be validated and there will never be time to test all of them, so it’s necessary to consider the relevance of the functionalities to be tested at the time of the creation of the test case, because if every single detail is considered there will be no time to run all the tests; and

Be pessimistic – Seemingly inoccent test can be a trap! As the maturity of the tester grows, the feeling increases and the simplest scenarios end up demanding the same atention as the complex ones; and

Record and track everything -Keeping recorded and tracked all failures found in the environment is an essential part of the quality of test. An important tip: when registering a bug, describing with details every step performed until the error is reproduced makes the developer’s work easier and reduces the time to fix it. Track and test again the error until the bug is eliminate; and

Don’t be obvious – During tests, explore the system in order to find errors unnotice by the development team or even the business area. Try not to run the test by the easy path, and construct test scenarios to indicate this situations; and

Think as the user – This makes it easier to develop test scenarios and implementation of the tests because expands the tester’s mind to the user’s reality and not only cases related to the system.

An essential part of quality assurance in test execution is to follow best practies in developing test scenarios. Tha main thing is that the test case must to be self-sufficient, comprehending all steps to reach the expected result, so that the tester can execute it without impediments. Avoidng test cases from being extensive and tiring makes the tester keeps on the focus, for this it’s important to write the steps clearly and objectively, describing the expected result with the execution. The test cases must be written waiting for positive and negative results of the system.

Regarding the quality of the system, the developers must not disregard the needs and roles of users because each customer has a different need in relation to the same product. In general, users are more interested in the system performance, its functionality and how it will respond their needs. With the most competitive market and the increase of the supply products, the customer is aware of his power. This demands a higher quality in product development and quality assurance to atends this new customer profile.

As any process, developing a system is also subject to failures that can disappointed the end user. The products need to be developed considering that they will be released to users with the quality levels that they expected at the begining of the project. Thereby, giving due value to the quality area and including their values and practices from the biginnng of the project is essential for value deliveries that satisfy customers.

Ana Luiza de Freitas Gil Câmara Santos | Quality Analyst

References

OLIVEIRA, Thaís. Automação de testes: o que é, quando e por que automatizar. Medium, Apr 03, 2018. Available in: <https://medium. com/venturus/quais-as-raz%C3%B5es-para-automa%C3%A7%C3%A3o-de-testes-c177cbd9397>. Access in: Jul 01, 2020.

CARVALHO, Ingrid. Boas Práticas de Teste. Medium, Apr 11, 2019. Available in: <https://medium.com/@ingrid.carvalho.mo/boas-pr% C3%A1ticas-de-teste-fd826e25f68>. Access in: Jul 07, 2020.

SANTOS, Glyciane Silva. Melhores práticas na elaboração de casos de teste. Cedrotech, Jun 01, 2018. Available in: <https://blog. cedrotech.com/melhores-praticas-na-elaboracao-de-casos-de-teste/>. Access in: Jul 07, 2020.

ABREU, Bruno. Como manter a qualidade durante um processo de desenvolvimento digital. One Day Testing [s.d], Available in: <https:// blog.onedaytesting.com.br/qualidade-desenvolvimento-digital/>. Access in: Jul 16, 2020.

RICARDO, Diana Rúbia Rodrigues. Desenvolvimento de uma Metodologia para Testes Exploratórios. UFPE, Recife, Aug 22, 2007. Available in: <https://www.cin.ufpe.br/~tg/2007-1/drrr.pdf>. Access in: Jul 18, 2020.

QUALIDADE de Software. DevMedia [s.d], Available in: <https://www.devmedia.com.br/qualidade-de-software/9408>. Access in: Jul 22, 2020.

Proudly powered by Wpopal.com