TESTAVO

Consultoria de Testes - LUGATI @Vitória-ES

2011-12-13T04:09:00.000-08:00

Na última semana estive em Vitória-ES e fui apresentar um Workshop sobre Testes de Software para oito empresas. Primeiramente gostaria de agradecer ao Leonardo dos Santos e Luciano Raizer pela oportunidade e indicação.
De maneira geral, o trabalho foi bastante proveitoso. Todas as empresas participantes agradeceram bastante e saíram com um plano de ação bem palpável e direcionado para a sua necessidade.
Às empresas que participaram desse processo, são cúmplices do feedback que estou passando nesse post: INNET, Tempro, DBM, Mogai, BL, Polaris e RaizerMoura, infelizmente não tive a oportunidade de conversar com a equipe da Vixteam por questões de cronograma.
De maneira geral, o trabalho teve um resultado bastante positivo pelo seguinte fato: lembra que eu sempre bato na tecla que "teste é dependente de contexto"? Pois então, todas as empresas, sem exceção, tinham uma realidade completamente diferente umas das outras, e completamente diferente das demais empresas que já prestei Consultoria ou pude trabalhar.
Isso é bastante claro, os processos são criados partindo das pessoas e das necessidades específicas para aquele negócio. Tem empresas que são Microsoft Partner e usam o ALM, tem empresas que possuem equipe de Suporte e esta é sua principal ponte com o cliente, tem empresas que possuem equipe de implantação de software e é quase que independente da equipe interna, tem empresas que possuem um processo de concepção perfeito mas a tradução (mais formalmente chamada de análise) para a "linguagem tecnológica" ainda engatinhando, entre outras, e cada uma com suas peculiaridades.
Basicamente nós nivelamos nossa linguagem, avaliamos o processo, definimos objetivos e metas, estudamos ferramentas e descrevemos um plano de ação que fosse viável. Eu, sozinho, não defini nada, afinal, não vou decidir nada sobre qualquer empresa sem conhecê-la profundamente. Simplesmente o que fiz foi dar ferramentas suficientes para a equipe tomar seu próprio rumo, e deu certo, pelo fato deles serem os especialistas do negócio deles, não eu.
E antes de finalizar, gostaria de descrever a minha percepção a respeito do pequeno* empresário capixaba: vocês estão de parabéns, nunca vi um povo tão motivado para crescer e que acreditasse tanto na sua competência local.
Tive a feliz oportunidade de ouvir do Diretor de uma das empresas a seguinte frase: "Qual foi a lavagem cerebral que fizesse na minha equipe? Já mandei eles para uma dúzia de workshops de Testes e nunca voltaram tão motivados como agora..." O que acontece é que a equipe se deu conta das melhorias, e em momento algum eu impus que as coisas devessem funcionar daquela maneira ou de outra. Estou ansioso pela próxima etapa do processo... :)
*Pequeno: Pequeno entre aspas, essa é a percepção deles quando se comparam a empresas como Accenture, Petrobrás, Vale e ArceloMittal, por exemplo.

Nova versão do Selenium Server (2.6.0)

2011-09-21T13:14:00.000-07:00

Neste último dia 13, lançou a versão 2.6.0 do Selenium Server e Driver em Java (e em outras linguagens também), facilitando o uso do Selenium em vários aspectos.
Eu estava tendo problemas ao rodar um script via Remote Webdriver e este problema foi corrigido nessa versão (digamos que foi uma melhor orientação para achar o problema). Este foi meu motivo de alegria e motivação em criar esse post:
Added timing information to WebDriver exceptions resulting from command invocations in the remote driver.

v2.6.0
======

WebDriver
* Better handling of the case where emphemeral sockets are exhausted.
* More widespread use of the InvalidSelectorError in Chrome and Remote.
* When using native events, prevent firefox from scrolling if an element is
already in the view.
* Improvements in the mouse emulation (movement, click, double click, context
click)
* Bumped included version of OperaDriver to 0.7.1.
* Attempt to address issue #1443 (the infamous "getWindow() == null" problem)
* Added timing information to WebDriver exceptions resulting from command
invocations in the remote driver.
* Added an ExpectedConditions class with common ExpectedCondition
implementations.
* Better usage of sockets in the remote webdriver

RC
* WebDriver-backed Seleniums will now clear text fields before typing.

Grid
* Significantly improved thread safety.
* Improved information on the index page of the hub.

Automation Atoms
* bot.inject.executeScript* handles function arguments better.
* Add atom to get the frame index of a frame element (bot.frame.getFrameIndex)
* Added emulation of touch devices and events
* Use DOM Events level 2 and 3 for events IE if available

Fonte: http://selenium.googlecode.com/svn/trunk/java/CHANGELOG

Exemplo do uso incorreto de templates

2011-09-13T14:22:00.001-07:00

Estava visitando alguns sites de Testes em inglês e me deparei com o seguinte texto:

What should be done after a bug is found?
The bug needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested, and determinations made regarding requirements for regression testing to check that fixes didn't create problems elsewhere. If a problem-tracking system is in place, it should encapsulate these processes. A variety of commercial problem-tracking/management software tools are available (see the 'Tools' section for web resources with listings of such tools). The following are items to consider in the tracking process:

* Complete information such that developers can understand the bug, get an idea of it's severity, and reproduce it if necessary.
* Bug identifier (number, ID, etc.)
* Current bug status (e.g., 'Released for Retest', 'New', etc.)
* The application name or identifier and version
* The function, module, feature, object, screen, etc. where the bug occurred
* Environment specifics, system, platform, relevant hardware specifics
* Test case name/number/identifier
* One-line bug description
* Full bug description
* Description of steps needed to reproduce the bug if not covered by a test case or if the developer doesn't have easy access to the test case/test script/test tool
* Names and/or descriptions of file/data/messages/etc. used in test
* File excerpts/error messages/log file excerpts/screen shots/test tool logs that would be helpful in finding the cause of the problem
* Severity estimate (a 5-level range such as 1-5 or 'critical'-to-'low' is common)
* Was the bug reproducible?
* Tester name
* Test date
* Bug reporting date
* Name of developer/group/organization the problem is assigned to
* Description of problem cause
* Description of fix
* Code section/file/module/class/method that was fixed
* Date of fix
* Application version that contains the fix
* Tester responsible for retest
* Retest date
* Retest results
* Regression testing requirements
* Tester responsible for regression tests
* Regression testing results

Nesse momento, o Analista de Testes inexperiente (espero que o chapéu não sirva) vai lá e cria um "template" maravilhoso para reportar defeitos encontrados no sistema com tooodos aqueles itens acima listados.

O problema é que ele esqueceu da citação do próprio autor: "The following are items to consider in the tracking process". Ou seja, para quem gosta de tradução: "Os itens a seguir devem ser CONSIDERADOS ..."

Nesse caso, o próprio autor deu a dica. Mas a impressão que eu tenho é que o camarada sai desesperado no Google atrás de "itens para compor meu documento", vê um "troço" desses e sai montando odiosos artefatos no processo das empresas. É graças a esses "gênios", que a área de Testes tem esse "prestígio todo"...

[Selenium Webdriver] Utilizando Rich-Faces: Modal Panel

2011-09-12T09:31:00.001-07:00

Vou compartilhar uma solução bem simples que descobri para tratar Modal Panels com o Selenium. Na verdade a solução é bem fácil mas como eu quebrei a cabeça com até chegar nesse ponto, acho interessante repassar pois outros podem utilizar esse mesmo tempo para descobrir e compartilhar outras soluções. Descobri conversando com outros profissionais da área tais como Elias Nogueira e uns colegas da Índia e Singapura, através de fóruns e listas de discussão sobre Selenium e Java e outros.

Para este caso, é importante levar em consideração três etapas importantes:
- O próprio Selenium IDE já gera essa linha de código, mas é interessante entender o motivo pelo qual ele insere o mesmo:
driver.manage().timeouts().implicitlyWait(20, TimeUnit.SECONDS);
Esse trecho de código é utilizado para o Selenium "esperar" o browser durante 20 segundos (ou quantos segundos o usuário desejar) enquanto o elemento desejado não aparece na tela. Então, só depois desses 20 segundos o elemento ficaria disponível.

- Pode-se mapear o Modal Panel e utilizá-lo como referência para procurar o objeto daquela tela, como por exemplo:
WebElement modalPanel = driver.findElement(By.id("idDoElemento"));
WebElement dsArquivo = modalPanel.findElement(By.xpath("xpathDoElemento"));

- Ou, caso a solução acima não atenda, sugiro acessar diretamente a URL (mapeando esta através de um Firebug da vida) e acessar o arquivo diretamente. Como por exemplo:
// Preencher URL
driver.get("http://URL.com.br/sistema");

// Mapear campos da tela
WebElement login = driver.findElement(By.id("username"));
WebElement password = driver.findElement(By.id("password"));
WebElement submit = driver.findElement(By.cssSelector("input.formSubmit"));

// Preencher usuário//senha e clicar em Enter
login.sendKeys("teste");
password.sendKeys("teste");
submit.click();

// Navega até a tela Cria Minuta de Documento
driver.findElement(By.linkText("linkDaTela")).click();
driver.findElement(By.xpath("xPathDoLink1")).click();
driver.findElement(By.xpath("xPathDoLink2")).click();

// Tela do modal panel
// Acessar diretamente a URL do modal panel
driver.get("http://URL.com.br/sistema/modalpanel&blablabla?=usuario=testeblabla");

WebElement campo1 = driver.findElement(By.xpath("xpathDoCampo1"));

String textoTeste = "teste123";
campo1.sendKeys(textoTeste);

Espero ter ajudado!

Clientes odeiam templates

2011-08-29T15:02:00.000-07:00

Você foi incumbido de implantar/melhorar a célula de Testes da sua empresa? Legal, meus parabéns! Seja como contratado ou consultor, é importantíssimo entender que o cliente quer que seu problema seja resolvido de forma prática. E não o contrário! Ele não quer aprender metodologias, processos, templates e ferramentas novas, a não ser que ELE sinta essa necessidade.

Quer implantar os padrões do IEEE 829 nessa empresa? Ok, boa estratégia! Mas só uma pergunta: eles adotam os demais padrões do IEEE para as demais atividades da empresa? Algum outro padrão com o mesmo nível de detalhamento? Não? Então esqueça esse template. O cliente vai odiar, acredite em mim.

O Testlink é uma ferramenta maravilhosa, né? Mas enquanto você não ouvir o cliente dizer: precisamos gerenciar melhor nossos testes, nossa execução e outros. Não ofereça, tampouco force-o a usar ou chame-o de qualquercoisa só pelo fato dele não conhecer seu mundo fantástico dos testes. Na pior das hipóteses, faça sua parte: aconselhe. Se houver resistência, faça do jeito que ele achar mais prático, não insista.

O cliente tem que se sentir à vontade para adotar seus conselhos. Aconselhe um piloto e mostre a ele o resultado, os benefícios. "Show them numbers".

Jamais (repito: jamais) chegue com um template que você pegou de um colega da DFTestes ou daquele seu amigo que trabalha na IBM, HP, Dell e outras empresas que já possuem um processo já consolidado e diga: vamos utilizar esse template, é supercompleto! Principalmente se você trabalha numa empresa cujo processo é caótico ou não justificável para uso desse tipo de documentação. Use toda sua experiência para abordar seu cliente ou chefe: seja criativo. Sinta quais as necessidades da empresa e como o teste poderá ser melhor encaixado.

Quer utilizar um TMMi para abordar seu cliente? Será que ele criaria um "Test Policy" para sua organização? Um "Master Test Plan" para cada projeto? Um Test Plan para cada nível de testes? Dentre outras dezenas de abordagens que uma metodologia dessas possui...

Features a serem testadas, critérios de aceitação, test approach, test scope, você realmente acha que seu cliente vai "investir" seu tempo utilizando esse tipo de documento? Se sim, utilize-os. Mas antes tenha bastante cuidado ao apresentar esses templates...

Nunca se esqueça do princípio que repetidamente cito no meu blog: "Testing is context dependent".

Test Case Lifecycle - Test Analysis/Implementation

2011-07-22T04:35:00.000-07:00

Para seguir na fase de Test Analysis, é importante lembrar que os cenários macro de teste já foram criados. Agora é detalhar como estes cenários serão testados. Inclusive esta fase às vezes pode estar atrelada a fase de Test Execution, o que se transforma numa grande salada de fruta se o sistema estiver fora de controle.

Parece que estou escrevendo o ciclo de desenvolvimento de testes (plano de teste, caso de teste, etc.) tudo de novo, né? Na verdade a resposta é sim, tudo tem uma relação. A ideia é oferecer uma nova visão de como dar manutenção nos casos de teste propriamente ditos, e não em todas as atividades de teste em geral. Por exemplo, se esse caso de teste possui um pré-requisito que deve ser cadastrado em outra tela, faça-o direto no banco (com suas devidas validações). Dai pode ter gente que vai perguntar: mas não vai testar de forma apropriada o cadastro dessa outra tela, os dados vão ficar viciados! Sim, resposta certa. Todavia a ideia é que a manutenção dos casos de teste sejam feitas no sistema inteiro (tanto no anterior como no atual).

Quem nunca ouviu a frase: "esse sistema até meu priminho de quatro anos testa."?concordo, qualquer um testaria. Todavia é importante levar em consideração que os sistemas crescem e podem, de certa forma, perder o controle. Geralmente as pessoas só se dão conta da importância de criar os casos de teste quando se perde o controle do sistema (ou às vezes nem isso). Esse controle de cada atividade deve ser feito de forma evolutiva, principalmente no início onde a cara do sistema geralmente é mais nebulosa.

Nessa etapa do projeto, Test Analysis/Implementation, é onde os casos de teste não são só criados, antes da criação destes tem alguns itens bem críticos que serão cruciais para as próximas fases, como por exemplo: qual técnica será utilizada. Por exemplo, esses dias um colega me abordou perguntando como utilizar Pairwise Testing (ou Array Ortogonal). Perguntei a ele qual era o motivo pelo qual ele tinha escolhido a técnica. A intenção bem como a forma de abordar o desafio foram boas, ele decidiu por utilizar uma excelente técnica, mas o motivo pelo qual esta técnica foi escolhida (técnica que geralmente é utilizada para configurações, evitando as "combinações explosivas". Tais como 3x5x4x2 = 120 casos de teste) não atendia às necessidades do caso de teste.

Mas não só a utilização da técnica é um fator a ser levado em consideração, outro fator muito importante é definir a amarração dos casos de teste (test harness). O que seria isto? Bom, amarração dos casos de teste seria, em poucas palavras, definir a "rastreabilidade dos casos de teste", quais testes são pré-requisitos uns dos outros, quais dados devem ser criados para iniciar cada caso de teste, etc. Uma boa prática é não atrelar o resultado de um caso de teste ao pré-requisito de outro. Como assim? Por exemplo, vamos criar um cliente chamado João no meu sistema (TC1) e na tela de compra do produto utiliza o usuário do João para efetuar a compra (TC2). Perceba que o João é o output de um caso de teste e o input do outro? Sim, geralmente isso dá problema - levando em consideração que o TC1 pode falhar por algum motivo, vai impedir a execução do TC2 - e por esse motivo, é melhor criar o dado diretamente na base, e não no sistema.

Essa é a etapa crítica do Ciclo de Desenvolvimento dos Casos de Teste. Esse refinamento dado, tanto na questão técnica (detalhar o caso de teste) quanto na questão gerencial (definir qual teste é a sequência de execução), é muito delicado e não funciona da maneira correta com equipes juniores. Pois geralmente testadores menos experientes tem dificuldade de criar um caso de teste em tempo hábil, respeitando um cronograma de análise e implementação (há exceções).

Qual a função de Testes de Software (mesmo)?

2011-07-13T05:47:00.000-07:00

Primeiramente é importante entender que ter uma equipe de Testes robusta e madura é um INVESTIMENTO no seu projeto e/ou empresa.

O que todo mundo sabe é que, para aumentar a qualidade e a satisfação do cliente, deve-se investir em Testes. Isso está mais do que batido e inclusive é o primeiro ou segundo slide de qualquer pessoa que vá apresentar algo que seja ou envolva Qualidade ou Testes de software, seja um trabalho acadêmico ou uma apresentação comercial.

O que dificilmente fica claro para o gestor que decide optar por esse salto de qualidade no seu projeto, é justamente o significado dessa qualidade. Podem perceber que "ter qualidade no seu projeto" é algo meio que subjetivo. Qualidade em quê? Ter mais testadores na equipe? Ter menos bugs no projeto? Ter o cliente mais satisfeito? Contratar só analistas e desenvolvedores super experientes? O que é qualidade?

É importante especificar qual é o salto de qualidade que vai ser dado. Além de ter menos bugs e maior satisfação do cliente, é claro.

Quer aumentar a velocidade da sua equipe de desenvolvimento? Invista em Testes! Hã? Como?

Vamos ser práticos (e esse é mais um motivo pelo qual eu digo que metodologia ágil só é útil com projetos inovadores):

Imaginemos a seguinte situação, uma pessoa começa a desenvolver e a outra começa a criar os casos de teste. Por mais apertado que fique o cronograma, se os casos de teste estiverem prontos e o ambiente de testes populado com a massa de dados apropriada, a execução vai rápido. Garanto que para cada 40 horas de desenvolvimento, uma hora de execução de testes é suficiente (sim, é. acreditem - o Teste de regressão ainda mais curto). É simples e isso evita uma série de problemas, tais como retrabalho (os bugs existem, é só questão de analisar a hora que decidimos corrigi-los), custo (fica caro tirar um profissional de outro projeto para voltar a corrigir bugs para aquele projeto em desenvolvimento), estresse (nenhum cliente fica feliz em achar bugs em produção, por mais que eles cobrem a entrega no prazo previamente negociado) entre outros.

É importante entenderem que eu não prezo por sistema testado "nas coxas", mas o que eu venho percebendo é que se gasta cada vez mais tempo testando do que desenvolvendo. Quando poderia ter sido acelerado. Uma semana de Testes de regressão, a não ser que o sistema seja absurdamente grande ou a equipe de testes absurdamente pequena, já é mais que suficiente.

Ou seja, na minha opinião, a função do Testes de software é dar suporte e velocidade ao desenvolvimento. Porque os analistas e desenvolvedores são os caras, e não nós (rs).

Test Case Lifecycle - Macro Test Analysis

2011-05-30T11:06:00.000-07:00

Um segundo passo, é desenvolver em paralelo ao Analista de Sistemas, um documento com todos os fluxos macro de testes em cima das funcionalidades já citadas na reunião inicial (pode-se basear numa Ata de reunião, resultado da etapa anterior). É uma atividade que não acontece apenas em paralelo ao Plano de Testes, mas é uma parcela dele. Eu diria que esse tipo de atividade deve existir para diminiur o nível de ociosidade de uma equipe de testes no início de cada release ou projeto, o que, em alguns casos, é muito normal. Enquanto o gestor do projeto cria o Plano de Testes, o Analista fica responsável por definir um artefato mais específico nessa etapa do processo.

O objetivo é destacar quais são os cenários macro de testes, quais as técnicas que serão utilizadas para os mesmos, qual o tipo desses testes e eventuais especifidades declaradas durante a reunião com o cliente. Por exemplo, se em algum momento da reunião, o cliente disse que as atividades do seu Portal estão em expansão e este deverá atender a 5.000.000 usuários por mês e os picos de acesso serão nas segundas e quintas-feiras, quando as notícias são atualizadas. Nesse momento foi identificado um requisito de eficiência do projeto, anotado na ata de reunião e não necessariamente foi levado em consideração pelo Analista de Sistemas, mesmo porque, parece muito mais uma declaração comercial do que técnica. Sendo assim, deve-se aprofundar nos pré-requisitos e definições dos testes de performance.

É também um momento interessante na etapa do planejamento de testes para definir a utilização dos Testes Exploratórios, pois estes também devem ser planejados. A idéia é procurar áreas "bugadas" que não são reveladas através da análise de testes tradicional. O planejamento desses testes é definido através dos Test Charters (ver definição no glossário do ISTQB), onde são especificadas as atividades, objetivos e artefatos desses Testes Exploratórios, sendo este naturalmente complementado por checklists, casos de testes tradicionais ou análise de riscos de qualidade.

Definido o tipo de teste a ser utilizado, o artefato desta fase é a consolidação de todas as informações referentes ao projeto de testes, complementando assim, o Plano de Testes. Por exemplo, a etapa de análise dos riscos (ou brainstorming apenas), como dito anteriormente, a definição dos Test Charters, o Sprint Test Planning ou a descrição macro dos cenários de testes baseados em especificação. Este último é geralmente feito da seguinte forma: define o cenário, descreve um funcionamento básico e uma possível solução de testes para este (se vai utilizar checklist, se vai utilizar caso de teste, se vai utilizar uma tabela de transição de estados, etc.)

Test Case Lifecycle - Business Test Analysis

2011-04-28T10:17:00.000-07:00

Minha referência básica para escrever qualquer post é baseado nos sete princípios de testes. Nesse caso não é diferente, o princípio relacionado é o "Early Testing". Que, como todos sabem, é a premissa de que as atividades de testes devem estar precocemente envolvidas em projetos de Software.

Todavia, essa é uma situação digamos, bem delicada. Em todos os lugares onde eu trabalhei e/ou prestei consultoria e participei do processo do começo ao fim, a equipe de projeto sempre tinha uma resistência ao envolver a equipe de testes nas primeiras fases do projeto. Isso se dá por uma série de motivos, dentre eles: falta de experiência no negócio, falta de experiência profissional, perfil inadequado ou simplesmente a resistência em envolver um profissional de qualidade por simplesmente julgar desnecessário. Empresa que possui um profissional de qualidade com perfil inadequado ou com falta de experiência profissional, é a mesma empresa que tem resistência em envolver esse profissional precocemente no processo. Contrata uma pessoa sem (muita) experiência profissional, sem perfil adequado (às vezes) e espera que seu projeto tenha sucesso nos requisitos relacionados a qualidade. Pura inocência.

A primeira fase do Test Case Lifecycle é a Business Test Analysis, que, como já dito, resumidamente no post anterior, é o envolvimento da equipe de testes nas primeiras reuniões de definição do projeto. Eu diria que, se pudesse envolver a equipe de testes nos primeiros contatos comercial, seria o ideal, mas nesse caso poderia ser inclusive um tiro no pé (comercialmente falando), ou não. Se a empresa mostrasse ao seu cliente a preocupação em manter a qualidade daquele projeto alocando um profissional de testes como "ouvinte" na reunião, talvez pudesse ser uma boa ideia.

Para os fãs de metodologias ágeis, eu diria que, quanto maior a dependência de processos, menor a necessidade desse primeiro envolvimento. Para metodologias ágeis, no caso, seria justamente o contrário, o envolvimento inicial seria extremamente necessário. Digo isso pelo fato de que, na metodologia tradicional, as atividades de testes começam, teoricamente, quando o primeiro artefato de análise/desenvolvimento é gerado.

