JURNAL RISET INFORMATIKA Vol. 3, No. 2 March 2021 P-ISSN: 2656-1743 |E-ISSN: 2656-1735 DOI: https://doi.org/10.34288/jri.v3i2.188 137 The work is distributed under the Creative Commons Attribution-NonCommercial 4.0 International License THE BLACK BOX TESTING AND LOC METHOD APPROACH IN TESTING AND STREAMLINING THE PATIENT REGISTRATION PROGRAM Joosten Information System STMIK Mikroskil https://www. mikroskil.ac.id joosten.ng@mikroskil.ac.id Abstrak Software yang baik dapat digunakan jika ada pengujian yang tepat. Tahap pengujian cukup penting karena software perlu diuji sebelum digunakan oleh pengguna akhir. Pada pembuatan software untuk rumah sakit hewan belum adanya validasi dan verifikasi sehingga diperlukan pengujian. Penelitian ini menggunakan informasi bagian pendaftaran pasien rumah sakit hewan dan diuji dengan tiga metode Black Box Testing, yaitu Equivalence Class Partitioning (ECP), Boundary Value Analysis (BVA), dan Decision Table ditambah pendekatan LOC. Hasil pengujian dari ketiga metode tersebut adalah persentase ECP yang tidak valid lebih besar dari yang valid, sehingga perlu diubah lagi batas nilai inputnya. Kemudian untuk pengujian BVA, persentase yang valid lebih tinggi daripada tidak valid. Dalam tabel keputusan dibuat aturan pemendekan antara layanan operasi dan layanan lainnya sehingga menghasilkan status rawat inap dan besaran uang muka secara otomatis tanpa harus memilih lagi dan diuji kembali oleh decision table dengan cara mencocokkan hasil estimasi dari kedua layanan tersebut. Kata kunci: BVA, Decision Table, ECP, Pengujian, Validasi, Verifikasi Abstract Good software can be used if there is proper testing. The testing phase is quite important because the software needs to be tested before it is used by end users. In making software for animal hospitals there is no validation and verification so testing is needed. This study used information on the registration section of veterinary hospital patients and was tested by three Black Box Testing methods, namely Equivalence Class Partitioning (ECP), Boundary Value Analysis (BVA), and Decision Table plus the LOC approach. The test results of the three methods are that the percentage of invalid ECPs is greater than the valid ones, so the input value limit needs to be changed again. Then for BVA testing, the percentage of valid is higher than invalid. In the decision table, a shortening rule is made between operating services and other services so that it produces inpatient status and down payment automatically without choose it again and is tested again by the decision table by matching the estimation results of the two services. Keywords: BVA, Decision Table, ECP, Testing, Validation, Verification INTRODUCTION Today technological developments are increasingly developing in this modern world. One of them is software development or what is called software. The widespread software applications of the Internet and mobile computing have significantly increased the dependence on enabled software systems (Xu et al., 2015). One of the stages in software development is software testing. The role of testing activities is very important because testing is one of the activities that must be carried out on software developed before the software is applied by users or end-users. There are three main reasons for the importance of software testing, namely errors or deficiencies in software can occur, the application must be the best, and end-user satisfaction is everything (Solution, 2018). Testing is the process of checking software, both internally and externally. From the internal side, testing is carried out to see the statements that have been tested. While on the outer side, testing is directed to find errors that arise from the software and ensure that the limited inputs can produce the desired actual results according to the expected results. The increasing demand for software makes the testing aspect always neglected. Testing is an important part of the software development process (Hierons & Member, 2015). The complexity of the software programming logic flow that developers make is one of the problems when entering the testing phase. Developers often find it difficult to get http://creativecommons.org/licenses/by-nc/4.0/ P-ISSN: 2656-1743 | E-ISSN: 2656-1735 DOI: https://doi.org/10.34288/jri.v3i2.188 JURNAL RISET INFORMATIKA Vol. 3, No. 2 March 2021 138 The work is distributed under the Creative Commons Attribution-NonCommercial 4.0 International License errors in the software they make due to algorithms that are too complex. Users sometimes don't care if the software has an error or not. Ignoring testing activities in the software results in the results (output) that is displayed sometimes not as expected. Ordinary users will tell the developer to change the program they make in order to produce maximum results and satisfactory program performance. Joel Spolsky (Spolsky, 2020), a software developer in New York City, wrote an article discussing the top 5 reasons (wrong) that a tester is not needed. Joel is applying for a job at a company led by Mr. Gleick. Joel asked Mr. Gleick about the Pipeline that Gleick created. Joel sees that Gleick's creation has problems such as not using an error correction protocol so that it can damage or crash. But Gleick denies that Pipeline has no bugs and is just as bad as Ms. Word from Microsoft. Both reasons from Gleick kept Joel from applying to Gleick's company. From Joel Spolsky's case, it can be concluded that the average person ignores the validation, verification, and testing of the software that is made. Neglect of software testing makes the software unable to work optimally and many errors occur. This study discusses several methods that can be used to test software so that the software can work optimally. The use of excessive costs in software testing causes the quality of the software to be poor. Every year, poor software quality losses exceed $ 500 billion (Shahbazi & Miller, 2016). The National Institute of Standards of Technology (NIST) (Rep, 2002) conducted a study in 2012 that explained the United States economy calculates a loss of $ 59.5 billion every year due to bugs in software created. NIST explains about one-third of these losses can be avoided if the developers do software testing better. More than half the cost of fixing bugs given to software users is given to developers and vendors (Wong et al., 2016). Besides the use of large costs, another thing that assumes that software testing is not needed is the time spent. In the 1980s, one of the most notorious cases of software development failure was the Ariane rocket (Lynch, 2017). The rocket exploded due to software failure. As a result of the explosion of the rocket, the researchers over the years focusing their efforts on looking for problems or bugs in the software on the rocket. Rashad Khalid (Khalid, 2017) conducted a study that focused on the efficiency side of software testing by combining two methods, namely the black box testing method with the white box testing method. Khalid developed an automated analysis and testing technique consisting of two main steps: 1) the first step was to take the software under test (sut) and identify all files, input and output variables, and functions. 2) in the next step, the user selects the desired module part or function to test and selects the required tests such as dead-code, assertion based tests and exception tests. The programming language khalid tested was the c ++ programming language. Khalid claims the tools he recommends can perform various tests such as static analysis, unit testing, dead-code testing, exception testing and assertion based testing. But the program code that khalid tested was only a simple program and did not tell from the efficiency side whether the recommended tool could handle the limited testing time or not so that the tool did not guarantee the success of the test when the program code was quite complex. Christopher Dimas Satrio et al (Satrio et al., 2018), conducted a study comparing a test case generation with two genetic algorithm approaches, namely mutual analysis and sampling. The two approaches will be compared from the reduction in test cases that occur. Apart from reducing the test case, the number of iterations, the total number of individuals, the number of fitness evaluations, and the size of the test suites will also be a comparison between the two approaches. From the two approaches, it was found that the genetic algorithm mutual analysis approach was better than the genetic algorithm sampling in terms of the number of test case reductions and all the comparative variables applied. However, in terms of execution time, it is still assumed that the genetic algorithm mutual analysis is faster, so there has been no decision that the genetic algorithm mutual analysis approach is faster when executing larger sample data. Researchers also concluded that to increase the effectiveness and efficiency in software testing by shortening the time that must be allocated for the testing carried out. But the researchers did not explain how long the time should be allocated, so they had to see how complex the software to be tested was. Marcel Bohme and Soumya Paul (Bohme & Paul, 2016), conducted a study that analyzed the efficiency between random testing (r) and systematic testing (S0). They built a general model for software testing by specifying a sampling strategy on random testing and systematic testing associated with cost and sampling time. They considered two such strategies whereby random testing was unaware of partition based errors and systematic testing that sampled each partition exactly once. They perform calculations on these two strategies to calculate the relative efficiency value. In the end they conducted 24000 simulation experiments with various parameters. However, in http://creativecommons.org/licenses/by-nc/4.0/ JURNAL RISET INFORMATIKA Vol. 3, No. 2 March 2021 P-ISSN: 2656-1743 |E-ISSN: 2656-1735 DOI: https://doi.org/10.34288/jri.v3i2.188 139 The work is distributed under the Creative Commons Attribution-NonCommercial 4.0 International License this study there are recommendations from researchers to compare systematic testing techniques to random techniques with a given time limit practically because they assume random techniques must have the same "power" compared to systematic techniques so that there may be other testing techniques that can overcome the time required. Limited compared to using random techniques. RESEARCH METHODS This study uses methods to verify, validate, and test the hospital information system program. The methods used are Equivalence Partitioning (EP), Boundary Value Analysis (BVA), and Decision Table added with the Line of Code (LOC) approach to count the number of rows before using the Decision Table and after using the Decision Table. These three methods are part of the Black Box Testing method. Black Box Testing is a software testing technique that focuses on the functional specifications of the software being developed (Jaya, 2018). The way Black Box Testing works is only to check the output value based on the software input value without knowing what program code is used. Equivalence Partitioning (EP) or what is often called Equivalence Class Partitioning (ECP) is a technique or method that produces test data from several system requirements by grouping or dividing input data and testing the data in order to get several understandable and feasible categories (Jahanbin & Zamani, 2018). From these methods, there are several combinations that can occur in Equivalence Partitioning, including: a. Valid and invalid input values b. A numeric value that is negative, positive, or zero c. An empty, non-empty string Boundary Value Analysis (BVA) (Ardana, 2019) is a technique of the Black Box Testing method that focuses on the input process by testing the values at the upper and lower limits. There are three principles that underlie the Boundary Value Analysis (BVA) method are: a. Many errors occur with input errors b. Select a test case that tests the limits of input values c. BVA is a part of Equivalence Partitioning that selects elements in the equivalence class at the value limit. Decision Table is one of the techniques of the Black Box Testing method that uses tables to perform testing and can also be used to shorten the logic flow of software programming. Decision Table Testing (Joosten et al., 2020) is a software testing technique used to test software on different input combinations by combining different input and output values and summarizing them into a table. Decision Table is also often referred to as a cause and effect table because of the several causes and effects used to create a Decision Table. The reason the decision table is quite important is as follows (Joosten et al., 2020): 1. Very helpful in test design techniques. 2. Help testers to look for the effect of the combination of various inputs and the status of other software that must implement business rules properly. 3. Provide a regular way to express complex business rules, which is beneficial for both developers and testers. 4. Assist in the development process with a developer to do a better job. Testing with all combinations might not be practical. 5. This method is basically a technique used in testing and managing requirements. 6. This method is a structured exercise to prepare the requirements when dealing with complex business rules. 7. It can also be used in complex logic models. Line of code or what is often referred to as the source line of code (SLOC) is a software metric that is often used to measure the size and complexity of a software project. There are two main types of SLOC calculations, namely Physical SLOC (P-SLOC) and Logical SLOC (L-SLOC). The definition of P-SLOC is the line count in the source code text of the program as well as comment lines and blank lines. Meanwhile, L-SLOC is responsible for measuring the number of expressions that can be executed. The intended expressions are operators, functions, etc. So if there is one or more statements which are followed by the end-of-line comment is a line of code and is counted into L-SLOC. Meanwhile, comment lines and blank lines will not be counted into L-SLOC. In addition to Physical SLOC, Logical SLOC, comment line of code (CLOC), blank line of code (BLOC), there are also code & comment source line of code (C & SLOC) and comment words (CWORD). To find out the calculation of the number of lines in a source code such as P-SLOC, L-SLOC, and others, below is an example of source code: #include #include #include using namespace std; int main () { char lagi; int name; int option; int number; int paid; http://creativecommons.org/licenses/by-nc/4.0/ P-ISSN: 2656-1743 | E-ISSN: 2656-1735 DOI: https://doi.org/10.34288/jri.v3i2.188 JURNAL RISET INFORMATIKA Vol. 3, No. 2 March 2021 140 The work is distributed under the Creative Commons Attribution-NonCommercial 4.0 International License int price; int total; int code; // create menu list // cout << endl ends list; early: system("cls"); cout<<"======================"<