Para determinados tipos de sistemas a preparação de massa de dados é uma das etapas que mais pode consumir esforços e recursos e certamente define a qualidade dos testes funcionais.
Se você é o responsável por esta importante etapa dos testes, veja as dicas abaixo:
Leia mais …
As primeiras ferramentas de testes de software surgiram por volta de 1980 e eram focadas em testes funcionais. Eram também baseadas em atividades que eram extensão de debuging do software.
Após essas ferramentas ganharem popularidade, surgiram as ferramentas de gerenciamento de testes que tinham como propósito organizar e manter dados e comandos de testes, organizarem o resultado da execução dos testes, e apresentar relatórios de testes.
Por volta de 1990 os fornecedores passaram a integrar numa suite única ferramentas para testes funcionais e de gerenciamento de testes. Já em 1995 surgiram as primeiras ferramentas para automação de testes de performance que inicialmente eram focadas em medições básicas para algumas plataformas. Posteriormente foram abrangendo diversas plataformas com medições mais complexas de performance.
A Sociedade Brasileira de Computação (SBC), organizou um catálogo nacional dos cursos de computação, que está disponível em https://www.sbc.org.br/cnc/.
Neste site pode-se fazer pesquisas por instituição, que estão classificadas em públicas ou privadas, ou fazer pesquisas por nome do curso por estados da federação, sendo que os cursos estão classificados em diversos níveis, como graduação, especialização, mestrado, etc, e categorizados como gratuítos ou pagos.
Ao longo dos anos tenho estudado e praticado a modelagem de software com UML. Participei de vários foruns de discussão, li vários artigos acadêmicos, artigos do Gartner Group, medotologias como o RUP e livros. Muitos livros.
E como acredito que a teoria na prática é diferente, pratiquei muito do que estudei sobre modelagem seja no desenvolvimento de novos sistemas ou na manutenção de sistemas existentes. Os resultados? Nem sempre animadores…
Geralmente chegava ao final da modelagem com pressão sobre o prazo de entrega do projeto, e a pergunta que sempre ouvia era: quanto do código já está pronto? Eu ainda não tinha código pronto, “apenas” os modelos. E dá-lhe pressão de prazos…
Para os estudandes, praticantes e demais interessados no tema “Teste de Software”, aqui vai relação de livros e sites para consultas:
Bibliográficas
Paton, Ron. Software Testing. Sams Publishing. 2005.
H. Kan, Stephen. Metrics and Models in Software Quality Engineering. Second Edition. Addison Wesley. 2002
D. Everett, Gerald. McLeod Jr, Raymond. Software Testing Testing Across the Entire Software Development Life Cycle. IEEE Press. 2007
Eduardo Delamaro, Marcio. Carlos Maldonado, José. Jino, Mario. Introdução ao Teste de Software. Campus. 2007.
A. Menascé, Daniel. A.F.Almeida, Virgilio. Planejamento de Capacidade para Serviços na Web. Campus. 2003.
U.Smith, Connie. G. Williams, Lloyd. Performance Solutions A Practical Guide to Creating Responsive, Scalable Software. Addison-Wesley. 2002
Um dos grandes desafios do desenvolvimento de um bom software, certamente está em se ter um processo consistente para se capturar as necessidades do cliente, traduzí-las em requisitos e a partir daí definir os casos de uso. A partir deste ponto, como chegar ao início da codificação?
Elaborei um mapa conceitual do que entendo ser uma abordagem prática de análise e projeto de software, contemplando os seguintes artefatos:
Com essa abordagem creio que se obtém um modelo de análise e projeto consistente para o início da codificação. Veja o mapa conceitual dessa abordagem na figura abaixo. O que você acha a respeito dessa abordagem?
Escrever casos de uso parece coisa simples, mas ao não se concentrar nos princípios fundamentais que orientam a elaboração de um bom caso de uso, acaba-se cometendo erros. Conheça os sete erros mais comuns:
1. Escrever requisitos funcionais em vez de cenários de utilização
Os casos de uso são escritos em termos sobre o que o sistema deve fazer. Cenários de uso descrevem ações dos usuários e as respostas obtidas do sistema.
É importante que o texto do caso de uso permita claramente identificar como o sistema realizará um determinado comportamento. Deve-se manter uma clara distinção entre as descrições das ações (voz ativa) e os requisitos funcionais (voz passiva)
Exemplos:
Caso de uso: Editar conteúdo do carrinho de compras
(incorreto) – Fluxo Básico – Se o cliente modificar a quantidade de um item no carrinho de compras, e pressionar o botão de atualização, o sistema irá armazenar a nova quantidade, e exibir a novo custo para o item selecionado.
(correto) – Fluxo Básico – Na página do carrinho de compras, o cliente modifica a quantidade de um item e então pressiona o botão atualizar. O sistema armazena a nova quantidade e exibe o novo custo para o item selecionado.
2. Descrever atributos e métodos em vez de cenários de uso
Os casos de uso não devem conter muitos detalhes de telas e também estar livres de detalhes de campos de telas. Se você, por exemplo, estiver escrevendo um caso de uso e estiver relacionando vários campos da tela no texto de caso de uso, pare! O objetivo aqui é descrever o que o sistema deverá fazer, e não como será feito.
Exemplos:
Caso de uso: Processar Pedido
(incorreto) O operador do estoque certifica-se que os itens relacionados no pedido conferem com o itens físicos. O operador passa o código de barras na leitora da estação. O sistema executa o método mudança de estado do pedido, para mudar o pedido para o estado de atendido, e então chama o método alterar quantidade em estoque, para cada um dos itens do pedido
(correto) O operador do estoque certifica-se que os itens relacionados no pedido conferem com o itens físicos. O operador passa o código de barras na leitora da estação. O sistema muda o estado do pedido, para atendido, e então atualiza a quantidade em estoque, para cada um dos itens do pedido
3. Escrever casos de uso de forma muito resumida
O objetivo de um caso de uso é descrever todos os detalhes da ação do usuário e da resposta do sistema. É melhor que o texto seja o mais completo possível, do que ser um texto muito resumido que omite esses detalhes
Deve-se lembrar também que os casos de uso servirão para a elaboração do manual do usuário. Assim é melhor pecar por excesso do que por falta de detalhes no manual do usuário.
Exemplos:
Caso de uso: Criar conta do cliente
(incorreto) O cliente entra com a informação solicitada. O sistema valida as informações e cria uma nova conta para o usuário
(correto) O cliente entra com o seu nome, e-mail, e a senha (duas vezes) e então pressiona o botão criar conta. O sistema certifica que o cliente forneceu dados válidos e então cria uma nova conta usando esses dados. O sistema conduz o cliente à página principal do sistema.
4. Desconectar-se completamente da interface do usuário
Um dos fundamentos da notação de casos de uso, é que os desenvolvedores concordem em desenhar o sistema sob o ponto de vista dos usuários. Não é possível praticar isso, sem ser especifico as quais ações serão realizadas pelos usuários nas respectivas telas.
Entretanto não é necessário entrar em detalhes de campos ou detalhes cosméticos sobre a tela (trabalho do protótipo). O importante é citar pontos da interface que permite ao usuário dizer para o sistema fazer algo.
Exemplos:
Caso de uso: Procurar item
(incorreto) O cliente digita o nome do animal e então submete uma requisição de pesquisa. O sistema recupera detalhes importantes sobre cada animal e então exibe uma lista de animais.
(correto) O cliente digita o nome do animal na página de pesquisa e então pressiona o botão procurar. O sistema recupera detalhes importantes sobre cada animal, então o sistema exibe uma lista de animais em página de resultados da pesquisa.
5. Evitar explicitar o nome dos objetos de fronteira
Objetos de fronteira são objetos que os atores irão interagir. Exemplos – janelas, caixa de diálogos, menus, etc. Na diretriz de detalhar a navegação do usuário, é necessário dar nomes aos objetos de fronteira no texto do caso de uso
Os nomes desses objetos serão posteriormente úteis nas próximas fases do desenho do sistema
Exemplos:
Caso de uso: Acompanhar pedidos recentes
(incorreto) O sistema recupera e exibe os pedidos que o cliente solicitou nos últimos 30 dias. O cliente solicita detalhamento de um pedido. O sistema recupera e exibe o conteúdo do pedido, apenas no modo de leitura. O cliente retorna para a lista de pedidos, quando ele finalizou a leitura dos detalhes do seu pedido.
(correto) O sistema recupera e exibe os pedidos que o cliente solicitou nos últimos 30 dias, e exibe esses pedidos na página de acompanhamento de pedidos. Cada registro possui um numero de pedido (em forma de link) O cliente seleciona um link. O sistema recupera e exibe o conteúdo do pedido, apenas no modo de leitura na página de detalhamento do pedido. O cliente pressiona OK e retorna para a página de acompanhamento de pedido.
6. Descrever apenas as interações do usuário e esquecer as respostas do sistema
A narrativa de um caso de uso deve ser orientada por respostas a eventos, ou seja, “O sistema faz isto quando o usuário faz aquilo” O caso de uso deve capturar o que ocorre em decorrência a ação do ator: criação de registros em tabelas, validação de entrada de dados do usuário, mensagens de erros, etc.
O texto do caso de uso deve descrever os dois lados do diálogo entre o ator e o sistema, e todo o comportamento que se está buscando descobrir, ocorre do lado do sistema neste diálogo. Deixar a resposta do sistema de fora, significa ignorar o comportamento do sistema
Exemplos:
Caso de uso: Editar conteúdo do carrinho de compras
(incorreto) Na página do carrinho de compras, o cliente modifica a quantidade de um item do carrinho de compras, e então pressiona o botão de atualização. Então o cliente pressiona o botão de continuar comprando
(correto) Na página do carrinho de compras, o cliente modifica a quantidade de um item do carrinho de compras, e então pressiona o botão de atualização. O sistema armazena a nova quantidade, calcula e exibe o novo custo para tal item. Então o cliente pressiona o botão de continuar comprando.
7.Omitir texto para os fluxos alternativos
Apesar dos fluxos básico serem mais fáceis de se identificar, não significa que se deva deixar de fora os fluxos alternativos. Geralmente os fluxos alternativos importantes só são descobertos na fase de codificação e depuração.
Nesta ocasião, o programador tende a encontrar uma solução que lhe seja mais conveniente, o que não é saudável para o projeto
Exemplos:
Caso de uso: efetuar logon
(incorreto) O cliente entra com a sua identificação e senha, e então o cliente pressiona o botão de log-in. O sistema conduz o cliente para a página inicial.
(correto) O cliente entra com a sua identificação e senha, e então o cliente pressiona o botão de log-in. O sistema valida as informações contra os dados da conta do usuário e então conduz o cliente para a página inicial
A comunidade de software livre tem ao longo dos anos influenciado a indústria de software tradicional, no sentido de forçá-la a oferecer alguma versão dos seus produtos para uso sem custo. Empresas grandes como a IBM já adotaram essa abordagem de ofertar uma versão livre de alguns de seus softwares pagos.
Para a modelagem de software utilizando UML tenho usado para fins acadêmicos o Visual Paradigm Community Edition, que é uma versão sem custo e com algumas limitações em relação à versão paga, como por exemplo, só poder criar um diagrama UML de cada tipo sem que apareça a marca d’água da empresa nos diagramas. Uma outra restrição é a de não ter uma funcionalidade que permita o desenho da interface gráfica (elaboração de protótipos de telas)
Essa versão suporta todos os diagramas da UML 2.1, permite a descrição detalhada de requisitos, análise textual dos requisitos para identificação de classes, análise através de cartões CRC e diversas outras funcionalidades relacionadas à etapa de projeto de software.
O Visual Paradigm Community Edition pode ser obtido a partir do endereço http://www.visual-paradigm.com/product/vpuml/communityedition.jsp
Se é de uma ferramenta para modelagem UML que você procura, vale a pena instalar essa versão e testar suas funcionalidades, antes mesmo se for o caso, de partir para a compra de uma versão paga
Nos últimos anos tenho trabalhado bastante com a utilização da técnica de caso de uso tanto para validação das funcionalidades com o usuário, quanto para apoiar a etapa de análise e projeto do software visando um desenvolvimento orientado a casos de uso e que resulte num conjunto de especificações do software que possa ser construído por um programador.
A questão que trago aqui é a que muitos autores recomendam que a descrição do caso de uso deva ser genérica, independente de tecnologia ocultando assim detalhes de implementação e no extremo da abstração, a descrição fica até desassociada da interface gráfica.
Tenho visto que quando se adota essa abordagem, a descrição do caso de uso acaba tendo pouca utilidade, só servindo muitas vezes para validar as funcionalidades de software com o usuário, e mesmo assim com algumas limitações. Para a etapa de análise onde se deseja identificar as classes, suas propriedades e comportamentos, a descrição do caso de uso se torna abstrata, ambígua e incompleta. Daí decorre um problema: ela não ajuda na análise, não é atualizada e daí em diante a análise e o projeto seguem sem as descrições dos casos de uso. Perde-se portanto um importante instrumento para dirigir a analise o projeto e os testes do software.
Penso que ao decidir orientar o desenvolvimento por casos de uso, e isso é muito forte, as descrições de caso de uso devam sim ser detalhadas, escritas na voz ativa, de forma clara e sem ambigüidades. Deve-se escrever os casos de uso mão só pensando no cliente, mas também como eles irão ser úteis na fase de análise de projeto do software. Não esquecer também que um caso de uso fica bem mais preciso quando escrito a partir de alguns esboços da interface gráfica.
Veja esses dois exemplos para um caso de uso RESERVAR VEÍCULO (para um sistema de locadora de veículos). Qual descrição lhe parece mais adequada tanto para a validação pelo cliente, quanto para orientar a análise, o projeto e o teste do software?
| Exemplo 1 | Exemplo 2 |
|
1.O caso de uso se inicia quando o cliente acessa o site, faz autenticação com seu usuário e senha, e seleciona a opção reservar veículo 2. O sistema solicita ao cliente informar o local, data e horário de retirada e devolução do carro . O cliente indica as datas e locais desejados. 3. O sistema pede para o tipo de veículo que o cliente deseja. O cliente indica o tipo de veículo. 4. O sistema apresenta todos os veículos disponíveis no local data e horário de retirada selecionado. Se o cliente solicitar informações detalhadas sobre um determinado veículo, o sistema apresenta esta informação para o cliente. 5. Se o cliente escolhe um veículo para aluguel, o sistema pede a identificação do cliente. O cliente fornece as informações necessárias. 6. O sistema apresenta informações sobre produtos de proteção e pede ao cliente para aceitar ou recusar cada produto. O cliente indica sua escolha. 7. Se o cliente indica "aceitar reservas", o sistema informa o cliente de que a reserva foi concluída, e apresenta ao cliente uma confirmação de reserva. 8. Este caso de uso termina quando a confirmação da reserva foi apresentado ao cliente. |
1.O cliente seleciona a opção de efetuar reserva O sistema exibe a página de localidade de retirada e entrega e categoria de carro desejado. O cliente seleciona a localidade de retirada (estado, cidade,loja, data e hora) e de entrega (estado, cidade,loja, data e hora) e a categoria de carro (pequeno, médio, grande) e clica no botão enviar. 2.O sistema exibe a página de carros disponíveis e o valor de locação para o modelo selecionado. O cliente faz sua escolha e clica no botão continuar. 3.O sistema exibe a página com as opções de proteção (básico, completo e premium). O cliente visualiza o detalhamento de cada opção, seleciona sua preferência e clica no botão continuar. 4.O sistema exibe a página de identificação do cliente. O cliente se identifica com nome, cpf, e-mail e telefone. 5.O sistema exibe a página de confirmação da reserva, com todos os dados da reserva e solicita confirmação do cliente.O cliente confirma a reserva 6. O sistema finaliza a reserva exibindo uma página com os dados da mesma que podem ser impressa pelo cliente. O sistema envia um e-mail para o cliente com os dados da mesma |
No desenvolvimento de software das grandes empresas as fábricas de software vem desempenhando cada vez mais um papel central. O modelo que se busca e o de delegar a programação para a fábrica e manter o foco das áreas de desenvolvimento na análise do negócio, na especificação do que será construído nos testes e implantação.
Para que um programador possa implementar um código ele necessita de uma boa solicitação, e como ela deve ser ?
Seria apenas um formulário de requisição para a fábrica onde as informações contidas nele não formam uma documentação do software, ou a requisição deve ser a própria documentação de requisito análise e projeto do sistema?
Haverá sempre a tentação de se preencher um formulário rápido e enviá-lo para a fábrica de software, pois elaborar uma documentação adequada de requisitos, análise e projeto dão um bocado de trabalho. Entretanto penso que o melhor seria elaborar uma documentação completa de requisitos e análise e projeto e essa mesma documentação passa a servir a dois propósitos: documentação do software e para envio à fábrica de software
Essa documentação deve certamente conter uma página que oriente claramente o programador sobre o que deverá ser feito para que ele não precise ler todos os documentos de requisitos análise e projeto do início ao fim. Essa página serviria como um índice rápido para que o programador pudesse localizar o tipo de informação que ele necessita na documentação existente.
Penso que esse tipo de abordagem além de atender a dois propósitos contribui ainda para a produção de um código de melhor qualidade. O você, o que pensa sobre esse assunto?