Considere as seguintes afirmações sobre métricas de projeto.
I - Diferentemente das métricas de processo de software, métricas de projeto e os indicadores delas derivados são usados por um gerente de projeto e uma equipe de software para adaptar o fluxo de trabalho do projeto e as atividades técnicas. II - Métricas de projeto são usadas para minimizar o cronograma de desenvolvimento, fazendo os ajustes necessários para evitar atrasos e mitigar problemas e riscos em potencial. III - Métricas de projeto são usadas para avaliar a qualidade do projeto e fornecer indicadores que terão influência na abordagem adotada para geração de código e teste.
Quais estão corretas?

Segundo Pressman, os interessados (stakeholders) de um processo de software podem ser categorizados em: gerentes seniores, gerentes (técnicos) de projeto, programadores, clientes e usuários finais. Dentre essas categorias, ___________ é a que reúne aqueles que devem ter habilidades técnicas necessárias para desenvolver a engenharia de um produto ou aplicativo de software.
Assinale a alternativa que preenche corretamente a lacuna do texto acima.

Uma métrica de qualidade que traz benefícios tanto para o projeto quanto para o processo é ___________, que essencialmente é uma medida da habilidade de filtragem das ações de garantia de qualidade e controle quando são aplicadas através de todas as atividades da estrutura de processo e que também pode ser usada no projeto para avaliar a habilidade de uma equipe para encontrar erros antes que passem para a próxima atividade na estrutura do software ou para a próxima ação da engenharia de software.
Assinale a alternativa que preenche corretamente a lacuna do texto acima.

Uma das métricas de teste utilizada para avaliar a eficiência do controle de qualidade é:

Considere as seguintes afirmações sobre relatórios de teste.
I - Os relatórios dos resultados dos testes servem tanto para os desenvolvedores como para os projetistas de teste. II - Um projetista de teste utiliza os relatórios para avaliar e refinar suas abordagens, por exemplo, observando quando alguma classe de falhas está fugindo das fases iniciais de teste e aparecendo apenas nos testes de sistema. III - Registros detalhados de teste são projetados para uma leitura seletiva e incluem tabelas-resumo que normalmente incluem os conjuntos de testes executados, a quantidade de falhas e uma classificação das falhas que se repetiram de execuções anteriores, falhas novas e casos de teste que falharam anteriormente, mas que agora foram executados corretamente.
Quais estão corretas?

Observe os testes de aceitação especificados abaixo.
I - Como aluno de matemática Desejo saber o tipo de triângulo baseado no tamanho de seus lados Para conhecer o tipo de triângulo
II - Funcionalidade: Leitor de tipos de triângulo Cenário: Triângulo escaleno Dado que estou na página de consulta de triângulos Quando eu informo os lados de um triângulo: | lado_a | lado_b | lado_c | | 3 | 4 | 5 | Então o sistema informa que o triângulo é "Escaleno"
III - Funcionalidade: Leitor de tipos de triângulo Cenário: Triângulo inválido Dado que estou na página de consulta de triângulos e que informo apenas dois lados de um triângulo Então o sistema informa que o triângulo é inválido Porque eu deveria informar três lados
Quais dessas especificações são expressões bem definidas de teste de aceitação, segundo o Behavior-Driven Design (BDD), usando a notação Gherkin?

Considere as afirmações abaixo sobre desenvolvimento ágil orientado a testes de aceitação, em inglês Acceptance Test-Driven Development (ATDD).
I - Em ATDD, testes de aceitação devem ser especificados de forma colaborativa por desenvolvedores, clientes e testadores, de forma a reduzir a diferença entre teste de sistema e teste de aceitação. II - Em ATDD, testes de aceitação são executados pelo cliente ou usuário apenas na última fase do projeto, sendo o propósito principal verificar se o sistema desenvolvido está funcionando de acordo com o que foi acordado. III - Em ATDD, testes de aceitação oferecem um contexto para derivar testes para as diferentes unidades do projeto do software em TDD (Test-Driven Design – projeto orientado a teste). IV - Em ATDD, testes de aceitação não podem ser automatizados.
Quais estão corretas?

Suponha uma organização que já está em processo adiantado de práticas ágeis de teste. Ela já tem bem consolidada a prática de criação de testes automatizados para as funcionalidades desenvolvidas, e um processo de integração contínua que inclui a verificação de testes de regressão durante a construção do build. Neste contexto, analise as afirmativas abaixo.
I - Mesmo que os desenvolvedores se assegurem de que todos os testes sejam executados com sucesso antes de integrar seu código (check-in), ainda assim é possível que testes de regressão falhem quando o novo código for integrado, causando uma “quebra de build”. O desenvolvedor responsável por esse novo código deve consertar o problema para que o build possa ser refeito, avaliando a lista de tarefas que tem a executar, a fim de definir a prioridade desse conserto, ao longo de seu dia de trabalho. II - Para assegurar que um build possa dar retorno imediato, é necessário que possa ser gerado em um tempo curto. Se alguns testes de regressão são muito demorados (por exemplo, scripts de interface), podem-se usar estratégias, como ter um processo de build separado que rode os testes mais demorados, ou versões diferentes de construção completa e resumida de build que rodariam durante a noite ou durante as horas de trabalho, respectivamente. III - Ao longo de uma iteração, novos testes automatizados são construídos. Todos os novos testes automatizados construídos para uma dada história devem ser incluídos na respectiva suíte de regressão.
Quais afirmativas estão corretas?

Considere as ações abaixo, executadas em desenvolvimento orientado a testes, Test-Driven Design (TDD).

1. Escrever código de teste.
2. Verificar se o teste falha.
3. Escrever código de produção.
4. Executar teste até passar (reescrevendo o código de produção, se for necessário, até que o teste passe).
5. Refatorar código de produção e/ou de teste para melhorá-lo.

Considerando que se deseja incluir um novo caso de teste, assinale a alternativa que apresenta a sequência de ações que devem obrigatoriamente ocorrer para essa inclusão, segundo o TDD.

Teste estático de código é realizado por ferramentas que analisam o código à procura de potenciais problemas. Considere os problemas abaixo.
I - Problemas de uso de memória e ponteiros nulos. II - Violação de padrões de código, de acordo com alguma configuração. III - Vulnerabilidades de segurança.
Quais problemas podem ser detectados por meio de ferramentas de análise estática?