Durante a etapa de desenvolvimento de um projeto, deve-se ter em mãos toda a documentação realizada anteriormente. O primeiro documento é justamente o briefing que descreve o conteúdo do sistema. Como já fizemos anteriormente, o briefing pode organizar uma entrevista. No entanto, vamos ver agora um exemplo de uma entrevista direcionada, ou seja, aquela em que o entrevistador realiza perguntas previamente elaboradas.

Dando continuidade, iremos descrever os requisitos para o sistema acadêmico que está sendo desenvolvido. Para complementar o seu conhecimento, nos requisitos, vamos complementar o documento com a prioridade, que pode ser baixa, média ou alta.

#PraCegoVer: Neste quadro constam os requisitos funcionais em três colunas que são: Código, Requisito e Prioridade. Esta tabela tem tem 9 linhas de requisitos passando por sistemas de cadastrar aluno, consulta de professor até relatório de frequência. Na primeira linha código RF01 requisito o sistema deve permitir cadastrar aluno prioridade alta; na segunda linha RF02 o sistema deve permitir consultar aluno prioridade alta; RF03 o sistema deve permitir enviar notificações prioridade média; RF04 o sistema deve permitir enviar mensagens ao professor prioridade baixa; RF05 o sistema deve permitir cadastrar professor prioridade alta; RF06 o sistema deve permitir consultar professor prioridade alta; RF07 o sistema deve permitir enviar mensagens aos alunos prioridade baixa; RF08 o sistema deve permitir fazer relatório de horas prioridade alta; RF09 o sistema deve permitir fazer relatório de frequência prioridade alta.

Complementarmente, foi realizado o levantamento de alguns requisitos funcionais. Lembrando que os requisitos funcionais são aqueles que dependem dos agentes externos ao sistema, ou seja, não se trata de uma funcionalidade.

#PraCegoVer: Segundo quadro de requisitos funcionais com três colunas que são: Código, Requisito e Prioridade. Esta tabela tem 3 linhas de requisitos passando por sistema que deve garantir a segurança dos dados até os dados obtidos anteriormente e os sistemas existentes. Na primeira linha RNF01 o sistema deve garantir a segurança dos dados prioridade alta; Na segunda linha RNF02 o sistema deve permitir o acesso responsivo as telas do sistema prioridade baixa; Na terceira linha RNF03 o sistema deve permitir integração com os dados já obtidos anteriormente e sistemas existentes prioridade média.

Uma vez tendo os requisitos em mãos, é realizado o diagrama de casos de uso. O diagrama de casos de uso traz uma visão geral do comportamento dos atores do sistema com as funcionalidades que serão desenvolvidas.

#PraCegoVer: Diagrama de caso de uso no qual temos várias relações. Temos a relação de atores como de professor com o Administrador e o Aluno. E de funcionalidades como: lançar notas, lançar frequências, manter professor, manter disciplinas e outras. O professor pode lançar nota e que vai incluir dentro do manter aluno; o professor pode lançar frequência e também vai incluir dentro do manter aluno; o administrador vai ver manter o aluno, manter o professor e manter o curso; o aluno vai ter o relatório de frequência.

Uma abordagem durante o desenvolvimento de um caso de uso é a utilização do manter. O manter representa as operações principais em cima de determinado dado: inserir, alterar, listar e remover. Desse modo, quando se utiliza o manter, permite-se deixar o diagrama com menos elementos, mantendo o foco nas demais operações que o sistema deve realizar.

Vamos pegar como exemplo o caso de uso Manter Aluno e, sabendo que representa Inserir aluno, Excluir aluno, Editar aluno e Listar aluno, vamos ver como fica o caso de uso descritivo do Cadastrar Aluno.

#PraCegoVer: Esse quadro tem um caso de outro completo onde tem o nome do caso de uso denominado Manter Aluno. Tem a descrição do Nome do caso de uso, Qual é o ator principal, Quais são os interessados e interesses. Qual as pré-condições e pós-condições, qual o cenário principal e qual é o fluxo de alternativo. Primeira linha: caso de uso alugar o livro; ator principal: cadastrar aluno; interessados e interesses: administrador usuário responsável por realizar os cadastros do sistema. Deverá utilizar informações dos alunos para alimentar o sistema; Pré-condições: o administrador deverá estar logado no sistema; Pós-condições: os dados serão armazenados. o usuário será direcionado para a tela de inserir aluno em uma disciplina; Cenário Principal: 1. O administrador obtém os dados do aluno; 2. O administrador clica em menu alunos cadastrar novo aluno; 3. O administrador solicita os documentos para o aluno; 4. O administrador insere os dados: nome do aluno, cpf, rg, data de nascimento, endereço completo e telefone para contato; 5. O administrador clica em gravar; 6. Os dados serão salvos no banco de dados. Fluxo alternativo: 5 ou 6 os campos são todos obrigatórios caso algo esteja faltando deverá emitir uma mensagem.

