Papéis no Scrum

24 de novembro de 2011 Deixe um comentário

Este post descreve os papéis empregados na metodologia e serve como complemento ao post anterior sobre o Teste de Software no Scrum.

PAPÉIS NO SCRUM

Os papéis no Scrum determinam as atribuições de responsabilidades de cada membro do time. No total, eles são três: Scrum Master, Product Owner e Time. Por isso, esta seção tem-se o objetivo de descrever cada um deles detalhadamente.

PRODUCT OWNER

O Product Owner (PO) pode ser o dono do projeto ou um procurador que represente o cliente. Suas funções principais são:

a)     Defender os interesses do cliente;

b)     Ajudar a criar, manter e priorizar a lista de tarefas do projeto;

c)     Auxiliar na definição das metas do Time para cada Sprint;

d)     Responder pela parte financeira do produto.

É importante resaltar que quando o Time Scrum analisa a priorização dos itens do Product Backlog e se compromete a finalizá-los durante o Sprint o PO se compromete em não criar ou mudar os requisitos. Uma vez que isso só é permitido fora do Sprint.

Para exercer o papel do PO, são necessárias algumas caracteristicas como: conhecer bem o negócio, ter capacidade de se comunicar de forma clara e objetiva, ter tempo e disponibilidade para acompanhar o projeto e se possível, possuir alguma experiência com desenvolvimento de software.

SCRUM TEAM

O Scrum Team (ST) representa as pessoas responsáveis pelo execução das tarefas do projeto de software. Suas funções principais são:

a)     Auxiliar nas definições de estimativas de tempo;

b)     Ajudar na priorização dos itens do Sprint;

c)     Definir os esforços de implemtação dos itens do Sprint;

d)     Determinar o objetivo do Sprint;

e)     Desenvolver o produto propriamente dito.

Segundo alguns autores, o recomendado é que o Time seja pequeno e possua de cinco a nove componentes, com características multidisciplinares necessárias para entregar o projeto utilizável a cada ciclo. Outros autores diminuem esse limite e sugerem que o Time seja composto por no máximo 7 componentes. Independente do tamanho da Time, o importante é destacar que no Scum não existem rótulos tais como: gerente, coordenador, analista entre outros. Pois, todos os componentes são membros do mesmo Time e trabalham com um objetivo comum, cumprir as metas do Sprint e entregar software funcionando e com qualidade.

SCRUM MASTER

O Scrum Master pode ser considerado o líder do Time Scrum conforme. Pois suas funções prinicpais são:

a)     Proteger o Time de influências externas;

b)     Garantir o Time de desenvolvimento seja produtivo;

c)     Perceber e resolver problemas internos entre o Time;

d)     Auxiliar o PO no processo de condução dos requisitos;

e)     Identificar, priorizar e remover impedimentos para a conclusão dos trabalhos;

f)      Conduzir as reuniões diárias (Daily Scrum Meetings), de revisão de atividade (Sprint Reviews) e de planejamento (Sprint Planning);

g)     Gerenciar e repassar todo o trabalho que foi definido na reunião de Sprint;

h)     Assegurar que a metodologia está sendo seguida.

Para executar todas essas funções é importante que SM seja um profundo conhecedor do Scrum e que consiga contagiar toda a equipe com boas práticas. Por isso, algumas das características de um bom SM são:  ser responsável, humilde, colaborativo, comprometido, influente e entendido.

Finalizamos por aqui. No próximo post pretendemos explicar um pouco mais sobre a metodologia e fornecer novos complementos ao post sobre o Teste de Software no Scrum.

Anúncios
Categorias:Scrum

Teste de software

23 de novembro de 2011 Deixe um comentário

TESTE DE SOFTWARE

Este post  além de ser uma homenagem ao nome do blog rsrs, também aborda de forma conceitual o que é teste de software, suas técnicas e as fases mais utilizadas.

O QUE É TESTE DE SOFTWARE?

Segundo a Wikipédia o teste de software é uma investigação do software a fim de fornecer informações sobre sua qualidade em relação ao contexto que se deve operar. Isso inclui o processo de utilizar o sistema a fim de econtrar defeitos. Essa atividade é realizada por um profissional chamado de Analista de Teste. Ele tem a responsabilidade de acompanhar outros processos da Engenharia de Software, que envolve desde o levantamento de requisitos até a execução do teste propriamente dito.