Todo profissional de testes com certa experiência sabe (ou já ouviu falar) da ISO9126. É aquela ISO que define os requisitos de qualidade que um projeto de software deve possuir. O perfil do profissional deve ser cuidadosamente analisado antes de ser alocado. Digo por isso, porque para alguns tipos de projetos requerem competências específicas, por exemplo, portais corporativos geralmente necessitam de conhecimento em análise de usabilidade. Inclusive tenho a leve impressão que um site hoje é mais bem visto pelo seu design e usabilidade do que por suas funcionalidades, confiabilidade e eficiência propriamente ditos.

Para maiores informações, segue:
http://pt.wikipedia.org/wiki/ISO/IEC_9126

Test Case Lifecycle (Ciclo de Vida de um Caso de Teste)

2011-04-19T07:34:00.000-07:00

Eu diria que, como tudo em desenvolvimento de software, o Caso de Teste também possui um Ciclo de Vida. Estas fases se dividem em (OK, não sou muito bom em criar nomes): Business Test Analysis, Macro Test Analysis, Test Case Analysis/Implementation, Test Execution, Test Refactoring e Test Maintenance.

Só para questões de entendimento, não extrai essas informações de nenhum livro, decidi detalhar o que entendo por criação de casos de teste. Os termos que eu costumo utilizar em todos os meus posts são do ISTQB, que, na minha opinião, é a certificação mais consolidada no mercado global (e nacional) de testes.

Diferente de antigamente, hoje as pessoas (ou a maior parte delas) já tem noção da importância dos testes e dos malefícios em abdicá-lo no seu processo de desenvolvimento de software (seja este qual for). E isso, é graças ao esforço praticado pela comunidade de testes no Brasil e no mundo.

Todavia, às vezes nem nós temos consciência do quão complexa pode ser uma "simples" atividade de criar casos de teste. Sendo assim, eu definiria seis fases primordiais:

Business Test Analysis: Visto de maneira mais simples, essa fase do projeto é a simples presença do responsável pelos Testes do projeto na reunião de requisitos, para uma explicação geral sobre o que é a proposta do sistema/componente a ser desenvolvido e como estes serão testados. De forma mais profunda, é nessa reunião que o Analista de Testes vai avaliar quais são requisitos do sistema que estão de acordo com as normas da ISO 9126. Por exemplo, mais obviamente, as funcionalidades do sistema, qual o nível de acurácia, se aderente às leis locais; questões de usabilidade, questões de desempenho, testabilidade (muito importante), portabilidade e outros.

Macro Test Analysis: Definidos os requisitos é o momento de decidir qual estratégia e planejamento que serão utilizados para os testes naquela release, se vão utilizar testes ágeis/exploratórios, se vão utilizar testes baseados em riscos, ou baseados em especificação. É a etapa de testes onde, eu diria, que vai definir a abordagem utilizada e detalhar os cenários de testes (utilizando Test Charters ou Test Conditions - de acordo com a definição do ISTQB).

Test Analysis/Implementation: Essa fase pode ser integrada à próxima fase (Test Execution) se for um projeto ágil. Mas de maneira geral, é a fase onde, com a definição macro dos testes no sistema, as técnicas serão utilizadas e as informações sobre o projeto serão refinadas (lembrando que, uma das atividades de testes é dar informações ao projeto). É nessa fase onde, num projeto iterativo, também serão definidos quais os cenários/casos de teste que serão utilizados nas próximas releases, quais serão selecionados para a fase de testes de regressão, e outros.

Test Execution: Essa fase continua sendo a fase de execução dos casos de teste, reporte de defeitos mas também é importante lembrar nessa fase, que os desvios nos casos de teste devem ser anotados, para, numa fase posterior, serem corrigidos.

Test Refactoring: Depois dos casos de teste executados e finalizados, é muito importante que, com intuito de garantir a longevidade do projeto, esses casos de teste sejam corrigidos e adaptados ao sistema da forma como ele é implementado de fato. Só assim os casos de teste vão espelhando a realidade do sistema a médio prazo, tornando também os Analistas de Teste mais especializados no sistema com o passar do tempo.

Test Maintenance: Eu diria que essa fase está presente em todo o ciclo de vida dos casos de teste. Na verdade eu deveria utilizar a expressão "artefatos de teste", sendo assim, mais generalista e adaptável para qualquer contexto. Bem como o sistema muda o tempo todo (independente da metodologia) os artefatos de teste também devem ser atualizados, garantindo assim a qualidade também dos artefatos de teste.

Só para deixar claro que eu não estou reinventando a roda. Sendo assim, provavelmente ideia do Testcase Lifecycle tenha ficado um pouco nebulosa. O objetivo é criar mais posts detalhando e exemplificando cada fase dos mesmos. Ficando assim, mais claro.

A verdade sobre as Metodologias Ágeis

2011-04-12T11:06:00.000-07:00

Durante muito tempo, testar utilizando metodologias ágeis era um grande mistério. Até hoje é impossível alguém dizer que aplicou uma metodologia de testes em projetos ágeis e funcionou perfeitamente. O que existe hoje são boas práticas ou alguns cases (não necessariamente de sucesso) utilizando essas metodologias chamadas "ágeis".
Escrevo isso por causa de um comentário feito sobre Bernard Homès numa palestra dele: "Would you fly in an airplane developed and tested by Agile methodologies? Traduzindo: você voaria num avião que foi desenvolvido e testado utilizando metodologias ágeis?" É claro que não. E a partir disso fiz uma reflexão...
Uma coisa deve ficar clara: metodologias ágeis são "bem vindas" quando a qualidade não é o requisito principal daquela aplicação. Como uma empresa é capaz de dizer que seus softwares são de ponta e têm qualidade se estes são desenvolvidos utilizando metodologias ágeis? Isso é hipocrisia, qualquer um que conhece desenvolvimento de software sabe que isso é uma grande piada. Como que vão garantir a qualidade no desenvolvimento do software se a alteração do requisito é feita ao telefone pelo Product Owner e gritado para a equipe pelo Scrum Master? Controle de mudanças? Em software pequeno é fácil ter esse controle. Só que nenhuma empresa quer que seu software seja pequeno e nunca tenha alterações por parte dos clientes? Bom, na verdade a resposta é sim, e obviamente isso seria o ideal, mas isso não existe, OK? Clientes pedem alteração o tempo todo, e é dinheiro jogado fora ficar alterando software on-the-fly. "Ah para, isso é ser ágil! Não tem burocracia, é só chega e dá-lhe".
Esse pensamento do "chega e dá-lhe" veio à tona porque ninguém sabe desenvolver software, a gente tem mania de dizer que documentação só serve para virar rascunho, e que ninguém usa para nada. Com certeza, ninguém usa porque ninguém controla. Chega uma hora que não faz mais sentido cuidar da matriz de rastreabilidade, é muito grande, desnecessária e ninguém usa para nada, não é? Daí quando o projeto está perdido, vão dizer: ué, não tem uma matriz de rastreabilidade? Deveriam ter feito... Foi incentivado no início? Não! Agora os Testes de Regressão causam uma GRANDE dor de cabeça.
Esses dias eu vi uma propaganda "nossa empresa tem uma metodologia própria, o Dynamic Outsourcing". Que, nada mais nada menos, é praticar o outsourcing utilizando metodologias ágeis. Ou seja, sugar dinheiro do seu cliente da forma mais "inocente" possível. O cliente acha que o projeto está sendo ágil mas na verdade está sendo uma grande farsa, pois o tempo que gasta fazendo uma alteração de cada coisa que não está de acordo, é tempo perdido.
Bom, antes de qualquer coisa, gostaria de declarar que eu não sou um defensor das metodologias tradicionais. Como eu costumo defender as citações de Glenford J. Myers: "testing is context dependent", eu já diria nesse caso que: "methodologies are context dependent". Ou seja, metodologias ágeis podem ser ótimas, mas para contextos específicos. Não caiam na ilusão de que é aplicável para qualquer tipo de projeto.

TestComplete - Por onde começar?

2011-03-14T06:52:00.000-07:00

Muitas pessoas me perguntam, qual é a grande sacada do TestComplete? Por onde começar? Bom, tem várias formas de trabalhar e a forma mais prática que eu costumo dizer, é: aprendam a programar, senão serão desenvolvedores de testes limitados. As ferramentas do mercado, não só o TestComplete, bem como o Quicktest Pro, Winrunner, Rational Robot, Selenium e outros são excelentes, muitas delas possuem as funções de "Record&Play", apenas alterando os parâmetros. Ótimo!
Mas e as rotinas mais complexas? Como fazer? Se quiser validar um dado adicionado? Uma instrução? Uma rotina específica do sistema? Vai travar? Pois então... É aí que eu digo: saibam programar!
Para ser bem sincero, não precisa ser o melhor programador do mundo, o Google te ajuda bastante! Basta, claro, não ter fugido das aulas de Programação da faculdade e/ou do seu curso.
Todavia, o objetivo desse post é mostrar como o TestComplete pode ser uma ferramenta excelente e auxiliar muito nos testes automatizados.
Dá para associar "Record&Play" a algumas rotinas básicas em programação, funciona e na maioria das vezes, são suficiente. Mas, com certeza, os horizontes são muito maiores utilizando a função de Name Mapping.
A grande sacada, basicamente, é mapear os objetos na tela, criar um Name Mapping para ele (o tal do Aliases.ie7.Page.Mapeamentos* utilizados nos posts anteriores) e utilizá-los como se fossem objetos. Daí pra frente é só por a mão na massa.
É importante utilizar o "ctrl+space" e ver quais funções podem ser utilizadas e ir, muitas vezes, na tentativa e erro.
Por exemplo:
Aliases.ie7.Page.ObjetoMapeado.Click(); // Para clicar no objeto caso este seja um botão, link, etc.
Aliases.ie7.Page.ObjetoMapeado.Keys("texto"); // Para inserir um "texto" no campo, caso esse seja um textfield, etc.
Aliases.ie7.Page.ObjetoMapeado.focus(); // Para colocar o foco da tela no link, pois às vezes ele não é localizado pois o PC onde o teste está rodando, pode ter uma resolução menor.
Esses são os mais simples, possuem vários outros bem interessantes.

TestComplete - Trabalhando com grids

2011-03-11T06:53:00.000-08:00

