Click here to edit title

Click here to edit subtitle

Blog

Pequenos Projetos Grandes Desafios - parte 2

Posted by JJ on February 9, 2013 at 2:45 PM Comments comments (0)

Bom pessoal, demora demais para postar a 2° parte da situação "PPGD - Pequenos Projetos Grandes Desafios".

Muitos projetos na empresa que trabalho, sem interneta na empresa(meu Deus fomos bloqueados, agora vamos trabalhar em regime semi aberto, na hora do almoço ta liberado!), correria total com a Copa TI(vide: Copa TI Site)... Vamos ao que interessa.

Lembra do nosso time?


Neste capitulo vamos conversar com o programador, saber mais sobre as regras possiveis que testaremos no sistema. Porque conversar com ele sobre as regras do sistema? Muita das vezes o que acontece no dia a dia é isso. Os Programadores sabem mais das regras do sistema do que o nosso Grande Gerente Trakinas. E estas regras ficam 'obscuras' nos projetos, pois não são colocadas em documento nenhum, ficam apenas na cabecinha do nosso Programador.

 

Vamos apresentar hoje o Programador Troll.

 

Programer Troll

 

 

Vamos primeiramente, fazer amizade com nosso Programador Troll, pois ele adora trollar os Analistas de Testes e Testadores. Sejamos amigos dele! Lembre-mos-os que estamos no mesmo time e que ele não nos precisa Trollar, pois afinal de conta, precisamos entregar o mesmo projeto. Entregar o produto final para o cliente. E que se o barco afunda, cai todo mundo.

 

Programador Troll

 

O tipico programdor Troll é aquele que não ta nem ai com a usabilidade do sistema, que nunca ouviu falar em valores limites e muita das vezes é o sujeito começou com 16 anos fazendo um '.batzinho' pra trollar os amigo da escola, depois fez uns sitezin em php, ai foi trabalhar de programador na empresa do tio, mas que se formou em veterinária, hoje depois de 10 anos de programador, programa em java, .net, pyton, ruby e defende que a área não tenha um conselho regional, que pra programar não precisa fazer 5 anos de Computação na Faculdade e muito menos ta nem ai com os testes, pois ("Pra que eu vou testar? Tem o tester" Troll, Programer. 2013/02).

Ou seja? O cara que se formou para mecher com animais, não sabe que o verdadeiro animal muita das vezes é ele. (Trollando o programador mode off)

 

 

 

Depois das devidas apresentações. O que devemos fazer?

 

Bom vou passar um poquinho do que eu tento fazer que é, dividir minhas atividades dos projetos em fases, processos.

Quais são os possiveis processos, tanto Tradicionais quanto Àgeis?

 

Tradicionais

- Levantamento do Projeto de Testes
- Criação do Plano de Testes
- Levantamento de Casos de Testes
- Especificação de Casos de Testes
- Execução de Casos de Testes
- Entrega Final


Àgeis

- Levantamento de Atividades de Testes
- Levantamento do que é Automatizavel e do que Manual
- Levantamento de Idéias de Testes
- Especificação de Estórias(postits com as idéias de testes resumidas)
- Entrega do Product Backlog

 

Então o que fariamos agora?

Já sabemos o que o projeto é, sabemos também algumas regras que o Gerente nos passou, vamos então conversar com o programador, encontrar o que seria o ambiente, levantar mais regras e após isto definir o caminho que seguiremos dentro das 40 horas deste projetinho. Dado que, já gastamos 2h no repasse, das 12h que tinhamos para o 'Plano de testes'

 

Na conversa com o Programador descobrimos que:

Vamos exemplificar com um projeto de Video Locadora.

O sistema de cadastro, terá cadastros para filmes novos e diferenciação para alterações de cadastros, dos filmes antigos que foram descartados e vendidos. Sim o sistema permitirá vendas de filmes antigos.


No capitulo anterior descobrimos que o sistema tem 2 perfis. Um de administrador e outro de Usuário.
O administrador realiza os cadastros, e o usuário utiliza os cadastros já predefinidos para trabalhar com o sistema.

Ou seja: Já descobrimos várias formas para o sistema ter erros, listemos elas e já passamos ao programador:

 

 

