# A Methodical Approach to Functional Exploratory Testing for Embedded Systems
## 2 Exploratory Testing  
A common problem of many organizations when it comes down to product development is creating and maintaining functional requirements. Some fail to do it properly because they lack a systematic approach, while some suffer from low capacity while working on complex projects, or pay less attention to the documentation because of the framework or style of work they have chosen to operate within. Exploratory testing was coined by [PERSON] in [16] and was then expanded upon as a teachable discipline by [PERSON], [PERSON], and [PERSON] in [17]. Exploratory testing combines test design with test execution and focuses on learning about the system being tested [21]. This is an extremely helpful aspect when testing products without proper functional requirements specifications. Simultaneous learning, creating a test design, and performing product verification are the essence of functional testing. Moreover, when working on projects that lack functional requirement specifications, exploratory testing may be used for additional coverage. Although exploratory testing can be used as a beneficial supplement for traditional script testing, the software industry has long praised, but also criticized, its applications. It does not belong to any specific testing technology and cannot be constrained by a certain testing characteristic during testing. It can be applied within any testing phase or test implementation, and can also be combined with corresponding test technologies [22]. ET is often opposed to scripted testing; however, exploratory testing can apply varying degrees of exploration, from fully exploratory to fully scripted [23]. Therefore, the question is not whether to apply ET, but rather when to apply which level to achieve the desired outcome. [PERSON] et al. rightly claim that all testing is exploratory, at least to some degree, and exploration is the natural mode of testing [24]. Both scripted and unscripted testing require a level of familiarity with the device being tested. However, in the case of ET, it adds a level of intangibility and requires test engineer's experience, sometimes becoming an art of its own. Considering that statement, exploratory testing is not only reliant on tacit knowledge, but is a process for developing tacit knowledge about a product that enables better testing. Since ET relies on the knowledge of engineers, the question is whether it is possible to take a structured approach by providing a model to support the optimization of exploratory testing on a case-by-case approach. Based on many interviews with industry practitioners,models are being developed that provide systematic test improvements over time [21; 25]. Other work aims to minimize the drawbacks of exploratory testing (the time and resources required for manual execution) by combining it with model-based testing techniques to automate the process [26]. The results of the work show that this approach can be effective. Exploratory testing techniques are also evolving toward the application of machine learning and the use of neural networks [27; 28; 29]. To present the difference between scripted and exploratory testing, we take a typical simplified process for creating and executing a traditional test case design, based on the functional requirement specification:  
1. Requirements analysis. 2. Define the coverage area and test objective. 3. Create the description and test conditions. 4. Identify any preconditions. 5. Develop the test procedure (test steps), including test data, and a pass/fail criteria. 6. Perform the review. 7. Approve the procedure and include it within the test suite. A test case created by following those steps can be automated, or automation can simultaneously be a part of the process. Exploratory testing typically follows a less formalized approach, which is reduced to defining the test objective without giving the exact steps as to how to perform the procedure.