A forma mais fácil e prática de trabalhar com grids é utilizando árvore DOM, nesse caso eu estou utilizando o TestComplete 7 e linguagem Javascript (o cliente que quer assim, por mim utilizaria C#). Aqui segue um exemplo de código que fiz para percorrer os dados de uma grid.
Essa função criada retorna os dados de uma coluna da grid, passando a grid como parâmetro, como por exemplo:
var grid = Aliases.ie7.Page.Main.RelatorioFuncionarios.grid;

Sendo assim, o método ficaria dessa forma:
function retornaColuna(grid)
{
//Nessa variável tBody eu coloquei o childNodes[0] que é referente ao objeto TABLE
var tBody = gridEspelhoPonto.childNodes[0];

//Inicializa array para armazenar os objetos de cada coluna
var arrayColuna = new Array();

for (var i = 0; i | tBody.length; i++)
{
arrayColuna [i] = tBody.childNodes[i].childNodes[11].outerText;
}
return arrayColuna;
}

Para entender a linha: arrayColuna [i] = tBody.childNodes[i].childNodes[11].outerText; é preciso conhecer o conceito de Árvore DOM. Basicamente o primeiro "childNodes" é referente à tabela, o segundo, é referente à linha e o terceiro é referente à coluna (é como uma grid se estrutura no HTML), para entender melhor, segue um exemplo:
|TABLE| //Refere-se à grid.childNodes[0]
|TR| //Refere-se à grid.childNodes[0].childNodes[0]
|TD|...|/TD|//Refere-se à grid.childNodes[0].childNodes[0].childNodes[0]
|TD|...|/TD|//Refere-se à grid.childNodes[0].childNodes[0].childNodes[1]
|TD|...|/TD|//Refere-se à grid.childNodes[0].childNodes[0].childNodes[2]
|/TR|
|TR| //Refere-se à grid.childNodes[0].childNodes[1]
|TD|...|/TD|//Refere-se à grid.childNodes[0].childNodes[1].childNodes[0]
|TD|...|/TD|//Refere-se à grid.childNodes[0].childNodes[1].childNodes[1]
|/TR|
|/TABLE|
PS: Utilizei | ao invés de <> para não dar conflito com o HTML do Blog.

Porque eu considero essa a forma mais fácil e prática de trabalhar? Pois pode haver uma grande variação de layout de uma grid mas a estrutura interna geralmente se mantém, obviamente os scripts devem ser periodicamente revisados. Tive muitos problemas com mapeamento de objetos do TestComplete, pois as páginas são dinâmicas e/ou é preciso dar um find dentro de uma estrutura para encontrar o objeto necessário. Cada um tem sua forma de implementar, essa é a minha. Postem suas sugestões!

TestComplete - Parâmetro trazendo valor incorreto

2011-02-23T09:53:00.000-08:00

Estou escrevendo esse post para dividir a minha incomodação das últimas horas.

Estou desenvolvendo um método que, dentre outras coisas, eu defino no filtro a Data Início e a Data Fim.

Desta forma:
function ID010 (DataInicio, DataFim, Matricula)
{
//Informar Data de Início e Data Fim
Aliases.ie7.Page.Main.TelaABC.txtDataInicio.Text = DataInicio;
Aliases.ie7.Page.Main.TelaABC.txtDataFim.Text = DataFim;
...
}

Todavia, o campo Data Início estava com um comportamento muito estranho, toda vez que eu executava a função ID010, ele não trazia o valor correto definido no parâmetro.

Tal como:
ID010 (01112010, 31112010, 123123);

Ou seja, a Data Início definida no parâmetro era: 01/11/2010
E a Data Fim definida no parâmetro era: 30/11/2010

Durante a execução dessa função, a Data Início carregada na Aplicação (após execução do Script) variava (como por exemplo, 824328 ou 300040), e a Data Fim carregada na Aplicação (após execução do Script) estava OK, conforme previsto: 30/11/2010.

Fiz uma série de análises:
- Refiz o mapeamento;
- Já utilizei um método específico para definição de datas (utilizei um dos seus como parâmetro conforme a seguir):
function preencheDataInicio(valor)
{
aguardaCarregar();
if (aqString.Compare(valor, "__/__/____", false) == 0)
Aliases.ie7.Page.Main.TelaABC.txtDataFim.Keys("[Del][Del][Del][Del][Del][Del][Del][Del]");
else
{
valor = aqString.Replace(valor, "/", "");
Aliases.ie7.Page.Main.TelaABC.txtDataFim.Keys(valor);
}
}
- Já utilizei .Keys(valor) ao invés de .Text
- Já coloquei focus() e Click() no campo (apesar de não ter nada a ver);
- E quaisquer outras funções que possam referenciar ou limpar o conteúdo do campo antes de inseri-lo.
- Já tentei até fazer uma gambiarra: clicar em Consultar, dar erro (campo obrigatório) e setar o valor no campo novamente, mas o script insiste em setar o mesmo valor no campo.
- Inclusive, coloquei como primeira linha do script, trazer o valor do parâmetro e jogar num Log.Message(DataInicio). Mesmo problema;

O curioso é que eu tentei fazer o mesmo com a data 31102010 e o valor retornou corretamente. Tentei com a data 02112010 e 03112010 e deu o mesmo problema. Parece que esse campo retorna scriptado ou algo do tipo.

Fui almoçar, esfriei a cabeça e voltei. Quando vi a solução era mais simples do que eu pensava. Era só passar a data como String, talvez o Javascript (linguagem utilizada para scriptação) não estava processando corretamente esse valor.

A solução era:
ID010 ("01112010", "31112010", 123123);

Por isso eu digo, quando estiverem batendo a cabeça num problema. Tomem um ar, respirem fundo e pensem fora do quadrado. Garanto que vai ajudar!

TMMi - o que é isso?

2011-02-04T17:54:00.000-08:00

Para quem foi ao CinTeQ 2010, esse termo é no mínimo familiar, para quem não foi, talvez só tenha ouvido falar. TMMi é o chamado Test Maturity Model integration, nada mais é do que o complemento do CMMi, que é um modelo de negócio focado para melhoria contínua dos processos de desenvolvimento de software de uma empresa. O TMMi veio da necessidade de se ter um processo evolutivo e bem definido de testes para as empresas já possuidoras do certificado CMMi (level 2 ao 5).
Apesar de eu recentemente ter postado um escândalo sobre uma prova do ISTQB, ainda assim acredito nos procedimentos deste órgão. Pessoas são seres passíveis ao erro (nós da área de testes sabemos bem o que é isso) e consequentemente instituições podem errar também, sendo assim, o erro é perdoável.
Comentei do ISTQB pois a base do TMMi veio do ISTQB, as sintaxes, expressões e abordagem. Isso se dá, claro pelo fato do principal entusiasta do TMMi ser o antigo vice-presidente do ISTQB, Erik Van Veenedaal (gestão de 2005 a 2009).
Resumidamente, a abordagem do TMMi, veio para mudar o paradigma da computação, focando o objetivo dos testes na prevenção de defeitos e não na detecção destes.
O mais interessante, é que o primeiro nível do TMMi (no caso, o nível 2) é estabelecido assim que a empresa consegue adotar os procedimentos padrão que é abordado na certificação mais simples do ISTQB, o CTFL. A empresa é considerada TMMi nível 2 assim que ela estabelecer os seguintes padrões: Estratégia de Testes, Planejamento de Testes, Monitoramento e Controle de Testes, Execução e Modelagem de Testes e Ambiente de Testes dedicado. De longe parece simples, mas é necessário que a empresa esteja com os processos BEM maduros para aplicar com perfeição essas práticas.
Fonte: http://www.tmmifoundation.org/

Analista de Testes? Tem certeza?

2011-02-03T04:30:00.000-08:00

O objetivo deste post é relatar minha indignação contra esse cargo "tão" almejado que é ser ANALISTA de Testes.
Para início de conversa, o que é um Analista? Pessoa que analisa ou é versada em análises. Pessoa cujo ofício é fazer análises das propriedades químicas, físicas ou de outra espécie de uma substância ou produto.
Em outras palavras, um ANALISTA de Testes é aquele que vai analisar o artefato de Análise/Desenvolvimento (seja este uma documentação de qualquer gênero, um sistema legado, um papel riscado, etc) e transcrevê-los em palavras amigáveis para profissionais de teste. Em tese, o Analista de Testes não deveria executar os testes, quem faz isso é testador, mas na prática isso não funciona.
Talvez a dificuldade seja entender o que significa a palavra ANALISAR. Então vai outra explicação do dicionário: Ponderar ou estudar vários aspectos, fatores ou elementos a fim de chegar a uma conclusão, resultado ou solução. Ou seja, abstraia isso para o "mundo de testes", o que significa?
O profissional deve ESTUDAR o artefato e PROPOR uma solução. O que eu vejo muito por aí é o profissional do estilo "deixa a vida me levar", qualquer coisa pra ele deve ser um caso de teste e colocar no maldito Testlink. Existem coisas que são infinitamente mais fáceis de testar criando um simples checklist. Por exemplo, desenvolvemos um módulo para um sistema do cliente o qual era para criar uma atividade no sistema que gerava um documento .txt. Esse documento buscava informação de algumas tabelas no banco de dados, tratava algumas e as colocava nesse .txt. Esse documento possuía 8 colunas. Recebo o documento com os Test Cases com o seguinte formato: Cenário, Passos e Resultado esperado.
Cenário 1: Verificar tamanho da coluna 1
Passos 1: No arquivo XXXXXX.txt verificar se a coluna 1 possui 8 caracteres de largura
Resultado esperado 1: A coluna 1 possui 8 caracteres.
E assim sucessivamente para os demais cenários. Isso é só a ponta do iceberg, o último Test Case que recebi possui mais de 100 cenários, sem contar os trocentos testes que poderiam estar aglutinados em apenas um. Nesse caso, por que não criar um checklist? Infinitamente melhor! Vejam:
Verificar se a coluna 1 do arquivo XXXXX.txt possui 8 caracteres - OK?
Verificar se a coluna 2 do arquivo XXXXX.txt possui 2 caracteres - OK?
Verificar se a coluna 3 do arquivo XXXXX.txt possui 10 caracteres - OK?
Viu? Simples.

TestComplete - Primeiros passos

2011-01-26T07:03:00.000-08:00

Comecei recentemente a brincar com o TestComplete (apesar de já ter feito o treinamento na Qualister há 1 ano, não lembro de nada lecionado nele) por necessidade de um cliente meu, então vou postando no Blog algumas rotinas. A maioria conhece a ferramenta, mas para quem não conhece, vai um post introdutório de uma colega sobre a ferramenta. Pode ser útil para alguns e completamente inútil para outros, sendo assim, aí vai.

Lembrando que estou utilizando o TestComplete 8 criando os scripts na linguagem C# numa aplicação Web, desenvolvida em Microsoft .NET com Banco de Dados SQL Server.

Muitas das referências dos scripts que eu criei foram encontradas diretamente no site da AutomatedQA. Boa parte delas estavam incorretas.

A rotina que eu criei é simples, julguei o mais interessante para ir me ambientando com a sintaxe do software. A rotina é: Criar vários usuários no sistema e utilizar os dados de cadastro a partir de uma planilha no Excel, para isso:
- Precisei definir como vou inicializar o objeto do Excel no TC (TestComplete), pois este oferece três opções: DB Table, DDT (Data-Driven Test)e instanciando um objeto propriamente dito. Tive que usar DDT e instanciar um objeto, cada um para um propósito:

- Primeiramente precisei descobrir como fazer a leitura do total de linhas do arquivo (para ele cadastrar todos os usuários do arquivo) pois como estava no site da AutomatedQA, estava de forma incorreta. Para este caso, utilizei o DDT:

//Inicializando o Excel via DDT
ExcelDDT = DDT["ExcelDriver"]( "C:\\Usuario.xls", "Usuario");

//Verificar quantas linhas o Excel possui e contabilizar na variável "rowcount"
while (! ExcelDDT.EOF() )
{
ExcelDDT["Next"]();
rowcount++
}

//Fechar o driver
DDT["CloseDriver"]( ExcelDDT.Name );

- Posteriormente, tive que instanciar o objeto do Excel, para facilitar a leitura das linhas:

//Instanciando o objeto Excel
Excel = Sys["OleObject"]("Excel.Application");
Excel["Workbooks"].Open("c:\\Usuario.xls");

- Como o script precisava inserir vários usuários no sistema, fiz um "for" para leitura do documento até o último registro da planilha. Lembrando que nessa planilha existiam três colunas (Matricula, Nome e CPF). Conforme a rotina a seguir:

for (i = 2;i<=rowcount; i++)
{

//Referência dos campos da tela Inserir Usuário
frame = page["Panel"]("ext_gen36")["Panel"]("ext_gen43")["Frame"]("main");
table = frame["Form"]("baseForm")["Table"](0);
panel = table["Cell"](2, 0)["Panel"](0);
table2 = panel["Table"]("dPess");
table3 = table2["Cell"](1, 2)["Table"]("Table16");

//Matricula
matricula = VarToString(Excel.Cells(i,1));
textbox = table3["Cell"](0, 0)["Textbox"]("txtCode");
textbox["SetText"](matricula);

//Nome
nome = VarToString(Excel.Cells(i,2));
textbox = table2["Cell"](2, 0)["Textbox"]("txtNmUser");
textbox["SetText"](nome);

//CPF
cpf = VarToString(Excel.Cells(i,3));
textbox = table2["Cell"](4, 2)["Table"](0)["Cell"](0, 0)["Textbox"]("txtCpf");
textbox["SetText"](cpf);

...

}

A referência dos campos foi inserida dentro do "for" para não se perder numa próxima iteração.

Lembrando que as devidas variáveis foram instanciadas no início do script. O objetivo principal desse post é a troca de experiência, espero ter ajudado nesse pontapé inicial.

Bom, é isso. Assim que tiver mais novidades retorno com um novo post.

A moda agora é ser Consultor...

2011-01-06T10:18:00.000-08:00

Muitos vão ler esse post e dizer: "ah, esse Luiz Gustavo está reclamando que tem muito consultor então ele cria esse post reclamando que tem muita concorrência", na verdade não, talvez até eu tenha me equivocado ao me considerar um "Consultor". A idéia da consultoria veio pelo simples fato de eu me tornar, há quase dois anos, dono da minha própria empresa, cuja especialidade é Outsourcing de Desenvolvimento de Software. Então, sempre que existe uma oportunidade de prestar algum serviço relacionado a Testes de Software na qual minha equipe tem condições de absorver, eu fecho o negócio. Confesso que em 2010 prestei somente 3 consultorias relevantes de testes (o resto eram apenas serviços agregados ao desenvolvimento propriamente dito), e sinceramente não é um mercado muuito promissor (corrijam-me se eu estiver errado, ou talvez seja tudo uma questão mais comercial). A situação do mercado de Testes todos já estão cansados de saber e que a mentalidade dos gestores está mudando, todo mundo também está cansado de saber.
Defendido meu lado (mesmo que sem necessidade), gostaria de comentar um fato o qual percebo que é, no mínimo, engraçado. Essa situação se dá devido ao fato de que muito pouca gente conhece realmente o assunto "Testes de Software". Tudo o que a nossa comunidade preza por disciplinas em Testes de Software, pros demais, se resume ao "testa aí".
Sabido disso, todo profissional que tem alguma experiência em Testes de Software e/ou alguma certificação relevante na área, percebe uma oportunidade e se considera um mega-especialista em "implantação do processo de testes nas empresas". Pensem, quem vai querer contratar um terceiro para implantar um processo de testes (custos altos) se pode contratar um Junior/Pleno e este agregar à equipe e ir implantando, aos poucos, o processo propriamente dito?
É como eu falei no segundo parágrafo, isso é uma piada. Hoje existem mais Consultores de Testes de Software que Analistas de Testes no mercado. Para exemplificar a situação, abrimos um processo seletivo para a vaga de Analista de Testes aqui na LUGATI. Apareceram alguns bons candidatos, mas apareceu ainda mais profissionais já empregados interessados em prestar "consultoria". Perguntando-me o seguinte:
- Você terceiriza a criação dos seus casos de teste?
- Você terceiriza a revisão dos seus documentos de análise?
- Você terceiriza a execução dos seus testes?
Ou até:
- Podemos negociar uma consultoria para implantação o processo de testes na LUGATI?
- Legal, e o que podes me oferecer?
- Podemos definir o que é um caso de teste, posso instalar o Testlink integrado com o Trac/Mantis e explicar como se reporta um defeito!
Ou seja, isso prostitui nossa profissão. Não é um grande feito saber instalar o Testlink, saber o que é um caso de teste ou saber como se deve reportar um defeito.
Na minha opinião, consultorias relevantes são:
- Otimização do processo de testes (e não implantação) caso seja identificado um gargalo na própria equipe;
- Automação de Testes;
- Testes de Segurança;
- Testes de Desempenho;
- Ou até um pente fino no Software da empresa desesperadamente à procura de bugs (Testes Exploratórios e outros) - pouco provável.
Mais alguma sugestão?

Certificações perdendo o valor no Brasil...

2010-12-03T06:03:00.000-08:00

Tenho acompanhado nas listas de discussão muitas reclamações sobre as certificações de Testes de Software no Brasil (em específico a CBTS) e confirmo: isso está perdendo o controle, o valor e a qualidade dos profissionais que essas certificações estão formando.
Sou um membro fiel do ISTQB (inclusive, como alguns já sabem, faço parte do BSTQB TAG - que é a banca que é responsável pela tradução do Syllabus do inglês para o português e tem por objetivo principal, não perder a qualidade do material quando traduzido para a nossa língua nativa), mas o que ouvi hoje foi uma grande palhaçada e não posso me omitir quanto a isso.
Fui procurado por um colega há algumas semanas para oferecer uma ajuda nos estudos para a certificação CTAL-TA e passei para ele alguns Mocks e Sample Questions e orientações sobre a prova em geral.
Hoje ele veio me dizer as seguintes frases, antes até de me dar bom dia:
"Provinha de merda... ESCRITA, EM PROTUGUÊS e IDÊNTICA aos Sample Questions!"
"Cara, eu não tava acreditando. Terminei a prova em menos de uma hora e meia. Porra, mas isso é uma merda pq enfraquece o valor da certificação."
"Sem sacanagem: foi IGUAL. Até a posição das respostas eram idênticas."
O que me dizem disso?
E pra concluir, ele disse a seguinte frase:
"Se num gabaritei vou ficar puto."
Outro comentário que recebi através da lista de discussão que participo quando divulguei em primeira mão esse post:
"Hoje estava agendado a prova para ser realizado na cidade de Goiânia, pela BSTQB.
E adivinha o que aconteceu...
A prova não chegou... ou seja, eu e mais 8 pessoas não tivemos a oportunidade de falar a respeito da prova.
Estamos aguardando a pessoa da BSTQB, entrar em contato."
Não vou dar minha opinião pessoal sobre o que eu acho disso, mas se as entidades certificadoras daqui do Brasil pensam em criar bons profissionais, estão fazendo errado. Mal estamos terminando de refinar a tradução do Syllabus Foundation e já estão aplicando a prova do Advanced.
Desculpem-me, mas ponto negativo para o BSTQB. E o pior de tudo, se anularem a prova, vai ser uma grande sacanagem com quem estudou e decorou as questões.

Offshoring to Brazil or India?

2010-10-07T06:42:00.001-07:00

Já passou a época na qual a Índia era um país extremamente barato. Há 4 ou 5 anos, os salários na área de tecnologia na Ásia eram 1/3 do salário no Brasil, hoje, como podem comprovar na imagem em anexo, os salários já são quase compatíveis.

A Êtkâ Pardhi é uma Test Manager com quatro anos de experiência na área de tecnologia e trabalha numa pequena empresa de Mumbai, Índia.

54.800 Indian rupees é aproximadamente 1240 dólares. Dá algo em torno de 2100 reais. A cotação do dólar paralelo de hoje é 1.7 reais. Independente da cotação do dólar, os salários lá cresceram bem mais justamente pelo motivo de que os investimentos mundiais em tecnologia no Brasil foram fracos nos últimos anos, as empresas americanas e européias ainda optam por terceirizar em países asiáticos. Nos últimos dois anos isso tem mudado, mas por enquanto, essa é a triste realidade.

Meu Test Case tem informação suficiente?

2010-09-21T08:20:00.000-07:00

Tive a iniciativa de escrever esse post após presenciar uma discussão sobre "como elaborar um caso de teste" na lista DFTestes. Sinceramente não li todos os posts e nem faço muita idéia do que estava sendo discutido, mas percebi que muitas pessoas colaboraram com propostas de casos de teste, qual o nível de detalhamento seria necessário, entre outras sugestões muito interessantes.
Todavia, se for analisar a situação com uma visão mais gerencial, o nível de detalhamento dos casos de teste, na minha opinião, deve estar associado ao tempo disponibilizado para esta etapa do processo. Não tem como elaborar um teste com validação campo a campo, por exemplo, se o tempo é curto.
Vamos para uma situação cotidiana, se a pessoa possui uma semana (40 horas) para criar 80 casos de teste, deve-se levar em consideração que o tempo de criação do mesmo deve ser de aproximadamente 30 minutos. O que pode ser detalhado em 30 minutos? Os artefatos de testes são sólidos ou subjetivos para se ter um detalhamento suficiente dos casos de teste?
Por isso, antes de avaliar como deve ser criado o caso de teste, é importante levar em consideração qual a estratégia dos testes. Caso sua empresa não tenha essa formalidade, não é necessário criar um documento específico declarando quais os objetivos e a missão do teste para aquele projeto em específico. Basta conversar com a gerência e questionar o que deve ser testado.
Quem vai avaliar como esses casos de teste serão elaborados e qual técnica vai ser melhor aplicada, é o Analista de Testes. O gerente delimita: foram planejadas 40 horas para testar a aplicação, faça da melhor forma possível.
Caso seu gerente de testes tenha efetivamente criado o Plano de Testes, analisado a aplicação como um todo e feito um planejamento adequado para as horas trabalhadas por cada recurso, possivelmente essas horas serão suficientes para criar os casos de teste com êxito. Caso não, se vira nos trinta...

Qualidade para todos!

2010-09-20T12:10:00.000-07:00

Muitos (ou todos) os profissionais que trabalham da nossa área sabem que Testes de Software é somente uma das várias disciplinas que abrangem a Qualidade de Software. Como todos sabem, qualquer atividade dentro de um processo de desenvolvimento de software que agrega valor ao projeto é considerado um requisito de qualidade, mas para ser bem honesto, não sou um especialista em Qualidade de Software, meu conhecimento é focado em Testes de Software.
Muitas empresas têm interesse em investir na criação de um departamento de testes e algumas delas tem êxito na implantação do processo, até aí tudo bem. O problema é que parece que os demais profissionais se tornam preguiçosos, naturalmente declarando o seguinte discurso: "Eu sei que tem erro no código e/ou documento, mas quando for testado e/ou revisado, vão achar e me reportar, daí eu corrijo."
Ou seja, na minha opinião, isso se dá devido a alguns fatores:
- Prazos apertados (ou por deixarem tudo para a última hora);
- Profissionais de testes se tornam muito "caxias", como por exemplo, relatarem bugs por alinhamento incorreto de um campo na tela;
- Falta de visibilidade do negócio, ou seja, se o profissional não sabe a importância do negócio para a empresa, ele inconscientemente não vai dar a mesma importância para aquele código/documento;
- Ou simplesmente por desinteresse com o negócio e falta de profissionalismo (mas isso daí já é um problema com o setor de RH...);
- etc.
Sabido disso, sempre que faço consultoria de testes nas empresas, primeiramente faço uma apresentação sobre "o que é teste de software" para toda a equipe de desenvolvimento, inclusive gestores. Assim toda a equipe tem uma visibilidade sobre o que é e como funciona o negócio.
Não adianta ter uma empresa com processos e profissionais de teste excelentes se os demais profissionais se tornam preguiçosos, entregando códigos/documentos falhos por pressão da entrega. É preciso que haja cooperação na entrega. Sendo assim, eu dou a devida importância para a seguinte situação: Qualidade é para todos!

Técnicas Avançadas: Tabelas de pares (ou Array Ortogonal)

2010-08-19T12:23:00.000-07:00

Provavelmente a mais complexa e menos utilizada das técnicas avançadas de Testes de Software. Ela não é utilizada por desconhecimento, pois muitas pessoas deixam algumas combinações de fora e utilizam outras milhares de combinações. Dessa forma, os profissionais normalmente acabam pecando na elaboração desses casos de teste (ou até mesmo durante a execução dos mesmos), fazendo a chamada "combinatory explosion". Cuidado!

A tabela de pares é criada quando precisa testar várias combinações de configurações. Sabe-se que é impraticável testar todas as possíveis combinações, levando isso em consideração, percebeu-se que a maior parte dos erros acontece em pares ou triplas. Essa técnica combina várias colunas de maneira que todos os dados se encontrem pelo menos uma vez, em pares.
Para melhor entendimento, veja a tabela a seguir.

Cada coluna significa um item de configuração, e cada linha são os casos de teste, ou seja, a combinação de valores. Por exemplo: deve-se testar um sistema fator 1 seria o Sistema Operacional (onde os dois itens existentes são: Windows XP e Linux) e o fator 2 o Navegador (onde os dois itens são: Firefox e Internet Explorer). A tabela ficaria assim:

Nessa tabela, perceba que todas as combinações foram testadas, ou seja, não é útil para apenas dois fatores. Como funciona?
Todos os fatores da coluna um devem ser combinados com todos os fatores da coluna dois que devem ser combinados com a coluna três e assim por diante. A ilustração da tabela a seguir, mostra a eficiência dessa técnica, se fosse fazer um máximo de combinações, três fatores com dois itens cada, resultariam em seis casos de teste. Portanto, utilizando a técnica, esses valores diminuem para quatro. Veja como:

Adaptando o exemplo anterior, supõe-se que o terceiro fator seria o tipo de conexão (banda larga e wireless), então, a tabela ficaria assim:

A pergunta é: está faltando algum valor? A resposta é não. Perceba que todos os valores da tabela combinam, em pares, com todos os valores da tabela:
- Windows XP combina com Firefox e IE (coluna dois) e com Banda larga e Wireless (coluna três). Mesma coisa para o Linux.
- Firefox combina com Windows XP e Linux(coluna um) e com Banda larga e Wireless (coluna três). Mesma coisa para o IE.
- Banda larga combina com Windows XP e Linux(coluna um) e com Firefox e IE (coluna dois). Mesma coisa para o Wireless.
Já existe uma forma de combinar esses fatores de maneira que não precise ficar gerando manualmente essa tabela. Existe uma técnica chamada Taguchi Orthogonal Array onde os valores já são pré-estabelecidos e só devem ser renomeados pelos valores em questão:
http://www.york.ac.uk/depts/maths/tables/orthogonal.htm

Técnicas Avançadas: Grafos de transição de estado

2010-08-12T12:15:00.000-07:00

Continuando meus estudos sobre as Técnicas Avançadas de Testes de Software funcionais. A bola da vez são os grafos de transição de estados. A imagem que utilizei como exemplo é bem simples e não dá pra ter uma dimensão do benefício de uso desta técnica.

Os grafos de transição de estado são utilizados para validar workflows e quaisquer outras formas de sistemas em que o estado do mesmo pode variar devido a ações específicas dentro do próprio fluxo. O objetivo basicamente é garantir que uma ação correta no sistema não vá levar o mesmo a um estado inválido, ou, a um estado válido através de um comando inválido (analisa-se também as questões de segurança do sistema).

Dividem-se os grafos de transição de estado em três elementos:

- Estado: É a situação em que o sistema se encontra por tempo indeterminado. Por exemplo: navegando no browser ou uma tela em específico do sistema (tela de login, tela de cadastro, etc).

- Evento: É o que acontece instantaneamente (ou por tempo determinado) que ocasiona numa transição. Por exemplo: clicar num link, efetuar login, etc.

- Ação: É a resposta do sistema durante uma transição. Uma ação é como um evento, acontece instantaneamente (ou por tempo determinado). Por exemplo: aparecer uma tela, disparar uma mensagem de erro, etc.

Nesse tipo de exemplo em específico, deve-se ter mais estados, como por exemplo, logando no sistema, efetuando a compra, enviando os dados de cadastro, etc. E mais ações e eventos, como abandonando a compra, logando corretamente ou incorretamente, confirmando dados de cadastro, etc.

Sendo assim, monta-se o diagrama com todos os estados e transições possíveis. Durante a criação ou execução dos testes, deve-se verificar se todos os estados são possíveis e se as transições (eventos e ações) levam para os estados corretos.

Técnicas Avançadas - Tabelas de Decisão

2010-08-04T06:28:00.000-07:00

É importante lembrarem que a todo post, estou fazendo alusão à certificação CTAL-TA, muito do que escrevo é a minha visão simplificada sobre cada uma das técnicas, mas alguns exemplos podem ser comuns à algumas bibliografias, não sei dizer exatamente de onde tirei cada exemplo, mas grande parte deles não é de minha autoria. Até pensei em utilizar exemplos práticos utilizados na minha empresa, mas não são dos mais didáticos.

Essa técnica, na minha opinião, é inteligentíssima, muita gente utiliza essa técnica de alguma forma seja via Excel, caderno de anotações ou qualquer outra forma prática de armazenar informações sobre o projeto. Mas é interessante saber exatamente como ela funciona para poder cobrir, de certa forma, todas as opções relevantes para o negócio.

Tabelas de decisão são uma maneira de modelar os testes baseados nas regras de negócio. O objetivo principal dessa técnica é verificar se as possíveis combinações do sistema estão sendo manipuladas de acordo com o previsto. Em outras palavras, definir quais casos de teste devem ser modelados para executar uma combinação de entradas (inputs) e/ou estímulos descritos na tabela de decisão, ou seja, é uma técnica que tem por objetivo auxiliar na criação de casos de teste.
Para obter um melhor entendimento de como as tabelas de decisão funcionam, é importante mostrar na prática quando e como elas devem ser utilizadas. Por exemplo, imagina-se uma empresa que faz o processamento de cartões de crédito para validação dos titulares e vendedores (empresas de cartão como Mastercard, VISA, etc.), algumas perguntas devem ser respondidas ao definir as ações que devem ser tomadas de acordo com cada perfil.
- O nome da pessoa e as outras informações sobre cartão de crédito estão corretas?
- O cartão ainda está ativo ou foi cancelado?
- A pessoa possui limite ou acima dele?
- A transação foi feita de um endereço válido ou suspeito?

Essas perguntas devem ser respondidas e devem responder a algumas questões importantes:
- A transação deve ser aprovada?
- Devemos ligar para o titular? (Por exemplo, avisá-lo que a transação foi feita de um endereço suspeito)
- Ligar para a empresa do cartão? (Por exemplo, perguntar a eles se o cartão cancelado foi confiscado)

Perceba que o total de casos de testes foram estabelecidos de acordo com a quantidade de condições, por exemplo, na primeira linha foram preenchidos oito vezes com S e oito vezes com N, na segunda linha, de quatro em quatro, na terceira linha de dois em dois, e assim por diante. Entretanto, algumas transações podem não fazer sentido, como por exemplo, a conta não existir e ser ativa, ou não existir e possuir limite, e por aí vai.
Para diminuir a quantidade de casos de testes, é necessário juntar as colunas que possuem valores em comum e não afetam nas ações tomadas. Por exemplo, perceba que sempre que a conta é inexistente (da coluna 9 à coluna 16), as ações são as mesmas, e por aí vai.

Colidindo as colunas da tabela, o resultado ficaria assim:

Nas condições que possuem hífen, significam que, independentemente da condição, a ação tomada é a mesma. Por exemplo, no caso de teste número 9, independentemente da conta estar ativa, possuir limite ou ter endereço válido ou inválido, a ação tomada é a mesma (não aprovado, não ligar para o titular e deve ligar para a empresa de cartões de crédito – vendedor)

Revista The Testing Planet

2010-07-29T10:04:00.002-07:00

A versão digital da revista está disponível.

Façam download em:
http://wiki.softwaretestingclub.com/f/TheTestingPlanet-July2010.pdf

Técnicas Avançadas: Partição de Equivalência

2010-07-27T11:22:00.000-07:00

Depois de falar de Análise de Extremidades, vale partir para o segundo conceito (que também é abordado no CTFL) que seria o Partição de Equivalência. Lembrando que estes conceitos podem ser usados ao mesmo tempo, existem situações específicas e úteis. Estas serão abordadas num próximo post.

Conceitualmente, partição de equivalência significa dividir as entradas em grupos (ou Subclasses) que sejam tratados da mesma forma no sistema, exibindo um comportamento similar.
A idéia é separar os itens de teste em subclasses que possuam as mesmas características e sejam disjuntos, ou seja, nenhum dos grupos selecionados podem ter um valor de entrada que pertença a ambos os grupos.

Idealmente, todos os valores devem ser testados, mas não necessariamente eles devem ser combinados. Imagine que vamos dividir os itens de teste em dois grupos principais: classes de conexão (X) e browser (Y), são duas conexões X1 (wireless) e X2 (ADSL) utilizando três browsers Y1 (Internet Explorer), Y2 (Firefox) e Y3 (Chrome). Com três casos de testes (representado pelas três colunas) esses opções podem ser eficientemente testadas, veja a figura a seguir:

Perceba que foram necessários três casos de teste para testar todas as classes de equivalência, ao invés de testar a combinação entre estes, o que resultaria em seis casos de teste. É importante salientar que essa técnica (bem como todas as outras) aplica os testes em áreas de maior cobertura do código, é possível que exista uma combinação de browser + conexão, não coberta pelos itens testados anteriormente, que gere um defeito. Estatisticamente isso é uma exceção.

Técnicas Avançadas: Análise de Extremidades

2010-07-19T16:33:00.001-07:00

Como muitos já sabe, tirei recentemente a certificação CTAL-TA (Certified Tester Advanced Level - Test Analyst). Nessa certificação estudei diversas técnicas para Analistas de Testes aplicarem ao desenvolverem seus procedimentos de testes. É importante começar pelo básico, essa técnica pode ser aplicada em diversas situações, não só em input fields.
Análise de Extremidades (ou Análise dos Valores Extremos) é basicamente testar os valores das extremidades, onde geralmente os erros são encontrados.
Essa técnica só é aplicável quando o sistema possui alguma relação de “maior que” ou “menor que” entre os valores declarados no sistema.
Por exemplo, digamos que um sistema para público adolescente só permite cadastrar idades entre 12 e 19 anos. A técnica prevê que existem valores válidos e inválidos nessa faixa etária. Por exemplo, 12, 15 e 19 são valores válidos, e 0, 11 e 20 são valores inválidos. Veja a imagem a seguir:

O que explica o principal motivo dessa técnica é a comum confusão feita por desenvolvedores na utilização de sintaxes como: “maior que ou igual a”, “maior que”, “menor que ou igual a” e “menor que”.
Por exemplo, se o desenvolvedor digitar: “IF 12 <= valor <= 19 THEN aceita” é diferente de “IF 12 < valor < 19 THEN aceita”, no primeiro exemplo o sistema aceitaria os valores 12 e 19, que são válidos, no segundo exemplo, não. Esse é um exemplo trivial, mas em sistemas mais complexos isso pode se tornar uma iminente confusão.

Erros comuns na instalação do Testlink

2010-07-13T07:15:00.000-07:00

Hoje fui instalar o Testlink aqui na minha empresa (www.lugati.com.br) e fiquei um bom tempo até perceber o problema.

Fiz o procedimento normal, instalei um WAMP Server no servidor, coloquei o Testlink na pasta 'www', coloquei o servidor online, e iniciei todos os serviços (é uma opção do próprio wamp) e acessei Testlink através do IP da máquina na rede (por exemplo: http://10.1.1.5/testlink), até aí tudo bem.

Eis que surge a primeira dúvida, no preenchimento do formulário do banco de dados na primeira tela, o que fazer?

Como estava instalando o WAMP (WAMP = Windows+Apache+MySQL+PHP), escolhi as seguintes opções:

Preencher formulário para escolha do BD com os seguintes dados:

1. Type: MySQL 4.1 or higher
2. Host: localhost
3. Database name: testlink
4. Table prefix:
5. Database admin login: root
6. Database admin password:
7. Testlink db login: testlink
8. Testlink db password: testlink

Acessei vários fóruns (sem sucesso) até lembrar que a senha do Banco de Dados era 'root' e o password deveria estar em branco, até esse ponto, tudo bem.

Eis que surge um novo problema: Acessava normalmente o Testlink mas antes, sequencialmente, aparece a seguinte mensagem de erro:

Deprecated: Function ereg_replace() is deprecated in C:\wamp\www\testlink\lib\functions\lang_api.php on line 173

A primeira coisa que eu fiz foi comentar essa linha e as duas linhas seguintes, que eram:

$t_lang_var = preg_replace( '/^TLS_/', '', $t_var );
if ( $t_lang_var != $t_var) {
$g_lang_strings[ $p_lang ][ $t_lang_var ] = $$t_var;
}

Sinceramente, sem me atentar muito à estrutura do código. Voltei e acessei o testlink normalmente, mas curiosamente todos os campos estavam da seguinte forma:
"LOCALIZE: variavel_campo". Ou seja, percebi que era um arquivo de tradução para a linguagem corrente. Procurei o tal do 'custom_strings.txt' e nada.

Então comecei a procurar em alguns blogs e achei a solução:

Pode-se resolver esse problema instalando o php 5.2 ou indo até o diretório testlink\lib\functions\ e mudar a linha 173 do arquivo 'lang_api.php' (aquele que o próprio Testlink alertou como erro acima):
$t_lang_var = ereg_replace( '^TLS_', '', $t_var );

para esta linha:
$t_lang_var = preg_replace( '/^TLS_/', '', $t_var );

Pronto! Seus problemas acabaram! Só acessar normalmente o Testlink (refresh na página, que seja).

PS: Não sou um expert em Testlink, somente um usuário com um pouco de experiência e bom senso. Se tiverem dúvidas posso até tentar ajudar, mas não garanto que vou saber resolver todas elas.

Reportar Defeitos

2010-07-07T06:02:00.000-07:00

Esta atividade da equipe de Testes é muito importante, principalmente pela visão da gerência. Deve-se levar em consideração que poucos gestores tem a visão da importância e complexidade dos Testes de Software (pelo fato deles virem do desenvolvimento). Ou seja, o que vai mostrar trabalho nesse caso, é quão bem o Analista de Testes vai se comunicar com a equipe de desenvolvimento e quantos defeitos (sendo estes divididos por gravidade e prioridade) foram encontrados.
Tendo isto por base, na minha opinião, esse é o grande diferencial dos profissionais que estão começando nessa área: a capacidade de comunicação. Como podem perceber, eu coloquei como objetivo dessa atividade (Reportar Defeitos) a melhora do nível de comunicação da equipe.
O defeito pode ser reportado no grito e ser corrigido? Sim, claro que pode, em alguns casos não precisa ter frescura para resolver uma situação da forma mais rápida e prática possível. Mas imagina uma equipe com 20 Desenvolvedores e 6 Analistas de Testes. Já imaginou eles tratando essas questões no grito? Nesse caso, é sempre bom seguir um padrão e também levar em consideração que sua empresa deve (e quer) crescer. Ou seja, se acostumando desde o início como a situação deve estar sob controle num segundo momento.
Já trabalhei em projetos em que os Analistas de Testes reprovavam uma tela crítica por causa que o campo estava desalinhado! É muito importante ter a visão do negócio como um todo nessa hora (bem como em todas as horas), o profissional nem imaginava o impacto que isso causaria na aplicação pois:
- O analista de sistemas teve que refazer os testes de homologação (o que é um outro problema, pois isso foi falha na comunicação) - o que durou nesse caso, três dias.
- O desenvolvedor teve que corrigir somente o alinhamento da tela.
- O gerente teve que explicar pro cliente que aquele módulo iria atrasar mais, pelo menos, três dias.
- O cliente ficou insatisfeito com o atraso (a não ser que o gerente seja um ótimo sabonete, o que também é possível)
- O desenvolvedor ficou insatisfeito pois o feedback do gerente não foi muito positivo "essa tela foi atrasada quatro dias por sua causa"
Resumindo, gerou um grande problema por causa da "falta de feeling". Nesse caso, meu recado é: profissionalismo.

1)Objetivo
Melhorar o nível de comunicação entre o desenvolvedor e o analista de testes.

2)Artefatos de entrada
Casos de teste