VISÃO GERAL

Os projetos de software podem ser de complexidade exorbitante. Nesses casos, é quase inviável e impossível eliminar todos os defeitos. Isso se deve, algumas vezes, a quantidade de pessoas alocadas ou a complexidade dos algoritmos que requerem uma quantidade impraticável de possibilidades.

Os defeitos presentes no sistema são acarretados por vários motivos. Por exemplo, uma especificação funcional ou implementação de alguma funcionalidade incompleta e errada entre outros. Assim, um defeito é caracterizado pelo comportamento indevido de alguma parte do projeto de software.

O teste de software visa eliminar a maior quantidade possível de defeitos contribuindo com uma parcela importante no processo de qualidade do projeto de software. Segundo a ISO 9126 são atributos qualitativos de funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade.

Um projeto de software com qualidade normalmente é construído de forma organizada baseando-se em uma métodologia de desenvolvimento como Scrum entre outras. A união da metodologia com as técnicas de teste, além de fornecer meios sólidos de minimizar os defeitos, também possibilita produzir software de forma eficaz.

TÉCNICAS DE TESTE

As técnicas de teste são maneiras previamente conhecidas e muito utilizadas na engenharia de software para fazer uma investigação no sistema a fim de encontrar suas falhas. A seguir serão detalhadas as mais conhecidas:

a) Caixa branca

A técnica de caixa branca avalia o software de maneira estrutural. Ela é aplicada diretamente sobre o código fonte do programa, testando o mesmo de maneira lógica e comportamental. Ela também analisa os caminhos mais longos, o fluxo de dados e códigos que nunca são usados, sendo recomendada para as fases de teste unitário e de integração cuja a responsabilidade principal fica para o desenvolvedor que conhece bem o código fonte desenvolvido.

b) Caixa preta

A técnica de caixa preta avalia o software conforme as entradas e saidas. Ela é aplicada externamente no software sem considerar o funcionamento interno do mesmo. Para isso, dados de entrada são fornecidos ao sistema que os processa e devolve uma saída previamente conhecida pelo testador. Os resultados são comparados para validar a efetividade da funcinalidade testada. Este tipo de técnica é baseada na especificação funcional e é recomendada para todas as fases de teste: teste unitário, teste de integração, teste de sistema e teste de aceitação.

c) Regressão

A técnica de regressão avalia o software perante a todos os testes já realizados nele. Ela é aplicada a cada nova versão do sistema e tem objetivo de indentificar impactos de alterações pela nova versão. Em sistemas maiores, para esse tipo de técnica é recomendada a utilização de ferramentas de automação. Uma vez que, a cada nova versão, pode se executar os testes das versões anteriores com maior rapidez.

d) Técnicas não funcionais

As técnicas não funcionais avaliam o software sem levar em consideração os aspectos funcionais da especificação de requisitos. Ela é aplicada no sistema com a finalidade de criticá-lo sobre situações inesperadas. Como exemplo, robustez do software em relação a uma grande quantidade de dados ou o desempenho do mesmo.

FASES DE TESTE

O ato de testar o software está ligado ao fato de dizer que um determinado requisito ou funcionalidade está pronto. Por isso, o Analista de Teste pode atuar em diversas fases do desenvolvimento. Um exemplo mais comum é no final do processo, quando um requisito termina de ser desenvolvido e um grupo de pessoas verifica se tudo está conforme o esperado. No entanto, como dito no início deste post, essa realidade pode ser diferente. Pois, o teste de software pode estar inserido desde o levantamento de requisitos até o teste propriamente dito. E para acompanhar a maioria dessas etapas, existem as principais fases de teste que serão detalhadas a seguir:

a) Teste de unidade

O teste de unidade também conhecido como teste unitário avalia a menor unidade de código desenvolvido. Normalmente uma classe, método ou função. O objetivo desse tipo de teste e verificar falhas de funcionamento do sistema em uma pequena parte independente do todo.

b) Teste de integração