Deste modo, o Quadro 4.3 demonstrou o caso de uso completo.

O objetivo de um projeto de software é justamente utilizar recursos da engenharia de software para garantir que o software esteja atendendo às necessidades, antes mesmo do seu desenvolvimento.

A etapa de projeto e desenvolvimento dos diagramas de banco de dados e diagramas relacionados ao código é considerada um dos pontos cruciais, pois o que for desenvolvido aqui será idêntico na prática.

Desse modo, por mais que se trate de uma etapa de projeto, muitas decisões estão relacionadas ao desenvolvimento do sistema. Tais decisões podem ser relacionadas a algum tipo de framework utilizado, a alguma arquitetura específica de um sistema gerenciador de banco de dados e até mesmo a algum padrão de projeto que poderá ser seguido.

Modelagem de Banco de Dados

Você já sabe que o projeto de um banco de dados é composto por modelo conceitual, modelo lógico e modelo físico. No entanto, muitas decisões devem ser tomadas.

Para chegar até aqui, é essencial um documento de requisitos bem descrito, bem como um diagrama de casos de uso e suas descrições.

No desenvolvimento de um modelo de dados para o mesmo sistema acadêmico, podemos considerar algumas alternativas sobre o modelo conceitual de banco de dados, lembrando que elas irão impactar nos próximos modelos:

• Se alunos e professores têm muitos atributos similares, qual a melhor opção?
  ○Criar uma única entidade-pessoa: se essa opção for considerada, todos os registros ficarão armazenados em uma única tabela no banco de dados (o que remete à economia de espaço). No entanto, haverá dificuldades para desenvolver consultas para discernir dados das duas tabelas.
  ○ Criar duas entidades: nessa opção, haverá uma otimização das consultas e inserções. No entanto, pode implicar redundância e aumento do espaço utilizado.
  ○ Criar uma entidade-pessoa e generalizar as duas: essa é uma boa opção para garantir a integridade e a baixa redundância dos dados, envolve consultas mais complexas.
• O campo endereço: o campo endereço pode ser modelado no modelo conceitual como um campo composto, mas ficarão opções para o modelo lógico:
  ○ Inserir todos os campos na tabela como texto: essa opção na prática permitirá com que cada usuário insira seus dados, deste modo além de um grande volume de dados a dificuldade de extrair relatórios. Por exemplo, para o mesmo estado várias pessoas podem inserir dados diferentes: Santa Catarina, SC, S. Catarina.
  ○ Criar tabela estado ou integrar com base dos correios: esta opção envolve a criação de tabelas e pode auxiliar na diminuição da redundância dos dados.
• O campo Telefone: sabendo que haverá muitos telefones para o usuário, no modelo conceitual basta indicar o campo como multivalorado, mas no modelo lógico deve haver as opções:
  ○ Criar campos fixos na tabela: é uma opção que pode limitar a inserção como telefone1, telefone2 etc. Nessa opção, torna-se limitativo e pode desperdiçar espaço de armazenamento.
  ○Criar uma Tabela-Telefone: essa opção permite um armazenamento dinâmico. No entanto, só faz sentido se o telefone puder pertencer a várias pessoas.
  ○ Criar um campo Telefones: essa opção permite armazenar vários telefones em um único campo, seja utilizando um separador como “;” ou recursos do SGBD.

Avaliando as alternativas acima, juntamente com o objetivo da unidade, foi criado o modelo conceitual a seguir:

#PraCegoVer: Figura com a representação de um diagrama E-R (Entidade Relacionamento). Onde tem as Entidades: Aluno, Professor e Disciplina. Tem como um relacionamento com campos entre aluno e disciplina com um relacionamento chamado de frequência. Tem também, um relacionamento entre aluno e disciplina com nome do relacionamento de matrícula. Tem um relacionamento entre professor e disciplina com o nome do relacionamento de ministra.