3)Artefatos de saída
Ticket gerado na ferramenta de Bugtracking
Planilha do Excel com descrição dos defeitos

4)Tarefas a serem realizadas
Durante a execução dos casos de teste deve-se reportar um defeito quando este for encontrado.

5)Atores envolvidos na atividade e suas responsabilidades
Analista de Testes – reporta
Desenvolvedor – corrige
Gerente – acompanha

6)Padrões
N/A.

7)Procedimentos e Orientações
Encontre o defeito e reproduza-o
Reporte a reprodução fiel do defeito encontrado
Para um sistema, um erro só é um erro quando pode ser reproduzido
Não utilizar termos ofensivos ao reportar um defeito

Executar Casos de Teste

2010-06-29T09:44:00.000-07:00

Esse é a tarefa mais trivial (e também a mais conhecida) de Testes de Software. Qualquer profissional que tem por objetivo entrar nesse mundo de Testes deve ter em mente que essa é a atividade primordial (e também mais importante) dos Testes. É nessa fase onde o Analista de Testes encontrará os defeitos e os reportarão para os demais envolvidos no projeto (esta atividade - Reportar Defeitos - será abordada num próximo tópico do blog).
Nessa etapa é muito importante lembrar que a gestão do processo, a abordagem definida no plano de testes bem como a motivação do testador são fatores importantíssimos para que seja finalizada com sucesso! Várias são as formas de motivar uma equipe a executar as atividades com êxito, mas não são foco desse tópico.
É importante lembrar que uma vez que os casos de teste tenham sido 100% executados, re-testados e verificados, é uma boa prática sugerir que os testadores apliquem Testes Exploratórios no sistema caso haja ainda tempo no cronograma, lembrando que o foco da fase de Execução é achar bugs, então, mão na massa!

1) Objetivo
Manter um nível de qualidade no sistema desenvolvido.

2) Artefatos de entrada
Casos de teste
Protótipo de telas
Quaisquer artefatos que possam ajudar na execução dos casos de teste

3) Artefatos de saída
Sistema testado, homologado e aprovado pelo Analista de Testes

4) Tarefas a serem realizadas
a) Executar os casos de teste
b) Reportar ao desenvolvedor os defeitos encontrados

5) Atores envolvidos na atividade e suas responsabilidades
Analista de Testes – executa
Gerente – acompanha

6) Padrões
N/A.

7) Procedimentos e Orientações
Deve estar sincronizado com as atividades de desenvolvimento
Assim que houver uma entrega de uma aplicação do sistema, os testes devem ser aplicados.
Utilização de técnicas de testes funcionais para melhor abrangência dos mesmos (que serão abordadas posteriormente)
Registrar os resultados reais e comparar com os resultados esperados para verificar se o sistema está de acordo com o planejado.

Preparar Ambiente de Testes

2010-06-15T14:48:00.000-07:00

Nessa fase do projeto, deve-se estimar o esforço gasto para montar o ambiente, ordenar e priorizar os casos de teste e preparar a massa de dados para testes. Dependendo do projeto, essa fase pode ser feita durante a execução, o que não é aconselhável, claro, pois devido a isso um grande atraso para o projeto passaria despercebido.
Em grande parte dos projetos que participei e acompanhei, a massa de dados é criada somente durante a execução dos testes (com exceção dos projetos de performance que participei na EDS, que são outros quinhentos... :)
Até projetos de automação, já vi criando esses dados on-the-fly... Portanto, já dá pra ver que o sucesso esperado não foi obtido...
Todavia, boa parte desse processo de preparação do ambiente de testes eu adaptei do processo da RSI, empresa de consultoria e treinamentos especializada em testes, muito séria e profissional.

1) Objetivo
Oferecer um ambiente com infraestrutura similar ao de produção, com bases de dados reduzidas, descaracterizadas e íntegras, utilizando processos automáticos de carga e validação de informações. O resultado é a realização de testes integrados e com total visualização dos processos de negócio da empresa.

2) Artefatos de entrada
Plano de testes
Sistema em desenvolvimento
Acesso ao Banco de Dados
Quaisquer outras ferramentas periféricas ao sistema que necessitem estar configuradas/preparadas para a execução dos casos de teste

3) Artefatos de saída
Sistema pronto para ser testado

4) Tarefas a serem realizadas
a) Preparar a infraestrutura do ambiente de homologação e manter o controle sobre a utilização de seus recursos.
b) Estabelecer infraestrutura de hardware, software e testware.
c) Definir o tipo de ambiente (sistemas ativos e sistemas por demanda).
d) Definir as políticas, normas e padrões do ambiente e dos processos.
e) Estabelecer as regras e critérios para criação da Massa de Dados de Teste.
e1. Se os dados vão ser populados manualmente
e2. Se os dados vão ser populados automaticamente (através de uma ferramenta de automação dos dados do ambiente)
e3. Se os dados vão ser populados diretamente no Banco de Dados (verificar se estes precisam estar associados à Regras de Negócio interdependentes ou se podem ser simplesmente adicionados sem afetar a estrutura do ambiente).

5) Atores envolvidos na atividade e suas responsabilidades
Administrador do Banco de Dados – executa
Analista de Testes – executa
Desenvolvedor – acompanha
Gerente – acompanha

6) Padrões
N/A

7) Procedimentos e Orientações
Deve, idealmente, haver um ambiente exclusivo e dedicado para testes.

Definição de requisitos de infraestrutura:
Hardware: CPU e armazenamento
Software: Básico e produtos
Testware: Recursos humanos com especialização e foco em testes, e ferramentas de gerenciamento, documentação, automação, produtividade e geração de massa de testes.
Segurança: Segregação física ou lógica
Metodologia de teste: Processos estruturados
Tipo de ambiente:
Ativo: permanentemente disponível; sincronismo com a produção; processamento diário; controle rígido dos acessos, testes integrados.
Por demanda: gerado pela necessidade; sem sincronismo; execução sob demanda; flexibilidade de acessos; testes integrados.
Normatização:
Definição de normas de controle de configuração e versão, gestão de mudanças e problemas.
Definição de padrões de Nomenclaturas e Codificação (identificador de ambientes, estruturas de processamento, automação de processamento e scheduler).
Massa de dados de teste:
Definição da origem dos dados: laboratório, produção ou simulado
Definição das ferramentas de produtividade

Elaborar Casos de Teste

2010-06-10T15:55:00.000-07:00

1) Objetivo
Garantir que a funcionalidade atende aos requisitos.

2) Artefatos de entrada
Todos os artefatos de requisitos
Todos os artefatos da especificação técnica
Documento de Arquitetura
Documento de Plano de Testes
Documento de casos de uso
Outras aplicações ou partes da aplicação já construídas que são necessárias para a criação dos testes.

3) Artefatos de saída
Roteiros de teste criados na ferramenta de Gestão de Testes (Testlink e afins)

4) Tarefas a serem realizadas
a) Refinamento dos itens de teste definidos no Plano de Testes
b) Detalhamento dos casos de uso
c) Definir o sumário de cada roteiro de teste
c1. Resumo: Explicação sucinta sobre o objetivo do roteiro.
Exemplo: Cadastrar usuários com idade entre 18 e 25 anos no sistema acadêmico
c2. Pré-condições: Condições em que o sistema deve se encontrar ao iniciar o caso de teste.
Exemplo: Executar um caso de teste anteriormente, ter um usuário pré-cadastrado no sistema (se esse roteiro tiver por objetivo, por exemplo, a edição dos dados de um usuário), etc.
c3. Dados de teste: Todos os dados que devem estar pré-populados no sistema para dar início à execução do caso de teste.
Exemplo: Usuário com 18 anos, terceiro grau incompleto, renda entre 1 e 3 salários mínimos.
c4. Pós-condições: Situação em que o sistema deve se encontrar ao finalizar o caso de teste.
Exemplo: Habilitação do cadastro de usuários entre 26 e 40 anos.
d) Descrever os passos (bem como os resultados esperados para cada passo) que o usuário deve seguir para que tenha êxito na execução do roteiro.
Observação: Um exemplo de caso de uso e como detalhar um caso de teste (http://testavo.blogspot.com/2010/05/exemplo-de-caso-de-teste-criado-partir.html)
e). Aplicar as técnicas de modelagem de casos de teste quando necessário (serão detalhadas nos próximos posts).

5) Atores envolvidos na atividade e suas responsabilidades
Analista de Testes – executa
Analista de Sistemas – acompanha e aprova
Gerente - aprova

6) Padrões
N/A.

7) Procedimentos e Orientações
O objetivo do caso de teste é achar bugs (embora muitos acreditem que o objetivo é validar os fluxos).
Utilização de uma ferramenta de Gestão de Casos de Teste para facilitar o acesso e manutenção. Por exemplo, Testlink.
Aqui está a lista de como o caso de teste deve ser escrito, seguindo os padrões e boas práticas:
- Links ou botões: Utilizar os itens > e < entre os links ou botões. PS: Essa postagem não permite demonstrar o exemplo.
- Campos em geral: Exemplo: [campos em geral] ou [campo nome].
- Abas: (aba principal) ou (aba secundária).
- Dados de entrada (inputs): “Dados de entrada” ou “Nome completo do usuário”.
Exemplo: Na aba (Cadastro de Usuário) escreva “Analista de Sistemas” em [Profissão] e depois clique em .

Curso no Buzzero sobre Testes de Software

2010-06-09T18:41:00.000-07:00

Pessoal, disponibilizei uma apresentação TOTALMENTE GRÁTIS sobre os básicos de Testes de Software no Buzzero. Fiquem à vontade para baixar, só cuidado com os direitos autorais! :)

http://www.buzzero.com/luizgustavo/curso-online-Testes-de-Software.html

Aproveitem!

Aprovação no exame no CTAL-TA

2010-06-08T11:20:00.000-07:00

Pessoal, fiz a prova do CTAL-TA semana passada e hoje recebi uma excelente notícia: passei!
Esclarecendo algumas dúvidas:
A prova não está disponível no Brasil ainda, esta foi feita especialmente para os participantes do curso preparatório do CTAL-TA ministrado pelo próprio Rex Black. A prova foi elaborada em inglês. Em português só existe por enquanto a prova do CTAL-TM, minha próxima meta (semana passada o Syllabus Advanced foi liberado na versão em português).
Comentários sobre a prova:
A prova possui 65 questões e são divididas entre fáceis (valendo um ponto) e difíceis (valendo dois pontos). Totalizando 100 pontos.
As questões de um ponto são basicamente teóricas mas muitas delas pegadinhas pois misturam conceitos próximos.
As questões de dois pontos são elaboradas em forma de estória, conta-se uma situação e a resposta seria como aplicar a técnica, ou o que fazer em determinada situação para solucionar de forma mais apropriada aquela situação. Ou seja, geralmente as quatro respostas estão certas e tem duas respostas certíssimas, uma é mais certíssima que a outra, bem pegadinha...
No geral o pessoal disse não ter ido muito bem pois a prova, além de ser em inglês, tem seu nível de dificuldade por ser uma prova do CTAL-TA. Todavia, se estiver bem preparado, não é um bicho de sete cabeças...

Elaborar Revisão da documentação

2010-06-04T18:06:00.000-07:00

Apesar de eu já ter descrito de forma bem clara e suscinta sobre Revisões, vou manter o modelo de trabalho para prosseguir nos posts sobre o modelo de testes de software.

Segue os links dos posts anteriores, vale a pena conferir:
Revisões e Análise de Ambiguidades [parte 1]
http://testavo.blogspot.com/2009/04/revisoes-e-analise-de-ambiguidades.html
Revisões e Análise de Ambiguidades [parte 2]
http://testavo.blogspot.com/2009/04/revisoes-e-analise-de-ambiguidades_15.html
Revisões e Análise de Ambiguidades [parte 3]
http://testavo.blogspot.com/2009/04/revisoes-e-analise-de-ambiguidades_20.html
Revisões e Análise de Ambiguidades [parte 4]
http://testavo.blogspot.com/2009/05/revisoes-e-analise-de-ambiguidades.html
Revisões e Análise de Ambiguidades [parte 5]
http://testavo.blogspot.com/2009/05/revisoes-e-analise-de-ambiguidades_12.html

1) Objetivo
Refinar o documento e nivelar o entendimento do deste pelos demais membros da equipe

2) Artefatos de entrada
Quaisquer documentos que exijam um maior nível de detalhamento ou entendimento

3) Artefatos de saída
Documento em questão refinado
Ata da reunião de revisão

4) Tarefas a serem realizadas
a) Planejamento: Autor seleciona os participantes e define funções (descritas no item 5)
b) Kick-off: Distribuição dos documentos e explicação dos objetivos, processos e documentos.
c) Preparação individual: Cada participante revisa a documentação, levanta possíveis dúvidas ou comentários.
d) Reunião de revisão: Moderador conduz a reunião de revisão. Revisores levantam suas dúvidas durante a reunião, tem uma breve explicação. Gravador anota todas as dúvidas e comentários para serem corrigidos no documento original.
e) Retrabalho: Autor do documento corrige o documento de forma que ele fique mais claro para os demais participantes e envolvidos no projeto.
f) Follow-up: Atividades relacionadas a finalização dessa revisão (adicionar ao repositório de dados, enviar por email, etc.)

5) Atores envolvidos na atividade e suas responsabilidades
Gerente - acompanha
Autor – autor do documento e responsável pelo planejamento e kick-off
Moderador – conduz a reunião
Revisores – quaisquer envolvidos no projeto
Gravador – anota as dúvidas, sugestões e alterações do documento na reunião

6) Padrões

7) Procedimentos e Orientações
O objetivo de cada revisão deve ser pré-definido
As pessoas corretas devem estar envolvidas
Defeitos e incoerências encontradas são bem vindas
Tornar esse processo uma experiência positiva para o autor (melhora da documentação)

Questão de prova

2010-05-31T13:12:00.000-07:00

Essa questão é da prova do ISTQB, podendo ser tanto para CTFL bem como para CTAL-TA.
Qual a principal diferença entre as técnicas de modelagem de testes baseadas em Defeitos e as baseadas em Especificação?
De acordo com o Syllabus, a resposta mais correta é:
Defect-based são aplicáveis sobre o que é conhecido sobre defeitos em geral e specification-based são técnicas criadas a partir do test basis.
Test basis é qualquer artefado que possa ser utilizado para definir (ou ter por base) os testes de um sistema (um sistema legado, documento de especificação de requisitos, casos de uso, protótipos, etc.)
Exemplos clássicos de técnicas defect-based: Quaisquer testes de segurança, error guessing, testes exploratórios, checklists, etc.
Exemplos clássicos de técnicas specification-based: análise do valor limite (ou análise de extremidades), partição de equivalência, tabelas de decisão, árvores de classificação, testes em pares, diagrama de transição de estados, etc.
Qualquer dúvida estou à disposição.

Elaborar Plano de Testes

2010-05-28T23:19:00.001-07:00

Após definida a estratégia para o projeto de testes, a equipe deve se planejar (eventualmente essas atividades são feitas ao mesmo tempo). Quais atividades serão feitas, qual o objetivo de cada fase, as técnicas utilizadas, recursos e ferramentas específicas, configuração do ambiente e massa de dados, etc. Todas essas informações (e um pouco mais) devem ser previstas na elaboração desse importante documento. Mais uma vez, é importante evitar que esse documento fique muito extenso e cansativo. Seu superior não quer saber o que está sendo feito para o projeto, ele quer que o produto/serviço dele seja entregue com uma qualidade mínima. Esse documento tem por objetivo orientar a equipe de testes nas fases posteriores.
É importante deixar claro que o Plano de Testes (bem como os demais documentos de testes) deve ser revisado continuamente durante todo o processo, quaisquer novas alterações ou novas atividades no decorrer do projeto devem ser declaradas neste documento. E sempre verificando se os documentos não estão se contradizendo (modelagem dos testes, caso de testes, plano de teste, etc.) ou se estão ambíguos. Ou seja, alterando um, sempre procure revisar os demais (é claro, se tiver tempo para isso, caso não tenha, deixe uma "nota" avisando que o documento está desatualizado ou algo do tipo). Sempre costumo lembrar que a equipe de testes serve muito mais para manter um nível aceitável de comunicação no projeto do que testar o software por si só. Mas isso não é assunto desse post.

1) Objetivo
Elaborar o Plano de Testes identificando as atividades de testes relacionadas àquele projeto. Define com e o que deve ser testado no projeto.

2) Artefatos de entrada
Estratégia de Testes
Plano do projeto
Documento de definição de requisitos funcional e não funcional aprovado pelo solicitante.
Documentação referente aos projetos/sistemas relacionados

3) Artefatos de saída
Plano de testes

4) Tarefas a serem realizadas
a) Itens de Teste: Especificação de requerimentos, modelagem de dados, esquema do banco de dados, etc.
b) Funcionalidades a serem testadas: São o que deve ser testado pela perspectiva do usuário.
c) Funcionalidades que não devem ser testadas: Podem ser postergados para a próxima iteração, baixo risco (já pode ter sido testada anteriormente e considerada estável), etc.
d) Escopo:
a. Uso de alguma ferramenta especial?
b. Como as métricas vão ser coletadas?
c. Como o ambiente de testes deve ser configurado?
d. Software? Hardware? Combinação de SW, HW e software de terceiros?
e. Quais serão as regras para testes de regressão?
e) Critérios de sucesso/falha: Número mínimo de defeitos encontrados, ou defeitos de alta severidade, execução de todos os casos de teste, etc.
f) Ambiente de Testes: VPN? Dados para teste? Ferramentas? Capacidade de hardware? Restrição de uso durante os testes?
g) Responsabilidades: Responsáveis por modelar os testes, por avaliar os riscos da aplicação, por avaliar quais são as funcionalidades que devem e as que não devem ser testadas.
Observação: Boa prática é selecionar por função na empresa e não por nome.
h) Necessidade de pessoal ou treinamento: Treinamento num produto ou ferramenta específica, necessidade de um profissional com conhecimento específico
i) Cronograma: Definição das atividades do projeto
j) Riscos e contingências: Explicar o que deve ser feito caso , por exemplo, alguma das situações venham a acontecer:
a. Falta de ferramentas específicas;
b. Entrega tardia da aplicação para testes;
c. Mudança nos requerimentos originais, etc.