O teste de integração avalia a união de diferentes componentes do software que foram desenvolvidos separadamente, mas que trabalham em conjunto. Esse tipo de de teste tem o objetivo de encontrar falhas de funcionamento relativo aos resultados esperados por um dos componentes.

c) Teste de sistema

O teste de sistema avalia o software da pespectiva do cliente. Ele é executado em um ambiente semelhante ao dos objetivos originais e tem a finalidade de varrer o sistema em busca de novas falhas que não foram localizadas em outras fases de teste.

d) Teste de aceitação

O teste de aceitação avalia o software em alguns clientes especificos. Ele tem o objetivo de garantir perante ao comprador, usuário ou a outra parte interessada que o sistema que foi desenvolvido é justamente o que foi solicitado.

CONSIDERAÇÕES SOBRE O POST

Tendo em vista que os conceitos estudados sobre teste de software, fornecem um arcabolso para o desenvolvimento de software de qualidade. No próximo post, será abordado o teste de software no Scum. Uma metodologia Ágil de muito destaque no Brasil.

Categorias:Teste Software

Teste de Software no Scrum

30 de setembro de 2011 1 comentário

1.          TESTE DE SOFTWARE NO SCRUM  X  METODOLOGIA EM CASCATA

No modelo tradicional em cascata, os times são divididos por áreas. Cada uma delas representa uma função distinta e não existe integração entre as mesmas. No Scrum não existe esta divisão pois, todas as equipes – Desenvolvimento, Teste, Negócios entre outras – trabalham juntas e fazem parte de um mesmo grupo. Essa união permite facilidade na comunicação, gerando um ambiente de parceria e um verdadeiro espírito de equipe na empresa. Desta forma, a área de teste não é vista por outras áreas como uma rival, mas sim como uma parceira (FERREIRA; RAMOS; LAGARES, 2010). Delesposte (2011) destaca todos juntos realizamos mais.

Com o conceito de que as equipes são vistas como um único time no Scrum, a definição do que está pronto, pode ser diferente entre elas, pois um determinado item pode estar pronto para uma e não para outra. Um item pronto pode ser:

– Codificação + Teste concluído

– Codificação + Teste + Integração concluída

– Codificação + Teste + Integração + Regressão concluída

– Codificação + Teste + Integração + Regressão + Instalação Concluída.

Além da definição de item pronto entre as equipes, vale lembrar que para cada item ela pode ser diferente, dependendo do que é proposto. Por isso, em Scrum é necessário que o time decrete quando um item vai estar realmente pronto e que este conceito evolua sempre.

1.1         ANALISTA DE TESTE NO TIME SCRUM

Relacionando Scrum aos métodos tradicionais, existe lugar para o analista de teste em um processo ágil? Sim, existe. O que faz a diferença é o time e o Analista de teste faz parte do time.

Em Scrum o Analista de Teste assume várias responsabilidades, como por exemplo: Líder, Arquiteto e Automatizador. Por isso, é necessário que ele possua diversas habilidades, incluindo conhecimento de programação, para que em cada fase do projeto ele “coloque o seu chapéu”.

No processo de levantamento de requisitos e definição do escopo o Analista de Teste participa com o “chapéu de líder de teste”.  Nessa etapa

o Product Owner (PO) define a visão do produto. Está visão é o que representa sua necessidade, é o que deve ser satisfeito até o fim do projeto. Para definir está visão o PO colhe informações junto a clientes, usuários final, time, gerentes, stakeholders, executivos entre outros.

O Analista de Teste colabora com o PO na fase de definição da visão do produto com a participação nas reuniões com o cliente para levantamento de requisito, com a participação das reuniões de Brainstorming, com a manutenção do foco na qualidade do produto, com a revisão e abordagem dos testes, com a identificação das habilidades de teste necessárias para o projeto entre outros.

Com a definição da visão do produto pronta, o PO e o Scrum Master (SM) utilizam de técnicas que visam o benefício relativo, financeiro entre outros para criar uma lista das necessidades que precisem ser produzidas para que a visão seja bem sucedida. Essa lista é chamada de Product Backlog (PB) e os itens dela são chamados de User Stories (US). As User stories são descrições simples que representam uma funcionalidade do produto.

