tag:blogger.com,1999:blog-51699347632848155892024-03-12T23:18:00.691-03:00Base de Teste de SoftwareUnknownnoreply@blogger.comBlogger14125tag:blogger.com,1999:blog-5169934763284815589.post-23231703741626305112011-02-13T13:29:00.005-02:002011-09-24T09:33:34.119-03:00Especialização é o melhor caminho?<div style="text-align: justify;">Essa pergunta é frequente em várias áreas de atuação, principalmente quando o assunto é a busca por maiores níveis de produtividade e qualidade diferenciada em relação à concorrência. </div><div style="text-align: justify;">Quando pensamos no processo de desenvolvimento de software essa questão torna-se ainda mais intrigante, pois trabalhamos com atividades nem sempre muito exatas; talvez quase nunca! Desenvolver um software e também testá-lo com excelência, geralmente requer muita imaginação, intuição e outras aptidões, que em cenários de grande especialização podem ficar prejudicadas.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Nesse contexto, uma especialização elevada na execução das atividades pode comprometer os resultados, mais do que alavancá-los pela maior produtividade e qualidade supostamente decorrente dessa especialização. Mas por que isso ocorre, se em tese, teríamos profissionais mais capacitados e com perfil mais adequado a cada área de atuação?</div><div style="text-align: justify;"><br />
</div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4cefCMoQ1dSExOTLSXN1PkTdbUWzk9OCZdF1tNJpJdh_D3c7ewGTvnqbMjT9GfL5G6pkQ4WZh5cLqmSv2PA_G2t8irYaCfGPLIkr1zgu2XvmNjXXbP2GEHDADhlmYZse1Jz-p8dNdfw8B/s1600/Linha+de+Produ%25C3%25A7%25C3%25A3o+07.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="141" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4cefCMoQ1dSExOTLSXN1PkTdbUWzk9OCZdF1tNJpJdh_D3c7ewGTvnqbMjT9GfL5G6pkQ4WZh5cLqmSv2PA_G2t8irYaCfGPLIkr1zgu2XvmNjXXbP2GEHDADhlmYZse1Jz-p8dNdfw8B/s400/Linha+de+Produ%25C3%25A7%25C3%25A3o+07.jpg" width="400" /></a></div><div class="separator" style="clear: both; text-align: center;"></div><div class="separator" style="clear: both; text-align: center;"></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">De fato, a especialização pode trazer um conhecimento específico e um foco no resultado que deveria ter como consequência a excelência e maior produtividade na execução de um processo produtivo. O problema é que não somos máquinas em uma esteira de produção, integradas através de interfaces cuidadosamente projetadas e ajustadas. Isso ocorre em uma montadora de automóveis, por exemplo, onde robôs executam atividades repetitivas e sem a necessidade de "pensar diferente". Nesse caso, produtividade e exatidão são palavras de ordem!</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Entretanto, os profissionais de tecnologia são únicos e repletos do pensar diferente, como só os seres humanos conseguem ser. E isso é muito bom! Mas será então impossível falarmos de especialização em nossa área? </div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Acredito, sinceramente, que podemos trabalhar de forma especializada ao longo do processo de desenvolvimento de software, mas também que devemos ter um cuidado extremo com as interfaces entre as diversas áreas de especialização intervenientes em nossos projetos. Quando pensamos em especializar nossas equipes, temos que cuidar para que os processos da organização garantam uma integração efetiva entre elas, pois sem isso estamos mais expostos a conflitos e desacordos, por não se ter uma visão clara e recíproca das necessidades e problemas de cada área envolvida, o que pode comprometer significativamente as chances de sucesso dos projetos.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Assim, para uma organização que deseja implementar a especialização em suas áreas produtivas, faz-se necessária a existência de processos em constante evolução e melhoria, ajustáveis a novas situações trazidas pelos projetos. Além disso, a atuação correta e tempestiva dos níveis gerenciais e lideranças da organização é fundamental, no sentido de viabilizar um ambiente propício à motivação, capacitação e integração das equipes especialistas. </div><div style="text-align: justify;"><br />
</div><div class="separator" style="clear: both; text-align: center;"></div><div style="text-align: justify;"></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiA-cZTxZ8GaXiDOCP08t7sksnuZmmsarJfyWgvqHnY35AQ12yo_tZNeBMWQP8k3Zd0uOzSInGDbXMhJJy8DDzCXFScNKgUrQNzeUVMQeli6ud7_vPRhwnV8rzDGITRoq1X052019AN2VNv/s1600/eureca2.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiA-cZTxZ8GaXiDOCP08t7sksnuZmmsarJfyWgvqHnY35AQ12yo_tZNeBMWQP8k3Zd0uOzSInGDbXMhJJy8DDzCXFScNKgUrQNzeUVMQeli6ud7_vPRhwnV8rzDGITRoq1X052019AN2VNv/s1600/eureca2.jpg" /></a></div><div style="text-align: justify;"> E talvez aí esteja o maior problema e não na especialização!</div>Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-5169934763284815589.post-19205919655331173212010-09-12T22:07:00.009-03:002011-09-09T22:48:56.083-03:00Como testar quando a documentação é precária?<div class="separator" style="clear: both; text-align: center;"></div><div class="separator" style="clear: both; text-align: center;"></div><div style="text-align: justify;">A importância da documentação para a realização de testes é sempre tema de muita <a href="http://dftestes.gershon.info/index.php/P%C3%A1gina_principal">discussão</a>.</div><div style="text-align: justify;">Quando falamos de projetos de desenvolvimento de software onde seguimos uma esteira rápida de produção ou quando a complexidade da solução é considerada baixa, normalmente a documentação é bastante simplificada e em muitos casos até desprezada. O fato é que a produção de documentação nesses projetos é normalmente vista pela maioria dos envolvidos no processo de desenvolvimento como perda de tempo e burocracia inútil. </div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBOt0uKJN0B_RA8dSE32ZwxUYloW2a4FtlfOt19Z6BHbTE6r3OXXmedntFf0SqBaJpMA7yLQ60R_CboRaZ-Xqd716I73Cng26SZ9qqEck_VRjB7Y8-xiDDa-vnArbNGatZP2yQ3P24rm-X/s1600/Documenta%C3%A7%C3%A3o+01.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBOt0uKJN0B_RA8dSE32ZwxUYloW2a4FtlfOt19Z6BHbTE6r3OXXmedntFf0SqBaJpMA7yLQ60R_CboRaZ-Xqd716I73Cng26SZ9qqEck_VRjB7Y8-xiDDa-vnArbNGatZP2yQ3P24rm-X/s320/Documenta%C3%A7%C3%A3o+01.jpg" /></a></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Isso pode trazer muitos problemas para as equipes de testes, que têm seu trabalho dificultado pela falta de insumos. Entretanto, essa dificuldade não deve ser motivo para que os testes sejam deixados de lado ou para que seja dispensada a participação de equipes de testes independentes. Mesmo com pouca documentação, é possível que essas equipes realizem testes importantes em nível de sistema, complementando a visão dos desenvolvedores sobre a qualidade da solução.</div><div style="text-align: justify;"><br />
</div><div class="separator" style="clear: both; text-align: justify;"></div><div style="text-align: justify;"></div><div style="text-align: justify;">Outro ponto importante, é que pouca documentação certamente é melhor que nenhuma! E em muitos casos, pode ser até melhor termos uma documentação simplificada, mas que agregue real valor ao produto, do que uma ampla documentação, que não possa ser mantida atualizada e que não seja confiável, ou ainda, que não seja mais utilizada após a sua produção, representando um custo desnecessário para o projeto. Mesmo quando temos apenas uma definição simplificada do escopo da solução a ser construída, podemos estruturar nossos testes funcionais de tal forma que seja garantida a rastreabilidade em relação aos requisitos definidos. Isso é importante tanto para a organização dos casos de teste, como também para a avaliação da cobertura obtida na execução dos testes, sejam estes previamente projetados ou realizados de forma exploratória.</div><div style="text-align: justify;"><br />
</div><div class="separator" style="clear: both; text-align: justify;"></div><div class="separator" style="clear: both; text-align: justify;">Mas como executar os testes se não temos uma documentação suficiente para compreendermos o comportamento esperado do sistema? Não existe milagre! Quanto menos documentação estiver disponível, maior deverá ser a interação entre os envolvidos no projeto. O problema é que os desenvolvedores também sofrem pressões por uma entrega rápida e não têm muito tempo e nem disposição para explicar o funcionamento do sistema aos testadores. Mas será que isso é mesmo um problema? </div><div class="separator" style="clear: both; text-align: justify;"><br />
</div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBG5OdbyPwMGtDt7DfZpQkcTpxMsiOjbRPi-b0GtGTfE-2IlhEsoURjel2CbykzvFgWhN_U1C2j_AtaGjGLiFm7NsbRN4iPqV3qNLyNHFQAtvvx6fWBWm9PSVRHPleUk_h__OA5ns0qdSM/s1600/REUNI%25C3%2583O.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBG5OdbyPwMGtDt7DfZpQkcTpxMsiOjbRPi-b0GtGTfE-2IlhEsoURjel2CbykzvFgWhN_U1C2j_AtaGjGLiFm7NsbRN4iPqV3qNLyNHFQAtvvx6fWBWm9PSVRHPleUk_h__OA5ns0qdSM/s1600/REUNI%25C3%2583O.jpg" /></a></div><div class="separator" style="clear: both; text-align: center;"><br />
</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Ao tratarmos <a href="http://basedetestedesoftware.blogspot.com/2010/06/importancia-dos-testes-de-aceitacao.html">a importância dos testes de aceitação</a> em nosso último <i>post</i>, ressaltamos que a aproximação entre a equipe de testes e o cliente pode ser muito útil para a construção de roteiros de aceitação e maior detalhamento dos requisitos. Esta certamente é uma estratégia muito útil também quando nos defrontamos com um cenário de documentação escassa nos projetos, pois o cliente pode fornecer à equipe de testes informações preciosas sobre o funcionamento do sistema, desonerando os desenvolvedores desta tarefa. Na verdade, isso pode representar um importante benefício para o projeto, pois não teremos a contaminação dos testes de sistema pela visão do desenvolvimento, além de podermos identificar inconsistências entre as necessidades apresentadas pelo cliente e os requisitos especificados e utilizados para a construção do software. Ao aproximar-se do cliente, a equipe de testes obtém informações que lhe auxiliarão tanto no entendimento de detalhes importantes do sistema como na especificação dos testes, mesmo sem a utilização de uma documentação formal.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Assim, acreditamos ser possível contornarmos uma eventual precariedade da documentação em um projeto de desenvolvimento de software, com uma comunicação mais efetiva entre as equipes de testes e o cliente, permitindo a realização de testes com um bom nível de detalhamento, sem prejuízo ao relacionamento entre testadores e desenvolvedores e à celeridade na entrega das soluções. </div>Unknownnoreply@blogger.com6tag:blogger.com,1999:blog-5169934763284815589.post-24664040443492300652010-06-22T23:12:00.004-03:002011-09-09T22:54:08.516-03:00A importância dos Testes de Aceitação<div class="separator" style="clear: both; text-align: center;"></div><div style="text-align: justify;">Quando falamos em testes de aceitação, normalmente nos lembramos da execução dos testes, quando o cliente ainda encontra alguns defeitos, mas que principalmente serve para a aprovação da solução entregue. </div><div class="separator" style="clear: both; text-align: center;"></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Certamente, a execução dos testes de aceitação é muito útil para que o cliente adquira confiança na qualidade do software, para mensurar a efetividade dos testes executados nos níveis anteriores ou para identificar alguns defeitos residuais. Mas uma grande contribuição que os testes de aceitação trazem para a qualidade da aplicação não está relacionada à execução dos testes, mas ao seu planejamento e projeto.</div><div style="text-align: justify;"><br />
</div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj5N0iYwPZeJvNYm7CosEBMiyuJnwjH7nOJyPQ0wpxrgzmfRG3LjRKbi1mkGWVTbHWN2YvOzqEQ0vgyapZNEmpLSbNcDuC7z0DkZ8dI4pGJar6zOk63JS8fAzicW2sZcucaTWgzjUJJEV4o/s1600/Modelo+V.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj5N0iYwPZeJvNYm7CosEBMiyuJnwjH7nOJyPQ0wpxrgzmfRG3LjRKbi1mkGWVTbHWN2YvOzqEQ0vgyapZNEmpLSbNcDuC7z0DkZ8dI4pGJar6zOk63JS8fAzicW2sZcucaTWgzjUJJEV4o/s400/Modelo+V.jpg" width="400" /></a></div><div class="separator" style="clear: both; text-align: center;"></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Ainda nas fases iniciais do desenvolvimento do software, quando seus requisitos estão sendo especificados com a participação do cliente, os testes de aceitação são também planejados e projetados. Esta atividade permite a construção de casos de teste, que mais tarde orientarão a execução dos testes de aceitação. Mas permite também a validação da definição dos requisitos pelo cliente, quando ele fundamenta e aprova o planejamento dos testes e os casos de teste projetados para a aceitação. Dessa forma, podemos evitar que determinados problemas na especificação dos requisitos passem para fases seguintes do desenvolvimento, o que pode comprometer a qualidade do software em construção e gerar retrabalho para o projeto. Além disso, é possível aproximar a visão das necessidades apresentadas pelo cliente dos requisitos efetivamente documentados, estabelecendo-se um acordo sobre os critérios de aceitação a serem observados na entrega da solução.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Portanto, com o apoio dos testes de aceitação, a qualidade do software pode ser beneficiada, tanto pela execução como pelo planejamento e projeto dos testes, que contribuem para a melhoria da especificação dos requisitos.</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5169934763284815589.post-57989364333765008802010-05-30T19:19:00.006-03:002011-09-09T23:34:23.532-03:00O Custo da Qualidade de Software<div style="text-align: justify;"><div class="separator" style="clear: both; text-align: center;"></div>Muito se fala sobre o custo elevado das atividades de teste e dos procedimentos que buscam garantir que um software tenha qualidade. Mas como um software adquire qualidade e quanto custa às organizações para que seus produtos atinjam um nível superior de excelência?</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"></div><div style="text-align: justify;">É possível que um software adquira qualidade tanto por uma construção que utilize processos maduros e bem definidos, como pela identificação e resolução dos problemas do software, antes que ele seja entregue aos usuários. Essa qualidade pode ser também atingida com a estabilização pós-implantação do software, considerando nesse caso, a possibilidade de alguns ciclos desgastantes de ocorrência de falhas, identificação e correção de defeitos, com a liberação de novas versões da aplicação.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">A cada uma dessas alternativas, está associado um custo específico. Esses custos, somados, constituem o custo da qualidade. O custo da qualidade é parte do custo total de produção do software, que contempla também os custos de sua construção.</div><div style="text-align: justify;"><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgV4S92tpRV1vEFZt9MaZo3zG-RRHlZBPocUg-E_TlsQyKTwRTQcxG-rxZ_OQViAWO12qWl2lu5OZWqLvYyPolvo3OeVrQwk5QrUfouxYON4sNkgfhtn3su7rPKkoQhfCOPVogkdedtE1Jh/s1600/Custo+da+Qualidade+1.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="260" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgV4S92tpRV1vEFZt9MaZo3zG-RRHlZBPocUg-E_TlsQyKTwRTQcxG-rxZ_OQViAWO12qWl2lu5OZWqLvYyPolvo3OeVrQwk5QrUfouxYON4sNkgfhtn3su7rPKkoQhfCOPVogkdedtE1Jh/s400/Custo+da+Qualidade+1.jpg" width="400" /></a></div><div class="separator" style="clear: both; text-align: center;"></div><br />
</div><div class="separator" style="clear: both; text-align: center;"></div><div style="text-align: justify;"></div><div style="text-align: justify;"></div><div style="text-align: right;"><span style="font-size: xx-small;">Fonte: QAI - Quality Assurance Institute</span></div><div style="text-align: right;"></div><div style="text-align: justify;"><b>Custo de Prevenção</b> – Mais que um custo, é um investimento realizado para se evitar erros e fazer o trabalho certo na primeira tentativa. É um investimento com retorno a médio ou longo prazo e que contempla a criação de métodos e procedimentos, a melhoria de processos, a capacitação dos profissionais, a aquisição de ferramentas e o planejamento da qualidade. Esse custo ocorre antes da criação do produto. <br />
<br />
<span style="font-size: small;"><b>Custo de Avaliação</b></span> – Esse custo refere-se ao que é gasto em procedimentos de verificação e em testes dos produtos de software para identificação de defeitos, após a sua construção e antes que sejam disponibilizados para uso ou implantados em produção. Contempla tanto produtos intermediários, como documentos de requisitos, modelos de dados ou especificações, como também o produto de software final. <br />
<br />
<b>Custo de Falhas</b> – Envolve todos os custos associados a produtos defeituosos, que já foram entregues aos usuários ou disponibilizados em produção e que geraram algum tipo de falha. Esses custos referem-se ao retrabalho para reparação de produtos defeituosos, ou a prejuízos decorrentes das falhas no software. Incluem-se nesta categoria, também os custos associados à manutenção de um Help Desk. <br />
<br />
Considerando as categorias de custos que compõem o custo da qualidade, podemos perceber que ao investirmos estrategicamente na prevenção e na detecção de defeitos, os custos de falhas podem ser sensivelmente reduzidos, com reflexo direto sobre o custo da qualidade. Dessa forma, o custo total de produção de um software pode ser também diminuído, acompanhando a redução do custo da qualidade. Ponto para os processos de Garantia da Qualidade e de Testes de Software, que estruturam importantes atividades de prevenção e detecção de defeitos.</div><div class="MsoBodyText" style="text-align: justify;"><span style="font-family: Arial;"><o:p></o:p></span></div><st1:verbetes><b><span style="font-family: Arial;"></span></b></st1:verbetes><span style="font-family: Arial;"><o:p></o:p></span><br />
<div class="MsoNormal" style="text-align: justify;"></div><span style="font-family: Arial;"><o:p></o:p></span> <br />
<span style="font-family: Arial;"> </span>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5169934763284815589.post-8863441165228522492010-04-12T22:18:00.004-03:002011-09-09T23:37:14.116-03:00Desenvolvedores não gostam de testar!<div style="text-align: justify;"></div><div style="text-align: justify;"><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhondwBAuHgg8ZWANB8bnBbOvB93Q6Ta9G2KNEd8w8JYuKzRp2TYBp7dxP93IZ9PNwPRkxs-04sbC-mJaGMb319VSyRFyOsTdbNbzAcgNENFjbhl8LGY7nEVFxNceJSR9hwq9lOqecuF3Hh/s1600/brain.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="199" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhondwBAuHgg8ZWANB8bnBbOvB93Q6Ta9G2KNEd8w8JYuKzRp2TYBp7dxP93IZ9PNwPRkxs-04sbC-mJaGMb319VSyRFyOsTdbNbzAcgNENFjbhl8LGY7nEVFxNceJSR9hwq9lOqecuF3Hh/s200/brain.jpg" width="200" /></a></div>Quando observamos os perfis psicológicos de desenvolvedores e testadores, percebemos algumas diferenças importantes na maneira de pensar desses profissionais.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Basicamente, os desenvolvedores têm suas energias direcionadas para a conclusão do projeto, sempre buscando executar com sucesso a implementação do software e provar que ele funciona. É uma forma de pensar muito diferente dos testadores, que estão sempre em busca de defeitos, certamente com o objetivo de trazer mais qualidade ao software, mas que pode parecer conflitante com a idéia de entrega do produto final. Até fora do trabalho, os testadores estão sempre procurando defeitos. Qual testador nunca se pegou perseguindo defeitos em placas de trânsito e anúncios pelas ruas ou em embalagens de produtos no supermercado? Esse comportamento faz parte do perfil do testador, que é um crítico por natureza.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Mas voltando aos desenvolvedores, sabemos que os testes podem e devem ser realizados também por eles. A grande questão é como convencer um desenvolvedor a investir esforço em testar o seu produto. Os testes seriam sempre direcionados a provar que a aplicação funciona ou podemos adotar alguma abordagem que garanta uma certa isenção do desenvolvedor em relação ao produto e mais qualidade para os testes? </div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Sabemos que uma boa parte dos defeitos pode ser identificada nos testes em nível unitário e integração, que normalmente ficam à cargo da equipe de desenvolvimento, quando existe na organização uma separação de papéis entre desenvolvedores e testadores. Dessa forma, a capacitação dos desenvolvedores para que realizem mais e melhor os testes sob sua responsabilidade, pode ser um investimento com possibilidades de excelente retorno para os projetos de desenvolvimento. Passar aos desenvolvedores conhecimentos básicos sobre testes pode fazer uma grande diferença na qualidade das aplicações. E nada que exija técnicas elaboradas de teste ou um esforço muito maior do que aquele já investido. Todo desenvolvedor testa, de alguma forma, a sua aplicação. O quanto ele testa é que é o problema. Como o seu foco é provar que a aplicação funciona, normalmente apenas o "caminho feliz" é testado e grande parte do código não é exercitado. </div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Mesmo sem exigir profundos conhecimentos em testes, podemos ampliar significativamente a quantidade de testes executados, se no planejamento dos testes unitários e de integração for acordado um determinado nível de cobertura sobre o código, compatível com a criticidade da aplicação e com os riscos do projeto. Dessa forma, o desenvolvedor deverá perseguir essa cobertura do código em seus testes, sem necessariamente ter que modificar muita coisa na sua forma de testar. É claro que para que isso seja possível, será necessária a utilização de ferramentas apropriadas para avaliar o atingimento da cobertura esperada. Os testes nos níveis a cargo do desenvolvedor precisam ser apoiados por ferramental específico, de tal forma que o desenvolvedor possa direcionar sua atenção prioritariamente para o desenvolvimento e os testes ocorram de uma maneira natural para ele e com o menor esforço possível. A automação criteriosa dos testes e o direcionamento à cobertura do código podem evitar que grande parte dos defeitos seja identificada apenas em níveis posteriores de testes ou mesmo em produção, quando os custos de correção são muito maiores.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">O mais importante de tudo isso é conseguir que o desenvolvedor teste o seu código com uma profundidade adequada, sem ser obrigado a realizar atividades que sejam conflitantes com o seu perfil. Com o apoio de ferramentas para avaliação da cobertura de código na execução dos testes, o teste será encarado como um aliado pelos desenvolvedores, e a qualidade final do software será a grande beneficiada.</div>Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-5169934763284815589.post-42237707943010753162010-03-27T11:37:00.005-03:002010-12-19T19:00:54.704-02:00Impressões sobre o CInTeQ 2010<div style="text-align: justify;"><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEidf06p6zCHT1nEZGeflse6p4dNz1X1RwlOdD1Vuv02ULJxqK_r-O-ZZs1NLH_95WusksTCsfHd0he311O3rcp-7eJoZqav4sOd-TeaaVOiyF5PxgZ8cGtTDZ0GuBcivwfys46GoLOq0gP_/s1600/RexBlack.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEidf06p6zCHT1nEZGeflse6p4dNz1X1RwlOdD1Vuv02ULJxqK_r-O-ZZs1NLH_95WusksTCsfHd0he311O3rcp-7eJoZqav4sOd-TeaaVOiyF5PxgZ8cGtTDZ0GuBcivwfys46GoLOq0gP_/s320/RexBlack.jpg" /></a></div>Antes de qualquer comentário sobre o evento, gostaria de parabenizar a organização do CInTeQ 2010, pela iniciativa de trazer para o Brasil grandes nomes do teste de software, como Rex Black (foto ao lado), Eric van Veenendaal e Dorothy Graham. Iniciativas como esta são visionárias e permitem que os profissionais brasileiros mantenham-se atualizados em relação ao que acontece na área de testes e qualidade de software em todo o mundo. É importante ressaltar que algumas palestras nacionais também enriqueceram muito o evento, demonstrando que temos em nosso país profissionais extremamente capazes.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Gostei muito do congresso e as palestras que mais me chamaram a atenção foram:<br />
<ul><li>Teste de Segurança em Aplicações WEB - Palestrante: Eduardo Habib</li>
<li>Lidando com os Desafios do Teste para as Metodologias Ágeis - Palestrante: Rex Black</li>
<li>A Importância da Especialização dos Papéis em uma Fábrica de Testes - Palestrante: Emílio Castro</li>
<li>Qualidade e Produtividade em Sistemas de Software: Um Desafio Brasileiro - Palestrante: Mauro Spínola</li>
<li>Melhoria do teste com TMMi - Melhoria do processo para o presente e futuro - Palestrante: Erik van Veenendaal</li>
<li>Ilusões Cognitivas no Desenvolvimento e Teste - Palestrante: Dorothy Graham</li>
</ul>Outro aspecto importante desse tipo de evento, além das palestras com conteúdo de muita qualidade, é a oportunidade de contatos com diversos profissionais da área, que muitas vezes conhecemos apenas por listas de discussão ou através de seus blogs e artigos publicados. Um bom exemplo disso é o Fabrício Ferrari, que tive a oportunidade de conhecer pessoalmente durante o evento. Pude perceber o entusiasmo e a dedicação do Fabrício em cobrir o evento e compartilhar com a comunidade tudo o que vimos nesses dois dias de congresso. O <a href="http://qualidadebr.wordpress.com/">QualidadeBR</a>, blog do Fabrício, traz uma cobertura bem completa e detalhada de todas as palestras. Não deixem de visitar esse excelente conteúdo! <br />
<br />
Para quem não pôde participar neste ano, fica a dica: ao final do evento foi anunciado o CInTeQ 2011, que ocorrerá nos dias 28 e 29 de março do próximo ano. Programem-se desde já!</div>Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-5169934763284815589.post-19495415329251833762010-03-20T16:47:00.003-03:002010-12-19T19:01:13.982-02:00CInTeQ 2010<div style="text-align: justify;">Acontecerá em São Paulo, nos dias 22 e 23 de março o CINTEQ 2010, um evento internacional sobre teste de software, promovido pelo BSTQB. Participaremos do evento, juntamente com outros profissionais do Banco do Brasil, que atuam na área. </div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Seguem abaixo informações sobre o evento, que contará com a participação de vários nomes do teste nacional e internacional.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">"O CInTeQ é um Congresso Internacional que apresenta assuntos relevantes sobre Teste e Qualidade de Software.</div><div style="text-align: justify;">Ele vem preencher uma lacuna nos eventos nacionais, trazendo as mais importantes celebridades no assunto Teste de Software em âmbito mundial para o Brasil.</div><div style="text-align: justify;">O Congresso vem em parceria com o encontro geral dos representantes mundiais do <a href="http://www.istqb.org/" title="Internacional Software Testing Qualification
Board">ISTQB</a> organização que reúne mais de 40 países este ano na cidade do Rio de Janeiro. Por ser um evento fechado o <a href="http://www.bstqb.org.br/" title="Brazilian Software Testing Qualification Board">BSTQB</a> (representante brasileiro da organização) se mobilizou para trazer alguns destes representantes para realizar palestras e treinamentos para um evento que toda a comunidade tenha a oportunidade de falar e trocar informações com estes gurus da área. </div><div style="text-align: justify;">Sendo realizado em São Paulo o CInTeQ pretende trazer um número elevado de participantes de todo o território nacional, já que possui toda a infra-estrutura de hotéis e transporte para os profissionais que desejem participar deste evento único no país."</div><div style="text-align: justify;"><span style="font-size: xx-small;">Fonte: CINTEQ 2010.</span> </div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Maiores informações: <a href="http://www.cinteq.org.br/">http://www.cinteq.org.br/</a></div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5169934763284815589.post-42027024383011189422010-02-18T21:40:00.000-02:002010-02-18T21:40:11.636-02:00Gerenciamento do Tempo em Projetos de Teste<div style="text-align: justify;"><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjQMbG-2p4cU2mHuLXxb-spvzO7BlsGLtD1Wy8H247RwQtGcvwSc44H7dCZwSa12lkFaRw1TfWYH7SIDdlcmaKmBbcEu7HTVauA78L_hoC207DSV50u-UwtJQsktm2BK18Gm5bLhog3z1Xl/s1600-h/ist2_5535692_the_person_turns_hourglass.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="180" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjQMbG-2p4cU2mHuLXxb-spvzO7BlsGLtD1Wy8H247RwQtGcvwSc44H7dCZwSa12lkFaRw1TfWYH7SIDdlcmaKmBbcEu7HTVauA78L_hoC207DSV50u-UwtJQsktm2BK18Gm5bLhog3z1Xl/s200/ist2_5535692_the_person_turns_hourglass.jpg" width="200" /></a></div>Quando falamos sobre o gerenciamento do tempo em nosso último post, destacamos que algumas atividades podem nos ajudar a obter um maior controle sobre o tempo. Sob a visão de gerenciamento de projetos, essas atividades estão relacionadas principalmente à área de conhecimento de Gerenciamento do Tempo. Mas podemos perceber uma forte relação também com outras áreas, como Gerenciamento de Custos, Riscos, Escopo, Qualidade e Integração.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Um dos primeiros e principais insumos para o gerenciamento do tempo dos projetos é o seu escopo, que pode ser representado pela Declaração de Escopo do Projeto, pela Estrutura Analítica do Projeto (EAP) e pelo Dicionário da EAP. Além do escopo, o Plano de Gerenciamento do Projeto também é um importante insumo para que o líder do projeto possa identificar as atividades que devem ser executadas.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Notem que quando falamos do projeto de teste, temos um escopo que é definido principalmente pelos requisitos do software, os quais serão validados através dos testes. Esses requisitos normalmente são entregues em pacotes, o que nos permite organizar as atividades de teste seguindo essa previsão de entregas. Mas atividades adicionais podem ser necessárias para cumprirmos os objetivos dos testes, mesmo não sendo atividades de teste propriamente ditas e devem ser consideradas para um efetivo gerenciamento do tempo. Um bom exemplo disso, seriam atividades relacionadas à capacitação da equipe ou à aquisição e implantação de alguma ferramenta necessária à realização dos testes. </div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Definidas as atividades necessárias ao cumprimento dos objetivos do projeto de testes, precisamos organizá-las no tempo, estabelecendo uma sequência lógica de execução. Para esta organização, além das técnicas de sequenciamento previstas na literatura para todos os tipos de projetos, nos projetos de teste devemos observar também a relevância e os riscos associados aos requisitos, para estabelecermos aquilo que merece maior atenção. Isso pode afetar as relações de precedência entre as atividades. Em seguida, deve ser identificado o que será necessário prover para que cada atividade possa ser realizada, incluindo pessoas, equipamentos e ferramentas. O quanto de cada recurso, quando será utilizado e por quanto tempo, são também definições que ocorrem nesse momento e impactam fortemente os custos do projeto.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Todas essas definições são pré-requisitos para o desenvolvimento do cronograma de testes, que é um processo iterativo. Mas elas podem também ser afetadas pelo cronograma, o que pode exigir revisões sobre as estimativas de recursos e prazos já estabelecidos. É importante observarmos que o cronograma evolui ao longo do projeto de teste, sensibilizado por mudanças no plano do projeto e em seu cronograma ou por ações decorrentes do gerenciamento de riscos associados ao projeto e seu escopo.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Gerenciar o tempo de projetos e principalmente de um projeto de testes, exige um acompanhamento cuidadoso do andamento das atividades, das mudanças ocorridas e da evolução dos riscos e do escopo do projeto. Em muitas ocasiões pode ser necessário sacrificar determinadas atividades para que os prazos do projeto sejam cumpridos. Nestas situações, é importante termos total controle sobre o cronograma e sobre o escopo dos testes. Isso nos permitirá reportar com propriedade aos intervenientes do projeto, o que está sendo sacrificado e quais os prejuízos à qualidade dos testes, informações preciosas para a tomada de decisão.</div>Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-5169934763284815589.post-57766489286480682042010-02-13T12:10:00.003-02:002010-02-16T15:05:26.132-02:00Gerenciando o Tempo<div style="text-align: justify;"><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhNoc8c6CK3aaJUvjW82HVIwAG0aqS2fzXr3Fvq6UK5NwNpd82Ea-kdJBwGkMKJSIYFYha4C59goQEHgosjTk8NrUMldBbJxNRbxC2IZDQEvOKccFSgWIyNATtvIvNdDYIbLiDhtWcZ6EyU/s1600-h/gerenciamento_tempo.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="130" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhNoc8c6CK3aaJUvjW82HVIwAG0aqS2fzXr3Fvq6UK5NwNpd82Ea-kdJBwGkMKJSIYFYha4C59goQEHgosjTk8NrUMldBbJxNRbxC2IZDQEvOKccFSgWIyNATtvIvNdDYIbLiDhtWcZ6EyU/s200/gerenciamento_tempo.jpg" width="200" /></a></div>Há alguns dias eu estava discutindo a importância de se gerenciar adequadamente o tempo dos nossos projetos de teste. E apesar disso parecer tão óbvio, cheguei a conclusão que quase nunca conseguimos fazer isso muito bem, nem nos projetos, nem em nossa vida profissional ou mesmo na pessoal.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Geralmente gastamos grande parte do nosso tempo em atividades que agregam pouco valor e nem percebemos isso. É um tempo enorme lendo um caminhão de e-mails, navegando na web sem muita direção, ou simplesmente sentados à frente de uma TV, ao final de um dia pesado de trabalho.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">É interessante sempre repensarmos a priorização que fazemos em nossas vidas, para que seja possível encontrar o equilíbrio entre as atividades que temos no dia-a-dia, conseguindo conciliar a vida profissional e pessoal, mantendo o prazer e a motivação nessas duas frentes. </div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Quando conseguimos identificar com clareza as atividades que são mais importantes e as colocamos numa sequência adequada, temos mais chances de executar a maior parte delas, o que pode nos trazer grande satisfação e sentimento de realização. Sem esse cuidado em identificar claramente o que precisamos ou queremos fazer e sem uma priorização adequada, dificilmente realizamos muita coisa.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Esse raciocínio é totalmente válido para as atividades de teste em nossos projetos, pois normalmente temos um escopo de teste muito maior que o tempo disponível para testá-lo adequadamente. Assim, se conseguirmos priorizar os nossos requisitos de teste, poderemos direcionar nossos esforços para aquilo que tem maior relevância. Não esqueçamos do <a href="http://pt.wikipedia.org/wiki/Princ%C3%ADpio_de_Pareto">Princípio de Pareto</a> ao priorizarmos os nossos esforços.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">É importante lembrarmos sempre de estabelecer prioridades e não querermos fazer tudo ao mesmo tempo. Dê importância ao que é importante.</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5169934763284815589.post-26319812291598281282010-02-07T21:07:00.001-02:002010-12-19T19:01:33.759-02:00Falando sobre Automação de Testes<div style="text-align: justify;">Recebemos em Brasília no dia 05/02, em um evento direcionado aos profissionais de teste do Banco do Brasil, o consultor e instrutor na área de testes e qualidade, José Correia da <a href="http://www.iterasys.com.br/">Iterasys</a>, que nos apresentou sua visão sobre o processo de testes e estratégias de automação.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">A palestra tratou dos desafios da automação de testes, dos aspectos positivos e das possíveis frustrações. Foi ressaltada a importância de um bom planejamento, por parte da organização, nessa fase de automação do seu processo de testes, abordando muito além da simples execução automatizada de atividades com maior velocidade. É necessário também que os processos sejam efetivamente melhorados.</div><div style="text-align: justify;"><br />
Alguns aspectos abordados: </div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><b>"Testar mais é possível"</b> - Um forte argumento utilizado em defesa da automação é o ganho de produtividade decorrente. Mas para que isso realmente aconteça, não basta apenas automatizar o processo atual. É necessário pensar na melhor forma de se implementar a automação. "Mais, não necessariamente é melhor". "Se um processo produz um produto com defeito, automatizar esse processo só servirá para produzir uma grande quantidade de produtos defeituosos em menos tempo".</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><b>"Vai ficar pior antes de melhorar"</b>- Ao automatizar os testes, possivelmente o processo ficará mais caro e lento, pois existe uma curva de aprendizagem. Somente depois de algum tempo é que os ganhos da automação serão percebidos.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><b>"Vocabulário de Testes"</b> - É um grande desafio no mercado de testes brasileiro, pois cada empresa tem um vocabulário diferente. As certificações têm um grande papel na unificação desse vocabulário.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><b>"Testar melhor"</b> - Importante a utilização de uma metodologia de testes. Foi descrito o Modelo V em sua representação mais conhecida e também como uma sequência de 8 peneiras (Requisitos, Análise, Arquitetura, Codificação, Testes Unitários, de Integração, Sistema e Aceitação), sendo que o profissional de testes pode participar em todas as fases do processo, pois qualidade deve ser uma preocupação em todas elas. Ao passar por todas essas peneiras, o produto possivelmente terá mais qualidade.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><b>"Ferramentas de Automação"</b> - Foram citados os principais tipos de ferramentas que apóiam o processo de testes: Planejamento de Testes, Gerência de Configuração, Virtualização, Registro de Defeitos, Padrões e Práticas, Cobertura de Código, Testes Unitários, Performance, Segurança e Robôs.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><b>"<a href="http://pt.wikipedia.org/wiki/ISO/IEC_9126">ISO 9126</a> "</b> - Características de Qualidade - Necessidade de se ampliar o escopo dos testes, utilizando o conjunto de características e sub-características de qualidade para direcionar os esforços da equipe. </div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><b>"Testar mais rápido"</b> - Para que isso seja possível é preciso antecipar os testes, acompanhando o processo de desenvolvimento desde suas fases iniciais. É preciso também saber quando interromper os testes. O tempo das áreas de negócio pode ser diferente do tempo da qualidade. </div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><b>"Testar a coisa certa"</b> - Para se ter segurança do que se está testando, são necessárias ferramentas para Gerenciamento de Testes, Gerenciamento de Defeitos e Gerência de Configuração.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><b>"Testar no ambiente certo"</b> - O ambiente de testes foi descrito como um conjunto de fatores , não apenas de hardware. Fazem parte do ambiente, por exemplo, as pessoas envolvidas nas atividades de teste, softwares como ferramentas de teste, documentações do sistema, além do próprio hardware e ambiente físico.<br />
<br />
</div><div style="text-align: justify;"><b>"Virtualização"</b> - Foi abordada a reprodução de ambientes de teste. No futuro os ambientes de produção também serão virtualizados, permitindo que os testes de uma aplicação sejam realizados compartilhando as mesmas condições de hardware e software disponíveis no ambiente produtivo.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><b>"Testar mais barato"</b> - Quando os testes se iniciam mais cedo dentro do ciclo de desenvolvimento, tem-se menos retrabalho e menor tempo para a liberação das soluções.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><b>"Testar o que realmente importa"</b> - Utilizar o gerenciamento de riscos para priorizar o que é mais importante, auxiliando no direcionamento dos esforços de teste. Uma estratégia de teste bem elaborada, considerando prioridades, é o que diferencia um teste produtivo de um teste improdutivo. Foram abordados também o <a href="http://pt.wikipedia.org/wiki/Princ%C3%ADpio_de_Pareto">Princípio de Pareto</a> e o <a href="http://pt.wikipedia.org/wiki/Diagrama_de_Ishikawa">Diagrama de Causa e Efeito,ou Ishikawa,</a> como ferramentas importantes para se priorizar o escopo de teste.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Concluindo sua palestra, José Correia ressaltou que o grande desafio na introdução da automação de testes numa organização não é aprender a utilizar as ferramentas ou se escolher a melhor ferramenta do mercado. O maior desafio é ter um processo robusto, que dê o embasamento necessário às atividades de teste.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Na sequência da palestra, foram abordadas as características das principais certificações em teste, especificamente <a href="http://basedetestedesoftware.blogspot.com/2010/01/calendario-de-certificacoes.html">a CSTE, a CBTS e a CTFL</a>. Nessa exposição, foi ressaltada a grande oportunidade existente na área de testes e qualidade, onde temos uma carência enorme de profissionais e mesmo de conhecimentos sobre os temas da área. Os profissionais pioneiros certamente terão destaque nesse contexto.</div><div style="text-align: justify;"><br />
Ao José Correia, o nosso agradecimento por compartilhar sua experiência profissional e vasto conhecimento. Esperamos tê-lo novamente conosco em outros eventos, contribuindo para a disseminação da cultura de testes e para o fortalecimento da área de testes e qualidade. </div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5169934763284815589.post-80020572855886479142010-02-06T12:05:00.003-02:002010-02-14T08:51:14.041-02:00O futuro do Teste de Software<div style="text-align: justify;">Aconteceu recentemente no <a href="http://br.groups.yahoo.com/group/DFTestes/message/7129">DFTestes</a>, uma boa discussão sobre o futuro do Teste de Software e gostaria de compartilhar com os leitores do Base de Teste a minha visão sobre esse tema.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Vejo o mercado de testes de software crescendo com muita velocidade nos últimos anos.</div><div style="text-align: justify;">Há 3 ou 4 anos atrás, poucas empresas tinham equipes de teste independentes bem estruturadas. Hoje vemos essa estrutura se multiplicar, tanto em empresas que trabalham com desenvolvimento, como naquelas que utilizam os serviços de fábricas de teste para validar as aplicações desenvolvidas por terceiros.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">A terceirização de serviços de teste é uma forte tendência, complementando a capacidade de teste interna das organizações. A especialização conseguida com as estruturas de fábrica trazem muitos benefícios para o contratante, principalmente na escalabilidade no atendimento de suas demandas e na independência dos testes em relação ao desenvolvimento.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Com esse mercado aquecido, as empresas investirão maior esforço na seleção de seus times, pois aquelas que estiverem melhor estruturadas, vencerão a corrida pelos melhores contratos. Por outro lado, os profissionais de teste também deverão investir mais em sua empregabilidade. Nesse aspecto, as certificações serão um grande diferencial, principalmente aquelas que conseguirem distinguir profissionais com maior conhecimento e experiência.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Venho comentando há tempos com alguns colegas, que o teste é o carro chefe para a melhoria de muitos processos. É um processo que catalisa uma mudança cultural nas organizações, na direção de uma busca contínua pela qualidade.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">É bonito ver isso acontecendo com a nossa área e saber que fazemos parte desse movimento!</div>Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-5169934763284815589.post-22042658700897300862010-01-09T13:06:00.005-02:002010-01-20T22:54:19.770-02:00Garantia da Qualidade de Software<div style="text-align: justify;">Conforme o QAI - Quality Assurance Institute, o processo de Garantia da Qualidade é formado por um conjunto planejado e sistemático de atividades, que tem por objetivo prover confiança sobre a conformidade de produtos e serviços a requisitos especificados e que venham ao encontro das necessidades dos usuários. Já para o MPS-br - Melhoria do Processo de Software Brasileiro, <i>o propósito do processo Garantia da Qualidade é assegurar que os produtos de trabalho e a execução dos processos estão em conformidade com os planos e recursos predefinidos.</i><br />
</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Estas duas visões normalmente conduzem a uma confusão muito comum, ao compararmos os processos de Controle e de Garantia de Qualidade de Software. Notamos que o conceito de Garantia da Qualidade é muito próximo daquele que já discutimos sobre o <a href="http://basedetestedesoftware.blogspot.com/2010/01/controle-da-qualidade-de-software.html">Controle da Qualidade</a>, principalmente pelo fato de os dois processos definirem atividades que tratam da qualidade do software.<br />
</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Entretanto, a Garantia da Qualidade tem seu foco na prevenção de inconformidades e na melhoria contínua de processos, enquanto o Controle da Qualidade busca identificar e corrigir estas inconformidades, num processo muito mais reativo. Esses dois processos são complementares e muitas vezes são executados através de atividades semelhantes, como na aplicação de Listas de Verificação ou <i>checklists</i>. A grande diferença é o foco em prevenção ou em detecção.<br />
</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Assim, se você estiver verificando um documento com a intenção de identificar e corrigir eventuais inconformidades, certamente estará trabalhando em uma atividade de Controle da Qualidade. Mas se o seu objetivo é avaliar o processo que gerou este documento, procurando analisar suas fragilidades e otimizar a execução das atividades previstas, estará trabalhando na Garantia da Qualidade deste processo.<br />
</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Então, como diferenciar esses dois processos no dia-a-dia? Não parece muito fácil, mas uma forma bem simples é lembrarmos das palavras <b>Prevenção</b> e <b>Detecção</b>.<br />
</div><ul style="text-align: justify;"><ul><li><b>Prevenção</b> refere-se à <b>Garantia da Qualidade</b></li>
</ul>
</ul><ul style="text-align: justify;"><ul><li><b>Detecção</b> refere-se ao <b>Controle da Qualidade</b> </li>
</ul>
</ul><div style="text-align: justify;">Esta diferenciação é válida, principalmente no contexto do <a href="http://basedetestedesoftware.blogspot.com/2009/12/o-que-e-teste-de-software.html">Teste de Software</a> e das certificações como a CSTE. Entretanto, observando a definição de Garantia da Qualidade feita pelo MPS-br, percebemos que é importante termos o cuidado de avaliar o contexto onde os termos Controle e Garantia são utilizados, para construirmos o entendimento mais adequado a cada caso.<br />
<br />
<br />
<span style="font-size: large;"><b>Referências</b></span><br />
<br />
Guia de Implementação - Parte 2 - Fundamentação para Implementação Nível F do MR-MPS<br />
Disponível em:<a href="http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_de_Implementacao_Parte_2_2009.pdf"> http://www.softex.br/mpsbr/...</a><br />
<br />
Guide to the CSTE COMMON BODY OF KNOWLEDGE - Version 6.2 - 2006<br />
QAI - Quality Assurance Institute<br />
</div><ul><ul></ul>
</ul>Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-5169934763284815589.post-20030821172575742962010-01-03T21:42:00.002-02:002010-01-03T21:47:21.288-02:00Controle da Qualidade de Software<div style="text-align: justify;">Controle da Qualidade, no contexto de software, é o processo que compara um produto com normas, padrões e requisitos estabelecidos, procurando identificar inconformidades, para que estas possam ser corrigidas antes que o produto chegue ao seu ambiente de uso. Tendo seu foco na detecção de defeitos, trata-se de um processo essencial na indústria de software atual, cada vez mais competitiva e exigente. Nessa indústria, qualidade não é mais diferencial competitivo, mas requisito básico para que os produtos desenvolvidos sejam bem recebidos pelo mercado.<br />
</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Ao contrário do que se pode imaginar de um processo que busca por defeitos em produtos, o Controle da Qualidade não ocorre apenas ao final de um processo produtivo, principalmente quando falamos de desenvolvimento de software. O Controle da Qualidade pode ser aplicado sobre os produtos do processo de desenvolvimento desde suas fases iniciais, permitindo que produtos intermediários sejam verificados e que os defeitos identificados sejam corrigidos antes que se propaguem às fases seguintes da construção do software.<br />
</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Dessa forma, podemos controlar a qualidade de um Documento de Especificação de Requisitos ou de um Modelo de Dados por exemplo, identificando precocemente defeitos que poderiam causar grandes prejuízos no futuro. Isso é possível, dentre outras formas, através da aplicação de Listas de Verificação sobre os documentos gerados durante a construção do software ou pela aplicação de <a href="http://basedetestedesoftware.blogspot.com/2009/12/o-que-e-teste-de-software.html">Testes de Software</a>. Quando as inconformidades identificadas são corrigidas, as fases seguintes do processo de desenvolvimento recebem insumos de maior qualidade, o que contribui substancialmente para a qualidade final do software.<br />
</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Investir na detecção de defeitos, através de um Controle da Qualidade sistemático, é muito mais que uma forma eficiente de se reduzir o custo total do software, ao evitar prejuízos decorrentes de falhas em produção. Envolve a satisfação do cliente final, que espera receber um software com qualidade superior e que atenda satisfatoriamente as suas expectativas. <br />
</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-5169934763284815589.post-47102058487561639562009-12-05T11:51:00.021-02:002010-06-20T11:02:18.249-03:00O que é Teste de Software?<div style="text-align: justify;"><div class="separator" style="clear: both; text-align: left;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiZBi11b9dY1VvfOjRV7Zh6qfv27sI0X3CwaGsHKDLG6nUSegQ-f-5Jq4LnCijEpZ0HPoNnGEUVLJZ1IzbXHbwRD4e9CkFHmpqUfRQEJQjYo6ykqxrcvM0K5ZE2LerVSQLf-nNnB_r56b3t/s1600-h/Bugs01-3.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="133" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiZBi11b9dY1VvfOjRV7Zh6qfv27sI0X3CwaGsHKDLG6nUSegQ-f-5Jq4LnCijEpZ0HPoNnGEUVLJZ1IzbXHbwRD4e9CkFHmpqUfRQEJQjYo6ykqxrcvM0K5ZE2LerVSQLf-nNnB_r56b3t/s200/Bugs01-3.jpg" width="200" /></a></div>Apesar da pergunta parecer elementar para os profissionais da área de testes, muitas pessoas não têm uma visão consolidada sobre o tema, principalmente quem não trabalha diretamente com testes de software.<br />
<br />
Por isso, vamos discutir neste <span style="font-style: italic;">post</span> alguns conceitos que nos auxiliarão a construir essa visão.<br />
<br />
Segundo o QAI - Quality Assurance Institute, <span style="font-style: italic; font-weight: bold;"><span style="font-size: 100%;">teste é o processo de avaliar um entregável com a intenção de encontrar defeitos</span>.</span> De fato, esse talvez seja o principal objetivo dos testes. Mas outros objetivos podem ser considerados, como adquirir confiança na qualidade do software através das informações que o teste provê, ou prevenir a ocorrência de falhas do software em produção, pela detecção antecipada dos defeitos. De qualquer forma, estaremos sempre buscando pelos defeitos.<br />
<br />
Nesse ponto é importante fazermos uma distinção entre erro, defeito e falha.<br />
Resumidamente, podemos dizer que um <span style="font-size: 100%; font-weight: bold;">erro</span> é uma ação humana equivocada, que pode introduzir algum tipo de vício ou problema (<span style="font-size: 100%; font-weight: bold;">defeito</span>) em um documento ou no próprio software, que quando executado pode apresentar um comportamento anormal, ou seja, uma <span style="font-size: 100%; font-weight: bold;">falha</span>.<br />
<br />
Definições semelhantes encontramos no Syllabus - Base de Conhecimento em Teste do ISTQB, que nos diz que <span style="font-style: italic;">um ser humano está sujeito a cometer um erro (engano), que produz um defeito (dano, bug), no código, em um software ou sistema ou em um documento. Se um defeito no código for executado, o sistema falhará ao tentar fazer o que deveria (ou, em algumas vezes, o que não deveria), causando uma falha. Defeitos no software, sistemas ou documentos resultam em falhas, mas nem todos os defeitos causam falhas.</span><br />
<br />
É certo que falhas podem ocorrer também por problemas de ambiente ou provocadas por fatores externos ao software, não sendo necessariamente consequência de um defeito. Mas a definição apresentada acima, apesar de simplificada, nos permite entender que erro, defeito e falha <span style="font-weight: bold;">não</span> são sinônimos.<br />
<br />
Além dos objetivos já descritos para o teste de software, um outro aspecto importante é a contribuição dos testes para a melhoria do processo de desenvolvimento. Quando identificado um defeito, a análise da sua causa pode revelar fragilidades do processo de desenvolvimento, que podem então ser corrigidas, num processo contínuo de melhoria. Assim, os benefícios dos testes vão além da retirada dos defeitos e do consequente aumento da qualidade do software, pois permitem também que a organização direcione seus esforços para a prevenção dos defeitos.<br />
<br />
Assim, podemos definir teste de software como um conjunto de atividades direcionadas para a detecção de defeitos em documentações e no próprio código-fonte do software, evitando que tais defeitos acarretem falhas quando o software for utilizado em ambiente de produção. Essa é uma visão que considera o teste como uma importante ferramenta para o <span style="font-weight: bold;"><a href="http://basedetestedesoftware.blogspot.com/2010/01/controle-da-qualidade-de-software.html">controle da qualidade</a>.</span> Mas podemos ampliar essa visão, se avaliarmos a importância dos testes também para a <span style="font-weight: bold;"><a href="http://basedetestedesoftware.blogspot.com/2010/01/garantia-da-qualidade-de-software.html">garantia da qualidade</a>,</span> com a utilização das informações geradas pelos testadores para a prevenção de defeitos e melhoria de processos. Discutiremos esses temas em nossas próximas postagens.<br />
<br />
</div>Unknownnoreply@blogger.com2