Technical Aspects of Game Test Automation

Test automation always ahs been a lucrative way of reducing the monotonous burden on the tester. But beyond the standard incentives for test automation, sometimes automation can become almost imperative for certain kind of games. The obligation of automation is explained below:

• Game Speed : Sometimes, the game is to played at very high speed (say hardest level or fastest mode), which can be achieved only after a certain level of skill and experience with that particular genre of games. In this case, the tester must either spend hours in becoming master of a game, or resort to some automation technique.
• Game Complexity : Game play may become quite complex and the user may not be sure about the next move. This happens in planning games (ranging from Chess to Lemonade Tycoon), luck games (like card games) and in almost all multi-level games after more complex levels are reached. Again, the tester must either spend hours in becoming master of a game, or resort to some automation technique.
• Multiple Builds : In any commercial software – more so in games – the developer may give several builds (versions) of the game before the final market-ready build. The initial builds have several flaws (popularly called as BUGS), which are progressively removed in further builds. Every time, a similar suite of test cases has to be executed and the automation of this suite can pay rich dividends in the long run. In the current Game Testing project done by the team, some thirty-six different file versions of the game have been tested for nine consecutive builds, with minor modifications. Thus, a few extra efforts done for making automation on the first build, result in substantial saving of time and efforts later.
• Time/Logic Constraint : Games may need a long sequence of moves to attain completion. A classic example would be the card games like Solitaire. In such games, the tester would have to expend a lot of time to reach the end-game scenario. Secondly, the tester would have to continually apply logic for making the right moves. So his efforts are directed at playing the moves, rather than testing the game behavior. Here automation can play wonders, by handling the game moves and leaving the tester free to focus on the other aspects. (We will see the way to manage this later)
• Load Simulation : For multiplayer games, the tester would have to manually load the game across several platforms or use network techniques to simulate the multiplayer situation. Either way, a lot of efforts are required and still the conditions are not adequately simulated. Testing tools can provide the multi-user simulation easily.
• Scenario Simulation : A classical problem in game testing is when the user suspects a bug in some peculiar game scenario, but is unable to reach that particular stage easily. Suppose you believe that the transition between given levels causes a problem if some other control parameter has a particular state(Imagine that you want to see the transition from 12th to 13th level when the game character has its last life). The situation becomes also arises in case the game algorithm is already proven, and the current focus is on game experience (UI and performance verification). The tester has no desire to play the game moves, but is forced to do so, just to reach the desired stage. A testing tool, correctly programmed can provide the scenario simulation easily.

Don't miss any article:Get it by E-mail

Software performance testing: There is no 'I' in 'team'

"When everyone on the team does his job and works together to support one another the net result is almost always dramatically more desirable"

It makes more sense to think about performance testing and tuning as a team sport in which the following takes place:

• The team works together collaboratively
• The team is informed and involved in the decision-making process about what to test next
• The team generates ideas about how the performance tester can help isolate performance issues using the tools that are exclusively available to him
• The team finds out about performance issues in real time
• The team gets to work together to help find functional errors under load
• The members of the team who best understand the various components of the system under test get to participate in analyzing the results data in real time
• The performance tester gets to sit next to the developer during the tune-retest-retune-retest cycle (frequently shortening that cycle from days or weeks to hours)
  Maybe I should rethink my conference

When everyone on the team does his job and works together to support one another the net result is almost always dramatically more desirable.

Like the guide, then subscribe by entering you mail id to get updates daily
Don't miss any article:Get it by E-mail

Living life as a Software Tester!

Recently I read a very interesting article on “All I Ever need to know about testing” by Lee Copeland.I was so impressed with the concept of our day to day work comparison with the software testing.

I will extract only points related to software testing. As a software tester keep in mind these simple points:

Share everything:

If you are a experienced tester on any project then help the new developers on your project. Some testers have habit to keep the known bugs hidden till they get implement in code and then they write a big defect report on that. Don’t try to only pump your bug count, share everything with developers.

Build trust:

Let the developers know any bug you found in design phase. Do not log the bug repeatedly with small variations just to pump the bug count. Build trust in developer and tester relation.
Don’t blame others:As a tester you should not always blame developers for the bugs. Concentrate on bug, not always on pointing that bug in front of all people. Hit the bug and its cause not the developer!

Clean up your own mess:

When you finish doing any test scenario then reconfigure that machine to its original configuration. The same case applies for bug report. Write a clean effective bug report. Let the developer find it easy to repro and fix it.

Give credit to others for their work:
Do not take others credit. If you have referred any others work, immediately give credit to that person. Do not get frustrated if you not found any bug that later has been reported by client. Do work hard, use your skill.
Remember to flush Like the toilets flush all the software’s at some point. While doing performance testing remember to flush the system cache.

Take a nap everyday:
We need time to think, get refresh or to regenerate our energy.Some times its important to take one step back in order to get fresh insight and to find different working approach.

Always work in teams, team score are always better and powerful than individuals.