No início do projeto o PB não precisa estar completo. Pode-se começar com o conceito de Minimum Viable Product (MVP) que é o conjunto mínimo do que deve ser implementado para testar se o produto será rentável, ou seja, tudo aquilo que é mais óbvio em um primeiro momento. Com o tempo, o PO cresce e muda à medida que se aprende mais sobre o produto e seus usuários. Nessa etapa o Analista de Teste participa com o “chapéu” de líder de testes auxiliando para que as US sejam independentes, negociáveis, valiosas, estimáveis, pequenas e principalmente testáveis. Para alcançar os resultados anteriores, segundo Ferreira, Ramos e Lagares (2010) são realizadas algumas tarefas, como:

• Participar das discussões de definição de arquitetura;

• Participar das definições de tecnologias utilizadas;

• Identificar as necessidades do ambiente de teste;

• Identifica restrições tecnológicas;

• Identifica ferramentas de teste necessárias para auxiliar na execução do projeto;

• Utilizar mapa mental (Mind Map) para auxiliar no entendimento das funcionalidades/requisitos;

• Identificar os “melhores” analistas de teste para o projeto em questão;

• Identificar a necessidade de suporte do time de suporte/operações.

• Estimar o tempo de teste.

Continua em breve.

Estamos reunindo mais informações a respeito do assunto para dar continuação ao post atual.

 

REFERENCIAS

FERREIA, Renata Eliza Pinto; RAMOS, Sibele Esteves; LAGARES, Vivian Cristina. Srcum no Teste deSoftware: 2010. Trabalho de conclusão de curso. (MBA em Teste de Software) – Centro Universitário Euroamericano, Belo Horizonte, 2010.

QUEZADA, Gustavo. Papel do “Time de teste” em projetos Scrum. In: Encontro do SPIN, XXXVII, 2009, Campinas.

SATO, Danilo. Uso eficaz de métricas em métodos ágeis de desenvolvimento de software: 2007. Dissertação. (Mestrado em Ciência da Informação) – Instituto de Matemática e Estatística da Universidade de São Paulo, São Paulo, 2007.

Categorias:Scrum, Teste Software

Trabalhando com banco de dados – Introdução

18 de agosto de 2011 7 comentários

Introdução

O TestComplete permite trabalhar com diversas fontes externas de dados, como arquivos de texto, banco de dados etc.

Para se conectar com bancos de dados, o TestComplete possui mecanismos de conexão, como ADO (ActiveX Data Object) e BDE (Borland Database Engine). Não iremos entrar em detalhes sobre o BDE, pois, o ADO é um mecanismo abrangente e permite que o TestComplete manipule a maioria dos bancos de dados existentes. Existem duas implementações para acessar bases de dados via ADO. Uma utiliza métodos nativos Microsoft e a outra utiliza métodos da Borland.

Microsoft

– CreateCommand;
– CreateConnection.

Borland

– CreateADOCommand;
– CreateADOConnection;
– CreateADODataSet;
– CreateADOQuery;
– CreateADOStoredProc;
– CreateADOTable.
Construindo um exemplo de acesso a dados no TestComplete

A seguir iremos implementar no TestComplete um exemplo de acesso a banco de dados.

Ambiente que foi utilizado para a construção do exemplo:

– Sistema operacional Windows 7 ultimate 64 bits;
– TestComplete 7.20.562.7;
– Firebird 2.1.

Partindo do presuposto que o leitor dispõe de um ambiente similar ao descrito acima, vamos abrir o TestComplete e por a mão-na-massa.

Crie uma Suite e um projeto teste. Quem ainda não sabe como fazer isso, pode consultar o post anterior (Aprendendo TestComplete – Introdução). Adicione um novo script e escreva o seguinte código:

procedure ConsultaBancoDados;
var
  ComandoSQL, CaminhoBanco, StringConexao: String;
  Query : OleVariant;