Entre outras possíveis falhas que o sistema apresentaria, você já poderia entregar anotado ao programador, para que futuramente, o sistema não traga essas falhas. E principalmente otimizar nosso tempo de testes, pois erros como estes, atrasam todo projeto de software.

 

 

Bom, espero que tenha ajudado neste capitulo. E também espero possa postar mais vezes hehehe.

No próximo capitulo veremos dicas sobre como montar o plano de testes e/ou levantar testes automatizados ou manuais.

 

Até mais!

 

 

1° Grande dica: Anote os possíveis erros que você encontrou no repasse e acredita que o sistema traria depois de desenvolvido, e já passe para o programador anotado até em uma folha de caderno(é mais simples e funcional, o progrador só da um check).

 

 

 

Pequenos Projetos Grandes Desafios

Posted by JJ on January 25, 2013 at 7:25 AM Comments comments (3)

Meus caros, chegou até mim, por meio de vários e vários pedidos de uma pessoa só.

Que falasse um pouquinho sobre o curso de Testes Ágeis da Qualister, ministrado pelo Cristiano Caetano(O Grande!).

 

Meu grande querido Frederico Alan, que descobri na ultima semana o quão mais top conhecedor de Testes de Software ele é, me pediu que fizesse um post sobre Testes Ágeis em Fabrica de Software, e sim, se espantem, eu tenho idéias sobre isso. Descorramos...

 

Bom, inicialmente não falarei neste post, porém, vou adiantar e explicar algumas coisas.

Vejam só, eu, tu, ele, nós, vós, eles, todos temos uma equipe no minimo assim em algum projeto de software:


 

 

 

 

Esses dai serão os personagens deste blog e sempres serão citados.

Vou falar hoje sobre esse carinha ai do meio. O Gerente do Projeto.

O Gerente Trakinas.



 

Vamos descobrir quem é o Gerente Trakinas.

 

Gerente Trakinas, geralmente é o sujeito mais 'animado', comunicativo, 'lider'(vide: conceito de capataz). Mas a maior qualidade é: Ele consegue planejar um projeto que necessita de 500 horas de Trabalho, caber em 50.(Não seria um Juscelino Kubitschek dos Projetos?)


Heheh, não estou aqui para falar do estilo Gerente, pois conheço, vários e vários Gerentes, uns bons, uns ótimos e outros. O que trago a vocês aqui é o querido Gerente Trakinas.




 

 


Veja só o que o Gerente Trakinas nos trouxe dessa vez.

 - Meu querido TESTER. O projeto é o seguinte:

 

 

Momento 1 O REPASSE:

Vamos fazer um sistema para Arbitros de Futsal de um campeonato para empresas. Este sistema, será utilizado pelo mesário e terá as seguintes funcionalidades:

Nosso sistema terá uma tela de login que poderemos acessar com 2 perfis, Administrador ou Mesário

Administrador:

- Terá um cadastro de Time (Nome, Empresa, Responsável)

- Terá um cadastro de Jogadores (Nome, número, jogo, data do jogo, gols, cartão amarelo, cartão vermelho, suspenso)


Mesário

- Terá um cadastro de Jogo (Sumula)(Time A, Time B, Placar Final Time A, Placar Final Time B, Placar Primeiro Tempo Time A, Placar Primeiro Tempo Time B, Placar Segundo Tempo Time A, Placar Segundo Tempo Time B, Placar Penalts Time A, Placar Penalts Time B, Pedido de Tempo 1° Tempo Time A, Pedido de Tempo 1° Tempo Time B, Pedido de Tempo 2° Tempo Time A, Pedido de Tempo 2° Tempo Time B, Horário Inicio, Horário Final, Tempo do gol, Número do jogador que fez o gol, time do jogador que fez o gol, gol contra, tempo do Cartão amarelo, número do jogador cartão amarelo, time do jogador cartão amarelo, tempo do Cartão vermelho, número do jogador cartão vermelho, time do jogador cartão vermelho, anotações)

 

Regras

- Ao preencher o nome do time nos campos 'Time A' ou 'Time B', o sistema já preencherá automaticamente com o nome dos jogadores.

- Caso exista algum jogador Suspenso, o nome do atleta virá em negrito e na cor vermelha.

- O mesário, poderá preencher antes do inicio do jogo os números do jogador

- O mesario, poderá preencher durante o jogo, os campos Cartão, os campos de gol, campos de horários e anotações da partida