Like the guide, then subscribe by entering you mail id to get updates daily
Don't miss any article:Get it by E-mail

Top 20 replies by Programmers to Testers when their programs don't work:-)

1. "That's weird..."
2. "It's never done that before."
3. "It worked yesterday."
4. "How is that possible?"
5. "It must be a hardware problem."
6. "What did you type in wrong to get it to crash?"
7. "There is something funky in your data."
8. "I haven't touched that module in weeks!"
9. "You must have the wrong version."
10. "It's just some unlucky coincidence."
11. "I can't test everything!"
12. "THIS can't be the source of THAT."
13. "It works, but it hasn't been tested."
14. "Somebody must have changed my code."
15. "Did you check for a virus on your system?"
16. "Even though it doesn't work, how does it feel?
17. "You can't use that version on your system."
18. "Why do you want to do it that way?"
19. "Where were you when the program blew up?"
20. "It works on my machine"

Finally they won't fix it :)

Like the guide, then subscribe by entering you mail id to get updates daily
Don't miss any article:Get it by E-mail

Funny Software Testing Terminology !

Here is a list of types of testing that we'd like not to see:

AGGRESSION TESTING: If this doesn't work, I'm gonna kill somebody.

COMPRESSION TESTING: []

CONFESSION TESTING: Okay, okay, I did program that bug.

CONGRESSIONAL TESTING: Are you now, or have you ever been a bug?

DEPRESSION TESTING: If this doesn't work, I'm gonna kill myself.

EGRESSION TESTING: Uh-oh, a bug... I'm outta here.

DIGRESSION TESTING: Well, it should work, but let me tell you about my truck...

EXPRESSION TESTING: #@%^&*!!!, a bug!

OBSESSION TESTING: I'll find this bug if it is the last thing that I do.

OPPRESSION TESTING: You will test this, now!

POISSION TESTING: Alors! Regardez le poission!

REPRESSION TESTING: It's not a bug, it's a feature.

SUCCESSION TESTING: The system is dead. Long live the new system!

SUGGESTION TESTING: Well, it works but wouldn't it be better if...

PRESIDENTIAL TESTING: Using the definition of testing as defined in the affidavit...

Like the guide, then subscribe by entering you mail id to get updates daily
Don't miss any article:Get it by E-mail

Who is a Good Developer ?

A good programmer is someone who looks both ways before crossing a one-way street.

Like the guide, then subscribe by entering you mail id to get updates daily
Don't miss any article:Get it by E-mail

Think of it and Answer

How many testers does it take to change a light bulb?

ANSWER: Testers just report that it's dark.

Like the guide, then subscribe by entering you mail id to get updates daily
Don't miss any article:Get it by E-mail

Developers are not good testers. What you say?

This can be a big debate. Developers testing their own code - what will be the testing output? All happy endings! Yes, the person who develops the code generally sees only happy paths of the product and don’t want to go in much details.

The main concern of developer testing is - misunderstanding of requirements. If requirements are misunderstood by developer then no matter at what depth developer test the application, he will never find the error. The first place where the bug gets introduced will remain till end, as developer will see it as functionality.

Optimistic developers - Yes, I wrote the code and I am confident it’s working properly. No need to test this path, no need to test that path, as I know it’s working properly. And right here developers skip the bugs.

Developer vs Tester: Developer always wants to see his code working properly. So he will test it to check if it’s working correctly. But you know why tester will test the application? To make it fail in any way, and tester surely will test how application is not working correctly. This is the main difference in developer testing and tester testing.

Should developers test their own work?

I personally don’t mind developers testing their own code. After all it’s there baby They know their code very well. They know what are the traps in their codes. Where it can fail, where to concentrate more, which is important path of the application. Developer can do unit testing very well and can effectively identify boundary cases.

This is all applicable to a developer who is a good tester! But most of the developers consider testing as painful job, even they know the system well, due to their negligence they tend to skip many testing paths, as it’s a very painful experience for them. If developers find any errors in their code in unit testing then it’s comparatively easier to fix, as the code is fresh to them, rather than getting the bug from testers after two-three days. But this only possible if the developer is interested in doing that much testing.

It’s testers responsibility to make sure each and every path is tested or not. Testers should ideally give importance to all small possible details to verify application is not breaking anywhere.

Developers, please don’t review your own code. Generally you will overlook the issues in your code. So give it to others for review.

Everyone is having specialization in particular subject. Developers generally think how to develop the application on the other hand testers think how the end user is going to use the application.

Conclusion:

So in short there is no problem if developers are doing the basic unit testing and basic verification testing. Developers can test few exceptional conditions they know are critical and should not be missed. But there are some great testers out there. Through the build to test team. Don’t waste your time as well. For success of any project there should be independent testing team validating your applications. After all it’s our (testers) responsibility to make the ‘baby’ smarter!!

What you say? Comment here

Like the guide, then subscribe by entering you mail id to get updates daily
Don't miss any article:Get it by E-mail

Post Credits: Softwaretestinghelp