Arquivo mensal: junho 2008

Qualidades de um especialista em teste

Ser especialista em algo exige uma gama de competências e virtudes. E para ser um especialista em teste não é diferente. Cito abaixo, algumas características esperadas de um expert em teste:

  • Postura pragmática: O testador pragmático é realista e objetivo, as suas decisões são baseadas no seu conhecimento teórico e prático das técnicas de teste e nas ferramentas disponíveis no mercado. Por outro lado, o testador pragmático não se limita somente aos aspectos tecnológicos; em contrapartida, o testador pragmático é um contador estórias, abordando os problemas por meio de metáforas e analogias compensando assim a falta de requerimentos formais.
  • Flexível: flexibilidade é um pré-requisito para qualquer profissional de TI e na atividade de testes é exigido mais ainda, pois os requisitos mudam, os prazos afunilam e o especialista em teste não pode ser a verso as mudanças e deve-se adaptar com facilidade as novas realidades.
  • Criativo: deve pensar em todas as situações possíveis de teste e até as que aparentam ser impossíveis.
  • Crítico: colocar sempre em dúvida aquilo que está em teste, não se contentar com resultados aparentes, ter um olhar crítico.
  • Realista: tomar decisões baseadas em fatos.
  • Incansável: sempre interrogar e investigar a causa raiz dos problemas e a razão das coisas. Testar a exaustão o software, nunca acreditar que não há mais defeitos.
  • Assertivo: nunca pressupõe ou se baseia em informações contidas nas entrelinhas, todas as suas suposições são aferidas a fim de garantir a sua veracidade.
  • Diplomata: foca os seus esforços nos problemas ao invés de focar nas pessoas que os causaram. Deve saber se comunicar com o desenvolvedor, nunca desprezar ou criticar negativamente o seu trabalho.
  • Perfeccionista: Cada detalhe conta na execução do seu trabalho, no entanto, não troca um ótimo resultado por um resultado perfeito (e provavelmente impossível).

Uma última característica de um especialista em teste é ser um generalista. Isso mesmo, o conhecimento sobre outros assuntos são fundamentais para todo profissional de TI. A especialização é algo bem-vindo sempre, mas o mercado de TI pede cada vez mais por profissionais generalistas, aquelas pessoas “quadradas” em determinados assuntos já não tem mais espaço nas empresas de TI. E a atividade de teste exige, muitas vezes, conhecimentos de linguagens de programação, redes, linux, banco de dados e até de negócios. Por isso, além do entendimento do processo de teste o especialista de teste deve buscar está sempre atento as tendências de mercado e buscar a atualização constante.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

http://www.linhadecodigo.com.br/Artigo.aspx?id=1083&pag=1

Padrão de nomes de componentes

Quantas vezes escrevendo um caso de teste ou reportando um bug, a gente não acaba se esquecendo do nome de um determinado componente ou até confundindo com outro. E em equipes de Teste de Software, é muito comum uma pessoa acabar citando o componente de maneira diferente da outra. O que acaba resultando na falta de padronização e até pode comprometer o entendimento do desenvolvedor, que por sua vez, está acostumado a tratar o componente utilizando outro nome.

Tendo em vista evitar tais situações, montei uma galeria de imagens, que apresenta os nomes dos componentes mais utilizados em aplicações Web, espero que sirva de ajuda:

Fique por dentro das novidades, assine o feed do QualidadeBR.

O que é bug?

O uso do termo bug já é antigo, dizem que ele foi criado por Thomas Edison quando um inseto causou problemas de leitura em seu fonógrafo em 1878.

O primeiro bug em computadores possivelmente ocorreu em 1947. Quando os engenheiros que trabalhavam com o Harvard Mark I, o primeiro computador digital automático de larga escala desenvolvido nos EUA, encontraram uma traça entre seus circuitos, que causou um erro nos cálculos da máquina, prenderam-na no livro de registro e rotularam-na como o “primeiro bug” encontrado, como vemos na figura 1.

Naquela época, havia literalmente bugs, devido as proporções gigantescas dos computadores (figura 2), que serviram de abrigo para vários insetos e até para ratos. Situação essa, que em muitas vezes ocasionava problemas no sistema.

O primeiro bug.

Figura 1 (retirada do myoldmac)