A Entidade aluno tem os Campos: identificação da aula, nome, CPF, endereço, telefone e e-mail. A Entidade Professor tem os Campos: identificação do aluno, nome, CPF endereço e hora aula. A entidade Disciplina tem os Campos: identificação da disciplina, nome da disciplina e carga. O relacionamento com o campus chamado Frequenta tem os Campos: identificação da aula, data e hora.

Tendo como base o modelo conceitual desenvolvido e levando em consideração os aspectos para criação dos modelos de dados, foi desenvolvido o modelo de dados mostrado na Figura 4.3.

#PraCegoVer: Tem-se um caso de uso completo. Tem-se um modelo com as entidades: Estado, Aluno, Professor, Aula, Disciplina e Matrícula. Em cada uma das entidades tem seus campos com suas características.

Descrição da relação entre as tabelas: O Estado pode ter vinculado a ele várias Cidades; mas uma Cidade pode estar vinculado a somente um estado. Um Aluno pode estar vinculado somente a uma Cidade mas uma cidade pode ter vários alunos vinculados. Um Professor pode ministrar pode morar em uma cidade uma cidade pode ter vários professores o professor pode ministrar várias disciplinas, mas uma disciplina pode estar vinculada a somente um professor. O Aluno faz matrícula em várias disciplinas, mas cada disciplina-aluno pode ter somente um aluno. A matrícula ele tem somente uma disciplina-aluno, mas a Disciplina-aluno pode estar vinculada a várias Matrículas. O Aluno pode estar vinculado à várias salas de aula, mas cada Sala de Aula pode estar vinculada a um aluno.

Perceba que, no modelo desenvolvido, surgiram novas entidades, como é o caso de Cidade e Professor. A decisão de utilizar essas entidades em vez de campos nas tabelas facilitará a criação de combos para que os usuários selecionem de maneira automática, bem como auxiliará a geração de relatórios.

Diagrama de Classes

No desenvolvimento de um projeto de sistemas utilizando diversas metodologias, bem como o desenvolvimento de diagramas UML, cada diagrama tem a sua finalidade. O diagrama de classes mostra as classes de objetos em um sistema e seus relacionamentos.

O diagrama de classes permite desenvolver um projeto de software orientado a objetos, antes mesmo de codificar.

Um diagrama de classes exibe um conjunto de classes, interfaces e colaborações, bem como seus relacionamentos. Esses diagramas são encontrados com maior frequência em sistemas de modelagem orientados a objeto e abrangem uma visão estática da estrutura do sistema. Os diagramas de classes que incluem classes ativas direcionam a perspectiva do processo estático do sistema. Os diagramas de componentes são variantes dos diagramas de classe (SOMMERVILLE, 2011, p. 64).

Para o desenvolvimento do diagrama de classes, foram considerados todos os diagramas desenvolvidos até o momento. Os diagramas de casos  de uso, bem como o documento de requisitos e os casos de uso descritivo foram utilizados para compreender a funcionalidade em geral.

Uma vez que o diagrama de banco de dados já foi desenvolvido, auxiliará na compreensão dos principais dados utilizados e no comportamento e relacionamento entre as informações. A Figura 4.4 mostra o diagrama desenvolvido para o nosso projeto.

#PraCegoVer: Diagrama de classes desenvolvido onde se tem demonstrado: a Pessoa, o Professor, o Aluno e a Aula. Em cada uma destas os seus respectivos Campos identificados. Principais campos de cada um: Pessoa tem identificação, nome, cpf, endereço e telefone; Professor tem: Valor e disciplina; Aula tem identificador, data e hora e no Aluno tem matrícula.

Importante: Deve-se tomar muito cuidado ao desenvolver o diagrama de classes, tendo o diagrama de banco de dados em mãos. Nem sempre cada tabela terá sua própria classe.

Note que o diagrama de classes utiliza o recurso de herança para realizar os cadastros de Professor e Aluno.

O processo de desenvolvimento de software é considerado como a hora de “colocar as mãos na massa”. Embora você tenha aprendido até aqui que há muito trabalho até chegar nesta etapa, é na hora do desenvolvimento de um sistema que a codificação acontece e os programadores entram em cena.