5) Atores envolvidos na atividade e suas responsabilidades
Analista de Testes – executa
Analista de Sistemas – acompanha e aprova
Gerente - aprova

6) Padrões
A definir.

7) Procedimentos e Orientações
Durante a definição do escopo do projeto é que as atividades serão definidas ou planejadas, quais serão as técnicas utilizadas e como as ferramentas vão ser inseridas no processo. Por exemplo, vão utilizar alguma ferramenta específica para fazer consultas no banco de dados durante a execução dos casos de teste? É importante que esta esteja instalada antes de dar início a essa fase, nunca se sabe quando algum software vai dar conflito com seus softwares ou sistema operacional.

Torne o documento de Plano de Testes um guia para a modelagem dos casos de teste e configuração do ambiente de testes/homologação, e não mais um documento para encher lingüiça no projeto e mostrar que estão "trabalhando em algo importante". Mais uma vez, objetividade.

Questão de prova

2010-05-27T10:32:00.000-07:00

Tanto para a prova do CTFL mas principalmente para a prova do CTAL é importante lembrar que não é necessário que os procedimentos de teste (criação dos casos de teste, configuração do ambiente, massa de dados, etc.) estejam completamente finalizados antes de iniciar a execução dos testes.
Ou seja, conheci muito profissional que quer cada etapa dos testes 100% perfeitos, finalizados, e enlouquecem quando as coisas não ficam prontas a tempo. Já vi até gente atrasar a entrega do cliente por causa de um simples erro de digitação ou uma cor diferente do padrão. Pessoal, bom senso. Nessas situações é importante lembrar de uma opção muito pouco utilizada nas ferramentas de Bug Tracking, chamada "Deferred to the next release".
Como eu falei, para ser Analista de Testes (bem como qualquer outro profissional), tem que ter bom senso. Todos nós sabemos que atrasos são coisas comuns na área de TI, bem como bugs no software! O mais importante é que saibamos como lidar com as adversidades. Jamais entrar em desespero. Antes de qualquer coisa, quem tem a razão é o cliente, o responsável pelo projeto que deve ter jogo de cintura para negociar com ele. Lembrem também de uma premissa básica de qualquer empresa de desenvolvimento: se atrasar o desenvolvimento e/ou análise, aperta nos testes. Infelizmente.
Porque aí entra outra questão muito relevante, quanto de teste é necessário para que o programa esteja aceitável? Será que se eu falar pro cliente: "preciso de mais um dia para testar", ele vai entender? Vai fazer diferença? Nessas horas é que o gerente de testes deve avaliar quais são as suites de teste que oferecem maior risco para o sistema e dedicar um maior esforço nesses módulos.

Elaborar Estratégia de Testes

2010-05-25T10:51:00.000-07:00

Como eu já havia divulgado, vou descrever de forma objetiva as principais atividades de uma metodologia "genérica" (leia-se genérico o que pode ser aplicável e abstraído para os demais contextos) de Testes de Software.
Como a temática é ser objetivo, não tem muito mistério na criação de uma Estatégia de Testes, sabido qual é a necessidade do cliente, definir a estratégia pode ser só uma questão de alinhar objetivos.
Prefiro trabalhar dessa forma (objetividade) pois muitos gerentes tem anseio de aplicar o processo de Testes de Software na sua empresa pelo fato de acharem que este pode gerar documentação demais, para uma atividade tão irrisória.

1) Objetivo
Delimitar o escopo do sistema a ser testado

2) Artefatos de entrada
Declaração de escopo
Documento de definição de requisitos funcional e não funcional aprovado pelo solicitante.
Documentação referente aos projetos/sistemas relacionados

3) Artefatos de saída
Documento de Estratégia de Testes

4) Tarefas a serem realizadas
a) Definir a missão e o objetivo dos testes.
b) Fases de teste envolvidas: Testes unitários, de integração, de performance, de sistema, de aceitação, de regressão, etc.

5) Atores envolvidos na atividade e suas responsabilidades
Responsável pelas atividades de teste - executa
Gerente do projeto – acompanha
Analista de Sistemas – acompanha

6) Padrões
A definir.

7) Procedimentos e Orientações
Definir a missão do projeto geralmente está associada a saber qual é o objetivo do mesmo, pode ser simplesmente "achar o maior número de defeitos", bem como pode ser "promover a integração com o sistema legado" ou "dar mais atenção aos módulos de maior risco para o projeto", etc. Pode estar explícito bem como pode precisar de um maior entendimento do negócio, isso dependerá de projeto para projeto.
O objetivo do teste está intimamente associado às atividades que serão executadas no decorrer do projeto de testes, como por exemplo, casos de teste baseados em risco, baseados na especificação, ou até, não criar casos de teste, somente executar testes exploratórios, tudo depende.

Exemplo de Caso de Teste criado a partir de um Caso de Uso

2010-05-20T12:21:00.000-07:00

Bom, antes de qualquer coisa, é importante lembrar que o objetivo desse exemplo é mostrar que é possível criar um caso de teste mesmo com pouca (ou nenhuma) informação sobre o sistema. Visto isso, é importante levar em consideração alguns pontos:
- O nível de detalhamento do caso de teste, deve ser o mesmo nível de detalhamento do caso de uso, quanto mais artefatos para criar um caso de teste tiver, melhor, se não tiver, não entre em desespero.
- Essa é a hora de aplicar as técnicas de modelagem de casos de teste (Análise das extremidades, Partição de Equivalência, Tabelas de decisão, Grafos de transição de estado, Grafos de causa e efeito, Tabelas de pares, Checklists, etc). Lembrando que essas técnicas podem ser aplicadas em paralelo ou serem interdependentes, desde que sejam úteis. Não faz sentido colocar uma tabela de pares no meio de um caso de teste que parte de um caso de uso. Por esse motivo, eu disse alguns posts anteriormente, que causou polêmica, Caso de Teste é uma terminologia utilizada quando este é criado a partir do Caso de Uso (ver post aqui).
- Também julgo importante manter um padrão de texto na criação dos casos de teste, como no exemplo abaixo, quando é um link está entre , etc.
- Todo caso de teste deve ter "Resultados esperados", e durante a execução, este deve ser comparado com o "Resultado real" para verificar se o sistema está de acordo com o planejado.
- É uma boa prática a utilização de uma ferramenta de Gestão de Casos de Teste para facilitar o acesso e manutenção.
- Utilizar outros documentos (documento de padrões do sistema, protótipo de telas, por exemplo) para auxiliar na criação e execução dos casos de teste.

Exemplo de Caso de Uso:

Fluxo normal

1. Cliente coloca um ou mais itens no carrinho de compras
2. Cliente seleciona checkout
3. Sistema coleta endereço, informações de pagamento e de envio do cliente
4. Sistema apresenta todas as informações do usuário
5. Usuário confirma a ordem de pedido para o envio do Sistema

Fluxos alternativos

- Cliente seleciona checkout com o carrinho de compras vazio; Sistema retorna mensagem de erro
- Cliente provê endereço, informações de pagamento ou de envio do cliente inválidos
- Sistema abandona a transação antes ou durante o checkout; Sistema executa logout do cliente depois de 10 minutos inativo

Exemplo de Caso de Teste:

Passos

Passo 1 – Colocar 1 item no carrinho
Passo 2 – Clicar em
Passo 3 – Colocar valores válidos para endereço, utilize Mastercard para pagamento e método de entrega válido e clicar em
Passo 4 – Verificar a ordem de envio
Passo 5 – Confirmar a ordem de envio
Passo 6 – Repetir os passos 1-5 mas colocar 2 itens no carrinho e escolher VISA como forma de pagamento

Resultado esperado

Passo 1 – Item no carrinho
Passo 2 – Tela de checkout
Passo 3 – A tela aparece corretamente e os inputs válidos são aceitos
Passo 4 – Aparece como digitado na tela
Passo 5 – A ordem de envio está cadastrada corretamente no sistema
Passo 6 – Conforme feito nos passos 1-5

Frase do Dia

2010-05-08T11:09:00.001-07:00

"A test is an action which produces discoveries that can be used to evaluate product quality." Ben Simo

Desmistificando Testes de Regressão

2010-05-06T10:08:00.001-07:00

Bom, qualquer profissional da área de testes sabe o que é um Teste de Regressão e quando ele deve ser aplicado. Para os leigos, a definição mais correta é: aquele teste feito quando o sistema sofre alterações, ou seja, quando um novo módulo é criado ou alterado no sistema, estas mudanças podem gerar defeitos quando integrados com outros componentes do sistema. Por este motivo, os testes de regressão são aplicados nas outras áreas do sistema com o objetivo de garantir que a criação ou alteração do novo componente não afetou a estabilidade do sistema.
Sendo assim, o objetivo desse teste serve para garantir o sistema ainda contempla os requisitos iniciais. Na prática, é a maneira mais utilizada de testar um sistema que já está em produção (ou aqueles que possuem desenvolvimento ágil ou iterativo), tendo por base, muitas vezes, o próprio sistema para elaboração dos casos de teste.
É importante sempre lembrar que deve haver manutenção nos casos de teste continuamente, e se possível, manter a rastreabilidade dos requisitos com os testes, para saber qual suite de testes vai sofrer alteração com a mudança dos requisitos do sistema.
Há autores (Robert V. Binder) que defendem cinco tipos principais de regressão, são estes:
- Reteste total;
- Reteste baseado em casos de uso de maior risco;
- Reteste por perfil;
- Reteste de segmentos modificados;
- Reteste com firewall.
A abordagem adotada pela equipe de testes para criação dos casos de testes de regressão deve ser seguir a mesma linha adotada para criar os testes de sistema.
Sinceramente, nunca adotei uma maneira formal de aplicar os testes de regressão nos projetos em que trabalhei, sempre selecionava alguns testes de sistema que tinham uma maior cobertura e aplicava para ter certeza que aquelas alterações não afetaram os demais módulos do sistema, e aparentemente funcionava.

Aplicação de Diagrama de Estados num sistema de workflow

2010-04-22T13:01:00.001-07:00

É como eu sempre digo, a criação do procedimento de testes depende de uma análise bem sucedida do Analista de Testes. De nada adianta experiência, currículo e certificação se o profissional não tem bom senso e atenção no que está fazendo.

O objetivo da aplicação das técnicas de teste (black box e white box) é para ganhar tempo de execução dos testes (também chamado de economics of testing). Quem define a janela de testes é o gerente do projeto com a sugestão do gerente de testes (através de um cronograma definido), ou seja, a partir dessa janela de execução (tempo disponível) os testes devem ser planejados, pois, quanto mais tempo para testar, melhor. Mas se deve ter em mente que é preciso ter bom senso para saber qual o tempo ideal para a fase de execução dos testes, muitas vezes difícil de mensurar.

Mas esse tópico eu criei com o objetivo de discutir um pouco sobre uma técnica interessante, que, na minha opinião, serve mais para o profissional ter uma melhor visualização da atividade que está sendo executada do que do teste propriamente dito. É a criação do diagrama de estados durante a modelagem dos testes. Esta é principalmente utilizada quando o testador quer verificar a possibilidade de "acessar" um estado através de outro que, em princípio, não deveria ter acesso. Hoje muitos frameworks evitam esse tipo de acesso não autorizado.

Fui designado a criar o Plano de Testes de um sistema de workflow. O meu Test Oracle eram o esquema o banco de dados, onde, através de uma seqüência de ações, era definido o fluxo do sistema e uma versão draft do sistema.

Nem o próprio desenvolvedor responsável tinha idéia se o desenvolvimento estava contemplando todos os estados que o sistema deveria ter, sendo uma forma de visualização onde, mais tarde, os procedimentos de teste basear-se-iam.

Podem existir milhares de técnicas de teste aplicáveis para cada contexto, definido meu Test Oracle, julguei a aplicação dessa técnica as que se encaixavam melhor no contexto daquele sistema.

Foi criado um Diagrama de Estados para facilitar o entendimento da aplicação e poder, num segundo momento, checar se os estados estão sendo acessados corretamente (inclusive através da aplicação de técnicas de segurança de perfis de usuário). Foi criado um checklist de interface para manter um padrão e consistência em todas as telas do sistema. Foi previsto um esforço de Testes Exploratórios em algumas telas, com objetivo de quebrar alguns campos e achar mensagens de erro não tratadas. Bem como aplicação das técnicas de análise de extremidades (que são utilizadas em quaisquer campos que possuem números inteiros), entre outros.

Dessa forma, fiz um cronograma que deve estar de acordo com a entrega do projeto e levantei alguns riscos possíveis para o projeto de testes, como por exemplo a não disponibilidade de um ambiente de testes (com seus devidos dados de teste) espelhando o ambiente de produção e a não disponibilidade de usuários com diferentes perfis, o que impossibilitaria aplicar os testes de perfis, tornando os testes ineficientes. Desta forma, é importante ressaltar que a aplicação dessas técnicas devem prever a experiência do testador (estagiário, junior, pleno, senior, etc.), o que muitas vezes deixa a desejar...

Desktop de um tester para causar boa impressão

2010-04-12T13:47:00.000-07:00

Vi essa imagem em outro blog e achei interessante. Inicialmente é engraçado, mas se pensarem por outro lado, tem gente que deve ter achado uma idéia ótima.

Está aí o grande problema do Analista de Testes hoje em dia (bem como de outras pessoas, em outras profissões). Ele se preocupa mais em parecer importante do que ser importante de fato. Se preocupa em que os outros vejam seu valor ao invés de mostrar seu valor pros outros.

Uma coisa é fato: por sua essência, testador é aquele cara que não serve para ser programador. E é muito normal ver esse tipo de profissional jogado às traças das empresas. Aviso dado: cuidado!

Criação de casos de teste: regra ou exceção?

2010-04-06T13:49:00.000-07:00

Antes de levantar qualquer crítica a respeito dessa prática, é importante nivelar a seguinte informação: caso de teste é a aplicação de uma técnica de modelagem de testes baseada em casos de uso. Podem ter outras definições, isso varia de organização para organização, ou de certificação para certificação.

Nivelado o diálogo, é importante relembrar um dos sete princípios do Teste de Software: Teste é dependente de contexto. E por ser dependente de contexto, esse conceito deve ser abstraído e utilizado corretamente na prática.

Não adianta entrar na empresa que não tem a prática de criar casos de uso e querer inserir essa prática (casos de teste) no contexto caso queira ter um processo de testes formal e bem definido. O que move o mercado é o capitalismo selvagem, tem cliente que não tem a mínima idéia de como se faz um caso de uso. Simplesmente tem dinheiro na mão, pouco tempo disponível e vontade de fazer um sistema que nem ele tem certeza de como realmente é ou deveria ser.

Partindo desse princípio, devemos entender que o mundo de testes não é e nem nunca será mil maravilhas. Se tem gente que está esperando entrar numa grande organização para "ver o processo realmente funcionando", desista. A verdade é que a documentação geralmente que chega nas nossas mãos é superficial, inconsistente e cheia de defeitos.

Se um Desenvolvedor consegue criar um sistema a partir de um rabisco no papel, por que os Analistas de Teste têm que inventar desculpas e dizer: "Os requisitos não estão claros, então não podemos testar"? Isso é preguiça.

A mesma base que um Analista de Testes terá para criar seus testes é a mesma base que um desenvolvedor terá para criar o sistema, então, mãos na massa.

Várias técnicas de testes podem ser aplicáveis para cada situação específica. Casos de teste (conforme especificado no primeiro parágrafo) é só uma forma de aplicação de técnicas de modelagem de teste, baseada em requisitos funcionais de software. Ou seja, é uma técnica para uma situação bem específica.

E se pedirem para testarem um sistema sem documentação? Vão se desesperar? E se a documentação não foi suficientemente clara a ponto de prever os "Expected Results"? Tem muito Analista de Testes desesperado que não tem onde se basear para fazer os testes e partir para o monkey testing. Ou seja, inserindo loucamente inputs em todos os campos da tela esperando que algum deles falhe. Boa sorte.

Até a aplicação de Error Guessing, Experience-based Testing ou Testes Exploratórios devem ser previstos em módulos específicos do sistema, para que possa ser coletadas as métricas necessárias após a execução.

Concluindo, a resposta é NÃO, a criação de casos de teste não é regra nem exceção. A criação de casos de teste é a aplicação de uma das técnicas de modelagem de testes existentes, bem como técnicas conhecidas como partição de equivalência, análise de extremidades, checklists, testes exploratórios, testes baseados em riscos, tabelas de decisão, etc. E estas podem ser aplicadas conjuntamente, sem problemas.

CInTeQ 2010 - Dorothy Graham - Cognitive Illusions in Development and Testing

2010-03-24T12:43:00.003-07:00

Essa apresentação foi para fechar o evento com chave de ouro. Por motivos óbvios não teve nada que realmente agregasse em termos de tecnologia, metodologia ou processos. Em contrapartida, fez muita gente pensar sobre a forma atual de trabalho, tanto própria quanto dos colegas que os acercam.

Discursou a respeito da teoria da insanidade citada por Einstein "Insanidade é fazer todos os dias a mesma coisa, esperando resultados diferentes", comentou que as pessoas fazem os mesmos erros (sem procurar aprender com eles) de um projeto para o outro e espera que este tenha sucesso. Evitam avaliar riscos pois acham que estes não podem ocorrer, sempre.

Começou falando sobre algumas pegadinhas do cérebro, fez comentários muitíssimo interessantes sobre questões psicológicas associadas ao nosso ambiente de trabalho como pressão social, sensibilidade(awareness) seletiva, usou como exemplo o fato da pessoa não estar prestando atenção na conversa mas sua mente sinaliza quando seu nome é falado no meio do assunto.

Comentou muito profundamente sobre a questão da culpa. O ser humano tem a "blame culture" que é expressada pela seguinte frase: "If there is a problem, is his fault!" as pessoas deveriam adotar a forgiveness culture, mas costumam dizer: "Forgiveness is not an option, blame is much easier".

Algumas ilusões citadas por Dorothy vão em contrapartida outras apresentações, como por exemplo: "We don't need anything, we don't need documentation, process, design, testing, we are agile!"

No geral foi uma apresentação muito espirituosa, mostrou algumas sacadas feitas no dia-dia dos desenvolvedores, testadores e gerentes. Essa percepção foi feita através de anos de observação e estudos no mundo de Software Testing. Terminou a apresentação com a seguinte frase: "Don't believe everything you think", e acrescentou: "our mind is tricky"!

CInTeQ 2010 - Antonio Coutinho - Gestão de Conhecimento de Teste

2010-03-24T12:43:00.001-07:00

Apesar de ter sido uma palestra bem "marketeira" sobre o Santander, teve seu fundo de colaboração. O palestrante Antônio Coutinho mostrou a importância da gestão do conhecimento no processo de testes de software. Normalmente as empresas falham nesse ponto, o objetivo da apresentação é mostrar a forma pela qual eles chegaram ao objetivo deles, declarando que este era tornar o conhecimento um ativo organizacional.

Fez um paralelo com três entidades de importância na gestão do conhecimento, que seriam: Pessoas, Ferramentas e Processos. Alertando que o conhecimento deve ser absorvido no começo para ser aproveitado no final (algo muito parecido com a proposta do Modelo V). Apresentou uma nova abordagem para Smoke Test (diferente da já conhecida), que seria, o funcionário de uma manufatura tira um item da produção aleatoriamente, se este queimar, pára a produção inteira e revisa o processo. Com testes não é muito diferente.

A utilização das ferramentas visava tirar aquela impressão de que teste era uma caixa preta, tornando o resultado dos testes mais visível para a alta gerência através da utilização de ferramentas mais transparentes (fornecidas pelo seu parceiro e produtor do evento, a RSI), apresentadas por simples dashboards.

O mais interessante da palestra toda, na minha opinião, foi a política de incentivos ao profissional adotada no Santander. Os planos de capacitação, de exposição, plano de carreira, bolograma, revisão de performance, etc. Ele alega que essa nova política de incentivos reduziu drasticamente o turnover da empresa. Parabéns por essa nova política. É sensacional!

CInTeQ 2010 - Naysawn Naderi - Dia-a-dia do testador usando a solução de testes Microsoft

2010-03-24T12:11:00.000-07:00

Bom, como é de se esperar de uma palestra da Microsoft, as questões de Marketing são inteligentemente inseridas. A forma envolvente de como a apresentação foi conduzida é o motivo pelo qual entendemos como um sistema tão falho como o Windows pode ter tanta força. É simples: Marketing. Nessa apresentação não foi diferente.

Antes de começar a falar da ferramenta ele mostrou um curioso vídeo que o título era: "Making developers feel pain". O objetivo desse vídeo era mostrar para os usuários dos produtos Microsoft que eles estavam interessados que os produtos deles não tivessem mais bugs. Fizeram uma promoção, mostrando para os desenvolvedores o quão ruim é sentir dor, colocando eles para sentar numa cadeira cheia de inovações, os quais dava picadas, shoques e chacoalhava a pessoa caso o gerente julgasse necessário. No mínimo, interessante.

O palestrante levantou alguns pontos interessantes no decorrer dos discursos como o fato do Excel ser a principal ferramenta de Software Testing da atualidade. E que 70% dos profissionais de testes são focados nas áreas de teste manual e que a maioria possui aversão às ferramentas mais especializadas, como as de automação e performance. Nessa abordagem ele deixou claro a intenção da figura do Analista de Testes, apresentada posteriormente: "She likes to find bugs, and that's it, eventually doing exploratory testing".

Mostrou a ferramenta por meio de uma abordagem prática, fez uma alusão a uma Analista de Testes (Ellen, e se fosse brasileira seria Fabiana) e um Desenvolvedor (Elvis) conversando num projeto fictício. É evidente que essa comunicação naturalmente é falha. A ferramenta da Microsoft atua exclusivamente nessa falha: a comunicação entre as partes.

A proposta da ferramenta é interessantíssima, bem como a abordagem como ela foi apresentada. O foco da ferramenta é em testes funcionais, ajudam a promover a elaboração dos casos de teste, automatizar os testes negativos (e seus respectivos re-testes) e a melhorar a comunicação entre a equipe de testes e de desenvolvimento.

A apresentação ganhou alguns pontos por causa do bem-humorado palestrante Naysawn Naderi. E a solução parece bem completa em questões de:
- Possuir um robusto sistema de colaboração dev x testing
- Excelente ferramenta de bug tracking
- Maior visibilidade da qualidade
- Automatização do re-teste por parte da própria ferramenta

