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

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).

 

 

 

Categories: Whatever, Conceitos

Post a Comment

Oops!

Oops, you forgot something.

Oops!

The words you entered did not match the given text. Please try again.

Already a member? Sign In

0 Comments