Model-Based Software Design and Testing in Blockchain Smart Contracts: A Systematic Literature Review

SPECIAL SECTION ON BLOCKCHAIN TECHNOLOGY: PRINCIPLES AND APPLICATIONS Received July 28, 2020, accepted August 17, 2020, date of publication September 3, 2020, date of current version September 21, 2020. Digital Object Identifier 10.1109/ACCESS.2020.3021502 Model-Based Software Design and Testing in Blockchain Smart Contracts: A Systematic Literature Review NICOLÁS SÁNCHEZ-GÓMEZ , JESUS TORRES-VALDERRAMA, J. A. GARCÍA-GARCÍA, JAVIER J. GUTIÉRREZ, AND M. J. ESCALONA Web Engineering and Early Testing Research Group, Escuela Técnica Superior de Ingeniería Informática, University of Seville, 41012 Seville, Spain Corresponding author: Nicolás Sánchez-Gómez ([email protected]) This work was supported in part by the Spanish Government’s Ministry of Economy and Competitiveness through the Guided Solutions for the Systematization of Early Quality Assurance in Software Engineering (POLOLAS) Project under Grant TIN2016-76956-C3-2-R, and in part by the Andalusian Regional Ministry of Economy, Knowledge, Business and University through the Trop@ Project under Grant CEI-12-TIC021. ABSTRACT Blockchain technology promises to spark a real revolution. One of most important concepts associated with this technology is smart contracts, which enable the automatic execution of agreements and augur a world without intermediaries. The conditions and rules of ‘‘contracts’’ are established in a computer codes and trust is enforced by consensus among the participants. One relevant feature associated with smart contract is the immutability property, which establishes the non-alteration of blockchain network data after the clauses of the contract are been approved by all parties or entities involved. For this reason, smart contract development requires more effort and care than the development of other common programs. They require systematic mechanisms to collect requirements and functional specifications. In addition, it is necessary to verify and validate the agreed functionality and the implemented code before they are deployed in the blockchain platform. This article presents a systematic literature review of primary studies in the field of Software Development Life Cycle, focusing on model-based software design and testing in the blockchain domain of smart contracts. This research aims to identify gaps and/or opportunities for further research. After carried out this review, it was observed that no clear methodology exists for evaluating and validating the quality either of this software or the overall development process. This means that software developers may implement smart contract code in which bugs and serious security vulnerabilities appear when the software is delivered to their customers. INDEX TERMS Software engineering, software development life cycle, blockchain, smart contract, modelbased software engineering, software testing, systematic literature review. I. INTRODUCTION Blockchain technology has well-known benefits in many areas (e.g., economic, political, humanitarian, or social, among others) and could reconfigure many aspects of today’s society [2]. Blockchain technology, based on distributed ledger technologies (DLT), is a chain of cryptographically linked blocks. This technology provides mechanisms to define agreements using the concept of smart contract [61], which is computer programs that run on blockchain networks without intermediaries. A smart contract, in the case of legal agreement, tends to replace the printed document with The associate editor coordinating the review of this manuscript and approving it for publication was Srinivas Sampalli . legal language. The software requirements that this computer program must satisfy, from the engineering perspective, are analogous to the terms, rules, and conditions in a conventional legal contract. However, it is important to highlight that smart contracts can encode automated agreement execution, but not all smart contracts may necessarily be agreements and do not always necessarily codify actions between more than one party. The first conceptualization of the smart contract term was published by Nick Szabo in 1994 [66]. In this article, the author defines a smart contract as a set of clauses, data and protocols. These protocols implement algorithms to automatically verify the fulfilment of each condition by each party/entity involved in the contract. In this sense, these 164556 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ VOLUME 8, 2020 N. Sánchez-Gómez et al.: Model-Based Software Design and Testing in Blockchain Smart Contracts: A SLR contracts are smarter than paper-based contracts because they automatically enforce the obligations of the parties involved. But a smart contract should not be seen as intelligent tools that can parse a contract’s more subjective requirements. On the other hand, it is important to note that the fact of eliminating the need for a trusted third party significantly reduces the transaction costs, that is, it facilitates the most economic exchanges. In this context, a set of important concepts will be introduced: •Software Development Life Cycle (SDLC) is a process that defines good practices to document, develop, maintain, and replace the software adequately [57]. As mentioned above, smart contracts are also software. Therefore, it is necessary to apply methodological processes for eliciting their requirements and functional specifications to improve their quality [36]. However, to the best of our knowledge, there are currently no guidelines for implementing smart contracts. •One of the most important aspects, to consider in SDLC, is the Software Testing because it allows improving the quality of the software [28]. However, this testing phase often becomes less important due to delays in development. Then, it is usually performed at the end once the coding phase is finished and before the software is delivered to the customer. In this context, it is relevant to start testing software as soon as possible when SDLC is carried out. Early testing allows detecting many defects soon what helps to increase quality and customer’s satisfaction [14]. •Over last years, Model-Driven software engineering [70] has become a practical, efficient, and successful methodology for software design and testing. Many proposals [7], [20], [21], [26] use this paradigm to define software requirements in structured, comprehensible, and formal models. This formalization allows establishing mechanisms to measure, check and verify these requirements from early stages. In addition, the definition of these formal models facilitates the definition of transformation rules to generate a test case systematically and automatically, and even software code associated with these test cases [19]. These methodological practices facilitate code reusability and the reduction of human errors. •Other important benefits achieved by Model-Driven software engineering are: (1) systematized design, and continuous software testing to increase software development effectiveness, and (2) reusable models and software code which can reduce costs and time in the software development process. In this context, this article presents the results of a study that analyzes the state-of-the-art of research works in the field of SDLC. Concretely, this study is focused on proposals that address the Model-Based software design and testing for smart contracts within blockchain domain. For this purpose, FIGURE 1. Schedule of the systematic review followed in this article. the Systematic Literature Review (SLR) method is used to identify gaps and to offer future research guidelines related to our research topic. The rest of the paper is structured as follows: Section II and III describe the method used for the systematic review and its planning, respectively; After defining the review protocol to be applied, it is conducted presenting in Section IV the results; Section Vanalyses and discusses the most relevant findings; finally, Section VI provides a set of conclusions and suggestions for future works. II. REVIEW METHOD The present study was carried out using one of the SLR methods most successfully and widely applied in software engineering field. Specially, the Kitchenham’s method [30]. This method present rigorous stages to analyze research knowledge using a trustworthy and auditable methodology. Some authors, however, have criticized Kitchenham’s method and/or proposed improvements on this one [15], [31]. In the wake of these criticisms and suggestions for improvement, Kitchenham published an updated version of her method in [30]. But, at present, some authors [15] admit that an important gap still exists regarding the evaluation of quality in studies based on empirical methods. This SLR follows the latest version of Kitchenham’s method, referenced above. It describes three phases for executing a systematic review: (1) planning, which defines aspects such as the need for the research, review protocol and research questions; (2) conducting, which the previously established protocol is carried out; and (3) reporting, which presents the final analysis to answer each research question. Figure 1shows these phases and their tasks on a timeline to achieve research objective of this article. III. PLANNING THE SYSTEMATIC REVIEW This section describes the planning process conducted in this SLR. During this process, the need to perform the review was identified, the research questions (RQs) were formed, and the review protocol was established and verified. VOLUME 8, 2020 164557 N. Sánchez-Gómez et al.: Model-Based Software Design and Testing in Blockchain Smart Contracts: A SLR A. THE NEED FOR THE REVIEW Over the last few years, much researches around the world to evaluate and identify challenges and obstacles to the application of blockchain smart contracts in different fields. This research has reported and evaluated the use of blockchain technology in multiple processes and services in different business areas (e.g., Internet of Things [39], Supply Chain [55], [64], [68], education [74], agriculture [72] or health [73], among others). In addition, one of the objectives of these investigations has been identifying challenges and barriers of this technology in different scenarios (e.g., quality [32], Big Data [29] or e-government [4]). In addition, some works partially related to our proposal have been published. Alharby et al. [3], present a Systematic Mapping Study (SMS) of technology-oriented research in smart contracts. In this study, the authors followed the method presented by Petersen et al. [52]. However, the process followed is not well detailed which makes reproducibility difficult. Following the same method, Macrinici et al. [41] propose an SMS to know the state-of-the-art in smart contract applications within blockchain technology. Authors deeply reviewed 64 papers identifying some gaps but, there is no mention about testing. Leka et al. [35] develop an SLR but the authors follow the SMS method mentioned earlier, they do not follow the SLR process. Moreover, no explanation about the execution is described and results cannot be reproducible. Finally, Dhaiouir and Assar [17] present an SLR of Blockchain-Enabled Smart Contracts, focusing on platforms, languages, or applications among others. Again, there is no mention about testing. Conversely to the present literature, this article describes an SLR carried out in the field of SDLC, in particular on smart contract development life cycle. The focus is on the modelbased design and testing of blockchain smart contracts. More specifically, we review the state of formal smart contract modelling and automatic code generation, together with the verification/validation of this code, in order to characterize and present the state-of-the-art (approaches) in this field and identify gaps and opportunities for further research. B. RESEARCH QUESTIONS Following Kitchenham’s method, RQs needed to be stablished for clearly focus the research on the topic and improve our understanding of the proposals being studied. The general RQ guiding our whole SLR was: What is the state-of- the-art as regards blockchain smart contracts in software engineering?. If software engineering is applied, it is fundamental to have specific analysis and design methods, quality control through testing and metrics, security assessment and overall development process. Therefore, this question could be considered very general, so it was reformulated in several more specific questions to provide a clear view of the most relevant aspects of proposals addressing the collection of requirements and functional specifications, analysis, design, coding and testing in the context of blockchain smart contracts. Table 1shows together the defined RQs with their motivations and corresponding sub-questions. In addition, the possible answers to be responded are described. C. REVIEW PROTOCOL After formulating each research question, the review protocol must be specified to define search strategies, inclusion and exclusion criteria for primary studies (PS), and quality criteria. This section aims to define these aspects. 1) SEARCH STRATEGY The search strategy is the procedure followed to locate the most relevant PS that have been indexed in different digital libraries. In this sense, this strategy is focused on locating papers published in peer-review journal and international conferences. The search strategy was divided into two phases: •Phase 1. The first phase consists of defining keywords that are going to be used in the search protocol. This definition has been performed after running different pre-searches, which allow to refine the most appropriate set of keywords. In this sense, it is important to obtain appropriate keywords because these allow improving the quality of the results. Table 2presents the keywords used in this SLR. Equation1=[(V4 i=1Ai)∧(V8 j=1Bj)] ∧(V2 k=1Ck) Boolean expression of keywords (1) •Phase 2. After defining keywords, these have been systematically used to carry out searches in different digital libraries. For this purpose, keyword combinations have been used as Equation 1states. This formula formalizes the boolean expression of the keywords used in the searches. Moreover, regarding digital libraries to be used, some authors establish criteria to select the most appropriate libraries. For example, Ngai et al. [48] propose more than ten digital libraries (i.e., Academic Search Premier, ACM Digital Library, Emerald Full Text or IEEE Xplore Digital, among others) considering their relevance. However, during the process of carrying out preliminary searches, we noticed that many papers were repeatedly returned by different digital libraries. After considering this fact, we decided to use only the following databases: ACM Digital Library, IEEE Xplore Digital Library, ScienceDirect, Elsevier’s Scopus, and Springer Link. References were managed using the Jabref tool [23] and a spreadsheet. Equation2=keyword(E1)∧abstract(E1)∧Title(E1) Boolean expression for the metadata of a paper (2) Once keywords and digital libraries were established, search expressions were formalized using Equation 1and executed on each digital library. For this purpose, titleabstract-keyword metadata of each paper were selected as information sources. The use of these metadata is formalized in Equation 2. Each digital library has its own syntax for 164558 VOLUME 8, 2020 N. Sánchez-Gómez et al.: Model-Based Software Design and Testing in Blockchain Smart Contracts: A SLR TABLE 1. Research Questions (RQ). TABLE 2. Keywords. indicating custom search expressions. Moreover, they have certain limits on the maximum number of logical clauses in the same search. Therefore, Equation 2was applied into different queries. Table 3shows each of the queries executed in each of the databases selected in this SLR. In addition, it was also necessary to extend each search query using filters due to the considerable number of search queries. These filters are provided by each digital library. For example, scientific area, specific topic, and year of publication greater than or equal to 2016 were some of the filters applied. Only from 2016, we started to identify paper that enhanced the predefined search criteria. Although Ethereum, for instance, was formally announced by Vitalik at The North American Bitcoin Conference in 2014 [8], the Ethereum network was not launched till 2015. In that year, developers began writing smart contracts and decentralized apps to deploy on the live Ethereum network. Finally, the previously defined systematic search protocol has been extended using the ‘‘snowball’’ technique [71]. This technique involves extending the search process to cover both the reference lists and the citations in each paper under study. Section IV-A describes in detail how the search strategy was executed. 2) SELECTION PROCESS, EXCLUSION AND INCLUSION CRITERIA, AND QUALITY ASSURANCE This section defines the selection process of relevant papers, which are going to be later analyzed considering the objectives of this SLR. Three researchers are responsible for carrying out this selection process. Table 4summarizes each phase conducted in the process of selecting papers for study. Our selection process includes some face-to-face meetings to offer a forum for discussion and agreement between researchers when there are doubts to evaluate a paper. The objective of these meetings is to reduce the bias of each researcher. On the one hand, the first meeting each face is made in the third phase (Ph3) of our selection process (see Table 4). As mentioned above, this phase aims to resolve any doubts when inclusion/exclusion criteria are applied. In these cases, a full reading of dubious papers is necessary. After this reading, all researchers decide — always jointly — to finally include or exclude the PS. The decision must be joint to avoid subjectivity. On the other hand, the second face-to-face meeting (Ph5) is carried out after applying the ‘‘snowball’’ technique and its objective is also to resolve any doubts when the papers returned by this technique are evaluated or when exclusion/inclusion criteria are applied. Regarding exclusion/inclusion criteria, we have established some objective criteria which have been grouped by each phase of the selection process (Table 5). In short, we consider papers written in English and published in well-reputed VOLUME 8, 2020 164559 N. Sánchez-Gómez et al.: Model-Based Software Design and Testing in Blockchain Smart Contracts: A SLR TABLE 3. Search queries. TABLE 4. Phases of the study selection. journals (i.e., journals indexed in Journal Citation Reports; JCR) or prestigious conferences (i.e., A*, A, B and C conference level categorized in CORE Conference Ranking). Regarding international conferences, we have considered conferences. Furthermore, we have decided to exclude surveys, discussion, reviews or opinion papers related to blockchain smart contracts. Finally, Table 5summarizes criteria defined to include and exclude PS during the selection process. 3) QUALITY QUESTIONS Quality Criteria (QC) were defined to obtain the best results for future research. Table 6shows the quality questionnaire applied in this SLR. The cumulative score for each criterion would make up the final quality score for each PS. It is important to note that these quality criteria are not used to exclude papers, but they are used to determine the most relevant and representative PS in future research. 4) DATA SCHEMA The analysis of each PS could become a difficult task due to the heterogeneous information and different structures TABLE 5. Exclusion and inclusion criteria per phase. of each study. In this sense, we propose a characterization scheme (see Table 7) to homogenize this analysis and reduce the complexity of this task. 5) REVIEW PROTOCOL VALIDATION Following the recommendations given in Kitchenham’s method, the SLR protocol was reviewed to obtain a comprehensive review process. As mentioned above, some random searches were applied to refine definitive keywords and exclusion/inclusion criteria, among other aspects. However, we decided to seek advice from experts in the conduct of SLR to define a systematic, full and comprehensive process. In this sense, a Full Professor in Software Engineering at 164560 VOLUME 8, 2020 N. Sánchez-Gómez et al.: Model-Based Software Design and Testing in Blockchain Smart Contracts: A SLR TABLE 6. Quality criteria questionnaire. TABLE 7. Data Scheme. TABLE 8. Summary of PS considered in the systematic review. the University of Seville (Spain) participated as an external expert to validate our review protocol. IV. CONDUCTING AND QUALITY RESULTS This section aims to present the results obtained after executing the review protocol defined in the previous section. This section also presents the set of PS obtained, as well as the quality score of each PS according to our quality criteria questionnaire (cf. Table 6). Finally, Section IV-B describes some threats to this work’s validation process. A. DETECTION, SELECTION OF PRIMARY STUDIES (PS) AND DATA EXTRACTION Table 8presents the distribution of PS obtained after applying inclusion/exclusion criteria in each phase of the selection protocol. For each digital library, it is showed the number of papers thrown up in each stage of the review protocol. Table 8 also includes a record of papers obtained after the ‘‘snowball’’ technique had been applied (to streamline the handling of the results, these papers were not classified by digital library). Figure 2graphically displays the evolution of the considered PS in the search protocol. FIGURE 2. Papers retrieved using the digital libraries. Figure 3displays the number of PS retrieved from each digital library, and finally included in the analysis divided by the number of papers selected from all the digital libraries. FIGURE 3. Analysis of results retrieved from each digital library as a percentage of the total papers included. B. THREATS TO VALIDITY The review and validation protocol presented in previous sections may involve weaknesses or threats on this protocol because the tasks have been conducted by people. Due to this human factor, the selection of papers could be affected by errors during the process of classification and selection of PS. These risks have been mitigated with the execution of several iterations in the review process and several meetings between researchers when there were doubts about the categorization of any PS. Although the review process has been exhaustively defined and executed, it is not possible to guarantee full coverage of the scientific literature about a topic (e.g., non-indexed papers or grey literature are not considered in this SLR). Moreover, Schmucker et al. [60] states that those types of publications are very rarely relevant in SLR results. That is VOLUME 8, 2020 164561 N. Sánchez-Gómez et al.: Model-Based Software Design and Testing in Blockchain Smart Contracts: A SLR TABLE 9. Primary studies (PS) included in the SLR and their quality assessment scores. why in our study the search terms were used in five online digital libraries covering a wide range of topics enough to be reasonably considered exhaustive for the research field on which this SLR focused. Furthermore, it is important to note that all authors have been involved in the definition of the search protocol, RQs and search terms. This decision has allowed to increase the objectivity of the review process. V. DISCUSSION AND ANALYSIS This section aims to answer and discuss each research question to identify state-of-the-art weaknesses according to the objective of this SLR. A. RQ1. ARE THERE APPROACHES IN THE LITERATURE THAT PROMOTE THE APPLICATION OF A SMART CONTRACT DEVELOPMENT LIFE CYCLE? WHAT PHASES OF THE LIFE CYCLE DO THE DIFFERENT PROPOSALS PROMOTE? Table 9shows the PS that were found and finally included in this SLR following all the quality criteria described in Section III-C. It is important to mention that the number of PS has not been reduced after applying quality measurements. These measures allow us to score the most relevant and representative PS for consideration in future research. In this sense, Table 9shows the quality score (chosen in the last column of Table 9; SC column) for each PS. The maximum score for quality measurement is ten points according to the criteria established in Section III-C. For instance, Grigg (PS15) proposes to use the Ricardian contracts. A Ricardian contract places the defining elements of a legal agreement in a format that can be expressed and executed in software. This work is very relevant to be considered in future research. In this studies list, highlights several papers as: •Marchesi (PS01) proposes a software development process to gather the requirement, analyze, design, develop, test and deploy blockchain applications. •Choudhury (PS03) provides a novel framework for autogenerating smart contracts by enabling the seamless translation of constraints encoded in knowledge representation to blockchain requirements. This framework uses ontologies and semantic rules to encode domainspecific knowledge and then leverages the structure of abstract syntax trees to incorporate the required constraints. •Tateishi (PS04) proposes a technique to automatically generate a smart contract from a human-understandable contract document that is created using a document template and a controlled natural language (CNL). The automation is based on a mapping from the document template and the CNL to a formal model that can define the terms and condition in a contract including temporal constraints and procedures. •Mavridou (PS13) argues, in practice, the smart contracts are riddled with vulnerabilities comprising a critical issue. To facilitate the development of secure smart contracts, we have created a framework, which allows developers to define contracts as finite state machines (FSMs) with rigorous and clear semantics. •Syahputra (PS19) discusses the development process of a smart contract platform that aims to generate smart contracts for heterogeneous blockchain technologies. 164562 VOLUME 8, 2020 N. Sánchez-Gómez et al.: Model-Based Software Design and Testing in Blockchain Smart Contracts: A SLR •Mavrodou (PS22) introduces a framework for the formal verification of smart contracts that are specified using a transition-system based model with operational semantics. This framework allows the generation of Solidity code from the verified models, which enables the correct-by-design development of smart contracts. After the detailed analysis of numerous studies, it can be said that software development practice has progressed steadily, and many methods and models have been recommended to enhance its productivity and effectiveness. Royce [58] is acknowledged as the first person to introduce a methodology specifically conceived for software development. Known as the waterfall model, this method was subsequently redefined by many different organizations and people, resulting in several variations known collectively as SDLC methodology. Despite the appearance of some new agile models it is also important to mention that SDLC is still the most widely used development methodology in most organizations [5]. The main phases of SDLC are requirements gathering, system analysis and design, coding, testing, deployment, and maintenance. Table 10 shows the distribution of PS about the phases they support, in the context of smart contract Development Life Cycle. As illustrated in Table 10, the most addressed phases by authors were, respectively: (A1) Requirements gathering, analysis or design phases (68%), (A2) Coding phase (40%), (A3) Testing phase (28%), and (A4) Other phases (12%). In these aspects, highlights the work of Marchesi (PS01) and Tsai (PS05). Marchesi proposes a software development process to collect the requirements, analyze, design, develop, test and deploy blockchain applications. On the other hand, Tsai (PS05) proposes a framework. This framework has 5 stages: smart contract template development from domain analysis, formal smart contract model and code development from templates and verification/validation. It can be concluded that the scientific community’s efforts are currently aimed at implementing some kind of SDLC. But in the smart contract context, this process consists only of a certain number of unlinked phases, lacking in a common vocabulary. These phases are not arranged in a clear order of precedence and the inputs/outputs are not clearly defined from one step to the next. In addition, there is no deterministic ‘‘definition of done’’ that can be used to confirm whether a step is truly completed. On the other hand, it is important to highlight the fact that, despite its importance to efficient blockchain development, the phase with the least impact in the literature is that of software testing. Blockchain differs from other, traditional applications, requiring testers to address specific requirements and acceptance criteria. Once a smart contract is implemented, its execution cannot be reversed. This calls for robust testing with emphasis on code debugging, but blockchain software testing is a highly specialized domain which requires proven expertise and a rigorous approach. Moreover, smart contract TABLE 10. Distribution of primary studies (PS) in relation to the Smart Contract Development Life Cycle phases. testing involves simulating all possible expected and unexpected variables for every smart contract and for the triggers that execute transactions. Smart contract testing requires expert knowledge of scenarios, business, and transaction variables specific to blockchain networks. In this kind of network, with numerous nodes and combinations, automatic testing should predominate. Since smart contracts enforce a set of rules through strong cryptography, it is also necessary to validate encryption codes using robust testing methodologies. Smart contract testing is complicated and requires specialized validation capabilities. Testers need QA (quality assurance software) skills and API skills in addition to regulatory, business process management, security, and compliance skills. B. RQ2. DO THEY PROMOTE MODEL-BASED ENGINEERING, EARLY STARTING OF THE TESTING PHASE OR AUTOMATIC SMART CONTRACT GENERATION? Since a few years ago, modelling tools [59] have been helping document enterprise process functionality and using model transformations to automate software code generation with Unified Model Languages (UML) and other modelling standards. For example, Marchesi (PS01) and Syahputra (PS19) make use of UML-Diagrams to describe the requirements of the applications. UML for testing, known as the UML 2.0 Testing Profile (U2TP) [13] has also closed the gap between designers and testers by providing a good reason for using UML for VOLUME 8, 2020 164563 N. Sánchez-Gómez et al.: Model-Based Software Design and Testing in Blockchain Smart Contracts: A SLR both system modelling and test specification. This allows UML-Design documents to be reused for testing and, most importantly, enables test development in an early phase of system development. Since models are usually easier to understand than software source code [24], it also makes it possible to improve development productivity and quality. It is easier to check the correctness of a model, and modelling tools can ensure that the deployed code, from the model, has not been modified after its generation [40]. Model-based software engineering [53], [56] is important in blockchain-oriented applications for the following reasons: •Best practices can be implemented, and well-tested codes generated, thereby reducing the occurrence of vulnerable code. Moreover, model-based tools can improve the verification/validation of smart contract code by applying testing techniques right from the early stages of the SDLC, a practice known as early testing. •The software code is more difficult to understand than the models. It is, therefore, easier to check the correctness of a model. Software code can also be generated automatically from model-based tools, thus ensure that the generated code has not been modified after it is obtained. •As they are platform-agnostic, models can avoid lockin to specific blockchain technology and model-based engineering can be applied across multiple blockchain platforms. Table 11 shows the distribution of PS concerning this type of proposals. As the table shows, the types of proposals most addressed by authors are, respectively: (B1) Application of model-based software engineering (48%), (B2) Promotion of early testing (5%), and (B3) Proposal of automatic code generation (48%). It can be concluded that although early testing helps to reduce the number of defects and, ultimately, cuts the cost of final revisions, the scientific community’s efforts are currently not aimed at this approach. Every software engineer knows that if a bug is detected in the final stage of testing [59], changes may then need to be made in the design and analysis phase. It is therefore important to carry out testing in every phase to ensure that software will run according to expectations and will not fail once it has been delivered to the client. When testing is performed at the end of the SDLC, i.e., after the coding phase, there may not be enough time to do it properly, resulting in compromises which could affect the quality of the software [27]. Early testing will provide enough time to identify the absence or inadequacy of any functional requirements. Moreover, test cases obtained from the requirements and shared with the developer’s team before the coding phase may reveal new possibilities and help them to estimate the chances of failure in their code [27]. In this context, Koul (PS06) highlights the need to deliver first-time quality while minimizing the impact of testing on the delivery teams. This PS stands out the challenges TABLE 11. Distribution of primary studies (PS) according to the scope of their proposal. currently faced in testing such applications. It also acknowledges the need to devise specialized tools and techniques for blockchain-oriented software testing to ensure high standards of quality. In short, the role of software testing is not only to verify the ‘‘rightness’’ of the software but rather to discover defects in time for then be rectified. The goal should be to develop smart contracts with higher quality code and as few errors as possible. Exhaustive testing, covering 100% of a software’s functionality, is not possible, but it is important to eliminate the highest number of errors as soon as possible. All members of the development team should be involved early in the SDLC. This will, in turn, have a positive impact on the development of the smart contract. If there are testers at the beginning of the development cycle, then errors can be reported at every step and team members may contribute to remedying those errors. By including early testing throughout this process, smart contracts can be implemented with higher reliability, and lower development costs [27]. Another important aspect to consider in connection with automatic smart contract generation is the technique used. Table 12 shows the distribution of PS regarding the different techniques used in the proposals. In our opinion, another important aspect is an automatic smart contract code generation using a model-based software engineering process. This eliminates the manual effort required in coding from design and therefore accelerates the process while decreasing the possibility of errors in comparison with manual coding from requirements or models. As the table shows, the techniques most proposed by authors are, respectively: (C1) Automatic code generation 164564 VOLUME 8, 2020