Segundo Montoni (2010), o desenvolvimento de software é uma atividade complexa e processos de software dependem fortemente do comprometimento humano para sua implementação. Desse modo, conforme você já estudou, existe um conjunto de processos e metodologias que impactam diretamente nessa etapa, antes mesmo dela ser inicializada.

Esta é etapa de desenvolvimento prático de um software , ou seja, a codificação deve ser inicializada após ter os documentos em mãos. Isso significa que todo o processo de engenharia de software e gestão de projetos foi executado e os programadores receberam os sprints com suas tarefas.

Assumindo que estamos iniciando um projeto do zero, existem diversas maneiras de se ter um ponto de partida para o desenvolvimento. No entanto, vamos começar preparando o ambiente de criação de um banco de dados.

Criando o Banco de Dados

Se você seguiu as etapas de modelagem de dados criando o modelo lógico e físico, utilizando as mesmas ferramentas, BrModelo e Power Architect, esta etapa pode ser uma etapa simples. Tais ferramentas simplificam a transformação dos modelos de mais alto nível em um modelo de baixo nível, ou seja, geram SQL.

O Power Architect, bem como outras ferramentas de modelagem, permite que você se conecte diretamente com o sistema gerenciador de banco de dados, auxiliando no processo de manutenção desses dados.

#PraCegoVer: Figura tendo bem em cima em destaque o título: Conexão de banco de dados - Nova conexão. Abaixo um Template com os campos: Nome da conexão, Tipo do banco de dados, Opções de conexão, URL JDBC, Nome do usuário e senha. Em um retângulo laranja na parte inferior a esquerda o botão Testar a conexão. Logo abaixo em outro retângulo a opção OK e a Cancelar.

Outra abordagem para criar o seu banco de dados é digitar os comandos SQL. Você pode fazer isso apenas utilizando o modelo e fazendo à mão. No entanto, para auxiliar no processo, pode utilizar o Power Architect no menu Ferramentas >> Engenharia Reversa. Feito isso, selecione o SGBD de destino, no caso o PostgreSQL, e aperte OK. Depois, a ferramenta irá gerar a DDL para criação da estrutura do banco de dados.

#PraCegoVer: Figura tem como título principal (com fundo preto): Visualização de um script SQL para fazer uma engenharia reversa com Power Architect. Tem escrito um script para a criação da tabela estado, cidade, professor e disciplina. Com seus respectivos campos. Criação de uma tabela chamada Estado com os campos de identificação do Estado inteiro não nulo, campo descrição varchar não nulo onde tem uma chave primária da identificação do Estado. Criação de uma tabela chamada cidade que tem seus campos: Identificação da cidade inteiro não nulo, Identificação do Estado inteiro não nulo, Descrição varchar não nulo e como chave primária código da cidade. Criação da tabela Professor com os campos: Identificação do aluno inteiro não nulo, varchar com 150 posições não nulo, CPF varchar com tamanho 11 não nulo, Telefone varchar com tamanho 12 não nulo, Rua varchar não nulo, Identificação da cidade inteiro não nulo e a chave primária é a identificação do Aluno.

Uma vez obtido o código DDL para a criação das tabelas, basta executá-lo na interface do SGBD. Em nosso caso, foi executado utilizando o PgAdmin, que é uma ferramenta visual para conectar e utilizar o PostgreSQL.

#PraCegoVer: Na figura aparece um framework de um editor de SQL. Neste editor consta o comando SQL para a criação da tabela Estado e seus campos identificação do estado, descrição do estado e a sua chave primaria. O script é a criação da tabela Estado com os campos Identificação do Estado inteiro não nulo, Descrição varchar não nulo e a chave primária é a Identificação do Estado.

Criando as Telas do Sistema

Os protótipos de tela são desenvolvidos tendo como finalidade dar suporte à versão final. Nesse caso, vamos desenvolver a tela em si utilizando uma tecnologia específica.

Para isso, utilizaremos a linguagem de marcação HTML ( Hypertext Markup Language - linguagem de marcação de texto)  para a criação das telas, e o CSS ( Cascading Style Sheets - folha de estilos em cascata) para dar estilo às telas.

Essas duas tecnologias são comumente empregadas em conjunto e em um padrão MVC, compõem a View , ou seja, a camada de visualização. Entre vários benefícios, o desenvolvimento com essas tecnologias faz com que a parte operacional ( back-end ) possa ser desenvolvida em qualquer linguagem que opere na web .