begin
  CaminhoBanco := 'C:\BANCO.FDB';
  StringConexao := 'Driver=Firebird/InterBase(r) driver;Uid=SYSDBA;
     Pwd=masterkey; DbName=' + CaminhoBanco;      

  ComandoSQL := 'SELECT' +
                    ' CODIGO,' +
                    ' NOME,' +
                    ' TELEFONE' +
                ' FROM' +
                    ' CLIENTES';     

  Query := ADO.CreateADOQuery();
  Query.ConnectionString := StringConexao;
  Query.SQL := ComandoSQL;
  Query.Open;
  Query.First;
  while not aqConvert.VarToBool(Query.EOF) do begin
    Log.Message(Query.FieldByName('NOME').Value, Query.FieldByName('CODIGO').Value);
    Query.Next;
  end;
  Query.Close
end;

Entendo o script

Em nosso exemplo, foi utilizado um banco de dados do Firebird com o nome de BANCO que possui apenas uma tabela de CLIENTES com os campos: CODIGO, NOME E TELEFONE.

– A variável CaminhoBanco recebe o caminho complete do banco de dados, incluindo seu nome e extensão.

– A variável StringConexao recebe uma String de conexão para acesso a bases de dados Firebird que funciona sobre o driver ODBC.

– A variável ComandoSQL recebe o comando SQL que se deseja aplicar sobre o banco de dados, em nosso exemplo foi realizada uma consulta.

– A variável Query é o nosso motor. Ela é instanciada com o mecamismo ADO de acesso a dados, recebe a StringConexao e o ComandoSQL. O comando Open abre uma nova conexão com o banco e realiza a consulta trazendo todos os registros que satisfazem a condição escrita no SQL. First posiciona um apontador para o primeiro registro do resultado da consulta.

– Por fim, um laço de repetição passa por todos os registros armazenando o valor do campo NOME no log do TestComplete. Após todos os registros serem percorridos, o comando Close finaliza a conexão com o banco.

Como dito anteriormente, a string de conexão funciona sobre o driver ODBC, portanto, um dos pré-requisitos é a instalação desse driver que pode ser obtido atráves do link. A instalação é fácil, Next, Next e Finish.

Finalizamos aqui a implementação do nosso exemplo.

Conclusão

O objetivo desse post é dar uma base de como se trabalhar com banco de dados no TestComplete. Agora cabe a cada um adaptar essa implementação e realizar melhorias para tirar o máximo de proveito no teste de software.

Espero que tenham gostado, qualquer dúvida deixe um cometário.

Abraço!

Aprendendo TestComplete – Introdução

18 de julho de 2011 6 comentários

-> TestComplete

Ferramenta completa de gerenciamento e criação de testes que possibilita a escrita de testes funcionais, testes automatizados, testes unitários entre outros.

Vamos parar por aqui os detalhes do TestComplete e deixar a curiosidade germinar na mente, pois, nos próximos posts será falado a fundo sobre essa ferramenta fabulosa.

-> Iniciando (preparando o terreno)

Para o estudo será utilizado o TestComplete versão 7.20.562.7 e um aplicativo piloto desenvolvido em Delphi que pode ser baixado no link a seguir.

Para começar a entender o ambiente do TestComplete, iniciaremos criando a Suíte de Teste.

-> Suíte de teste

A Suíte de teste representa um container para a organização de grupos de testes relacionados que podem ser planejados e gerenciados.

-> Criando uma Suíte de teste no Test Complete

Para criar a Suíte acesse o menu File -> New -> New Project Suíte, informe o nome da Suíte, a localização e clique no botão Ok. Seguindo esses passos, a Suíte é criada com sucesso.

-> Projeto de teste

Uma Suíte de teste pode ser composta por um ou vários projetos de testes. Os projetos de testes comportam os scripts de teste, casos de teste entre outros. Introduzir vários projetos de teste em uma mesma Suíte teste no primeiro instante pode parecer confuso, no entanto, imagine vários projetos de teste que podem ou não estar relacionados. Esses projetos podem ter funcionalidades similares a serem testadas e um deles pode possuir casos de testes prontos que podem ser reaproveitados em outros projetos.

Para criar um projeto de teste, semelhante a criação da Suíte de teste, acesse o menu File – > New -> New Project, informe o nome do projeto, a linguagem utilizada para a escrita dos scripts, a localização do projeto e clique o botão Create. Seguindo esses passos, o projeto de teste é criado com sucesso com o template padrão do Test Complete.

Continua…