Arquivo da tag: TI

BVT – Saiba como é o teste de BVT e entenda a sua importância.

O teste de BVT (Build Validation Test) sempre é realizado quando existe uma atualização no código do sistema e será introduzido no ambiente atual.
Esta atualização pode ter sido feita pelo motivo da chegada de uma nova funcionalidade para testes ou até correção de defeitos, para que assim a equipe de teste possa realizar os retestes dos defeitos em abertos.

O intuito do teste de BVT é testar toda a funcionalidade do sistema e podemos definir o escopo de acordo com a necessidade, tempo disponível, etc pois em sistemas de grande porte esta validação poderá durar um dia inteiro ou até mais. Geralmente as verificações são feitas com a maioria dos cenários positivos, com uma atenção maior nas funcionalidades que geram mais impacto, onde houveram a atualização do código e correção do defeito.

Para a execução destes testes geralmente não utilizamos nenhuma ferramenta e não há necessidade de coletar as evidências para tudo o que for validado, mas sim quando um defeito for encontrado.
Para o auxílio do testes, pode ser utilizado uma lista com todas as funcionalidades contendo os itens mais importantes.
Quando um defeito é encontrado é muito importante verificar a criticidade e qual o impacto que ele irá gerar, seja tanto na funcionalidade quanto para a execução dos testes que estão por vir após a BVT.
Quando são encontrados vários defeitos de grande impacto, a melhor decisão é não autorizar o deploy e continuar com o ambiente atual sem a atualização deste novo código.

Com assim, não autorizar nova build?

Isso mesmo, imagine uma situação em que a equipe de testes possui uma grande quantidade de Casos de Testes ainda para executar e a build que está validando possui um defeito que impacta diretamente com os testes e caso a equipe autorize a atualização do ambiente irá impactar e atrasar a execução dos Casos de Testes pendentes.

Mesmo que a equipe fique sem o novo código que liberariam alguns defeitos, ela pode continuar com os testes ainda pendente. Nesta situação será mais vantagem continuar como está do que liberar uns defeitos para reteste.
Porém esta regra vale para o outro lado. Muitas vezes é interessante liberar uma build mesmo que possua um ou mais defeitos encontrados na validação, para isso deve-se avaliar a criticidade dos mesmos e se a build irá liberar mais Casos de Testes do que impactar.

Até agora estamos falando quando encontramos um defeito ou não, agora imagine que a build possui um defeito grave e infelizmente ele não foi descoberto? Isso pode acontecer e com certeza o dano será maior! Então nem preciso falar o quão importante este teste é e que ele deve ser verificado com muita atenção pela equipe de testes.

Por fim, terminada a validação devemos analisar e decidir o que deverá ser feito. Caso a build seja aprovada, basta aguardar o deploy e mão na massa ; )

Abraços!

Vini Sabadoti

Anúncios

Carreiras em TI – Testador de Jogos

Olá pessoal!

Este é mais um post para falarmos sobre carreira! Vamos falar sobre testes, porém sobre testes em Jogos eletrônicos!