#PraCegoVer: Foto da tela do computador com o fundo todo preto. Nesta tela tem um programa de computador escrito. Este programa vai criar uma classe container. A identificação do um formulário é identificado como cadastro do aluno. Imprime na tela “Cadastro do Aluno” e faz o input (entrada) do nome, input do CPF, imput do telefone e e-mail. Para o campo Estado tem com opção de seleção (opção) 1 - SP e 2- SP. Depois o texto”Selecione”. Depois do input colocar o submit “enviando” ou “cancelando”.

A partir do código acima e sua combinação com CSS, é possível ter a tela do sistema, que é mostrada a seguir. O CSS utilizado pode ser obtido pelo site “codepen”.

#PraCegoVer: Uma tela de cadastro aluno aonde a borda toda tela é uma borda Verde tem escrito bem em cima, em destaque, Cadastro de Alunos. Abaixo os campos para preencher: O nome do aluno, o CPF, o telefone e o e-mail. Abaxio a opção para selecionar o estado se a cidade. Logo abaixo dois retângulos verdes. No primeiro retângulo verde a opção cadastrar e no outro a opção cancelar.

Codificando o Sistema

Agora você tem praticamente tudo em mãos: os documentos de requisitos, diagramas de caso de uso, descrição dos casos, diagramas de banco de dados e diagrama de classes. Com isso, pode-se dizer que está pronto para codificar.

Nesta etapa, com um projeto de software bem definido, a programação torna-se um processo simples, pois grande parte do desenvolvimento de sistemas é gasto na compreensão do que deve ser desenvolvido, bem como em alterações que precisam ser feitas porque a documentação foi construída erroneamente ou até mesmo não foi realizada.

A UML nos fornece o diagrama de classe e nele não definimos uma linguagem de programação.

O PHP é uma das linguagens mais utilizadas na web. Milhões de sites no mundo inteiro utilizam PHP. A principal diferença em relação às outras linguagens é a capacidade que o PHP tem de interagir com o mundo web, transformando totalmente os websites que possuem páginas estáticas. Imagine, por exemplo, um website que deseja exibir notícias em sua página principal, mostrando a cada dia, ou a cada hora, notícias diferentes. Seria inviável fazer isso utilizando apenas HTML. As páginas seriam estáticas, e a cada notícia nova que aparecesse no site a página deveria ser alterada manualmente, e logo após enviada ao servidor por FTP (File Transfer Protocol) para que as novas notícias fossem mostradas no site. Com o PHP, tudo isso poderia ser feito automaticamente. Bastaria criar um banco de dados onde ficariam armazenadas as notícias e criar uma página que mostrasse essas notícias, “puxando-as” do banco de dados (NIEDERAUER, 2011, p. 2).

Em um primeiro exemplo, vamos fazer o código orientado a objetos da classe Pessoa necessário para executar o exemplo desenvolvido (Cadastro Aluno) utilizando a linguagem PHP.

#PraCegoVer: Foto da tela do computador com o fundo todo preto. Nesta tela tem um programa de computador escrito. Este programa cria a classe como o nome Pessoa que tem como campos: nome, CPF, endereço e telefone. Tem uma função para fazer a conexão entre o localhost sendo o postgres. Seta a @banco = pg_select_db. Abre uma função com nome de Cadastrar na tabela. Insere o nome, cpf, endereço e telefone. Tem um if (teste) na inserção da pessoa . Se sim coloca a mensagem “ocorreu tudfo bem ao inbserir nos sitea” ou e não (else) “Falha ao realizsar inserção na tabela”.

Exemplificando como um mesmo modelo pode dar origens a várias implementações, bem como a mesma tela, agora será desenvolvido um código orientado a objetos da classe Pessoa necessário, utilizando a linguagem Python.

Python é software livre, ou seja, pode ser utilizada gratuitamente, graças ao trabalho da Python Foundation1 e de inúmeros colaboradores. Você pode utilizar Python em praticamente qualquer arquitetura de computadores ou sistema operacional, como Linux2 , FreeBSD3 , Microsoft Windows ou Mac OS X4 . Python vem crescendo em várias áreas da computação, como inteligência artificial, banco de dados, biotecnologia, animação 3D, aplicativos móveis (celulares), jogos e mesmo como plataforma web. Isso explica porque Python é famosa por ter “batteries included”, ou seja, baterias inclusas, fazendo referência a um produto completo que pode ser usado prontamente (quem nunca ganhou um presente de Natal que veio sem pilhas?). Hoje é difícil encontrar uma biblioteca que não tenha bindings (versão) em Python (MENEZES, 2010, p. 22).

