Requisitos Funcionais e Qualidade de Testes

Autor: Gregório Ivanoff e José Eduardo Belix

Data: 10/03/2020

Sessão: Comunicado

GEMS 377– TIDD/Depto de Computação/PUCSP

Com dois participantes, o encontro foi bastante diferenciado. Gregório convidou José Eduardo Belix para expor as suas preocupações com requisitos (funcionais) e qualidade de testes [1]. Iniciando com uma tipologia de requisitos, diferentes enfoques de enfrentamento práticos na forma de técnicas e processos, foram apresentados e discutidos ao longo da sessão. Introduzidos de maneira informal, podem ser complementados com as sugestões propostas pelo IEEE, ao menos como referencial de discussão. No “IEEE Guide for Developing System Requirements Specifications” [2]:

* requirement A) A condition or capability needed by a user to solve a problem or achieve an objec-tive. (B) A condition or capability that must be met or possessed by a system or system component to satisfya contract, standard, specification, or other formally imposed document. (C) A documented representation ofa condition or capability as in definition (A) or (B). (IEEE Std 610.12-1990)

* well-formed requirement: A statement of system functionality (a capability) that can be validated, andthat must be met or possessed by a system to solve a customer problem or to achieve a customer objective,and is qualified by measurable conditions and bounded by constraints.

* validation: The process of evaluating a system or component during or at the end of the developmentprocess to determine whether a system or component satisfies specified requirements. (IEEE Std 610.12-1990)

* verification: The process of evaluating a system or component to determine whether the system of agiven development phase satisfies the conditions imposed at the start of that phase. (IEEE Std 610.12-1990)

* testability: The degree to which a requirement is stated in terms that permit establishment of test crite-ria and performance of tests to determine whether those criteria have been met. (IEEE Std 610.12-1990)

* model: A representation of a real world process, device, or concept.

Relacionado aos testes, outro documento de referência, “IEEE Standard for Software and System Test Documentation” [3]:

* test: (A) A set of one or more test cases. (B) A set of one or more test procedures. (C) A set of one or more test cases and procedures. (adopted from IEEE Std 610.12-1990 (D) The activity of executing (A), (B), and/or (C).

* test case: (A) A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement. (B) Documentation specifying inputs, predicted results, and a set of execution conditions for a test item. (adopted from IEEE Std 610.12-1990)

* test procedure: (A) Detailed instructions for the setup, execution, and evaluation of results for a given test case. (B) A document containing a set of associated instructions as in (A). (C) Documentation that specifies a sequence of actions for the execution of a test. (adopted from IEEE Std 982.1 TM -2005)

Sob um ponto de vista sintético, podemos associar requisitos funcionais a comportamentos de máquina. A atividade de teste procura averiguar se os requisitos foram (plenamente) atendidos. Isto pode ser feito seguindo a ideia de Popper [4], procurando invalidar afirmações verdadeiras a respeito da qualidade da implementação. Caracteriza-se, assim, uma empreitada de software considerada como Ciência: procura-se demonstrar que os requisitos não foram atendidos pela implementação do modelo proposto como solução. Edsger Dijkstra procura traduzir tais preocupações por meio de duas sentenças muito representativas:

> “Software testing proves the existing of bugs not their absence.”

> “If debugging is the process of removing bugs, then programming must be the process of putting them in.”

De forma complementar, Gregório criou uma página preliminar em [http://www.ilanet.com.br/cgi-local/portal/bin/view/Ilanet/GrupoDeEstudosEmModelagemDeSoftware](http://www.ilanet.com.br/cgi-local/portal/bin/view/Ilanet/GrupoDeEstudosEmModelagemDeSoftware?fbclid=IwAR1gK_PO1Cq1hhTxzUO3FhaT3arwElt3YgktZ98RORoFrFgC0Kx9VUK7u6A) a respeito do GEMS. Sensacional!

[1]: José Eduardo Belix, Sobre inconsistências na implementação de requisitos, GEMS 377, Pontifícia Universidade Católica de São Paulo, 2020.

[2]: IEEE Std 1233, 1998 Edition.

[3]: IEEE Std 829TM-2008]