Figuring out how to balance resources for a software testing process can be overwhelming. Software components have different levels of complexity, which require different processing times. Different skill levels of resources, further modify the time to process. The order in which the components are scheduled provides additional complexity. Rework loops increase the level of difficulty. This is a multi-dimensional problem that can only be guessed at without simulation.
This article is only an example of how simulation and modeling can be applied to software development and testing. These techniques apply to many other software activities.
The real question we should be trying to solve is what’s the balance of resources that will minimize our cost and shorten our delivery time.
- How to Find the Software Testing Model
- How the Model Was Built
- Model Simulation & Output Report
- Model Optimization
- How to Import Raw Data
How to Find the Software Testing Model
Before we move further, let’s download the example model.
Download the Software Testing example model.
The example model needs ProcessModel to open and run. Make sure that you have ProcessModel installed on your computer. If you do not have ProcessModel, Request a Trial.
Once you have the model downloaded, open it in ProcessModel and let’s start reviewing how the model is built.
How the Model Was Built
1. Most of the objects in the model are color-coded.
1. All the activities are in light yellow.
2. All the resources are colored and numbered.
3. The squares in the light blue, green, or red background are highlighted texts that describe specific paths.
4. The objects at the bottom of the model, the people running, are used to attach the different optimizations files, which we will use later (below).
2. Activities have a separate input queue before them. For someone familiar with ProcessModel, this will look odd, since traditionally the input queue is defined in the activity by default. Here the input queue is separated so that we can define action logic in the input queue to capture resources, using the Excel files. Otherwise, Action Logic in the input queue, would not have been possible. The input queue in the activity itself is set to zero.
3. All activities have zero in the Time field. This is because all the times are accomplished using the action logic using attribute values, arriving with the entities.
4. Software Components are introduced into the model using a scheduled arrival. Opening the scheduled arrival, you can review all the arrivals having action logic. The attributes provide the processing time at each station.
5. The two Excel icons attach the two Excel files that will be needed to prepare and import user data into the model.
6. The three resources on the left have unique scenario parameters set as the quantity, p_NumbTester, p_NumbDesigner and so on. Scenario parameters provide a way to change the number of resources during experimentation.
7. Open the Attributes, Variables & Scenarios window by clicking Insert \ Attributes, Variables & Scenarios.
1. Entity Attributes:
1. a_TimeIN is used to record the time the Software Component enters the input queue.
2. a_Time_*Act-Name* provides the processing time for each entity at the activity name. The attribute is defined in scheduled arrivals.
3. a_ErrorRate_*Act-Name* The error rate attribute records potential errors on this software component.
2. Variables:
1. v_EntCheck# This is an internal variable to control the selection of resources.
2. v_*Act-Name*_TimeInQ Used to store the time software components have spent in the input queue, waiting.
3. Scenario Parameters:
1. p_Numb*Res-Name* is used to control the number of resources available for an experiment.
2. p_CostPer*Res-Name* Hr is used to control the hourly cost associated with a particular type of resource.
8. Notice there is action logic in the input queue and the action logic of the activities. Because we will be using the Excel files, we do not have to write or change this logic.
At this point, it is a good idea to go through the basic model flow to understand what is happening within the model. A software component comes in, goes to the input queue of the Design Test Cases, where the component must wait for a resource to become available. The software component then moves into the actual capacity. After capturing the proper resource and performing the processing time, the component moves to the input queue of Design Test Classes, and so on.
Model Simulation & Output Report
Now that we have a grasp of the model flow and what makes it work. Let’s simulate the model, and then view the Output Report.
Click the Simulate button to start the simulation.
You should now see a new window with the movement of the components animated. Spend some time reviewing where the animation to see where the components are getting stuck and so on.