- Ao final do jogo. O mesário gera um pdf com a sumula e imprime, para pegar assinatura dos capitães.

 

Você nós precisamos entregar esse sistema o mais rápido possível. Você tem 12 horas para o Plano de Testes e 28 horas para testar o sistema.

 

E agora? o que fazemos? Sentamos e choramos?


Não né! Não queremos conversar com o RH.

Bora pra mão na massa?

Vamos tentar mesclar, fazer um HIBRIDOZINHO, do método ágil com os métodos tradicionais(Nosso Gerente Trakinas, precisa de artefatos)

 

Nota: a documentação que tem do sistema é este repasse. Ta lindo né? descrevi tudo, hauehuaehueau. Não, lógico que não, tem um monte de buraco nisso ai, vamos para o próximo capitulo?

O que fazermos agora?

O que podemos usar de tradicional?
O que podemos usar de ágil?
Vamos tentar primeiramente falar em Testes Ágeis, não necessário falar de desenvolvimento ágil. O que nos ajuda a otimizar nosso tempo nestas 40 horas?

Digam ai o que vocês fariam e no próximo capitulo respondo esta questão.

Conceito sobre Testes

Posted by JJ on January 22, 2013 at 1:00 PM Comments comments (5)

Uma coisa que sempre me incomodou quando participei de discussões e até entrevistas de emprego, foi o conceito um tanto quanto errado sobre Testes.

 

O que são os testes? Para que serve teste? Por que testar? Defina testes.

 

Vamos ver algumas definições bibliograficas:

 "O objetivo principal do processo de teste é simplismente encontrar o maior número possível de defeitos no software." Base de Conhecimento em testes de software - CBTS

"Processo que consiste em todas as atividades do ciclo de vida, tanto estáticas quanto dinâmicas, voltadas para o planejamento, preparação e avaliação de produtos de software e produtos de trabalho relacionados a fim de determinar se elas satisfazem os requisitos especificados e demonstrar que estão aptas para sua finalidade e para a detecção de defeitos." Glossário de Termos ISTQB


 "O teste do software é a investigação do software a fim de fornecer informações sobre sua qualidade em relação ao contexto em que ele deve operar. Isso inclui o processo de utilizar o produto para encontrar seus defeitos. O teste é um processo realizado pelo testador de software, que permeia outros processos da engenharia de software, e que envolve ações que vão do levantamento de requisitos até a execução do teste propriamente dito." Wikipédia

 

Para muitas pessoas, se resume a isto:

'utilizar o produto para encontrar seus defeitos'

'O objetivo principal de teste é simplismente encontrar o maior número possível de defeitos no software'

 

Para mim se resume e eu respondo da mesma forma as questões:

O que são os testes? - São um conjunto de metodos e técnicas para validar se o produto é o que foi especificado(solicitado)

Para que serve teste? - Os testes servem para validar se o produto é o que foi especificado(solicitado)

Por que testar? - Porque é necessário validar se o produto é o que foi especificado(solicitado)

Defina testes - É validar se o produto é o que foi especificado(solicitado)


Estou errado? Não.

Errado está em quem define Testes em Encontrar Bugs.


Mas encontrar bug não é um objetivo dos testes? SIM. UM DOS OBJETIVOS. Não O objetivo. Pois o testador pode 'desenvolver' o software sem achar bugs, apontando melhorias, melhorando processos, melhorando a qualidade com que se é utilizado o software.


Este conceito é a mesma coisa que debilitar o testador. Ou no mínimo seta-lo como um 'Escovador de bugs'. Lembram do termo 'Escovador de Bits'?

 

"Escovador de bit é uma gíria usada com referência às pessoas que se dedicam a alterar o modo de funcionamento de um sistema de computação através de alterações no seu software" Wikipédia.

 
Pois então não podemos definir um desenvolvedor por aquele que só trabalha focado no código estrutural em si.


Escovador de Bugs.

"O objetivo principal do processo de teste é simplismente encontrar o maior número possível de defeitos no software." Base de Conhecimento em testes de software

 

Então pessoas que defendem esta idéia, vocês tem o direito de continuar com ela. Mas, por favor pessoal que querem entrar nesse mundo novo e 'lindo'! Entendam o conceito de Testes e principalmente o que é Qualidade de Software!

 

Abraços