No geral, a ferramenta é excelente para soluções Microsoft. Não suporta SAP, Java e outros top-market leaders. Até foi apresentado uma tabela com as tecnologias as quais essa ferramenta tinha suporte mas não pareceu suficiente para o público. Quando a Microsoft fizer uma ferramenta que não esteja focada no seu próprio umbigo, vão conseguir atingir seu público-alvo.

CInTeQ 2010 - Erik van Veenendaal - Test Maturity Model

2010-03-24T10:03:00.000-07:00

Esse é outro palestrante que dispensa apresentações, Erik van Veenedaal é uma das grandes entidades de Software Testing européias e do mundo. Sua apresentação focada em TMMi trouxe temas bem atuais para a comunidade e, principalmente, para os participantes do CInTeQ 2010. Infelizmente não tive a oportunidade de fazer o curso sobre TMMi de 8 horas senão perderia as demais palestras, inclusive, a do Rex Black.

Essa apresentação veio como uma luva para as empresas que desejam melhorar, e até criar as célula de teste na sua empresa com uma maior competência e profissionalismo. Ele faz um paralelo às certificações de teste e aos contextos abordados por elas, ele ainda acrescenta: "It is not easy but is simple." pois os temas abordados nas certificações são o que chamamos de "mundo ideal dos testes" e nem sempre é fácil aplicar na realidade esse mundo encantado. É possível sim, segundo Erik, se aplicar uma idéia de cada vez, ou melhor, subindo um nível de maturidade do TMMi de cada vez.

Muitas dúvidas surgiram em torno da questão: é necessário que a empresa tenha CMMI para aplicar o TMMi? Ele reforça, para conquistar o nível três de TMMi é necessário que a empresa esteja pelo menos no nível dois de CMMI. Para conquistar o nível dois de TMMi pode ser muito trabalhoso mas não é necessário ter nível nenhum de CMMI e, sendo assim, não é impossível de conquistar.

A explicação de cada nível foi fundamental para o entendimento da implantação das melhores práticas de teste na empresa, segundo ele, se uma empresa não tem nem o nível dois (mais de 70% das empresas no panorama atual), ela nem pode considerar que possui uma equipe de testes. Pode chamar de qualquer coisa, menos de equipe de Testes de Software. Ele ainda acrescenta, "level 2 is good to every organization, but not enough".

Ele brinca dizendo que o máximo de níveis que uma certificação deve ter é cinco, pois gerentes só sabem contar até lá. Reforça o discurso dizendo que para uma empresa ter um approach de testes significativo é necessário cinco palavras: "Management, Management, Management, Management and Management". De nada funcionará numa organização caso ela não tenha uma boa gerência para apoiar essas práticas.

Para Erik, o balanceamento entre processos, infraestrutura e pessoas é fundamental. De nada adianta ter um processo perfeito se a equipe não sabe como proceder neste. Por isso ele comenta que os Analistas de Testes gostam de se defender alegando "Requirements are not clear", dizendo que não dá pra trabalhar pois não estão suficientemente entendíveis para o procedimento do trabalho. Funcionários interessados e interesseiros, podem muito bem correr atrás de uma luz. Proatividade!

No geral a apresentação de van Veenedaal foi excelente. Ele faz um apelo, em paralelo ao do próprio Rex Black, do Test Improvement Manifesto, para colocar nos fóruns de discussão o exemplo do que foi feito, se foi legal e como foi feito e como você pode melhorar o seu processo de Testes de Software.

E finalizando, palavras do vice-presidente, "Define process is easy, the difficult part is putting people to do it". Uma notícia interessante e de certa forma frustrante, no intervalo perguntei a ele quando o livro sobre TMMi vai ser publicado. Ele respondeu cordialmente: "Bom, mês que vem estarei lançando a versão em holandês, mas provavelmente não seja interessante para você..." ou seja, aguardaremos ansiosos pela versão em inglês.

CInTeQ 2010 - Adalberto Nobiato Crespo - Teste de Software no Contexto do Software Público Brasileiro

2010-03-24T08:23:00.001-07:00

Essa palestra, como dita pelo próprio Adalberto, foi de caráter essencialmente informativo. A apresentação girou em torno do portal de Software Público Brasileiro criado para tornar as práticas de desenvolvimento de software, abertos ao público, e de maneira mais acessível e colaborativa.

O 5CQualiBR (5C por causa das iniciais: Confiança, Cooperação, Comunidades, Conhecimento e Compartilhamento) tem uma proposta interessante, mas vai depender muito da comunidade para que proposta alavanque. Hoje o perfil da comunidade de testes de software no Brasil é muito passivo, poucas pessoas têm o interessa de fomentar atividades de teste, grupos de discussão, prover documentação de qualidade, oferecer treinamentos atuais (essa não é nenhuma crítica a nenhuma instituição, profissional ou grupo, sei que existem excelentes entidades preocupadas com a melhoria do Software Testing no Brasil, realmente). A idéia foi interessante mesmo porque foi impulsionada pela era da internet colaborativa, como o caso da famosíssima Wikipedia.

De maneira geral, a apresentação do Adalberto foi mais um apelo para a comunidade de Testes de Software a frequentarem e colaborarem com o portal já existente. Hoje o material presente na matriz de testes do 5CQualiBR é superficial. A comunidade precisa de um incentivo maior de profissionais interessados em colaborar e não apenas em promover e divulgar seus nomes na comunidade de Software Testing, em meia dúzia de documentos postados no portal.

CInTeQ 2010 - Neli E.Duarte - Test Mirror: a test strategy using Scrum in an outsourcing project

2010-03-24T08:10:00.000-07:00

Para os fãs de Agile Testing, essa palestra foi mais um case mostrando a forma de trabalho da IBM (e dessa equipe em específico) para projetos em Agile, e por isso, essa apresentação tem toda sua importância. Esse projeto teve uma característica curiosa, eram três empresas provedora de serviços de desenvolvimento e uma empresa provedora de serviços testes. A experiência contada na apresentação é, por motivos óbvios, da equipe de testes.

A grande lição dessa apresentação foi mostrar a importância de dois pontos importantíssimos em projetos de Agile: comunicação e proatividade. No decorrer da apresentação é comentado da forma de trabalho deles, e a figura do Analista de Testes como "Test Mirror".

Foi destacada também a importância de, no final de cada sprint, a equipe de testes ter o pacote completo, integrável, com qualidade e sem bugs críticos. Como todos sabem, é impossível achar todos os bugs numa apresentação (comentário reforçado mais tarde na apresentação da simpática Dorothy Graham), mas, como o próprio Rex Black disse, priorizem os bugs por criticidade, e foi o que a equipe da IBM que participou desse projeto fez. E foi um sucesso.

O comentário que finalizou a apresentação com chave de ouro foi o approach "Smart Testing", que, seria uma dinâmica visando o melhor planejamento e refinamento deste, em duas reuniões semanais presenciais com todas as equipes envolvidas. Enfatizando, mais uma vez, o quão importante é para um Analista de Testes ser proativo e saber se comunicar (e claro, documentando tudo, para que nada seja esquecido).

CInTeQ 2010 - Mauro Spínola - Qualidade e Produtividade em Sistemas e Software: Um Desafio Brasileiro

2010-03-24T08:07:00.000-07:00

Essa apresentação foi importante para destacar a importância das empresas em terem processos. A dica foi dada: não adianta reiventar a roda! Os padrões estão aí no mercado e estes devem ser utilizados.

Foram levantadas as seguintes questões: o que é e qual o tipo de produtividade. Para ter uma maior produtividade, segundo Mauro, é simples: defina sua arquitetura, processos, padrões, ferramentas, automatize suas atividades e faça bom uso da componentização.

Foram citadas entidades certificadoras e qual o foco das suas certificações para qualidade do produto e do processo. As empresas trabalham com produtos e serviços e se esquecem que o que vai ganhar o cliente, é a qualidade. E como ter uma maior qualidade? Inicialmente, preocupando-se com ela. Depois, bom, depois são outros quinhentos.

