Model‐based quality assurance of protocol documentation: tools and methodology

Grieskamp, Wolfgang; Kicillof, Nicolás; Stobie, Keith; Braberman, Vı́ctor

doi:10.1002/stvr.427

Cited by 102 publications

(82 citation statements)

References 19 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Two exceptions to this is provided by Hasling et al (2008) and by Nebut et al (2006) who both report on experiences from applying model-based testing by generating system test cases from UML descriptions of the requirements. The main benefits of model-based testing are in increased test coverage (Nebut 2006, Hasling 2008, enforcing a clear and unambiguous definition of the requirements (Hasling 2008) and increased testing productivity (Grieskamp 2011). However, the formal representation of requirements often results in difficulties both in requiring special competence to produce (Nebut 2006), but also for non-specialist (e.g.…”

Section: Related Workmentioning

confidence: 99%

Challenges and practices in aligning requirements with verification and validation: a case study of six companies

et al. 2013

View full text Add to dashboard Cite

Weak alignment of requirements engineering (RE) with verification and validation(VV) may lead to problems in delivering the required products in time with the right quality. For example, weak communication of requirements changes to testers may result in lack of verification of new requirements and incorrect verification of old invalid requirements, leading to software quality problems, wasted effort and delays. However, despite the serious implications of weak alignment research and practice both tend to focus on one or the other of RE or VV rather than on the alignment of the two. We have performed a multi-unit case study to gain insight into issues around aligning RE and VV by interviewing 30 practitioners from 6 software developing companies, involving 10 researchers in a flexible research process for case studies. The results describe current industry challenges and practices in aligning RE with VV, ranging from quality of the individual RE and VV activities, through tracing and tools, to change control and sharing a common understanding at strategy, goal and design level. The study identified that human aspects are central, i.e. cooperation and communication, and that requirements engineering practices are a critical basis for alignment. Further, the size of an organisation and its motivation for applying alignment practices, e.g. external enforcement of traceability, are variation factors that play a key role in achieving alignment. Our results provide a strategic roadmap for practitioners improvement work to address alignment challenges. Furthermore, the study provides a foundation for continued research to improve the alignment of RE with VV.

show abstract

Section: Related Workmentioning

confidence: 99%

Challenges and practices in aligning requirements with verification and validation: a case study of six companies

et al. 2013

View full text Add to dashboard Cite

show abstract

“…Given a model, there is the potential to automate test case generation and execution but also to automatically check that an observed behaviour is one allowed: the model acts as an Oracle. Recent industrial experience has shown that the use of MBT can lead to significant reductions in the cost of testing [Grieskamp et al 2011] but MBT builds on much earlier work in the context of automata theory (see, for example, [Moore 1956;Hennie 1964;Chow 1978]). …”

Section: Introductionmentioning

confidence: 99%

Combining Centralised and Distributed Testing

Hierons

2014

ACM Trans. Softw. Eng. Methodol.

View full text Add to dashboard Cite

Many systems interact with their environment at distributed interfaces (ports) and sometimes it is not possible to place synchronised local testers at the ports of the system under test (SUT). There are then two main approaches to testing: having independent local testers or a single centralised tester that interacts asynchronously with the SUT. The power of using independent testers has been captured using implementation relation dioco. In this paper we define implementation relation diococ for the centralised approach and prove that dioco and diococ are incomparable. This shows that the frameworks detect different types of faults and so we devise a hybrid framework and define an implementation relation diocos for this. We prove that the hybrid framework is more powerful than the distributed and centralised approaches. We then prove that the Oracle problem is NP-complete for diococ and diocos but can be solved in polynomial time if we place an upper bound on the number of ports. Finally, we consider the problem of deciding whether there is a test case that is guaranteed to force a finite state model into a particular state or to distinguish two states, proving that both problems are undecidable for the centralised and hybrid frameworks.

show abstract

“…An important benefit of MBT is that M can be used as the basis of a test oracle: we can check that observations made in testing are consistent with M . Recent work has reported the results of a major industrial project involving hundreds of software engineers, with it being found that the use of MBT led to significant benefits [1]. Most approaches to MBT use behavioural models written in languages that are either state-based or scenario-based.…”

Section: Introductionmentioning

confidence: 99%

The Oracle Problem When Testing from MSCs

Dan

Hierons

2013

The Computer Journal

View full text Add to dashboard Cite

Message Sequence Charts (MSCs) form a popular language in which scenariobased specifications and models can be written. There has been significant interest in automating aspects of testing from MSCs. This paper concerns the Oracle Problem, in which we have an observation made in testing and wish to know whether this is consistent with the specification. We assume that there is an MSC specification and consider the case where we have entirely independent local testers (local observability) and where the observations of the local testers are logged and brought together (tester observability). It transpires that under local observability the Oracle Problem can be solved in low-order polynomial time if we use sequencing, loops and choices but becomes NP-complete if we also allow parallel components; if we place a bound on the number of parallel components then it again can be solved in polynomial time. For tester observability, the problem is NP-complete when we have either loops or choices. However, it can be solved in low-order polynomial time if we have only one loop, no choices, and no parallel components. If we allow parallel components then the Oracle Problem is NP-complete for tester observability even if we restrict to the case where there are at most two processes.

show abstract

Model‐based quality assurance of protocol documentation: tools and methodology

Cited by 102 publications

References 19 publications

Challenges and practices in aligning requirements with verification and validation: a case study of six companies

Challenges and practices in aligning requirements with verification and validation: a case study of six companies

Combining Centralised and Distributed Testing

The Oracle Problem When Testing from MSCs

Contact Info

Product

Resources

About