There is a compelling reason why software testing cannot be a shallow activity, and a lot of it depends on the factor of Time…
If I ask you to define time, what would be your response?
In the context of simplicity this becomes extremely trivial. The modest and most collective elements of our daily lives are sometimes the hardest to explain. Among these things is also the element of time. According to a first hit definition on Google, we may define time as:
A component quantity of various measurements used to sequence events, to compare the duration of events or the intervals between them, and to quantify rates of change of quantities in material reality or in the conscious experience
Time: an important element:
While developing software applications time plays an important role. That is why the boundary testing and importance of date field is always on the top list of developers and testers.
For software testers, time plays an interesting role. If we look closely at the Heuristics Test Strategy model by James Bach and Michael Bolton, you would notice that they have used the factor of time right from the start, the definition of Quality:
“Quality is value to some person who matters at some time”
(Jerry Weinberg, Michael Bolton and Markus Gartner)
For example, the mobile devices we used 10 years ago are useless to us now, but then, if we need to test a certain application or develop a function for those devices then the requirements, results, and perceived quality will be guided by the principles set by the quality perceptions of that device only.
Time in Test Strategy:
The heuristics test strategy model or HTSM, starts with Project Environment heuristics, and we all know that a Project is nothing without time schedules and the resources embedded within that schedule. The heuristic for project environment for testers has:
Project Environment:
Mission, Information, Developer Relation, Test Team, Equipment and Tools, Schedules, Test Items, and Deliverables. This clearly tells us the importance of having timelines project management is as necessary as keeping them in Test Life Cycles as well.
Product Elements:
Second mention of “time” comes when the testers define Product Elements, where the element of time and its subsequent effect on a product is depicted deeply in terms of: Inputs and Outputs, Fast and Slow, Rate of change, and Concurrency.
These parameters help in identifying the effect of time on a product, and by the practice, this activity is not shallow. Testers who actually investigate time, has to be patient and precise – for example, revealing the effect of time as per the inputs and outputs or rate of change effect will be executed with the same care as lab experiments are carried out.
Perceived Quality:
Perception of quality is impossible without the inclusion of time, otherwise we will not have expiry dates on the products and the concept of shelf life will have no importance – and we the humans, would have lived forever.
In order to define the quality criteria for a product, testers can use the heuristics of FEW-HICCUPPS. The “H” in the heuristic represents “History”, which points that the system under test must be consistent with its previous versions, and in case it is not then what can be the reasons, causes and issues behind this change.
The criteria also points towards the “Familiarity”, which represents the effect of time in a rather different slant, where the testers expect from the system to be inconsistent with its past bugs. To track these bugs, a system needs to be executed with the same environment and time frames. Remember, quality is value to some person at some time”
Other important factors:
Time has its effect when testing is carried out in automated environment as well. But in this case the tools helps the user actually do a leap in time. The dummy data and number of users are two factors which cannot be reached right at the time of application being launched. It takes time, but for testers, the tools makes it easier.
In case of functional testing the testers need to identify the scenarios where the effect of time can take its effect. The game testers cannot reach a certain stage without playing all the stages, and that includes time as the principle driving force. There are objects in call, which are activated only with time or the instance where other objects interact with them, gamers can tell as gamers know this.
A guiding Process Stimulus:
System behavior in relation to time is something very critical for testers to test and developers to develop. For example, what happens to the web page with critical information being left idle for a certain time period, or what happens when a certain time or date is invoked in a payroll application, or an attendance system? All these criticalities cannot be tested manually or with just a shallow dive into the test data, testers need to go deep to find the right answers.
Time plays a critical role in forming behavior of application and the data it processes, the challenge for testers is to identify the areas affected by time, or where the later becomes the guiding process stimulus.