É fácil definir um processo, mas e pessoas para atuarem de forma pontual nesse processo? O Mauro levanta uma crítica bem relevante: falta gente qualificada, a formação é medíocre, às empresas que querem gente para resolver o problema e não para cooperar com o negócio e ao próprio profissional que não busca uma melhoria contínua. Até fez um convite ao SPIN (http://www.spinsp.org.br/), que é uma comunidade preocupada na melhoria contínua do profissional e das empresas.

Destacou também a importância das empresas em se preocupar com o cliente, afinal, como dizem, ele tem sempre razão, não é? Deve-se amadurecer a relação com o cliente quando ele está nas duas pontas: quando ele pede o produto/serviço e quando este é avaliado. As pontas e interfaces com os mesmos devem ser priorizadas, melhorando assim, a comunicação entre o cliente e empresa.

CInTeQ 2010 - Patricia McQuaid - Software Disasters: What Have We Learned?

2010-03-24T07:51:00.000-07:00

Essa palestra apesar de um pouco cansativa teve seus objetivos pré-estabelecidos: enfatizar o quão importante é a qualidade num produto em geral, não necessariamente num software (apesar deste ser o tema do evento).

Vários assuntos foram trazidos à tona pela palestrante e identificados quais são as causas de cada gafe cometida nessas situações específicas. Em geral, os problemas ocorridos foram omissão por parte dos engenheiros, falta de comprometimento com a causa, falta de processo específico em QA em geral, falta de conhecimento do negócio e outros.

Apesar do tema ser um pouco cansativo e também por estar no final do primeiro dia, os grandes executivos de empresas provedoras de serviços e produtos, devem entender que erros causados por falha em máquina (gerados a partir do erro humano) podem acarretar em grandes catástrofes, atingindo diretamente a vida das pessoas, ocasionando, eventualmente, mortes.

CInTeQ 2010 - Emílio Silva de Castro - A Importância da Especialização dos Papéis em uma Fábrica de Testes

2010-03-24T07:25:00.000-07:00

Tive a oportunidade de conversar pessoalmente com o mais novo CTAL-TM do Brasil e gerente de projetos da RSI. Sua palestra foi também de caráter informativo, bem como um case sobre a própria estrutura da empresa em que trabalha, que funciona como fábrica de testes para clientes como a Caixa Econômica e Santander.

Sabe-se que a especialização das funções dentro de um contexto em específico só tende a aumentar, o que pode ilustrar isso é a Medicina. Antes eram apenas Médicos, depois viraram Médicos Ortopedistas, depois Médicos Ortopedistas especialistas em ombro, e por aí vai. Em Testes de Software não é diferente. Antes eram Testadores, depois Testadores de Performance, depois especialistas em scripts de performance, depois especialistas em scripts de performance em aplicações SAP, e por aí vai.

Apesar do assunto "Fábrica de Testes" estar bem em alta, muito das colocações feitas durante a apresentação não eram novidades para os frequentadores de blogs como o Test Expert e afins. Todavia, como é um assunto que vem a tona muito frequentemente em blogs, empresas (que desejam expandir sua célula de testes) e livros da área, na minha opinião, foi uma ótima abordagem para o congresso, já era um tema batido mas necessário.

Aliada a apresentação sobre TMMi do Erik van Veenedaal, esse esclarecimento sobre Fábrica de Testes dá uma idéia bem interessante sobre "como estruturar a sua equipe de testes na sua empresa sem ter a menor idéia de como se deve testar um programa". Ótimo para a alta gerência das empresas interessadas. Nada mal!

CInTeQ 2010 - Mieke Gevers - How the Performance testing results can fool you!

2010-03-24T07:22:00.000-07:00

Num contexto geral, a apresentação da ilustríssima belga especialista em Testes de Performance foi de certa forma interessante. Na minha opinião, Testes de Performance não é mais um assunto novo, apesar dessa tendência ter começado no Brasil muito tarde.

Mieke comentou sobre o que é Performance Testing de maneira geral, não aprofundando esse tema para os leigos no assunto. Foi mais direta ao assunto, levando em consideração que os participantes do evento já sabiam do que se tratava, pequeno engano.

Além disso, deixou claro que os maiores desafios de Performance Testing são as métricas (o motivo de sua apresentação) e a elaboração dos cenários. Diz que os gráficos e resultados do teste de performance não fazem o menor sentido se não souber o que está acontecendo por trás disso. As métricas de performance precisam ser definidas anteriormente para saber o que deve ser elaborado nos cenários e traduzido nos gráficos.

Estive conversando sobre esse tema com um colega e ele disse que faz todo o sentido pois a empresa dele tem passado por esse problema. A aplicação está lenta e foi diagnosticado que o problema não é CPU, não é memória, não é HD, não é servidor, não é excesso de usuários, não é nada. Suspeita-se que seja problema na estrutura brasileira de rede, pois foram feitos alguns testes primários na mesma aplicação em outros países e não obtiveram os mesmos resultados. No mínimo curioso.

Uma das perguntas ao final da palestra do Rex Black, sobre Agile Testing, foi: como testar a performance de uma aplicação se ela está instável e não integrada no decorrer das sprints? Essa pergunta foi melhor respondida na própria palestra da Mieke Gevers, que dentre vários fatores, o envolvimento do performance tester deve ser também feito precocemente no projeto, a fim de avaliar se a aplicação, no decorrer dos sprints, deve estar testável (falando no quesito de performance).

A grande sacada do teste de performance, segundo Gevers, está em analisar os resultados, estes devem ser baseados em dados e não no feeling do profissional. Todas as respostas das questões que devem ser respondidas no início do projeto, devem estar mensuráveis nos gráficos.

Fez também um comparativo entre o ambiente de testes e o ambiente de produção, que, se estes não forem idênticos, devem ser no mínimo lineares (o dobro de HD, o dobro de banda, o dobro de memória, etc.)

A apresentação da Mieke Gevers foi de certa forma muito subjetiva, apesar de muito interessante. Não teve uma introdução efetiva no tema e foi precocemente para a leitura dos gráficos. Aos que já trabalham com isso, foi um avanço no cuidado pela atenção aos detalhes, aos que nunca viram, não fez o menor sentido.

CInTeQ 2010 - Rex Black – Dealing with the Testing Challenges of Agile Methodologies

2010-03-24T06:53:00.001-07:00

Apesar do tema "Agile Testing" não ser novidade para mim, é sempre bom ouvir comentários de alguém tido como a principal entidade do Software Testing em escala mundial, nada mais, nada menos que o ex-presidente da maior instituição certificadora do mundo, Rex Black. Terei o prestígio de participar do curso preparatório para a prova do CTAL-TA, esta que estará disponível no Brasil, através da RSI (organizadora do evento), apenas em inglês, conforme previamente comentado. O inglês americano bem calmo e claro facilitou o entendimento daqueles que não usufruiram do dispositivo de tradução simultânea.

A palestra do Rex Black foi fundamentada em cima dos desafios de testes que acercam a metodologia ágil. Segundo ele, estes desafios são Risk-based (testes baseados nos módulos de mais risco para o projeto), automação (não automação de casos de teste, mas sim Unit Testing em geral, comentando sobre ferramentas como CPP e JUnit, que são free's) e por último, dito ele como "reactive approach", ou seja, a figura tradicional do Analista de Testes é naturalmente reativa, espera o documento, atividade ou código pronto para começar a trabalhar, para ele, em agile isso não funciona.

Ele comentou do Agile Manifesto e até fez uma comparação às teorias da revolução: "You are not interested in revolution, but revolution is interested in you.", ou seja, por mais que não tenhas interesse em participar do Agile Manifesto, a comunidade acerca disso está interessada na sua participação, nos seus cases, nas suas dúvidas, tudo. Deixando claro, através de um comentário dito por ele mesmo em 2002: "Hardly we will find the agile testing best practices until the end of this decade", que as práticas de testes em metodologias ainda são muito vagas.

Rex confrontou colocações como "Much documentation or working application" alegando que tem formas de trabalho que tornam a metodologia ágil bem clara para os profissionais envolvidos, trazendo de certa forma, uma pilha de documentos e práticas que declararia quaisquer alterações no sistema.

Argumentou também contra o comprometimento para o término de um Sprint, que em testes, pelo fato de ser um contínuo teste de regressão, não deveria existir: "Killing team morale because of fixed dates to finish sprint". Na minha opinião essa é a grande diferença de ter uma palestra informativa e uma palestra com um expert do assunto, esses detalhes não são abordados quando o palestrante se resume a falar simplesmente de uma tecnologia, assunto ou produto em específico. Sendo assim, um conjunto de informações que acercam um assunto em específico, tornando os especialistas bem como os leigos no assunto mais envolvidos no tema.

Reforçou a importância de Unit e System testing funcionarem de forma conjunta e comentou, fugindo de perguntas "pegadinhas" (apesar de responder a todas as perguntas de forma objetiva com leves "sabonetadas"), a seguinte frase: "Show me a tester who have never found a testing challenge in a project and I will show you a tester who have never worked in a project". Genial.

CInTeQ 2010 - Eduardo Habib – Teste de Segurança em Aplicações Web

2010-03-24T06:51:00.000-07:00

Bem, como todos já sabem, a apresentação do Eduardo Habib foi sobre Testes de Segurança, apesar do visível nervosismo, a apresentação, de caráter informativo, na minha opinião, foi excelente. O assunto é bem atual, e como podem perceber as vagas de "Penetration Tester" (sem piadas) tem aumentado no âmbito mundial, esta é provavelmente a forte tendência para o mercado brasileiro nos próximos meses, ou anos. Outro assunto relacionado que está em alta no mercado internacional é a valorização da certificação de hacker ético (CEH - Certified Ethical Hacker), que seria nada mais, nada menos, que um hacker interno dentro de uma organização, a fim de visualizar o sistema como um usuário que tenta achar brechas, quanto mais experiente, melhor. Em outras palavras, um especialista e certificado em Testes de Segurança.

Outro comentário interessante foi a divulgação do site Web Goat (www.owasp.org), este que tem por objetivo, em formato tutorial, ensinar pessoas a acharem brechas no sistema. Quem não saiu da palestra com vontade de verificar a veracidade e segurança de portais e sites internet afora?

Resumindo, como o assunto é novidade e existem poucos profissionais no Brasil especializados nesse ramo, a palestra informativa teve um feedback bem positivo pelo fato de muitos serem leigos no assunto. Não tive a oportunidade de elogiar o Eduardo pessoalmente (bem como fiz com outros participantes) mas fica por aqui, meu "elogio virtual" à sua palestra. Parabéns!

CInTeQ 2010 - Apresentação sobre ética

2010-03-24T06:46:00.000-07:00

Esqueci-me, infelizmente, do nome deste apresentador do evento, que está de parabéns por suas colocações divertidas e inteligentes e suas citações bem fundamentadas.

Nesse intermédio sobre ética, este comentou sobre temas voltados para o ser humano como "confiabilidade", sabedoria (definido como conhecimento + ética), humildade (que vem do húmus, "terreno fértil") e fez uma alusão ao Software Testing comentando de uma platéia como se fosse um ensaio para uma grande estréia (no ensaio podemos errar, na estréia não - durante o projeto podemos achar bugs, na produção, "não").

Dentro de inúmeras citações inteligentes desferidas no decorrer do evento, fica a minha preferida, citada por Arete: "Seja o melhor que você pode ser, a partir do que você é."

CInTeQ 2010 - Abertura do evento – Osmar Higashi – Atuação do BSTQB e Panorama Atual dos Testes no Brasil

2010-03-24T06:45:00.000-07:00

Osmar Higashi, presidente do BSTQB, foi o responsável pela abertura do evento. Comentou sobre a importância do evento para a comunidade brasileira de Testes de Software e de alguns temas bem específicos sobre o crescimento da área, valorização do profissional e credenciamento de empresas à instituição.

Como já havia sido previsto, pelo fato de o próprio Rex Black em pessoa ter vindo para o Brasil ministrar um curso de CTAL (o qual participarei na próxima semana do dia 29/03), irão liberar, traduzida e adaptada para o português, a prova de CTAL-TM, esta, focada para gerenciamento de projetos de teste. Apesar de, em contrapartida, o curso ministrado pelo presidente do ISTQB ter seu foco em testes funcionais. Numa conversa informal com Osmar, tive a agradável notícia que a prova CTAL-TA será disponibilizada exclusivamente para os participantes do curso, mas, somente em inglês.

Outros assuntos pertinentes à abertura do evento foram divulgados somente no decorrer do evento, como, por exemplo, a data anual do mesmo. Este que será organizado toda última semana de Março anualmente. O CInTeQ 2011 será feito nos dias 28 e 29 de Março de 2011. Façam já suas inscrições, recomendo!

CInTeQ 2010 - 22 e 23 de Março

2010-03-24T06:44:00.000-07:00

Bom pessoal, não vou escrever sobre as palestras em caráter informativo, pois os vizinhos de blogs http://qualidadebr.wordpress.com e http://zarroboogsfound.blogspot.com/ já o fizeram. Fizeram inúmeras anotações sobre as palestras de maneira que tudo citado lá está descrito de maneira bem clara. Então, irei simplesmente escrever meus comentários e críticas sobre o evento de como um todo e um resumo sobre a minha impressão de cada palestra.

O CInTeQ 2010 de maneira geral foi sensacional, a organização foi impecável, a escolha e localização do hotel do evento foi certeira, o almoço executivo e os coffee-breaks estavam ótimos, os palestrantes eram "au concour" pois a maioria era expert no assunto em questão.

Minha única reclamação era o fato de que os participantes tinham que almoçar de pé, o que não era muito cômodo, apesar de promover a interação dos mesmos nesse desconfortável almoço executivo. Outro fator que comentaram foi que a tradução simultânea não era da área, tornando subjetivas algumas colocações dos palestrantes. Não tive oportunidade de avaliar o aparelho pois o inglês da maioria dos palestrantes era bem claro. Graças a Deus não tivemos indianos ou chineses presentes nesse evento. :)

O nível do evento foi excelente, bem como os participantes do mesmo. Tive oportunidade de conhecer project managers, test managers, equipes IBM, Microsoft, RSI e outros big players. Conheci e reconheci colegas como Daniel Cunha, Pedro Corrêa, Fabrício Ferrari, Ana Salete Aquino e Osmar Higashi, tive a oportunidade de conhecer a sortuda dupla da PRODEB (Eládio e Fernanda - ganhadores do curso oferecido pela Interasys e do Sony Vaio premiado pela Microsoft), bem como tive a oportunidade de conversar pessoalmente com figuras como Erik van Veenedaal, que fez uma impecável apresentação sobre TMMi.

Na foto: Daniel Cunha e Luiz Gustavo S. Vieira

Consultoria em Testes na LUGATI [parte 2]

2010-03-16T07:45:00.001-07:00

Existem muitos tipos de empresa que podem precisar de uma consultoria de testes. Algumas precisam de um profissional muito específico num detalhe do processo como um todo. Outras precisam refazer o processo para que este esteja adaptado a aceitar e entender como Testes de Software funciona.
Já tive a oportunidade de trabalhar com as duas formas. Já entrei de pára-quedas num projeto e precisei desenvolver Testes de Desempenho numa aplicação que jamais tinha visto antes. Foi um trabalho de certa forma tranquilo, apesar dos prazos apertados. Não foi nenhum desespero para conseguir a documentação ou os dados necessários, a equipe estava disposta a fornecer o que fosse e tinha cada papel no processo bem definido, ou seja, o projeto foi um sucesso. O perfil de cargas foi definido, o Analista de Negócios sabia exatamente o que o cliente necessitava. Os dados de teste foram todos feitos com excelência pelo DBA. Os casos de teste foram fornecidos pelos Analistas de Testes. E todo o trabalho "sujo" de scriptação desses casos de teste e elaboração dos cenários foram feitos em tempo.
Mas também já tive casos em que a empresa entrou em contato e disse: preciso de uma equipe de testes na minha empresa, como faço? Não entendo nada de testes! Existe uma certificação de testes? Não era só clicar na tela? Bom, aí começou o desespero... A maneira mais interessante de começar qualquer atividade de testes numa empresa, é importante nivelar o conhecimento, ou seja, mostrar para os stakeholders* o que é Testes de Software.
Mas antes de sair montando qualquer apresentação genérica sobre Testes de Software, é importante entender como funciona o processo da empresa, para que o profissional possa criar uma apresentação mais tendenciosa. Por exemplo, saber se a metodologia de desenvolvimento é RUP, SCRUM ou até mesmo, própria. Segundo Glenford J. Myers, "testing is context dependent", ou seja, pode-se e deve ter um processo de testes próprio para cada tipo de organização. Todas as organizações têm suas particularidades e estas devem ser levadas em consideração. É importante ressaltar que haverá uma mudança nos processos, mas a cultura da empresa deve ser mantida para que os profissionais que já estão lá dentro não se espantem e dificultem a evolução do processo...

Consultoria em Testes na LUGATI [parte 1]

2010-03-02T06:15:00.001-08:00

Pessoal, como muitos sabem, iniciei minhas atividades na LUGATI IT Services (o site já está no ar e o endereço é: www.lugati.com.br) e não tive tempo de postar com frequência no blog. Abrir uma empresa toma muito tempo!
Agora que as coisas estão um pouco mais tranqüilas e estou fazendo consultoria num dos nossos clientes, posso voltar a documentar as atividades e agregar um pouco de conhecimento ao Blog, bem como trocar idéias com o pessoal que tem frequentado.
Basicamente, tivemos a oportunidade de oferecer nossos serviços de consultoria de testes a um cliente (infelizmente não posso divulgar nomes por questões de confidencialidade). A atividade de desenvolvimento de Software não é fim nessa instituição, o que acaba mudando um pouco essa questão de definição dos processos.
Visto essa característica da organização, levamos em consideração dois pontos importantes:
- A questão dos prazos não é tão importante, ou seja, não tem aquela loucura de fábrica de software que tudo é pra ontem, lá as coisas podem ser executadas de forma correta, seguir um cronograma viável e mensurável.
- Todavia, sempre tem aquelas questões do "pra ontem". Geralmente é um "raio" que cai lá de cima (da alta gerência) e, daí sim, sai de baixo.
Inicialmente foi sugerida a implantação de algumas ferramentas básicas de testes, como o Testlink, para estruturação dos projetos de teste. Como as coisas aqui acontecem mais devagar, as boas práticas serão inseridas com calma.

Reabertura do Blog

2009-10-29T10:52:00.001-07:00

Estive um pouco ausente, há algum tempo sem postar. Tenho alguns motivos, dentre eles: a minha monografia e a empresa (LUGATI IT Services) de outsourcing de desenvolvimento e testes, a qual estou abrindo com mais três sócios.
Somos especializados nas linguagens .NET, Java, PHP e claro, Testes de Software (funcional, automatizado e de performance). Oferecendo serviço com estrutura de suporte internacional.
O site, versão inicial, estará disponível em alguns dias.

Contato:
- Luiz Gustavo Schroeder Vieira
Diretor Comercial
luizgustavo@lugati.com
Skype: luizgsvieira
+55 (48) 9994-3569

Revista TI Digital

2009-05-20T15:21:00.000-07:00

A terceira Edição, maio de 2009 é dedicada a Testes de Software (matéria da capa).
http://www.revistatidigital.com.br/index.php
Vale a pena conferir, custa apenas R$ 7,90.

Testes de Software no FISL

2009-05-14T21:02:00.000-07:00

O FISL (Fórum Internacional de Software Livre) é um Fórum que tem por objetivo agregar todos os interessados e envolvidos em atividades que utilizam de tecnologias free (e também as de código aberto). Pois há uma vertente que acredita que se houver uma grande colaboração para o desenvolvimento de aplicações free's, o mercado fica auto-suficiente e não se haveria a necessidade de comprar aplicações que hoje em dia são pagas.
Fui chamado pra representar o grupo de usuários de Testes de Software no FISL. O que significa isso?
Bom, visto pelo fato de que estamos buscando um espaço no mercado, tanto numa maior valorização e posicionamento não só do profissional bem como da atividade de testes no mercado. Mais que isso, esse é um passo importante para a comunidade de teste de software no Brasil, posicionar-se num cenário nacional que tem respaldo internacional.
O evento está hoje atingindo quase 4000 inscritos e até a data final, espera-se 10000participantes. É uma grande oportunidade da comunidade de testes de software comparecer e mostrar seu valor, apresentar seminários de qualidade e agregar valor às atividades dos profissionais de outras áreas.
Estou negociando a possibilidade de termos uma sala exclusiva para o grupo de usuários de testes de software fazerem seus próprios seminários internos, bem como um pré-evento (já aconteceu um pré-evento de Java - http://www.soujava.org.br/display/v/Javali+2008).
Quaisquer profissionais que tiverem interesse em participar ou apresentar seminários podem entrar em contato comigo, estarei centralizando todas as informações e entrando em contato com os organizadores para termos nosso espaço garantido nesse evento!

Revisões e Análise de Ambiguidades [parte 5]

2009-05-12T15:23:00.000-07:00

Verificar a existência de Casos de Teste Negativos, ou seja, se existem testes que verificam uma possibilidade que o sistema não aceita. Muitas vezes só são criados testes que verificam respostas do sistema com os parâmetros corretos e não possui testes que verificam se parâmetros incorretos são tratados corretamente pelo sistema.
Verificar a existência dos Boundary Testes (BVA – Boundary Value Analysis – análise de extremidades), ou seja, aqueles testes que verificam os extremos das funções.
Cada Caso de Teste deve estar ligado a um ou mais requisitos do sistema. Isto pode ser verificado através de uma Matriz de Rastreabilidade.
Um passo no caso de teste não deve referenciar a execução de outro caso de teste ou de outro passo do mesmo caso de teste. Isto pode gerar confusão e atraso na execução dos testes.
Se há um grande volume de documentos para serem revisados e não há tempo suficiente para revisar tudo, revise os documentos mais críticos (que possuem maior risco). É bom consultar algum superior para analisar essa criticidade.
Utilização de glossários é muito importante para que o revisor (ou qualquer outro envolvido) esteja ambientado com os acrônimos do sistema.

Revisões e Análise de Ambiguidades [parte 4]

2009-05-12T15:22:00.000-07:00

Para revisar a documentação é preciso saber se algum template está sendo utilizado, seja qual tenha sido o padrão adotado. Se o documento não está de acordo com o template, este poderá ser a primeira não-conformidade encontrada.
Depois de descoberto qual o template usado no documento, obtenha-o e compare aos Casos de Teste para verificar se não estão faltando seções.
Se este possuir guidelines em cada seção, verifique se o que o guideline indica está contemplado no documento.
Utilize algum checklist próprio ou do projeto para ajudar na revisão (não adianta criar um checklist padrão pois o foco de cada revisão é diferenciado de empresa para empresa).
Verifique se existem ambigüidades no documento (será analisada mais tarde).
Issues iguais que ocorrem em várias partes do documento podem ser agrupadas em um único issue. A severidade deste pode ser aumentada em um nível, dependendo do julgamento do revisor.
Nunca junte issues parecidas ou mesmo diferentes em um só issue. Isso poderá afetar as métricas ou então só um dos dois defeitos será corrigido e o outro ficará esquecido.
Todos os Casos de Teste devem possuir um identificador único.

Revisões e Análise de Ambiguidades [parte 3]

2009-04-20T17:21:00.000-07:00

Revisões informais são aquelas que não tem a necessidade de se criar um registro formal do recebimento da revisão como também não é necessário a criação de um documento específico onde estarão listados as possíveis gafes do documento. Depois de terminada a revisão os defeitos podem ser passados para o dono do documento verbalmente ou comentários feitos no próprio documento.
Revisões formais são aquelas em que o revisor deverá receber os documentos através de alguma forma (seja em diretório compartilhado, documento ou alguma outra forma. Constando o que deverá ser revisado, qual o prazo e se existe alguma instrução específica para a revisão, seja ela focando, por exemplo, em erros gramaticais ou em aspectos funcionais da arquitetura proposta. Junto com o documento deverá vir a planilha onde os defeitos devem ser listados (por tipo).
Finalizando a revisão, os defeitos devem ser enviado formalmente para o autor e o revisor deve manter uma cópia dos arquivos e defeitos levantados. Uma reunião deve ser marcada para discussão dos possíveis defeitos encontrados.

Revisões e Análise de Ambiguidades [parte 2]

2009-04-15T18:56:00.000-07:00

Esses detalhes devem ser minuciosamente esclarecidos para que as atividades se iniciem de maneira adequada. As atividades devem ser executadas de maneira que estejam adequadas ao contexto da empresa. Numa equipe que utiliza modelo cascata ou iterativo (com longos Milestones), é interessante que haja todo o procedimento detalhado de forma clara para evitar inconsistências.
Como muitos já sabem, quanto mais cedo corrigir uma falha, menos custoso será para o projeto (melhor descrito por gráficos que, quando um bug é encontrado na fase de produção é algo em torno de 100x mais custoso que encontrar/corrigir esse bug na etapa de análise).

Partindo desse princípio, vale destacar algumas boas práticas na revisão de documentação, que seria a primeira etapa num processo de desenvolvimento de qualquer equipe de software (estas atividades não são estritamente referentes às metodologias ágeis, por exemplo, mas podem, de certa forma, serem abstraídas).
Esse tipo de etapa de teste, é chamado de teste estático, ou melhor conhecido por revisão. O processo de revisão pode ser definido em basicamente 2 categorias: revisão informal e revisão formal.

Revisões e Análise de Ambiguidades [parte 1]

2009-04-07T18:59:00.000-07:00

Dos 7 princípios de Testes de Software definidos por Glenford J. Myers em meados de 1979, um deles se chama "Early Testing". Isso significa que as atividades de teste devem ser iniciadas o quanto antes.
A primeira fase no início de qualquer sistema é a definição dele, que na metodologia tradicional se chama Análise de Negócio. Isso é nada menos que a elaboração de um documento, a partir de uma série de reuniões com o cliente, com a idéia macro de como o sistema deve se comportar. Posteriormente vem a Análise do Sistema, onde os Analistas, a partir do documento de negócio, definem o sistema. Casos de uso, requerimentos, protótipos funcionais, não-funcionais, especificação de requisitos, diagramas e quaisquer outros artefatos que possam ajudar o desenvolvedor a proceder com suas atividades.
Fica uma pergunta: onde entra as atividades de teste nisso tudo? Não necessariamente o Analista de Testes precisa entender do negócio, simplesmente a tarefa dele é fazer com que o documento elaborado pelo Analista de Negócio fique claro para os Analistas de Sistema. Para que isso ocorra, é necessário que seja levado em consideração alguns detalhes visando nivelar a informação entre os membros do time.

Testing Experience Magazine

2009-03-16T08:46:00.001-07:00

Recebi através de uns colegas da área a indicação de uma revista totalmente voltada para Testes de Software, esta que já possui mais de 200.000 leitores no mundo todo.
Está disponível uma versão em PDF para análise.

http://www.testingexperience.com/testingexperience01_09.pdf

PS: Estou verificando como fazer para assinar a revista, assim que tiver notícias eu posto aqui.

Frases da semana

2009-03-15T16:20:00.000-07:00

"Given the high cost of defect correction in a product that's in production, the cost of a new software quality initiative could potentially pay for itself."
"Each hour spent on inspections avoids an average of 33 hours of maintenance."
"Software inspections are one of the software quality best practices we recommend."

Comentários:
Eu sempre digo para revisarem/questionar a documentação, sprint planning, protótipos ou o que utilizarem antes de codificar. Entretanto, às vezes parece que eu falo grego!
Essas frases eu achei num material sobre Qualidade de Software da IBM, este material que cita também sobre certificações ISO, CMMI, Six Sigmas e TQM (Total Quality Management).

Checklist para validação de XML's

2009-03-11T06:35:00.000-07:00

Visto a necessidade de uma validação mais profissional para os XML's utilizados na extração de dados do servidor do cliente, fui requisitado para ajudar nessa atividade. Essa validação foi necessária visto que utilizaríamos o modelo ETL. Na transformação dos dados, tínhamos que validar de alguma forma (por tipo e estrutural) e não a consistência dos dados. Essa consistência é validada somente na carga, verificar, por exemplo, se aqueles dados estão de acordo com o sistema em vigor. No caso de uma locadora de vídeo (famoso), ver se o nome do DVD importado existe de fato. Visto isso, levantamos algumas questões (feitas algumas pesquisas no Google também) e julgamos necessário fazer o checklist das seguintes atividades:
- Contém o elemento root;
- Elementos estão devidamente encapsulados e alinhados;
- Todas as tags estão fechadas;
- As tags não estão sobrepostas;
- Verificar case sensitive;
- Os atributos das tags estão de acordo;
- Tags não repetem os atributos com a mesma tag;
- Tags usam os delimitadores apropriados;
- Os elementos não estão sobrepostos;
- Tags mesmo com elementos vazios finalizam corretamente: "";
- Referências de entidade são declaradas;
- Checar caracteres ilegais.

Metodologias Ágeis - Scrum - Testes - Como fazer? [parte final]

2009-03-09T08:29:00.000-07:00

Como estou mudando de empresa (Fundação CERTI -> Politec), não vou continuar registrando minhas atividades de teste utilizando o SCRUM. Então preparei um resumo destas para os interessados (Acrescento que não sou especialista na função, só achei interessante proceder dessa forma na empresa que trabalho atualmente, caso alguém possa acrescentar de alguma forma a esses posts, ou até descrever a sua forma de trabalho, ficarei muitíssimo grato. Não utilizei nenhuma bibliografia como base, somente minha experiência profissional):
1. Integração com a equipe de análise e desenvolvimento – Procurar entender as regras de negócio, arquitetura e funcionamento das atividades no sistema (às vezes até melhor que o próprio desenvolvedor, pois a função do tester é validar o sistema).
2. Testes exploratórios – Entendido a arquitetura do sistema e definido os checklists necessários, o Analista de Testes deve executar alguns testes exploratórios, utilizando técnicas de error guessing. Vê-se que eu não estimulo a utilização de Casos de Teste devidamente descritos, pelo menos da minha forma de trabalho (com muitas mudanças semanais), não funciona.
3. Descrever/adequar as atividades de teste no Sprint planning – Revisar o Sprint Planning e participar ativamente na reunião de definição desse documento, avaliar a necessidade utilização de checklists, ou qualquer outra atividade que possa prever as atividades de teste no final de cada sprint.
4. Participação ativa em Dayli Meeting – A participação ativa nas reuniões diárias são importantes para o Analista de Testes ter o conhecimento da aplicação em vigor, do andamento dos story points e tirar possíveis dúvidas sobre a arquitetura do sistema. A participação ativa deve ser feita a partir da descrição dos assuntos discutidos na reunião e gerar uma ata diária sobre o que foi discutido para servir de referência para a criação dos casos de teste. Ex. Alterações no sistema, fechamento de atividades, impedimentos, etc.
5. Utilização do Mockup – Inicialmente a utilização do Mockup é fundamental para dar visibilidade dos testes que serão planejados e executados no sistema.
6. Utilização de um documento de mudanças – Durante o projeto as mudanças de tela e/ou arquitetura devem ser registradas de alguma forma e isso afeta diretamente no planejamento dos testes. Esse documento deve estar diretamente aliado ao Mockup.
7. Utilização de checklists – Para uma melhor organização na execução dos testes, durante o desenvolvimento dos componentes do sistema, o Analista de Testes deve criar um documento que seja responsável pelos testes de componente de um módulo e/ou tela do sistema em vigor. Verificar se esse módulo afeta outros módulos para planejar os testes de integração dos módulos do sistema. É também necessário manter esses checklists documentados para que sejam utilizados em possíveis testes de regressão.
8. Definição de um ambiente de testes – Idealmente o sistema deve estar hospedado em 3 locais:
- Servidor para o cliente: O deploy é feito somente ao final de cada Milestone, para o cliente avaliar o que foi produzido naquele Sprint.
- Servidor para desenvolvimento: Pode-se até utilizar deploys diários automáticos (como o Hudson) para manter os módulos do sistema sincronizados com a equipe de desenvolvimento.
- Servidor para testes: O sistema deve, idealmente, estar estável e preparado para os testes. O deploy só pode ser feito sob autorização do Analista de Testes para evitar que “quebre” os testes no meio da execução
9. Utilização da base de dados vazia – Geralmente os dados pré-populados no banco tornam os testes viciados e prejudica o andamento das atividades. Por exemplo, um dado que se deve ser inserido pelo administrador do sistema já vem pré-populado, não dá para saber se o cadastro desse dado está funcionando corretamente.
10. Testes do fluxo total - Nos últimos dias e/ou horas, deve-se fazer o teste contemplando o fluxo total do sistema, desde o cadastro de dados até a utilização desses dados para alguma atividade que necessite dos mesmos. Esta é uma simulação da atividade de um usuário final (User Acceptance testing), pois os módulos já foram testados independentemente.
11. Defect Management - Utilizem uma ferramenta de ticket tracking, aqui é utilizado o Trac mas se pode usar também o Mantis, é a maneira mais simples e prática de integração com a equipe de desenvolvimento. Planilha do Excel no Google docs jamais, é prática e interessante para poucos defeitos, quando passarem dos 40 defeitos por aba, vira um elefante e não há quem se ache lá dentro. Não tem como identificar os defeitos por caso de teste ou caso de uso (há quem teste a partir deles ainda, acredite), pois estes não são aconselháveis usar, somente em situações muito específicas. A melhor forma de identificar um defeito é descrevendo os passos que foram utilizados e tirando print screen da tela em vigor (use PNG, é mais leve) e de preferência, circule com vermelho e adicione algum comentário se necessário para facilitar a vida do desenvolvedor.

Bug no MSN (Windows Live Messenger)

2009-02-28T05:21:00.000-08:00

Eu sempre digo que o tester deve, por natureza, ter o perfil investigativo. Esporadicamente forço algumas aplicações (às vezes não intencionalmente) para ver o comportamento delas, e no MSN não foi diferente.
Posso estar errado, mas possivelmente, na especificação do Windows Live Messenger (popularmente generalizado por MSN) a Microsoft definiu que um usuário só poderia chamar a atenção do outro a cada 10 segundos, para evitar o inconveniente da tela ficar tremendo o tempo todo (para aqueles usuários que não tem mais o que fazer).
Então pensei: deve ter alguma maneira de quebrar a sessão do MSN. Foi aí que lembrei de um outro detalhe, para armazenar o histórico mais recente (em cinza claro) na própria tela. Esse histórico apaga/diminui a cada vez que a tela é fechada e é inserido um input.
Foi então que eu descobri uma maneira de chamar a atenção dos usuários num período menor que 10 segundos, pois provavelmente a sessão do chat aberto com aquela pessoa se "renovava" a cada vez que ele fosse aberto.
Basicamente é o seguinte: clica (treme), fecha, reabre o chat, clica (treme), fecha, etc. procure ser rápido :)
Dados da aplicação: Versão 2008 (Compilação 8.5.1302.1018)

Metodologias Ágeis - Scrum - Testes - Como fazer? [parte 3]

2009-02-27T16:41:00.000-08:00

Experiência em testes no SCRUM é necessária para que a equipe tenha um bom funcionamento? Olha, em qualquer outra situação eu diria que não, é só seguir o "roteiro", entender bem a arquitetura e sair clicando, sem nem precisar se programar. Isso até funciona (em partes) em sistemas pequenos mas no decorrer do aumento de complexidade alguns testes de regressão devem ser feitos periodicamente na aplicação, devido às mudanças constantes.
Eu diria que quanto mais experiência com testes (e com desenvolvimento também), melhor a performance do profissional. Por quê? No meu caso, os erros mais severos que foram achados na aplicação foram devido as vezes que apliquei técnicas de "error guessing". Poder-se-ia criar uma enorme planilha de checklists com "erros comuns às aplicações", mas é inviável.
Um dos 7 princípios de teste citados por Glenford J. Myers no livro "Art of Software Testing" dizia: "Testing is context dependent." ou seja, a criação dessa planilha seria algo completamente sem nexo visto que cada caso, é um caso. Visto isso, as atividades de testes estariam muito atrelada à experiência do profissional e isso faz toda a diferença.
Como coordenar uma equipe de testes inexperiente? Se uma empresa tem uma equipe toda de testes inexperiente, ela vai pro buraco. É preciso pelo menos um profissional que entenda da arquitetura do sistema e de lógica de programação, para que possa orientar os demais recursos.
Como orientar? Ainda é muito cedo para dizer a melhor forma de lidar com isso, mas procuro conversar com o programador para entender como aquele story point foi finalizado, isso ajuda até ele a entender melhor o que foi feito (podendo ser indiretamente uma inspeção de código). Como cada story point são referentes a meio período (4 horas) seria interessante conversar 2x por dia com cada programador, ou 1x, só para tirar dúvidas (caso na Dayli Meeting tenha ficado parcialmente claro).

Integração do Testlink com ferramentas de Bug Tracking

2009-02-19T06:05:00.001-08:00

Como a licença de ferramentas top de mercado, como o Quality Center, é muito alta (algo em torno de 10.000 dolares), devemos optar por ferramentas free que tenham uma qualidade próxima.
Fiz um levantamento das ferramentas free e sem dúvidas na gestão de casos de teste, nada como o Testlink.

Para uma melhor integração com a equipe de desenvolvimento, é interessante que essa ferramenta esteja integrada com ferramentas de gestão de defeitos, ou tickets.

Para integração do Testlink ao Mantis, um post do Elias Nogueira bem detalhado para que façam essa integração:
http://sembugs.blogspot.com/2008/06/integrao-do-testlink-com-o.html

Como utilizamos Trac como ferramenta de gestão de tickets/defeitos aqui na minha empresa, procurei uma forma de integrar o Testlink ao Trac e funciona da seguinte maneira.
Usa um plugin do Trac chamado XMLRPC, para instalação do plugin, é só seguirem os passos detalhados nessa página:
http://trac-hacks.org/wiki/XmlRpcPlugin

E para configurar o Testlink, só sigam essa página:
http://51elliot.blogspot.com/2009/01/trac-testlink-and-xml-rpc.html

Cuidado ao fazer a segunda modificação no nome da variável m_xmlrpcClient para xmlrpcClient.

Atributos gerais de bons Testers

2009-02-12T03:16:00.000-08:00

- São confiáveis;
- São perfeccionistas;
- São de natureza curiosa;
- Gostam de quebrar paradigmas;
- São implacáveis;
- São criativos em identificar falhas;
- São persistentes;
- São pacientes;
- São detalhistas - pensamento analítico;
- São diplomáticos - por exemplo, para evitar conflitos com desenvolvedores;
- São comunicativos;
- São observadores.

Frase da semana

2009-02-11T03:33:00.000-08:00

"Software deployment without professionally developed comprehensive testing is enterprise mission roulette without an opportunity to win."
– Daniel Kaberon, Hewitt Associates, Director, Enterprise Systems Engineering

Metodologias Ágeis - Scrum - Testes - Como fazer? [parte 2]

2009-02-06T08:16:00.000-08:00

Estabelecida uma arquitetura padrão sem muita documentação (uma simples referência aos story points, afinal, a partir daquele story point o profissional deve ter toda a base necessária para testar aquele componente do sistema), é preciso de uma base mais concreta.
Entra a hora do designer (juntamente com o analista de negócio) produzir um artefato inicial mais palpável para o melhor entendimento (não só do tester bem como da equipe inteira) do story point em questão. Esse artefato é conhecido por "Mockup" que é uma apresentação da interface do sistema por telas, podendo ser criado até em Powerpoint.
A utilização do Mockup é simples mas pode ser cruxial para manter a qualidade do sistema. O ideal seria manter esse documento atualizado a cada interação com o cliente, pois pela idéia do SCRUM, é normal as alterações serem feitas numa pequena reunião, até mesmo informalmente pelo telefone. Não é o que acontece, essas alterações geralmente são registradas numa ata ou até mesmo em post-it's.
A solução para essa situação foi manter um Mockup atualizado pelo menos no início do 1º Milestone e no final de cada iteração. A idéia é que esse documento esteja sempre "um passo a frente", sugerindo a interface do sistema para o próximo Milestone. E no decorrer de cada iteração tive a idéia de produzir um documento das mudanças solicitadas.
A idéia da criação desse documento, chamado também de Changes Management Document é para ter idéia do que foi mudado do início de cada iteração até o final desta, podendo ter base para negociação dos story points futuramente com o cliente. Essa planilha, no meu caso, deve ser atualizada pelo responsável pelos testes na aplicação, verificando possíveis inconsistências do sistema em relação ao Mockup. Ao visualizar uma inconsistência, este deve entrar em contato com o analista de negócios ou com o próprio programador. Pró-atividade e interação com a equipe até então são as palavras chave para um processo ideal.

Metodologias Ágeis - Scrum - Testes - Como fazer? [parte 1]

2009-02-03T02:24:00.000-08:00

Há pouco mais de 6 meses comecei a trabalhar numa empresa que tem por base a utilização do Scrum como metodologia de desenvolvimento ágil, esta que inicialmente foi sugerida para gerenciamento em empresas de fabricação de automóveis.
Vim de uma empresa a qual processos de desenvolvimento eram sólidos e tradicionais, com todas as fases bem definidas. A utilização de uma grande massa de documentação de análise era a base dos testes, focando a estratégia de teste no contrato.
Durante semanas ou até meses, questionei a utilização do Scrum como metodologia de desenvolvimento, não pelo seus meios mas pelo fato de não ter algo concreto no qual possa me basear para dar início às atividades de teste. Tudo parecia um pouco nebuloso. Com o tempo fui vendo que não era nebuloso só para mim, bem como para a equipe inteira e também para o cliente. A equipe aos poucos vai definindo o sistema e os testes deve acompanhar esse processo, mas como?
Esqueça a postura do Analista de Testes no Scrum, ele não existe. A figura responsável pelos testes nesse contexto é o SME (Subject Matter Expert), ou seja, um profissional com muito conhecimento da aplicação. Como no Scrum as equipes são multidisciplinares, é interessante que o profissional de testes tenha conhecimentos de lógica de programação, banco de dados, etc. Para quê?
Abandone a metodologia tradicional, Testes de componente, de integração e sistema. Isso, claro, pode ser abstraído no decorrer do projeto, mas não é o foco! A utilização diária dos testes exploratórios é a base para o Scrum. E para que esses testes sejam executados com êxito, é interessante que o tester tenha idéia de como a arquitetura do sistema foi desenvolvida. Nota-se que esses testes exploratórios serão feitos por um SME, ou seja, deve-se interagir com a equipe de forma que esteja por dentro de cada story point concluído.
Inicialmente, a solução que tive foi participar ativamente da SCRUM Dayli Meeting. Falei no início do post a respeito da capacidade multidisciplinar dos participantes de uma equipe de SCRUM, com o responsável pelos testes não é diferente. Agora o papel é de Scribe (ou recorder), ou seja, é aquele profissional que anota todas as questões, problemas e pontos identificados durante as reuniões diárias (aquelas de 15 minutos). A partir dessas anotações é criada a arquitetura dos testes, estes que deveriam ser executados naquele ou nos próximos dias.

[BSTQB] Classes de equivalência

2009-01-30T11:13:00.000-08:00

A questão é a seguinte:

Em um sistema projetado para trabalhar com taxa de imposto a ser paga:

Um empregado tem salário de $4000 livre de impostos
Os próximos $1500 são tributados em 10%
Os próximos $28000 depois disso são tributados em 22%
Qualquer quantidade posterior é tributada em 40%

$28000; $28001; $32001.
$4000; $5000; $5500.
$4000; $4200; $5600.
$32001; $34000; $36500.

Para o mais próximo valor inteiro, qual desses grupos de números caem em três DIFERENTES classes de equivalência?
_______________________________________
Resposta:

Para classes de equivalência pode-se usar o mesmo raciocínio do BVA.

Nessa questão ele diz o seguinte:
Valores até 4000 não são tributados
Valores entre 4001 e 5500 são tributados em 10%
Valores entre 5501 e 33500 são tributados em 22%
Valores maiores que 33501 são tributados em 40%

significa escolher valores que possuam outputs diferentes (nesse caso, tributações), ou seja, estes devem possuir 3 valores que estejam em grupos diferentes.

$28000; $28001; $32001.
$4000; $5000; $5500.
$4000; $4200; $5600.
$32001; $34000; $36500.

resposta certa é C:
4000 não é tributado.
4200 é tributado em 10%
5600 é tributado em 22%

esse teste é feito para ver se o sistema está contemplando os valores previstos no output, na prática geralmente os 2 testes podem estar aliados: BVA e Classes de Equivalência.

Vaga para estágio em Testes de Software

2009-01-29T09:59:00.000-08:00

Pessoal, a Fundação CERTI (Florianópolis - SC) está procurando estagiários interessados em trabalhar com Testes de Software, os interessados podem entrar em contato comigo.
A descrição da vaga está no seguinte endereço:
http://blog.certi.org.br/2009/01/oportunidade-de-estagio-em-testes.html

Estudos para o ISTQB/BSTQB

2009-01-29T06:15:00.001-08:00

Aqui vai uma página interessante com o Glossário das provas:

http://www.virtualtesting.blog.br/?page_id=61

É interessante para quem tem dificuldade com a língua e deseja mesmo assim tirar o ISTQB, as terminações em inglês começam a fazer mais sentido depois que esta é traduzida.

Caso tenham dúvida sobre essas provas podem entrar em contato comigo, de preferência por email. Ficarei grato em ajudar! Boa sorte!

[BSTQB] Análise de Valor de Fronteira

2009-01-28T11:58:00.000-08:00

Mais conhecido como BVA (Boundary Value Analysis) funciona da seguinte maneira:
Quando se quer testar um campo que recebe valores (inputs). Por exemplo, o campo aceita valores entre 5 e 20. A técnica de análise do valor de fronteira consiste em testar os valores de fronteira com intuito de achar os erros na aplicação.
Geralmente o programador pode se confundir e botar pra aceitar valores >= (maiores ou iguais) a 5 ou só valores > (maiores) que 5, o mesmo para valores relacionados a 20.
A técnica funciona da seguinte maneira: testa os valores 4, 5 e 6 ... 19, 20 e 21.
Evita que o tester perca tempo inserindo valores como 0, 1, 12, 13, 100, 200, 999999, etc. que para o sistema não tem nexo algum. Às vezes o valor zero pode ser utilizado, porém com outros propósitos.

Postei sobre essa técnica de teste por causa de uma questão de simulado que me enviaram numa lista de discussão sobre a prova do BSTQB, então como ajudei uma pessoa, posso distribuir o conhecimento com mais pessoas.

A questão é a seguinte:
Em um sistema projetado para trabalhar com taxa de imposto a ser paga:
Um empregado tem salário de $4000 livre de impostos
Os próximos $1500 são tributados em 10%
Os próximos $28000 depois disso são tributados em 22%
Qualquer quantidade posterior é tributada em 40%

Para o mais próximo valor inteiro, qual desses é um caso de teste da Análise de Valor de Fronteira?

A. $32001.
B. $28000.
C. $1500.
D. $33501.

Nessa questão foi dito que:
Valores até 4000 não são tributados
Valores entre 4001 e 5500 são tributados em 10%
Valores entre 5501 e 33500 são tributados em 22%
Valores maiores que 33501 são tributados em 40%

A resposta correta é a D, que é um caso de teste que checa se os valor inserido é será tributado em 40%. Não tem nexo (para a técnica de BVA) os demais valores.

Logando defeitos...

2008-12-12T06:39:00.000-08:00

Parece uma tarefa trivial, e é uma tarefa trivial, mas tem alguns macetes que sugiro para ajudar um bom direcionamento das atividades da equipe.
Quando a equipe trabalha na mesma sala, funciona no grito.
Quando a equipe trabalha no mesmo escritório, avisa em reuniões ou "informalmente".
Quando a equipe trabalha em localidade diferentes, envia por email.
Como tornar esse processo mais eficiente?
Bom, primeiramente, utilizar uma boa ferramenta de bug tracking, seja ela free ou paga. Ferramentas como o PLCM (Product Lifecycle Management) ou Quality Center já são intuitivas, mesmo porquê no Quality Center esta já vem atrelada ao Test Case executado. Caso as ferramentas de Gestão de Test Cases sejam integráveis com um Bug Tracking, facilitariam as coisas. Caso seja uma ferramenta à parte (ou não), é interessante levar em consideração alguns pontos:
- Milestone/Release: É importante saber em qual fase do projeto o defeito foi descoberto. Isto é feito para ter o controle de quando foram corrigidos ou, principalmente, se foram deferidos.
- Módulo/Componente: Em que parte do sistema aquele defeito foi encontrado, para caso os defeitos sejam centralizados num líder técnico, gerente ou responsável na equipe de desenvolvimento, possam ser direcionados para os responsáveis.
- Severidade: É importante saber que mesmo que um defeito tenha altíssima severidade (no caso dos catastróficos), não necessariamente ele possui alta prioridade, tudo vai depender do escopo de desenvolvimento.
- Prioridade: Basicamente seria o quão rápido esses defeitos devem ser corrigidos pelos responsáveis, estes precisam filtrar a gama de defeitos de alguma maneira.
- URL: É interessante repassar a URL da tela em vigor para que o programador possa mapeá-la dentro do código.
- Screenshot/printscreen: Nada como uma identificação visual da tela, uma descrição por mais precisa que seja, não vai ser tão eficiente quanto a própria tela. Caso o bug tracking possua sua própria ferramenta de screenshot, não será necessário anexar nenhum documento, mas caso seja, utilzar o formato .PNG, .BMP é muitíssimo pesado.
- Login/senha: Esse é o primeiro passo para reproduzir um defeito, usuários diferentes possuem, às vezes, diferentes permissões no sistema, esse detalhe pode ser crucial.
- Passos/inputs: É importante dizer quais passos foram executados e quais inputs foram digitados em cada tela para que aquele defeito ocorra.
- Browser: Diferentes navegadores possuem diferentes engines, erros de design são muito comuns afetando a disposição dos componentes ou efeitos gráficos. Visto esse motivo, o cliente deve anunciar quais browsers sua aplicação deve suportar, levando em consideração seu público-alvo.
Parece muito burocrático para logar um simples defeito no sistema, realmente é. Mas levando em consideração que tempo é dinheiro e dependendo da complexidade do sistema e da agilidade da equipe alguns desses passos se tornam desnecessários e consequentemente, descartados. Isso vai ajudar seu colega a evitar o famoso e "irritante" debug...

A lenda da automação dos testes

2008-12-10T15:28:00.000-08:00

Falando em globalização, é comum as empresas suplicarem por profissionais no mercado que tenham conhecimento em ferramentas para automação de testes. O que quase sempre acontece, é o milagre do "teste automatizado" que corre por ai: aperta um botão e voilá!
Bom, o que muitos não sabem é que geralmente a equipe leva tempo para treinar a ferramenta, as ferramentas são caras e quando são free geralmente têm bugs inesperados que podem afetar todo um escopo de projeto. Principalmente as metodologias de desenvolvimento ágeis que por terem uma maior interação com o cliente, os requisitos mudam periodicamente.
Mudança de requisitos = retrabalho, se a opção é automação dos testes, tenham certeza que o requisito não vai mais mudar, é aconselhável que aguarde um ou duas releases sem alteração naquela user story que deseja ser automatizada.
Algumas avaliações são devem ser sugeridas na escolha da utilização de uma ferramenta de automação de testes, como por exemplo o famoso ROI (Return of Investment), seria apenas o fato de colocar no papel se realmente vale a pena a utilização desta. Quanto tempo de projeto seria necessário para que a utilização da ferramenta valesse a pena em relação ao uso dos testes manuais?
Muitos fatores devem ser avaliados, é bom tomar cuidado com a lenda da automação dos testes, não é simplesmente clicar uma dúzia de botões, gerar um script e apertar para rodar ele assim que o sistema for entregue, muita calma nessa hora..!

O valor da certificação de Testes de Software

2008-12-02T03:41:00.000-08:00

Profissionais de Testes de Software e Qualidade ao redor do mundo estão procurando maneiras de melhorar sua credibilidade dentro das suas empresas e nas comunidades de software. A opção mais lógica é a certificação nos programas nacionais ou internacionais disponíveis. Entretanto, existem algumas questões, ou dúvidas, em relação ao valor da certificação. Recrutadores nas empresas ficam frustrados quando contratam testers certificados ou profissionais de qualidade e descobrem que estes não são capazes de executar as atividades mais básicas no seu trabalho. Essa é a causa pela qual alguns recrutadores e organizações questionam o valor de uma certificação.
Pensa-se que todos nós concordamos que qualquer programa de certificação mente na sua habilidade de satisfazer necessidades profissionais diversas e interesses para certos contextos mas melhoram a maneira pela qual eles executam suas atividades num dia comum de trabalho.
Para entender o motivo pelo qual as certificações recebem uma série de revisões, devem entender que são essenciais duas maneiras para obter certificações: baseado em provas e em educação (por meio de faculdades, cursos técnicos, etc.)
(fonte: http://www.testinginstitute.com/value.php)

Bom, esse artigo foi meramente traduzido de sua fonte, mas me faz pensar a respeito do real valor da certificação de Software Testing dentre a comunidade de Software. Na minha opinião, passar numa prova não significa que o profissional está preparado parar encarar um mercado cheio de diversidades, mesmo porque as certificações sugerem métodos extremamente formais que, se fossem aplicados, aumentaria significativamente o budget de um projeto.
Visto esse fator, cliente nenhum faz questão de ter uma equipe de testes trabalhando no projeto, levando em consideração que o valor do projeto pode aumentar em até 50%. Todavia, o cliente quer que seu projeto seja entregue "sem bugs"! Vai entender...

Validar é importante, mas não exclusivo!

2008-11-26T15:08:00.000-08:00

Quando os casos de teste são escritos a partir de casos de uso (e afins) na criação de um plano de testes deve ser levado em consideração que, pelo menos, todos os fluxos do sistema estejam cobertos. Esses são os casos de teste chamados de Testes de Validação. Na prática esses testes são aqueles fluxos que o desenvolvedor fez todas as gambiarras possíveis para deixá-lo funcionando. Um desenvolvedor deve estar odiando esse tipo de comentário, apesar de concordar. Não estou menosprezando a profissão e nem tenho motivos para isso todavia com o prazo apertado, é complicado fazer um código de qualidade seguindo todos aqueles patterns sugeridos no mercado.
Levando em consideração esse fator, o tester geralmente aparece como vilão da história e ouvimos comentários do tipo: "estava funcionando até ele por a mão no sistema", é claro que essa é uma visão pessimista da situação pois todos nós sabemos que a figura do tester vem para agregar valor ao produto final da empresa, não é?
Você, tester, quer mais um motivo para ser "odiado"? Comece a "validar" os fluxos do desenvolvedor ao contrário, faça exatamente aquilo que ele provavelmente não iria querer que fosse feito. Quando a primeira pessoa teve essa idéia, deu-se origem aos Testes Negativos.
"Negative test cases are designed to test the software in ways it was not intended to be used, and should be a part of your testing effort." Em outras palavras, Testes Negativos são aqueles que fazem o que a aplicação não está prevista para fazer e devem fazer parte do seu esforço de teste. Por exemplo, digamos que um Analista de Testes previu que levaria em torno de 15 minutos para cada Test Case de todas as Test Suites ser executado, fazendo a conta básica de Tester/h. Deve-se prever também a dedicação da equipe a algumas horas executando Testes Negativos.
Quando se começa a estudar Software Testing é natural as pessoas se prenderem às regras, é uma área cheia de metodologias, técnicas e métodos. Apesar de tudo isso, as chamadas técnicas de "Error Guessing" são ainda muito bem vindas, e isto é, nada mais nada menos, que navegar no sistema em busca de falhas comuns a todas as aplicações, baseado na experiência do profissional.
Formalmente falando, o "testa aí" é apenas um "aplique uma técnica de error guessing", muitas técnicas e métodos foram formalizados por necessidade. Toda atividade aplicada ao sistema com intenção de achar erros na fase de execução é necessária e bem vinda, portanto, se a fase de execução terminou antes, "brinque" no sistema, seu cliente agradece!

In English now, why not?

2008-11-23T05:56:00.000-08:00

Bom, como vivemos num mundo globalizado, a informação deve chegar a todos os cantos de todas as maneiras, então resolvi criar uma versão em inglês do meu Blog, procurando atender o público internacional também.
http://luizgustavovieira.blogspot.com/
Boa parte da minha experiência profissional foi lidando com o público estrangeiro, gente dos EUA, México, Índia, Austrália, etc.
Nessa versão em inglês do Blog procurarei escrever as mesmas matérias, basicamente traduzindo-as, então não terá nada de muito diferente, só a língua. A não ser que alguns assuntos sejam somente relacionados à cultura local. É trabalhoso mas vou procurar mantê-los ambos atualizados.

Evitando o "testa aí"

2008-11-21T15:12:00.000-08:00

Depois de meses de treinamento, estudando complexas metodologias, tirando as certificações mais conceituadas do mercado, somos contratados por uma empresa que não possui os padrões de testes definidos e eles desejam começar a investir numa equipe de testes. Bom, é interessante a empresa ter essa visão: a necessidade de um time que cuide da conformidade do sistema com o que foi previamente definido, dentre outros aspectos que devem ser levados em consideração quando se opta em ter uma equipe de testes.
O problema é que é natural (não por ignorância mas por desconhecimento) ouvir a famosíssima frase: “já fiz o deploy, agora testa aí.” É importante que não só a equipe de desenvolvimento, bem como todos os envolvidos no projeto tenham conhecimento de como um processo de teste bem definido deve funcionar. Esses dias ouvi o absurdo: “não vejo nexo em termos um profissional em testes, hoje já existem programas que fazem isso automaticamente”, pode até ser que exista programas como o JUnit que apliquem os testes unitários e é interessante que estes também sejam aplicados. Mas não adianta de nada JUnit quando o cliente pede X e é entregue Y funcionando perfeitamente...
Ah! Já que o programa acha os defeitos sozinho, roda ele ai no Windows e manda achar os bugs e ninguém mais reclama dele! Perfeito! Sabe-se que não, as empresas devem aderir à cultura de testes, bem como as faculdades deveriam ter pelo menos uma matéria dedicada ao Teste de Software, pois esse assunto geralmente é citado como um tópico dentro da Engenharia de Software, quando citado.
É importante ressaltar que o JUnit e outras ferramentas são responsáveis pelos chamados Testes Unitários, que é apenas um artefato para ressaltar que o desenvolvedor teve sua tarefa entregue, sendo estes apenas uma fase em todo o processo formal de Software Testing, antecedido por toda a fase de revisão do escopo de análise, análise de ambigüidades, seguido das fases de Integração, Sistema, Aceitação, Regressão, etc.
Quer dar início a uma equipe de testes na sua empresa? Aí então vai uma dica: procure entender como funciona, para assim saber o que solicitar e o que fornecer a um analista de testes. Primeiramente é importante entender que o teste não deve ser uma etapa no desenvolvimento e sim um processo, uma equipe, um projeto e/ou uma organização a parte, quiçá vendido separadamente do resto do desenvolvimento.
Quando eu digo que todos os envolvidos no projeto devem entender de testes, são todos mesmo, inclusive o cliente. Deve ser entendido que quando existe um fator chamado prazo e custo, é natural que algumas funcionalidades do sistema não tenham sido cobertas, não por incompetência e sim por falta de tempo, por exemplo. Nesse caso não são apenas testes de validação que farão sentido, apesar de já serem um bom começo...

Blogging kick-off!

2008-11-21T10:13:00.000-08:00

Pessoal, possuo certificação CTFL do ISTQB tenho mais de 3 anos de experiência na área de Software Testing, sendo exatos 2 anos e 11 meses em projetos off-shore para empresas como General Motors, Carrefour, MERS e outros grandes e consideráveis clientes. Em toda minha experiência sempre procurei estar presente em todas as fases, desde a revisão do escopo de análise até a parte de User Acceptance e todas as áreas, como testes manuais, automatizados e de performance.

Há pouco mais de 3 anos eu não sabia que me apaixonaria pela área de Software Testing como sou hoje e por esse motivo procuro sempre estar atualizado das tendências de mercado e fazer o melhor que posso enquanto trabalho. Por esse motivo, acabei obtendo uma visão mais crítica de toda situação na qual estou inserido, seja relacionado a Software Testing ou não.