O fato de existirem diversas bibliotecas para os mais diversos tipos de problemas em Python faz com que a linguagem seja uma das mais utilizadas no mundo. Devido ao número de bibliotecas, mesmo profissionais de outras áreas, como matemática e estatística, optam pelo emprego dessa linguagem.

#PraCegoVer: Foto da tela do computador com o fundo todo preto. Nesta tela tem um programa de computador escrito.

O programa cria a classe Pessoa definindo a identificação da pessoa, o nome da pessoa, CPF, endereço e telefone. Faz um self para cada um destes campos.

Faz um property na def do índice, do e-mail e da senha.

Por fim faz um try o e-mail e a senha faz 13 aonde testa se o usuário for igual e o pessoal foi igual a 123 o host 127.0.0. 1 na porta 5432 o banco de dado posto aonde faço o execute do conector se for um erro 30 o erro definir cadastrar onde fazer o cursor igual lugar do cursor o comando insert into pessoa nome CPF endereço e telefone.

Durante a leitura até este ponto, você pode perceber que tanto Python quanto PHP são poderosas linguagens para desenvolver os mais diversos tipos de aplicações. Além disso, é muito importante compreender que a modelagem de sistemas orientada objetos, por intermédio do diagrama de classes, não tem o seu projeto de desenvolvimento ligado obrigatoriamente a uma linguagem de programação.

Existem muitas perguntas complexas para se responder durante o processo de desenvolvimento de um sistema de informação. Talvez algumas que deem calafrios em desenvolvedores e analistas sejam: o sistema está pronto? Ele está funcionando?

Isso acontece porque cada membro da equipe tem sua definição/expectativa do que é um software pronto e seu funcionamento, e o cliente também tem a dele. Por isso, é necessário o desenvolvimento de uma documentação precisa, a cada etapa do desenvolvimento de um software , que auxiliará no processo de teste e validação.

O processo de desenvolvimento de software envolve uma série de atividades nas quais, apesar das técnicas, métodos e ferramentas empregados, erros no produto ainda podem ocorrer. Atividades agregadas sob o nome de Garantia de Qualidade de Software têm sido introduzidas ao longo de todo o processo de desenvolvimento, entre elas atividades de VV&T – Verificação, Validação e Teste, com o objetivo de minimizar a ocorrência de erros e riscos associados. Dentre as técnicas de verificação e validação, a atividade de teste  é uma das mais utilizadas, constituindo-se em um dos elementos para fornecer evidências da confiabilidade do software em complemento a outras atividades, como por exemplo o uso de revisões e de técnicas formais e rigorosas de especificação e de verificação (MALDONADO et al., 2004 p. 3).

O processo de teste pode ser composto por etapas e por tipos de testes realizados, tendo o objetivo de garantir que o sistema atenda aos requisitos, bem como indicar que não foram encontrados erros.

No que se refere às etapas de teste, podem-se elencar as seguintes:

• Teste de desenvolvimento: é o teste realizado durante o desenvolvimento do sistema com o objetivo de encontrar bugs e erros. Geralmente essa etapa é realizada pelo próprio programador responsável pela funcionalidade.
• Teste de release : é realizado por uma equipe independente, tem como objetivo validar se o sistema atende aos requisitos levantados, bem como procurar erros no sistema.
• Teste de usuário: o teste de usuário é um teste feito por “usuários de sistema”, ou seja, feito por pessoas que não são da área e que têm o perfil do usuário que irá utilizar o sistema.
• Teste de aceitação: é o teste realizado com o usuário final do sistema. Pode-se dizer que é o teste realizado pelo cliente e membros da sua empresa, indicando se o sistema atende à sua necessidade e será aceito.

Plano de Testes

O plano de testes é mais um documento que compõe a documentação de software e pode ser desenvolvido logo após o desenvolvimento dos casos de uso. Esse documento tem como objetivo guiar a equipe de software em relação a como os testes serão realizados.