Primeiramente gostaria de agradecer ao Bruno Cicanci do blog Game Developer (http://gamedeveloper.com.br/blog/) por ter me passado o contato de um profissional da área, o que permitiu que eu fizesse a entrevista!

O segundo agradecimento é ao Ronaldo Coimbra que dedicou um tempinho e paciência para responder algumas perguntas.

Atualmente Ronaldo é QA Lead e Preload Content Manager na GLU Mobile do Brasil.

Vamos ao que interessa! Segue abaixo a entrevista:

1. Como você entrou na área de testes de jogos? 

No terceiro semestre da faculdade de Jogos Digitais (Unisinos – São Leopoldo), começei a procurar mais sobre as oportunidades de carreira na área de jogos. Depois de um tempo, você percebe que existem duas grandes portas de entrada: QA (quality assurance – tester) e programação. Apesar da minha faculdade dar ênfase à programação, sempre tive mais interesse em design e acabei optando por entrar como QA mesmo, pra entender mais sobre os jogos e o processo de certificação (aprovação) desses jogos. O que fiz, então, foi avaliar empresas brasileiras que mais se encaixassem com meu perfil e mandei currículos (fui muito seletivo e mandei para umas 4 empresas apenas). Ter um bom portfólio e saber se relacionar e tratar bem outras pessoas faz uma grande diferença na hora de conseguir um emprego. Acabei vindo para São Paulo, onde havia mais ofertas na área e empresas mais bem estruturadas e fui escolhido para trabalhar na GLU Mobile como tester. A empresa chegou a me chamar para ser programador, mas realmente não houve interesse de minha parte.

2. Como é a diferença entre testar um Software e um Jogo? 


O primeiro passo aqui é diferenciar um software comum de um jogo. A primeira diferença é a subjetividade que está presente nos jogos. Você não tem um objetivo bem definido de armazenar e manipular dados (seja um banco de dados ou um programa de arte como photoshop). O objetivo varia com o jogo que deve envolver o usuário psicologicamente ao promover um desafio, geralmente atrelado a uma história e mecânicas de jogo (usabilidade e interatividade) que variam bastante de jogo pra jogo. Então, a primeira diferença é que um teste de jogo não só precisa passar por testes padrões que sejam aplicáveis a qualquer software, mas também por testes subjetivos que são exclusivos de cada jogo pra verificar quão divertido, desafiador e acessível está o jogo.
Outra grande diferença é que jogos são softwares que abrangem uma série de áreas diferentes de conhecimento. Enquanto a maioria dos softwares são especializados em determinadas tarefas, jogos visam um público de massa e equilibram uma série de conhecimentos num só aplicativo: arte, programação, design, música, roteiro, direção, marketing, hardware… Isso significa que o tester precisa ser mais versátil e avaliar o produto sob várias perspectivas. A grosso modo, um software de música precisa agradar músicos. Um jogo precisa agradar músicos, professores, cientistas, crianças, velhos… Enfim, o objetivo é promover lazer para quem tiver interesse.

3. Vocês seguem alguma metodologia para realizar os testes nos jogos? 

Sim. Não posso entrar muito em detalhes porque existem regras de proteção dentro da empresa onde trabalho com relação a isso, mas basicamente, o jogo passa por uma avaliação subjetiva intensa e, quando está aprovado nesse quesito, passa por avaliações padrões de software. Todos os procedimentos são estruturados em planilhas de testes que são constantemente atualizadas usando informações que são coletadas ao longo dos projetos. Existem diversas ferramentas que são utilizadas também, com os mais diferentes objetivos: Ferramenta de distribuição de testes, ferramenta de armazenamento de informações, ferramenta de emulação de software, ferramenta que analisa hardwares (lembrando que minha empresa trabalha com jogos para celulares e por isso precisamos entender cada aparelho – hardwares diferentes – tamanho de tela, memória, processamento, media player, etc).

4. Que tipo de testes são realizados em um jogo? Exemplo: Verificar cores, colisões, etc 

Primeiro, a análise subjetiva analisa diversão, grau de desafio e acessibilidade. Cada jogo tem sua própria metodologia, pois cada jogo é único.
Em segundo, é feita uma análise mais básica de software: instalação, usabilidade/interatividade, aparência, som, interrupção (quando alguém recebe uma ligação no meio do jogo, por exemplo), testes específicos relacionados às especificações dos aparelhos.

Enquanto isso tudo ocorre, a equipe de Marketing está sempre atenta em relação a nichos de mercado, oportunidades e capacidade de vendas. Apesar disso não ser um teste em si, se for determinado que o jogo não vai vender, ele provavelmente vai ser cancelado ou às vezes será deixado “on hold” (em espera), dependendo em que etapa do processo esteja.

5. Para qual plataforma de jogos você prefere realizar os testes? (Mobile, Web, Console, etc). 

Eu particularmente não tenho muita preferência na hora de testar (se o assunto fosse desenvolvimento e não testes, minha opinião seria bem diferente). Cada um tem suas especificidades mas, no fundo, todos acabam sendo interessantes e divertidos. Algo que muda muito de uma plataforma pra outra é a quantidade de testers necessária. Um jogo de console geralmente precisa de vários e vários testers e ainda assim, algumas empresas fazem os chamados “open betas” onde usuários interessados nos jogos podem experimentá-los desde que dêem feedbacks e reportem bugs para a empresa. Mobiles geralmente são jogos mais simples que usam de 2 a 5 testers por jogo. Web… bom, temos empresas que nem tem testers e isso fica por conta dos próprios programadores.
Outra diferença é que, como jogos para consoles são mais demorados e grandes em termos de ambiente e mecânicas, cada tester geralmente fica focado num aspecto específico ou num momento específico do jogo. Já Web e mobile, os testers geralmente passam por todo o jogo. Vale citar que as diferenças entre Consoles e Mobiles vem diminuindo, com lançamentos como Iphone e Android. Jogos mobile estão ficando mais acessíveis, rendendo muito dinheiro e tendo possibilidades de se transformar em big hits, devido à melhoria na tecnologia mobile. Há pouco tempo atrás, jogávamos snake (aquele jogo da cobra que tem que pegar os pontos ou frutas na tela). Hoje, já temos jogos em 3D e com física.

6. Qual é o defeito que vocês mais encontram quando realizam os testes em um jogo? 

Certamente é interrupção. A GLU faz jogos para mais de 400 aparelhos. Fazer um jogo para cada celular seria impossível, então geralmente agrupamos devices parecidos que usam uma “build” em comum. Build é uma versão especial do jogo preparada para funcionar em determinado grupo de aparelhos. Cada celular tem sua forma de manipular eventos no aparelho (como receber uma ligação no meio da execução de um aplicativo), então apesar dessa estratégia de grupos dar bem certo em relação a memória, tamanho de tela, som, etc, acaba deixando a desejar na parte de interrupção.

7. Quais são os requisitos para quem deseja começar a trabalhar na área? 
Essa é a parte boa da história! Você só precisa ter boas características pessoais: Vontade, garra, boa comunicação, pró-atividade, disposição, entre outras. E, claro, existem algumas coisas que são bonus: jogar bastante, ter uma formação na área, saber programar, ter experiência com testes… Acontece muito da empresa estar em busca de novos talentos e convocar pessoas nas próprias universidades e, para medir o potencial dos candidatos, usamos algumas técnicas e dinâmicas em grupo. Muita gente tem medo de dinâmicas de grupo mas, como tester, você precisa no mínimo reportar bugs para os programadores. Saber conversar, dialogar, mostrar sua opinião e aceitar a opinião dos outros é totalmente necessário em uma equipe e ponto final.

Resumindo, funciona da seguinte maneira: Processos, nomes e ferramentas, a empresa ensina. Já educação, pró-atividade, empenho e disposição, a empresa precisa muito, pode ajudar a conseguir, mas não tem como ensinar do zero 😉

Pessoal, espero que vocês tenham gostado assim quanto eu! Aproveito para agradecer novamente ao Bruno e ao Ronaldo!

Abraços!


Aplicando a Técnica 5W1H no processo de abertura de defeitos

Aplicando a técnica 5W1H em abertura de defeitos.

Semana passada participei de uma pequena reunião com a minha líder do projeto, onde ela apresentou a técnica 5W1H e discutiu sobre o processo de abertura de defeitos. Ela nos apresentou uma técnica que surgiu na área de qualidade que pode ser aproveitada em nosso dia-a-dia e achei interessante compartilhar neste artigo.
Primeiramente vamos ver um pouco sobre a importância de abrir um defeito com qualidade e em seguida sobre a técnica 5W1H e como podemos utilizá-la no processo de abertura de defeitos.

A importância de especificar um defeito com qualidade.

De nada adianta o testador realizar um bom teste e na hora de reportar um defeito para o programador não o fazer com eficiência. O defeito a ser aberto deve ser claro e possuir informações realmente necessárias.
Quando o defeito é objetivo e claro, a equipe ganha tempo e evita desgastes desnecessários, pois o defeito é validado com facilidade pela pessoa responsável e é enviado ao programador que compreende logo o defeito e trabalha na solução.
A maneira da escrita do defeito varia de cada profissional e acaba sendo em minha opinião uma espécie de identidade do testador. Identidade? Sim! Pois ao longo do trabalho o programador/gerente de defeito vai conhecendo o trabalho do testador que ao ler a descrição do defeito sabe quem o reportou.
Por outro lado, mesmo que cada um possua sua “identidade” nos defeitos, existem itens essenciais que não podem faltar na descrição do mesmo e para isso podemos utilizar a técnica 5W1H.

A Técnica 5W1H:

Esta técnica é muito conhecida na área de qualidade, marketing, TI, entre outras. O 5W1H ajuda na investigação do problema e com as informações obtidas com as 6 perguntas básicas, oferece uma respota clara e objetiva. Com esta técnica podemos adaptá-la com o processo de abertura de defeitos.

Ela é composta por seis simples perguntas:

What: O que?
When: Quando?
Who: Quem?
Why: Porque?
Where: Onde?
How: Como?

Agora vamos pensar na visão da abertura de um defeito e fazer estas simples perguntas:

What: Qual?

Qual é o problema que aconteceu no sistema?
O que ocorreu?

Ex: Sistema não realiza a venda do produto.

When: Quando?

Quando isto ocorre?
Quando não ocorre?
Este problema já vinha acontecendo?

Ex: Quando o sistema possui muitos produtos no pedido do cliente.

Who: Quem?

Quem é impactado?

Ex: Usuários que possuem um cadastro recente. Usuários finais, etc.

Why? Porque?

Porque o problema ocorre?
Porque deve ser resolvido logo?

Ex: Este problema ocorreu porque era uma grande quantidade de produtos

Where: Onde?

Onde ocorreu o problema?
Qual link/funcionalidade do sistema que ocorreu?
Qual ambiente/hardware?

Ex: Problema ocorreu no aplicativo móbile de celular.

How? Como?

Como aconteceu?
Como chegou a este problema?

Desta maneira, podemos utilizar estas perguntas para nos auxiliar a compor um defeito, tornando-o claro para o desenvolvedor:

Exemplo prático:

Severidade do defeito: 2

Headline:
Usuário final não efetua compra de uma grande quantidade de produtos através do software para móbile.

Descrição:

1. Acessar o aplicativo InfoLoja do Iphone e realizar o login com os seguintes usuários:
Login: vinisabadoti
Senha: as78dj098k
2. Preencher o carrinho de compras com mais de 5 produtos e fechar o pedido.
3. Informar os dados do pagamento com cartão de crédito e confirmar compra.

Resultado esperado: Sistema exibe mensagem da confirmação do pedido informando o número do pedido para futura consulta.

Resultado obtido: Sistema não confirma a compra e direciona o usuário para página inicial.

Verificar passo nº X da evidência em anexo.

Como no exemplo citado acima, fica muito fácil para a pessoa que irá validar o defeito entender e juntamente com uma evidência em anexo, comprova com imagens que o defeito foi encontrado conforme os passos descritos.
Desta maneira, quando o defeito foi validado e chega ao desenvolvedor, ele poderá entender facilmente o defeito. Claro que não são em todos os defeitos que é possível aplicar todas estas perguntas, porém podemos analisar quais se encaixam para reportá-los com maior qualidade.

Espero que tenham gostado e que esta técnica possa ajudar a vocês de alguma maneira, ajudando assim a fazer um trabalho com qualidade.
Afinal, não adianta exigir qualidade do software que testamos se em nosso próprio dia-a-dia não aplicamos qualidade no serviço em que fazemos.
Gostaria de agradecer a Lyamara Bonvechio pelo conhecimento transmitido e por deixar eu escrever um pouco sobre a técnica e compartilhar ela aqui no blog!

Caso queiram saber mais sobre a técnica, segue abaixo alguns links interessantes:

http://nccur.lib.nccu.edu.tw/bitstream/140.119/35210/7/35602807.pdf
http://www.mindmapinspiration.com/using-5w-1h-as-a-90-10-solution-finder/
http://www.canallmarketing.com/uploads/2/7/7/6/2776543/5w1h.pdf


Histórico sobre Testes de Software

Olá pessoal!

Este post faz parte da minha monografia que foi entregue no semestre passado em minha faculdade. Espero que gostem deste artigo, pois não foi fácil fazer!

Durante as pesquisas para a elaboração deste trabalho acadêmico, não foi encontrado nenhum material que descreva claramente o início e a evolução da área de Testes de software. Pode ser que exista algum material, porém em pesquisas feitas em sites especializados, blogs, e consulta a vários profissionais da área, não foi encontrado nenhum artigo que tratasse sobre o assunto. Portanto, este histórico foi criado com uma consulta e resumo de alguns fatos marcantes com uma atenção ao cenário nacional.

Para começar a falar sobre testes, podemos citar sobre a origem do termo bug, que inicialmente não surgiu com os softwares. O termo bug quer dizer inseto, porém na área de informática ele ganhou outro significado, pois quando ocorria um erro de programação, o termo bug era utilizado.

Thomas Edison teve problemas de leitura em seu fonógrafo com um inseto em 1878 e em todos os defeitos industriais passou a denominá-los como bug. Já o primeiro bug em computadores foi encontrado em 1947, os engenheiros que trabalhavam com a máquina Harvard Mark I, encontraram um inseto nos circuitos. Este inseto estava causando um erro nos cálculos da máquina. Ao ser encontrado, o inseto foi retirado e colado no livro de registro com a intenção de registrá-lo como o primeiro bug encontrado.

Com o livro “The art of software testing” Glenford Myers trouxe ao leitor um conhecimento mais avançado sobre testes, abordando sobre as técnicas de software no ano de 1979.

Este livro é muito conhecido pelos profissionais, podendo ser tratado como uma referência teórica, com o ano de 1979 um grande passo para a área. O livro possui uma coletânea de materiais sobre testes de software. Atualmente este livro se encontra em sua 2ª edição e é utilizado até os dias de hoje, onde muitos o consideram como o marco inicial de Testes de Software.

Os modelos prescritivos de desenvolvimento de software surgiram na década de 80. Estes modelos, cascata, espiral, entre outros foram criados para organizar e inserir padrões no processo de desenvolvimento de software. Ele é composto por vários processos genéricos: comunicação, planejamento, modelagem, construção e implantação.

Dentro do processo construção, estão presentes as atividades de desenvolvimento e testes. Foi a partir desta organização que o conceito de testes de softwares tornou-se mais conhecido. Vale lembrar que testes também está presente em outros processos, como planejamento, modelagem e implantação.
Neste ano, surgiram também as primeiras ferramentas para o auxílio de testes funcionais. Com seu sucesso, surgiram novas ferramentas para gerenciamento de testes com a intenção de organizar, manter dados, resultados e apresentar relatórios.

Sendo assim, em 1990 os fornecedores passaram a integrar em uma suíte única, ferramentas para testes funcionais e de gerenciamento.
A partir do ano de 1995 surgiram as primeiras ferramentas para automação de testes de performance para algumas plataformas.
No ano de 2002, surgiu no Brasil a Associação Latino Americana de Teste de Software (ALATS).

A ALATS é uma entidade sem fins lucrativos que foi criada com a finalidade de reunir profissionais das áreas de teste e de qualidade de sistemas com o intuito de servir de apoio a troca constante de informações objetivando a melhoria dos processos de teste, mantendo-se a sua integração como o processo de desenvolvimento de aplicações. (ALATS).

Atualmente a ALATS promove palestras, encontros mensais e seminários. Dentre os eventos, o mais conhecido é o Seminário Brasileiro de Teste de Software (BRATESTE). Este seminário abrange assuntos como processos de testes, técnicas, palestras e tutoriais.

Os profissionais brasileiros podem contar também com instituições internacionais que atuam no país, como o International Software Testing Qualifications Board (ISTQB) fundado em Edinburgh (Reino Unido) em novembro de 2002. O ISTQB chegou ao Brasil em 2006 com o nome de Brazilian Software Testing Qualifications Board (BSTQB). O BSTQB oferece o exame de certificação do ISTQB, treinamentos e download do material em português.

A primeira certificação brasileira de testes foi criada pela ALATS e no ano de 2006 surgiram os primeiros profissionais certificados com a Certificação Brasileira de Testes de Software (CBTS).
Atualmente podemos encontrar uma grande quantidade de certificações, ferramentas e conteúdo sobre testes de software. Livros, blogs, listas de discussões, são alguns exemplos de conteúdos que podem ser facilmente encontrado.

Antes de citar minhas fontes, gostaria de agradecer a algumas pessoas que de alguma forma me ajudaram dando dicas, opiniões ou ao menos se prontificaram a ajudar: Carolina Fontana, Fabrício Ferrari, Camilo Ribeiro, Fernanda Thiesen e Marcelli Barbosa

Abaixo, uma imagem para ilustrar resumidamente os fatos da área:

Fontes:

http://qualidadebr.wordpress.com/2008/06/22/o-que-e-bug/

http://myoldmac.net/FAQ/firstComputerBug.htm

http://blog.prasabermais.com/2010/02/15/histrico-da-evoluo-das-ferramentas-para-testes-e-qualidade-de-software/

http://istqb.dedicated.adaptavist.com/display/ISTQB/Brazilian+Software+Testing+Qualifications+Board+%28BSTQB%29

http://istqb.dedicated.adaptavist.com/display/ISTQB/History?atl_token=XcZn9CV4Ee

Livro Engenharia de Software de Roger S. Pressman.


Pesquisa para trabalho de TCC

Pessoal, atualmente estou em meu último ano de faculdade de Sistemas de Informação e estou desenvolvendo meu trabalho de conclusão de curso na área de Testes de Software. Gostaria de contar com a ajuda das pessoas que trabalham em empresas de desenvolvimento que respondam este pequeno questionário que criei no google docs.

A minha intenção é saber destas empresas quais possuem uma equipe de testes, quais tipos de testes aplicam, etc.

[ 21/08 – com a pesquisa concluída o link foi removido]

Desde já agradeço a ajuda!


Carreiras em TI – Testes de Software III

Pessoal estou postando mais uma entrevista com uma profissional na área de testes de software. O que mais gosto destas entrevistas é que cada profissional tem algo diferente e interessante para contar de experiência. Outro motivo é que um dos termos mais pesquisados que aparece no wordpress é este, portanto acho legal compartilhar mais este assunto.

A entrevista é com a Marcelli, minha amiga que trabalhou comigo no projeto do Santander e que me ajudou com os testes em Mainframe.

1. Como você conheceu e se interessou por testes?

Não conhecia a área de testes até entrar na IBM (Fevereiro de 2006). Eu imaginava que as empresas testavam seus produtos (softwares) mas não tinha noção de quão organizado e estruturado eram esses testes. Me interessei rapidamente por esta área, pois envolve muito a parte de análise, requisitos, leitura de documentos, que eram as áreas que já me chamavam atenção.

2. Quais as atividades de um profissional que trabalha nesta área?
São muitas. Resumindo, para um analista de teste:

• Ler, ler, ler e ler os requisitos do sistema. É o documento principal para seus casos de testes. Não assuma nada, tire todas suas dúvidas com o responsável pelo requisito. E leia também qualquer outra documentação do projeto que possa ajudar no entendimento da nova funcionalidade.
• Com base no que você leu, planeje os cenários de teste, pense na pré e pós condição, resultados esperados, dados específicos etc.
• Crie os casos de teste, e escreva o passo a passo. Vale ressaltar que o passo a passo deve ser escrito não só para você, ou seja, todos precisam entender e conseguir seguir o roteiro feito por você.
• Envie seus casos de teste para revisão e aprovação do cliente quando necessário. E analise as alterações sugeridas pelo mesmos.
• Quando o ambiente de teste estiver liberado, inicie a execução. Tire evidência dos passos de seu caso de teste, e quando o resultado obtido for diferente do resultado esperado, reporte este defeito e reteste assim que corrigido.

Paralelo a todos os itens acima, mantenha a ferramenta de testes que você utiliza atualizada com seus resultados.
Bom, acima é só um resumo de algumas das atividades de um analista de teste, porém dentro da área de Teste de uma empresa, temos vários cargos. Por exemplo, se você for um Líder de Testes terá que acompanhar e coordenar as atividades citadas acima, se for um Analista de teste de performance terá outras atividades adicionais etc..

3. Para trabalhar com testes é necessário saber sobre outras áreas?

É necessário ter um conhecimento de Lógica, raciocínio lógico para criar as situações de teste necessárias, e dependendo da aplicação que você for testar é necessário alguns skills específicos, como por exemplo: Mainframe, SQL etc.

4. Qual foi o defeito mais difícil que você encontrou?

Não me lembro de um em específico, mas defeitos que envolvem processamento batch, jobs em geral que passam dados de um sistema para o outro etc.

5. Alguma vez alguém já falou para você que testar não é preciso?

Os desenvolvedores hahahaha. Brincadeira, nunca ouvi isso diretamente, mas várias vezes já ouvi dos desenvolvedores: “Eu já testei e está tuuuudoo certo”.

6. Quais são os tipos de testes mais complicados?

Mainframe – batch, que eu já testei…mais complicado pois sempre envolve problemas de acesso, precisa ter um skill específico para acessar os diretórios etc. Performance parece ser complicado também, mas não conheço.

7. Dicas para quem está começando (materiais/links/etc).

Fazer um curso de inglês pois a maioria das empresas colocam como pré requisito;
– Para aprender sobre testes o livro BASE DE CONHECIMENTO EM TESTE DE SOFTWARE é muito bom;
– Ter concentração, pois precisamos ler vários documentos, e ter um bom raciocício lógico;
– Estudar algumas ferramentas de teste (Rational por exemplo) pode ser um diferencial;
– Fiz um estudo para minha monografia sobre Testes, especificamente sobre MAPEAR CASOS DE USO EM CASOS DE TESTE, quem tiver interesse sobre o assunto pode me contactar.

Obrigado Marcelli pela colaboração! Muito boa a descrição da atividade de um analista de testes, com certeza dá uma boa idéia sobre o papel deste profissional.

Para quem tiver o interesse em ver a monografia dela ou quer alguma ajuda, pode entrar em contato que ela irá responder com todo prazer: marcellitb@hotmail.com

Abraços a todos.

Vinicius Sabadoti


Testes de software e a razão de testar.

Resumo: Neste artigo irei abordar o conceito de testes de software, sua importância e o motivo de testar softwares. Realmente você poderá encontrar muitos artigos tratando deste assunto, porém convido ao leitor a ler o artigo sobre a minha visão referente ao assunto.

Quando converso com alguém para falar que atuo na área de testes de software percebo que na maioria das vezes as pessoas possuem uma visão básica da área. Simplesmente dizer que trabalho com testes de software não é uma tarefa simples de testar para ver se o software está funcionando corretamente.

Na minha opinião a principal atividade é encontrar erros, porém com a atividade de ao encontrarmos erros há várias consequências  positivas.

Quando um defeito é encontrado e corrigido consequentemente a qualidade do sistema aumenta, portanto aumenta sua segurança e confiabilidade, reduzindo os riscos. Se um defeito é encontrado em fase de levantamento de requisitos podemos dizer que o risco é menor do que encontrado em fase de desenvolvimento e o custo também (saiba mais deste conceito pesquisando sobre a Regra 10 Myers).

Imagine a seguinte situação:  A equipe do projeto passa pelo ciclo de vida inicial do projeto e com o levantamento de requisitos do sistema concluído. Os desenvolvedores começam a criar o sistema, porém não está de acordo com o que o cliente pediu e realmente necessita. Ao encontrar este defeito em fase de produção pode acarretar uma grande parte do tempo para solucionar o problema e consequentemente irá afetar o cronograma do projeto.  Acreditem podem haver casos em que sejam necessário começar tudo do zero e caso aconteça como fica o tempo gasto e o custo da equipe? Com certeza o custo do projeto será maior.

Há várias técnicas para realizar os testes para garantir a qualidade do sistema,  duas técnicas bem conhecidas são: testes de caixa preta e testes de caixa branca. Resumindo, testes de caixa preta são os testes afim de verificar a funcionalidade de um sistema,realizando testes práticos no sistema, interagindo o Tester com o sitema. Os testes de caixa branca são voltados para a estrutura interna do sistema, por exemplo, validar se uma variável está declarada corretamente, um laço de repetição e prosseguindo para testes mais complexos. Geralmente os testes de caixa branca são executados pelo próprio programador.

A equipe de testes pode contar com uma grande variedade de softwares para auxiliar nos testes. São softwares que auxiliam desde o planejamento, modelagem até a execução dos testes.

As atividades são divididas entre os cargos presentes na área de testes, onde cada profissional exerce uma função dentro da equipe. Para saber mais sobre sobre as atividades do profisisonal de testes confira meu outro artigo clicando aqui.

Espero que com este artigo vocês possam ter um conhecimento maior sobre a área de testes, os benefícios e sua importância. Caso possuam alguma dúvida sintam-se a vontade para perguntar, responderei com prazer.

Abraços e até a próxima!

Vinicius Sabadoti.