My life as a software tester, sometimes, when I’m using a certain application, my behavior to that application is like doing a test in it, beside phone application, sometimes home appliances, and so forth. Yesterday, I played Minion Rush, created by Gameloft, on my iPhone 4, and at the same time, my friends sending me several conversations using whatsapp, and here goes the bug.

On Minion Rush, I was playing on El Macho’s Lair, at the sliding deck, at the same time three friends of mind sent messages through Whatsapp. I kept playing and ignore the message, however, although Minion had finished sliding, the character was behaving like it’s still on the sliding, even when it crushed with the green statue, it didn’t die. Here’s the screen shot.

After Passing the ISTQB-ISEB Foundation Certification, I consider to post about how to find out decision coverage percentage. Here is a case study:

There is a pseudocode:
Begin
Read Time
If Time 12 Then
print(Time-12, “pm”)
Endif
If Time = 12 Then
print(Time, “noon”)
Endif
End

If the test cases Time=11 and Time = 15 were input, what level of decision coverage would be achieved?

Let’s find out the solution of case study up there:

Take a look at first condition –> If Time if Time > 12 Then…
if Time = 11 then the first condition will be False. (3)
and if Time = 15 then the first condition will be True. (4)
So: Again, Both of possibility are fulfilled for the second condition.(2 results)

Okay, Let’s try the third condition –> if Time = 12 Then…
if Time = 11 then the first condition will be False. (5)
and if Time = 15 then the first condition will be False. (6)
For this condition, with Time=11 and Time=15, we only get False condition and there is no True condition. Because there is no True condition for those two test cases, we count the coverage as 1 (result is False only). (1 result)

Testers do the bulk of the “grunt” work needed to move your application towards better performance. They provide accurate measurements in a timely manner. The accuracy and relevancy of their tests helps drive Management, Developers and Production towards measurement-driven thinking. Engineering rather than guesswork. When the role of the tester is misunderstood then the sloppily executed, poorly reported, or untimely, slow to emerge test data is often thrown out and disregarded by the very groups it is intended to help.

Important qualities, therefore, for load and performance testers include:

a dedication to accuracy and precision

a sense that they are communicating to the entire organization, not only merely verifying their tests.

flexibility to work overtime if needed.

system level thinking, an understanding that a bottleneck could be anywhere, SQL, Network, Web code, etc.

project management skills to work through company blockages to getting the data.

ability to work as a team member, both on the L&P team and within other devs, PMs and manager