Quote:- If you can’t do great things, do small things in a great way.
Automated testing requires more discipline compared to manual, Learning automation is not difficult but it requires a focused and planned approach. Keep this in your mind Cheating is acceptable in automation if you understand what you are doing. As you have more than two months to finish ...
In game testing, a tester focuses mainly on the following points (from Johan Hoberg's blog):
Fun Factor Testing
Game Level/World Testing
Modification API Testing
I personally believe that testing a game required very sharp judgment ...
Good question. Here I am going to explain some steps from my experience.
1) We need good teamwork for that.
2) Here I just want to clarify that "Execute All Test Case/Suite" term. We need to prioritize test cases in four quadrants like below.
3) Do a good amount of Exploratory Testing instead of totally scripted approach.
4) Try to cover all business-...
Basically you never have enough time and resources to test everything, your test cases are already a subset of this infinite "everything".
What should you do then ? prioritize. A common heuristic is RCRCRC:
Recent: new features
Core: essential functionality of your product
Risk: risk is defined as the Probability of occurrence (how likely is it to ...
Pretend you are going to lend a toy (a teddy bear) to a friend 'cos they really want it.
Before you lend the toy you want to make really sure it will make your friend happy.
You have to have dinner first though so you need to make a note of it to remind you to come back to it after dinner.
Dinner is eaten.
You know your friend really likes golden yellow ...
Software testing against Games is potentially cheaper as you can ask players to do it for you for free during closed beta, open beta or even early access stage, when games actually test your game for you after they pay you. (Assuming your game is not free).
Software testing against Games is rarely life-threatening, unlikely when you are testing a life-...
We took 0 and 101 to test for INVALID data scenario.
We took 1 and 100 to test whether = part of <= and >= is working or not.
We took 2 and 99 to test whether VALID values are also working in(best case scenario) or not. You can treat this as a positive test case.
So three test cases scenario would be there:
1) for INVALID values.
2) for exact ...
In your example, yes, it might be overkill if you are performing white-box testing. However, if you couldn't read or didn't have access to the code (i.e. black-box testing), these tests would be very useful to make sure, for example, that the implementation didn't look like:
if (x == 1 or x == 100):
There's two types of testing in the context of your question: black box testing and white box testing.
A black box tester doesn't know anything about the system. This allows the tester to uncover bugs that someone more familiar with the system might overlook. A white box tester has more familiarity with the system. Based on knowledge of the ...
We faced this during recent hiring and it took 6 months. We finally learned:
Test their automated test writing skills
i.e. the thing we want them to do on a daily basis!
Yes we started off with the puzzles and algorithm questions provided by our development group. However these consistently turned out to be poor predictors for the good people we wanted ...
Feedback also from my side what I learned from projects.
1. Prioritize the test cases
In my past projects we prioritized the test cases. We used HP ALM and there we had also couple of test cases and it was impossible to execute the all. So what we did is just to prioritize the test cases e.g. Critical, Very High, High, Medium, Low - same as you would do it ...
I stumbled upon some black box techniques, but I don't really get how it works. I found sources saying that black box techniques are techniques in which you input something in a program and check if the output matches with the wanted result, if it doesn't, there's an error somewhere.
Let's help with the terminology first:
Black Box Testing typically means ...
Some of our current thoughts:
build a fun Scratch program, then introduce "bugs" in it and ask her to find and fix them making the program work again. Then, explain that this is exactly what we are doing
"I am a Bug" book by a software tester Robert Sabourin which, it looks like, solved the very same problem 18 years ago (have not yet seen the contents of ...
I recently read quite good blog post from Michael Bolton, where he used James Bach's Heuristic Test Strategy Model to generate test ideas.
That blog post has 5 parts, so do not be discouraged on first two parts: Exploratory Testing on an API? (Part 1)
In such situations, the most important thing is to prioritize your tests. Risk-Based Testing is a good way to prioritize your tests. Look at the risks you foresee and base your tests based on the mitigation plan for the tests. For every risk analyze the impact and the likelihood of occurrence and assign a priority to the corresponding tests. Run the high ...
Start by analyzing what would be the impact regarding change. So you know the scope to be covered.
Out of the large set of Test Cases, you must be able to prioritize test cases as not all of them will have same priority. You may end up with High Priority, Medium Priority, and Low Priority set of Test Cases.
You might want to execute all the Test Cases but ...
As an ex-video game tester, some of the article is fairly inaccurate.
Whilst we were encouraged to raise defects (we actually had weekly targets) we weren't allowed to comment on the 'fun factor'. I remember suggesting that one game we tested shouldn't have a physical release because there was a lack of content and fun... just to be shunned and reminded ...
Generally I avoid randomness in tests.
I like to test a particular known state. I like to test by example. I like to have tests that are very easy re-runnable and produce the same result every time (deterministic). Thus when app codes that uses it breaks we can fix the app code and the test returns to green.
So for these reasons I nearly always avoid ...
You can generate the hash of the contents, and then compare the hashes. If the hashes are identical, the files are the same.
In ruby it would look something like this.
md5hashFile1 = Hash(file1)
md5hashFile2 = Hash(file2)
How about hashing the contents and comparing the results? As other folks say this requires opening the files in some fashion. So if you aren't allowed to see content you might need to create this as a service that protects the information and just exposes a SHA.
That depends on what you mean when you say "open" and what result you anticipate when you compare. You have to read both files in some way to compare them. File size won't give you reliable result. Two files might have the same size but different content. Basically I can see two ways how you can compare files.
byte-to-byte. you can either evaluate hash of ...
This isn't how I approach testing but I suppose you could try it like this. Based on the diagram it seems very top down and doesn't represent how you might actually approach testing. In practice I do something like this:
Test Plan - contains the logistical information (delivery dates, who is on the team, etc etc) and the Test Strategy. This ...
Find some measure then rank.
Lets say your measure is, say, line coverage; or exprssion coverage, or ...
Run each test collecting coverage measure for that individual test.
Rank the tests. (I'll expand on ranking after).
Next time around only run the ranked tests + tests that previousely found a bug + randomly selected other tests to fill out the resources ...
Domain testing is an umbrella term for Equivalent partition and boundary value analysis. Here, we try to cover all the available behaviours of a system by using the least number of inputs. Here domain means each partition that is created.
Equivalent partition means we divide the inputs into different partitions, here each partition means input value range ...
This is a good question, from my experience you should be breaking down the technical skills you expect the candidate to master into 3-5 essential must have skills. For example:
Knowledge in scripting/programming language, such as
Knowledge in relational database/no SQL, such as Oracle/MongoDB/Hadoop/SQL
Knowledge in testing ...
In black box test a tester should know the expected output depending on input. A tester shouldn't know how the program under test achieves this result (a tester may know it of course but it's not necessary). That is why it's called "black box" - you do not see what going on inside the box (program).
Quotation from your linked source:
Black box testing ...
Tell your child that it's like the coders give you a vending machine.
Then you put candy and chips into the vending machine, you decide how much of each item you want to start with. You also get to decide the prices on the items in the vending machine. - Sometimes you don't, but best case scenario you get to create your test data.
Then you start by doing ...
Pick a video game of her favorite. And explain how the game works. Tell her what happens when she uses the game controls. Later, explain to her how the game works and explain how the tester ensures the game works properly.
To add to the other answers here, the one time when it helps to know 'the technology behind the system under test' is when you're using recording tools to record automation tests. For instance, I once attempted to use Ranorex on an old .NET WinForms application, which Ranorex handled badly. It just could not identify any elements, relying entirely on the ...
Seemingly it does not help with Blackbox testing, but for other types of testing it could help a lot. Think of security-testing, load-testing and test-automation.
Knowing the technology stack could help or impact with testing things like:
Known defects in the stack, with info from the suppliers.
Common mistakes that can be made with the frameworks might ...