Harvard Mark I, o primeiro computador digital automático de larga escala desenvolvido nos EUA.

Figura 2 (retirada de IBM Archives )

Mas e hoje, em pleno século XXI por que os bugs ainda fazem parte das notícias de TI e são tão freqüentes?

Errar é humano.

Essa frase tão prolixa é o motivo da existência dos bugs, afinal por mais experiente que seja o programador, ele também é humano (embora alguns duvidem) e passa por dias ruins. No entanto, não é no desenvolvimento que ocorre a maioria dos bugs, segundo informações do QAI (Quality Assurance Institute), 36% dos erros encontrados nos softwares são provenientes da codificação, e os outros 64% são erros de desenho e análise.

Um exemplo dessa proporção é o bug mais famoso do mundo, o bug do milênio. Quem não se lembra do temor causado na passagem do ano de 1999 para 2000, devido ao armazenamento de datas com apenas 2 dígitos para o ano, ficando os restantes implicitamente entendidos como sendo “19”. Desta forma cada data armazenada deixava de ocupar oito bytes (dois para o dia, dois para o mês e quatro para o ano), e passava a ocupar somente seis bytes (somente dois no ano). Assim, quando o calendário mudasse de 1999 para 2000 o computador iria entender que estava no ano de “19” + “00”, ou seja, 1900.

E a decisão do uso de apenas 6 bytes, ocorreu devido a necessidade real de economia de memória e espaço de armazenamento. Hoje isso parece insignificante, mas na época isso foi o suficiente para justificar a adoção do padrão, tamanho o custo das memórias e dispositivos de armazenamento.

Para resolver o problema, velhos programadores de COBOL foram tirados da aposentadoria, para voltar a trabalhar em sistemas muitas vezes desenvolvidos por eles mesmos, vinte anos antes. Pagando-se a eles 1 dólar por linha revisada.

O bug do milênio foi um marco para a Qualidade e Teste de Software, no qual percebeu-se o quanto uma falha pode custar caro e como até mesmo o risco de tal, pode abalar empresas e levar a perda de dinheiro e credibilidade. Tirando como lição aprendida a importância do processo de testes, durante o desenvolvimento do software, para que se possa minimizar a probabilidade e o impacto dos riscos e diminuir o número de defeitos.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

http://pt.wikipedia.org/wiki/Bug_do_mil%C3%AAnio

http://www.clubedohardware.com.br/artigos/492/3

O que é Qualidade de Software?

Para definir Qualidade de Software (QS), necessitamos primeiro saber o que é qualidade:
Segundo a Wikipédia: “Qualidade é um conceito subjetivo que está relacionado diretamente às percepções de cada indivíduo. Diversos fatores como cultura, modelos mentais, tipo de produto ou serviço prestado, necessidades e expectativas influenciam diretamente nesta definição”.
Como podemos perceber, qualidade é um substantivo que pode ter muitos significados. Isso acontece pela forte ligação com as percepções das pessoas, que tem pensamentos e gostos diferentes.

Então, qual seria a definição para QS? Estaria ela também fadada às percepções do ser humano?

A QS assim como as outras está ligada diretamente as opiniões das pessoas, que neste caso, são representadas pelos clientes, usuários e envolvidos com o projeto de software. Possuindo as seguintes características:
• QS está fortemente relacionada à conformidade com os requisitos;
• Ela caracteriza o grau de satisfação do cliente;
• Não é responsabilidade de apenas uma área da empresa, e sim de todos;
• Deve está presente desde o planejamento do software.

Atualmente, QS vem ganhando um grande foco nas empresas de TI, pois percebeu-se que a Qualidade de Software não é um gasto e sim um investimento. E com a evolução constante da tecnologia, os clientes estão cada vez mais exigentes. Podemos até fazer uma analogia com o mundo dos games: antigamente (10 anos atrás), The Legend of Zelda: Ocarina of Time, lançado para o Nintendo 64, era “o game”. Hoje, se você der a uma criança o cartucho (nada de DVD, muito menos Blu-Ray), ela provavelmente vai achar os gráficos “toscos” e ainda vai perguntar porquê, movendo o controle ela não move o personagem.

Espero que vocês tenham gostado do primeiro tópico do blog QualidadeBR. Fiquem à vontade para comentarem.

Fique por dentro das novidades, assine o feed do QualidadeBR.