O principal objetivo desta atividade é planejar os esforços de teste dentro de uma iteração, descrevendo uma estratégia de testes, estimando os requisitos para o esforço de teste, tais como recursos humanos e do sistema, e criando uma escala de testes a ser executada. Assim, constrói-se um plano de testes, com base nos diversos modelos utilizados nas fases de especificação, análise, design e implementação. Assim, desenvolve-se aqui uma estratégia geral de testes, onde determina-se que tipos de testes serão executados, como executá-los, quando executá-los e como avaliar os resultados dos testes. Devemos lembrar que testes custam recursos e tempo. Portanto, deve-se efetuar uma solução de testes que tenha uma boa relação custo-benefício (GUDWIN, 2020 p. 143).

De todos os elementos que um plano de testes contém, pode-se dizer que o mais importante é o caso de testes. Um caso de teste descreve uma rotina que deve ser testada.

#PraCegoVer: O quadro de exemplo de caso de teste com duas colunas. A coluna da esquerda, com o fundo azul escuro, tem a linha com o número do caso, a próxima com o objetivo do teste, a outra com usuário ou ator, a próxima com os passos e a última com os critérios de êxito desse teste. Na coluna da direita tem a descrição de uma destas linhas.

Vamos a descrição de cada uma das linhas.

Caso número: CT010 – Realizar o cadastro de aluno. Objetivo do teste: Verificar se o usuário Atendente consegue realizar o cadastro de um aluno no sistema. Usuário/Ator: Administrador.

Passos: 1. Usuário clica em menu alunos cadastrar novo aluno. 2. Usuário clica em gravar. 3. Usuário insere nome do aluno João Silva e clica em gravar. 4. O usuário insere o CPF “111111111111”. 5. O usuário clica em gravar. 6. O usuário insere o RG “545858545854” e clica em gravar. 7. O usuário insere a data de nascimento “25/01/2020” e clica em gravar. 8. O usuário insere a data de nascimento “25 /01/1990” e clica em gravar. 9. O usuário insere o endereço “Rua da Penha” e clica em gravar. 10. O usuário insere o telefone “2521” e clique em gravar. 11. O usuário insere o telefone “479526345567” e clica em gravar.

A última linha é a de Critérios de êxito: 1. Usuário clica em menu alunos cadastrar novo aluno. A tela de cadastro de alunos é aberta. 2. Usuário clica em gravar. Todos os campos são preenchidos e obrigatórios (*) devem ficar em vermelho. 3. Usuário insere nome do aluno João Silva e clica em gravar. Todos os campos são preenchidos e obrigatórios (*) devem ficar em vermelho. 4. O usuário insere o CPF “111111111111”. a. Mensagem de erro “CPF inválido”. B. Todos os campos são preenchidos e obrigatórios (*) devem ficar em vermelho. 5. O usuário clica em gravar. Todos os campos são preenchidos e obrigatórios (*) devem ficar em vermelho. 6. O usuário insere o RG “545858545854” e clica em gravar. Todos os campos são preenchidos e obrigatórios (*) devem ficar em vermelho. 7. O usuário insere a data de nascimento “25/01/2020” e clica em gravar. a. Mensagem de erro “Data de nascimento maior que a data atual”. b. Todos os campos são preenchidos e obrigatórios (*) devem ficar em vermelho. 8. O usuário insere a data de nascimento “25 /01/1990” e clica em gravar. Todos os campos são preenchidos e obrigatórios (*) devem ficar em vermelho. 9. O usuário insere o endereço “Rua da Penha” e clica em gravar. Todos os campos são preenchidos e obrigatórios (*) devem ficar em vermelho. 10. O usuário insere o telefone “2521” e clique em gravar. a. Mensagem de erro “Telefone inválido”. b. Todos os campos são preenchidos e obrigatórios (*) devem ficar em vermelho. 11. O usuário insere o telefone “479526345567” e clica em gravar. Todos os campos são preenchidos e obrigatórios (*) devem ficar em vermelho. a. Mensagem “Aluno cadastrado com sucesso”. b. Mensagem com opção de seleção “Deseja cadastrar outro aluno?”

O caso de teste tem grande similaridade com o caso de uso, podendo ser desenvolvido com base no diagrama de casos de uso e seu descritivo. Porém, não se deve limitar à construção de casos de teste, deve-se descrevê-lo buscando refletir a real utilização do usuário.