Pular para o conteúdo principal

Postagens

Testes exploratórios

Recentemente no trabalho tive de criar uma apresentação-treinamento sobre teste exploratório. Assim que recebi o pedido pensei: “Ué, mas qual o segredo? Você entra na aplicação, começa a testar o que achar necessário, sem seguir roteiro, sem nada, pra que treinamento sobre isso?”. Depois comecei a pesquisar sobre o assunto e vi que, se tentarmos resumir a definição, podemos sim usar a minha primeira ideia, mas dessa forma deixaríamos de lado muita informação importante e, eu diria, até essencial sobre testes exploratórios. Então se você está aqui, você provavelmente não caiu no erro que cometi, definindo sem antes pesquisar. Na sequência do post você pode conferir tópicos interessantes sobre o assunto. ;-) Definição O BSTQB (Brazilian Software Testing Qualifications Board) define testes exploratórios como "técnica de modelagem de teste informal na qual o testador controla ativamente a modelagem dos testes já que estes são realizados e utilizam as informações obtidas durante o test...

Testes no RUP (Parte 2)

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

Testes no RUP (Parte 1)

Nesse post, falarei sobre a disciplina de Testes dentro do modelo RUP (Rational Unified Process). Antes de abordar a aplicação da disciplina de Testes no RUP, apresento aqui uma visão geral do processo. A seguinte ilustração sobre o RUP é, por si só, bastante elucidativa: (fonte: http://www.devmedia.com.br/) Na imagem acima, temos as fases e as disciplinas que compõem o RUP: Fases: Concepção Elaboração Construção Transição Disciplinas: Modelagem de Negócio Requisitos Análise e Projeto Implementação Testes Implantação Gerência de Configuração e Mudanças Gerência do Projeto Ambiente Como o foco é falar sobre Testes, não entrarei em questões relativas a outras disciplinas. Para outras informações sobre RUP, indico os seguintes links: http://www.ibm.com/developerworks/rational/library/content/RationalEdge/jan01/WhatIstheRationalUnifiedProcessJan01.pdf http://www-01.ibm.com/software/rational/ Como nota-se na imagem anterior, a nuvem da disciplina de Testes está presente em cada uma das 4 fa...

Uma boa dica de leitura - Desenvolvimento Ágil

Aí vai uma dica para os apaixonados por testes e desenvolvimento de software, a revista TI Digital de Novembro traz na capa o assunto "Desenvolvimento Ágil". Para aqueles que não estão por dentro do assunto, existem princípios do Manifesto Ágil que se corretamente seguidos (mesmo sem ferramentas e processos) você terá uma metodologia ágil de desenvolvimento na sua equipe. Para isso o foco da preparação deve ser em pessoas , as ferramentas e os processos ficam em segundo plano. A grande sacada da "técnica" é a proximidade com o cliente e a comunicação extremamente rápida , preferencialmente presencial e informal. Também não existe a famosa frase " esse cliente não sabe o que quer, toda hora muda ", afinal, desenvolver com agilidade tem tudo a ver com as mudanças do cliente. Na mesma reportagem sobre desenvolvimento ágil existe uma parte sobre testes automatizados, com boas dicas e definições. Acho que falei demais, vale a pena desembolsar R$ 7,90 e esmiuça...

Teste exaustivo: é possível?

Semana passada o "big cheese" da Microsoft, Steve Ballmer, anunciou que a Microsoft apostou em três coisas no Windows 7: testes, parceiros e feedback. Parceiros e feedback devem realmente ter ajudado pois as primeiras notícias que temos por aí é de que o Windows 7 é bem superior ao Vista no que se refere ao desempenho. Mas quanto aos testes, é possível dizer que testes exaustivos foram executados no Windows? O Syllabus do ISTQB (International Software Testing Qualifications Board) diz que testes exaustivos são impossíveis. Testar exaustivamente significa testar todas as combinações de entradas e pré-condições e fica difícil acreditar nisso em sistemas "comuns", quem dirá quando falamos de um sistema operacional. "Ballmer afirmou que a Microsoft apoiou o desenvolvimento do Seven em testes exaustivos para assegurar que a plataforma chegue ao mercado compatível com os mais diferentes tipos de hardware e tenha ótimo desempenho nas diferentes máquinas, desde desktop...

O + do FURPS+

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

FURPS

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