Este \u00e9 o primeiro de uma s\u00e9rie de posts que ir\u00e1 falar sobre qualidade de software. Antes que voc\u00ea saia correndo ao achar que vamos falar sobre teorias intermin\u00e1veis e processos enfadonhos, segura a\u00ed. Preparamos uma forma especial para falar com voc\u00ea sobre esse assunto.<\/p>\n
Vamos imaginar uma casa. Ela \u00e9 composta basicamente de alicerce, paredes e telhado. Ent\u00e3o, vamos usar essa analogia para compor a nossa abordagem:<\/p>\n
Vamos come\u00e7ar? No nosso primeiro post iremos apresentar a motiva\u00e7\u00e3o.<\/p>\n
Vamos come\u00e7ar pelo conceito de qualidade. Voc\u00ea j\u00e1 deve ter pensado nesse conceito v\u00e1rias vezes. E isso provavelmente ocorreu antes de adquirir um produto ou um servi\u00e7o, certo?<\/p>\n
Pois \u00e9, se pensarmos a respeito, veremos que nem sempre os nossos crit\u00e9rios de qualidade s\u00e3o claros. Assim, quando pensamos em qualidade, acabamos por nos expressar de diversas maneiras diante das situa\u00e7\u00f5es que nos s\u00e3o impostas. Por exemplo:<\/p>\n
As frases acima exp\u00f5em diferentes express\u00f5es relacionadas a aspectos de produtos e servi\u00e7os. As pessoas que falam exp\u00f5em percep\u00e7\u00f5es sobre o processo de fabrica\u00e7\u00e3o, a apar\u00eancia do produto, o atendimento<\/a> de uma necessidade. No fim, voc\u00ea observou que todas as situa\u00e7\u00f5es expressam, de uma forma ou de outra, o sentimento de satisfa\u00e7\u00e3o<\/strong>? Pois \u00e9, isso n\u00e3o \u00e9 coincid\u00eancia. \ud83d\ude42<\/p>\n Qualidade, de modo geral, est\u00e1 diretamente relacionada \u00e0s expectativas dos clientes<\/strong>. Assim, quanto mais um produto ou um servi\u00e7o atende \u00e0s expectativas, maior \u00e9 o grau de satisfa\u00e7\u00e3o dos seus clientes<\/strong>. Por isso, normalmente existe uma consider\u00e1vel preocupa\u00e7\u00e3o com a experi\u00eancia dos usu\u00e1rios e consumidores. A percep\u00e7\u00e3o do cliente quanto ao atendimento de suas necessidades e de seus desejos \u00e9 equivalente a sua percep\u00e7\u00e3o de qualidade. E isso \u00e9 fundamental para o sucesso do neg\u00f3cio<\/strong>.<\/p>\n Qualidade \u2192 Satisfa\u00e7\u00e3o<\/strong> A premissa b\u00e1sica de qualquer produto sempre \u00e9 que ele tenha qualidade. Isso porque quando adquirimos um produto ou um servi\u00e7o n\u00f3s esperamos que ele atenda nossas expectativas, sejam elas expl\u00edcitas ou impl\u00edcitas.<\/p>\n Uma defini\u00e7\u00e3o muito interessante \u00e9 citada por Andrii Dzynia, que trabalha como Engineering Coach na Spotify, em sua apresenta\u00e7\u00e3o intitulada Quality Built In<\/a>:<\/p>\n Quality is a \u2018state\u2019… when expectations match the reality.<\/p><\/blockquote>\n Vamos analisar um exemplo da vida real: uma pessoa vai at\u00e9 o mercado e adquire um pote de mostarda para colocar naquela pizza de sardinha que vai preparar em casa. Ela sempre compra a mostarda da mesma marca, porque sabe que suas expectativas s\u00e3o atendidas quanto ao sabor, aroma, consist\u00eancia, embalagem e conte\u00fado (o que tem dentro do pote \u00e9 realmente mostarda).<\/p>\n A partir desse exemplo, somos levados a pelo menos tr\u00eas conclus\u00f5es:<\/p>\n Logo, a percep\u00e7\u00e3o de qualidade de seu produto est\u00e1 relacionada ao n\u00famero de novos clientes<\/strong> que voc\u00ea ganha, ao n\u00famero de clientes que permanecem<\/strong> consumindo seu produto (ou contratando seu servi\u00e7o), e ao n\u00famero de clientes que falam bem de sua marca<\/strong>. E novamente, tudo est\u00e1 relacionado ao atendimento das expectativas de quem est\u00e1 do outro lado do balc\u00e3o. \ud83d\ude09<\/p>\n Com software n\u00e3o \u00e9 diferente. Podemos fazer v\u00e1rios paralelos com produtos e servi\u00e7os de software. No fim, chegaremos nas mesmas conclus\u00f5es. Qualidade \u00e9 um dos fatores decisivos n\u00e3o apenas para a sobreviv\u00eancia, mas tamb\u00e9m para o total sucesso do seu neg\u00f3cio. Por isso, qualidade \u00e9 importante! \ud83d\ude42<\/p>\n Qualidade \u00e9 um conceito subjetivo<\/strong>. De fato, mesmo no mundo do software, qualidade est\u00e1 relacionada \u00e0s pessoas, sejam elas usu\u00e1rios, stakeholders, testadores, ou desenvolvedores. E se est\u00e1 relacionado \u00e0s pessoas, sempre teremos margem para ambiguidades, conceitos relativos, aspectos culturais e opini\u00f5es divergentes. Ent\u00e3o, com toda essa subjetividade, como saber que seu software atende aos padr\u00f5es de qualidade esperados?<\/p>\n Basicamente, o teste de software visa garantir a qualidade, minimizando as incertezas e sistematizando os crit\u00e9rios de aceita\u00e7\u00e3o<\/strong>. Ele ajuda a validar se: as expectativas de todas as pessoas envolvidas est\u00e3o sendo atendidas (e est\u00e3o alinhadas); o software apresenta um bom funcionamento (parte disso est\u00e1 relacionada \u00e0s expectativas impl\u00edcitas – aquilo que \u00e9 inerente ao produto). Al\u00e9m disso, o teste tamb\u00e9m possibilita realizar verifica\u00e7\u00f5es complexas que um ser humano n\u00e3o conseguiria executar (pelo menos, n\u00e3o facilmente).<\/p>\n Contudo, teste n\u00e3o \u00e9 um puro sin\u00f4nimo de qualidade<\/strong>. Simplesmente executar testes n\u00e3o significa que o software atende a todos os crit\u00e9rios de qualidade. Os testes tamb\u00e9m precisam de um ciclo de planejamento, desenvolvimento, execu\u00e7\u00e3o e manuten\u00e7\u00e3o. E se essas fases n\u00e3o forem executadas com o m\u00ednimo de cuidado, a consequ\u00eancia pode ser resultados n\u00e3o confi\u00e1veis, verifica\u00e7\u00f5es equivocadas e o abandono da pr\u00e1tica do teste. Por isso, estude, explore e questione seus testes assim como voc\u00ea faz com seu sistema<\/strong>. Isso levar\u00e1 voc\u00ea a aprimorar o entendimento dos requisitos e a forma escolhida para atend\u00ea-los. Acreditamos que um dos mais importantes benef\u00edcios do teste de software \u00e9 fazer voc\u00ea pensar diferente, suscitando perguntas que voc\u00ea n\u00e3o teria feito em outros momentos. E isso enriquece o seu projeto.<\/p>\n A garantia de qualidade deve acompanhar o software desde a sua concep\u00e7\u00e3o at\u00e9 sua manuten\u00e7\u00e3o. E durante todo o ciclo de vida dele, todos os envolvidos tornam-se respons\u00e1veis pela qualidade<\/strong>. Ent\u00e3o, o teste nos ajuda a sistematizar a garantia dessa qualidade.<\/p>\n Se voc\u00ea ainda n\u00e3o est\u00e1 convencido que possuir um processo que inclua teste de software \u00e9 indispens\u00e1vel, calma a\u00ed. Agora, vamos apresentar a voc\u00ea sete \u00f3timos motivos para isso, os quais representam benef\u00edcios que s\u00e3o trazidos para o seu projeto a partir dessa pr\u00e1tica:<\/p>\n A pergunta que o teste ajuda a responder aqui \u00e9: Funciona como o cliente espera?<\/strong><\/p>\n Quando testamos, precisamos nos perguntar sobre o que nosso software deveria fazer, isso porque precisamos saber o que testar<\/strong>. Assim, principalmente os testes focados em aspectos funcionais e comportamentais, evidenciam desalinhamentos entre o que os usu\u00e1rios esperam e o que est\u00e1 sendo produzido. Se o usu\u00e1rio quer um sistema que permita a ele cadastrar fotos e descri\u00e7\u00f5es da sua cole\u00e7\u00e3o de bonsais, o sistema n\u00e3o deveria oferecer um gerador de memes?<\/p>\n Olhar para as especifica\u00e7\u00f5es em frente ao resultado final, somente de modo arbitr\u00e1rio, raramente \u00e9 o suficiente para percebermos expectativas n\u00e3o atendidas ou mal interpretadas. Ao planejar, escrever e executar os testes, somos impelidos a questionar e a reinterpretar aquilo que foi descrito como requisito do sistema<\/strong>. Assim, esse exerc\u00edcio frequentemente revela problemas na escrita e na interpreta\u00e7\u00e3o da especifica\u00e7\u00e3o, al\u00e9m de problemas no pr\u00f3prio entendimento das pessoas envolvidas no projeto.<\/p>\n Vale lembrar que no centro de todos os prop\u00f3sitos est\u00e1 a satisfa\u00e7\u00e3o do cliente. Logo, \u00e9 a expectativa dele que precisa ser atendida. Por isso, quando planejamos e escrevemos um teste, e tamb\u00e9m quando interpretamos o resultado dele, a pergunta que sempre dever\u00edamos fazer \u00e9: essa situa\u00e7\u00e3o est\u00e1 de acordo com o que o usu\u00e1rio do meu sistema espera<\/strong>?<\/em><\/p>\n \u201cEu tinha certeza que o usu\u00e1rio queria assim, mas agora n\u00e3o sei mais.\u201d \ud83d\ude41<\/p>\n Provavelmente isso far\u00e1 com que voc\u00ea revisite a especifica\u00e7\u00e3o, consulte novamente os stakeholders, fa\u00e7a um novo teste com um usu\u00e1rio. E no fim, voc\u00ea ter\u00e1 realizado um incr\u00edvel exerc\u00edcio de amadurecimento de seu projeto<\/strong>.<\/p>\n A pergunta que o teste ajuda a responder aqui \u00e9: Funciona como o desenvolvedor espera?<\/strong><\/p>\n O que acontece normalmente \u00e9 que voc\u00ea, no papel da pessoa que desenvolve, assume sempre que desenvolveu certo :). Mas voc\u00ea deve concordar que \u00e9 humanamente imposs\u00edvel testar todas as possibilidades existentes durante o funcionamento de um sistema complexo. Ainda mais, sem uma t\u00e9cnica clara e bem definida. Em outras palavras, se j\u00e1 \u00e9 dif\u00edcil imposs\u00edvel detectar todos os defeitos com testes adequados, imagina sem! \ud83d\ude2e<\/p>\n Mas antes que voc\u00ea fique bravo comigo, n\u00e3o estou dizendo que voc\u00ea n\u00e3o sabe programar! Defeitos sempre ir\u00e3o existir, e podem se manifestar em situa\u00e7\u00f5es que nunca haviam sido previstas. Ent\u00e3o, podemos usar as caracter\u00edsticas sistem\u00e1ticas dos testes a nosso favor para minimizar esses problemas! Diferentes n\u00edveis de teste levam a diferentes n\u00edveis de captura de defeitos. E testes automatizados, mais do que qualquer outra instrumenta\u00e7\u00e3o, s\u00e3o uma forma muito confi\u00e1vel de verifica\u00e7\u00e3o cont\u00ednua do software.<\/p>\n Quem nunca passou por uma situa\u00e7\u00e3o do tipo \u201cTinha certeza que esse erro nunca iria ocorrer! Como eu iria adivinhar que a atualiza\u00e7\u00e3o dessa biblioteca iria mudar o tipo do dado ap\u00f3s esse parser?\u201d<\/p><\/blockquote>\n Pois bem, sempre ir\u00e1 ocorrer uma situa\u00e7\u00e3o que foge ao controle de quem desenvolve. N\u00e3o podemos confiar na sorte. Ent\u00e3o, precisamos usar ferramentas adequadas para garantir que qualquer altera\u00e7\u00e3o, e tamb\u00e9m novas implementa\u00e7\u00f5es, n\u00e3o estejam guardando surpresas desagrad\u00e1veis. E manter uma boa cobertura de testes, principalmente os automatizados, \u00e9 uma das melhores ferramentas para isso.<\/p>\n A pergunta que o teste ajuda a responder aqui \u00e9: Voc\u00ea anda questionando seu projeto?<\/strong><\/p>\n Com certeza, al\u00e9m de t\u00e9cnicas como code review e pair programming, o desenvolvimento de testes a n\u00edvel de c\u00f3digo \u00e9 uma das formas mais baratas e r\u00e1pidas de detectar problemas comportamentais e estruturais de seu software. Isso se deve essencialmente \u00e0 necessidade de tornar o software test\u00e1vel, o que leva a questionamentos sobre a implementa\u00e7\u00e3o. Consequentemente, voc\u00ea passar\u00e1 mais tempo tomando caf\u00e9 em meio a refatora\u00e7\u00f5es aderentes a padr\u00f5es de projeto, boas pr\u00e1ticas, clareza, objetividade e… testabilidade. \ud83d\ude42<\/p>\n Normalmente se costuma falar em testes de unidade, com os quais se verifica a menor unidade de c\u00f3digo test\u00e1vel do software. Mas outros n\u00edveis de teste tamb\u00e9m ajudam a verificar n\u00e3o apenas se o funcionamento do software est\u00e1 de acordo com o esperado, mas tamb\u00e9m se a forma usada para alcan\u00e7ar os objetivos \u00e9 a mais adequada. Sabe aqueles code smells? Pois \u00e9, o teste te ajuda com isso tamb\u00e9m. \ud83d\ude09<\/p>\n Por exemplo, um teste de performance poderia ajudar voc\u00ea a identificar a necessidade do uso de uma cache. Um teste de unidade poderia indicar que o princ\u00edpio de responsabilidade \u00fanica est\u00e1 sendo ferido em algum ponto. Um teste de integra\u00e7\u00e3o poderia evidenciar o uso inadequado de uma interface. Um teste de componentes poderia alertar sobre uma intera\u00e7\u00e3o desnecess\u00e1ria entre unidades.<\/p>\n Se voc\u00ea j\u00e1 desenvolveu algum tipo de teste de software, j\u00e1 deve ter passado por algum momento que parecia imposs\u00edvel fazer aquele teste, n\u00e3o \u00e9? Se voc\u00ea concordou, essa foi a hora certa para rever sua implementa\u00e7\u00e3o. Saiba que quando o teste est\u00e1 muito (muito mesmo!) dif\u00edcil de desenvolver, \u00e9 um forte ind\u00edcio de que o design de seu sistema pode estar torto. Revise, questione, desentorte e tente novamente. \ud83d\ude42<\/p>\n A pergunta que o teste ajuda a responder aqui \u00e9: Voc\u00ea est\u00e1 tendo surpresas com seu software?<\/strong><\/p>\n Possuir uma estrat\u00e9gia de testes adequada, entre outras coisas, oferece uma verifica\u00e7\u00e3o bem estruturada de seu sistema e o benef\u00edcio de garantir seu funcionamento adequado. Mas o que faz brilhar os olhos mesmo s\u00e3o os testes automatizados!<\/p>\n
\nSatisfa\u00e7\u00e3o \u2192 Expectativas atendidas ou superadas<\/strong><\/p>\nEnt\u00e3o, por que qualidade \u00e9 importante?<\/h2>\n
\n
E o teste? Por que ele \u00e9 importante?<\/h2>\n
1. Alinhar as expectativas<\/h3>\n
2. Pegar o defeito antes do cliente<\/h3>\n
3. Detectar problemas de design da aplica\u00e7\u00e3o<\/h3>\n
4. Manter o sistema est\u00e1vel<\/h3>\n