Fuzz testing is a Black box testing technique which uses random bad data to attack a program and see what breaks in the application. Fuzz testing is mostly used to,
• Set up a correct file to enter your program.• Restore some part of the file by using random data.• Unlock the file with the program.• Observe what breaks. Fuzz testing can be automated for maximum effects on large applications. This testing improves the confidence that the application is safe and secure.
What are the major activities in Database Testing?
For those who demanded the major activities included in the Databse Testing are enlisted below.
The major activities in Database testing includes,Checking the Data ValidityChecking the Data IntegrityChecking the Performance related to DatabaseChecking the Security AspectsThe aspects to be considered in Database Schema testing are,Checking the Databases and DevicesChecking the Tables, Fields, Constraints, DefaultsChecking the Keys and IndexesChecking the Stored procedures & PackagesChecking the Error messagesChecking the Triggers - Update, Insert, DeleteChecking the Schema comparisons
Read more...
Scalability Testing is used to check whether the functionality and performance of a system are capable to meet the volume and size change as per the requirements.
Scalability testing can be done using load test with various software and hardware configurations changed, where the testing environment settings unchanged.
Today I am going to answer some reader’s questions. Actually I am thinking to start a weekly column on “Software Testing Questions and Answers”. Usually I get dozens of mails daily asking me on some software testing queries. Instead of answering them privately I will put them collectively in posts so that many similar questions of other readers will also get addressed. You can submit your questions in comment sections of posts. Before submitting question I will strongly recommend you to search here on this site if your queries are answered previously.
So I will kick it with some questions in this post.
Shivika asks:
“I have been given the assignment to test a UI based application page. They want me to break the functionality in any way. The first page is Sign up page containing fields like username password, email, url address field and some check box selection options . I have tried all the ways in which I can test the page. Can you also please suggest that what can be possible ways in which we can test the page?”
I will cover some major negative test cases to break the sign up page:
1) See the limit of username field. I mean the data type of this field in DB and the field size. Try adding more characters to this field than the field size limit. See how application respond to this.
2) Repeat above case for number fields. Insert number beyond the field storage capacity. This is typically a boundary test.
3) For username field try adding numbers and special characters in various combinations. (Characters like !@#$%^&*()_+}{”:?><,./;’[]). If not allowed specific message should be displayed to the user.
4) Try above special character combination for all the input fields on your sign up page having some validations. Like Email address field, URL field validations etc.
5) Many applications crash for the input field containing ‘ (single quote) and ” (double quote) examples field like: “Vijay’s web”. Try it in all the input fields one by one.
6) Try adding only numbers to input fields having validation to enter only characters and vice versa.
7) If URL validation is there then see different rules for url validation and add urls not fitting to the rules to observe the system behavior.
Example urls like: vijay.com/?q=vijay’s!@#$%^&*()_+}{”:?><,./;’[]web_page
Also add urls containing http:// and https:// while inserting into url input box.
8 ) If your sign up page is of some steps like step 1 step 2 etc. then try changing parameter values directly into browser address bar. Many times urls are formatted with some parameters to maintain proper user steps. Try altering all those parameters directly without doing anything actually on the sign up page.
9) Do some monkey testing manually or automating (i.e. Insert whatever comes in mind or random typing over keyboard) you will come up with some observations.
10) See if any page is showing JavaScript error either at the browser left bottom corner or enable the browser settings to display popup message to any JavaScript error.
These are all the negative test cases. I assume that you already tested the same sign up page with all valid cases to check application is working fine as per requirements.
If above cases are not breaking the application page then don’t forget to praise the developer 
If you have some killer test cases to break such applications that you learned from your experience, you can specify them in comments below.
Jayant asks:
“Normally freshers pass out have a state of their mind as “we are freshers”, recently pass outs from college and expect that the companies to recruit them should consider the knowledge base they have and further should impact them training. In true terms what is meant by fresher for an industry?”
Good question. When I was fresher I was thinking on the similar lines. But think from employer point of view. Employer will think like “Why should we hire candidates having little knowledge base and experience? and need training first before assigning any work? Well, fortunately not all employers think like this and that’s why frehsers are getting the jobs and training on the board. Thanks to the booming IT industry. Demand will continue for freshers having good educational background and appropriate problem solving skill.
Tremendous growth in number of engineering colleges resulted in significant increase in number of graduates passing out each year. And the gap is also increasing between the skill of graduates and the expectations of the companies.
Now I will focus on what industry look specifically in fresh graduates? Typically it will include:
So it will be always better if you try to achieve any experience or skill before trying for any graduate jobs. You are one step ahead than those freshers having no experience at all.
This work experience typically includes:
Internship -
Internship work done in any company during or after the graduation. It may be free or paid internship
Sandwich courses -
In some courses industrial training is included in curriculum itself. It is typically of 6 months to 1 year in most of the universities. You can include this project training in your resume.
Special skill achievements through classes or companies:
Training taken from some institute or companies can be included in your work experience.
Projects:
Projects accomplished for commercial or research purpose. These are the paid or certification projects accomplished for companies during the graduation years.
All above-mentioned work will definitely count as a experience as you get actual idea of company, team work and company working culture. Find out your skill areas and what you can offer to employer before hunting for jobs. Companies always look for all-rounded candidates who can effectively utilize their skill into projects from universities, experience and extra activities.
Read more...If you are willing to choose software testing as your career then this is a must read!
Nowadays I get many mails asking me about software testing jobs. Should I select software testing as my career? How to switch to software testing from other job experience? Which institute should I join for testing course? And many more …
I will give a common answer to all these questions whether you should choose software testing as your career or not? Let me first explain in brief about software testing. Software testing and quality control are the processes by means of which application quality is improved. Software testing is done in each phase of product life cycle i.e from requirement specifications , design, coding, to the user acceptance.
Many complex software structures require in depth analytical and technical skill to test the applications. Knowledge of programming languages is required for unit testing, scripting skill essential for Automation testing.
Now we will speak about your career in software testing. No one can guide you choosing your career more than you! Its right and you are the only person to decide your career.
Do self-assessment to figure out where you can fit well. Do study of your skills, interests, strengths, weaknesses.
Ask some questions to your self like:
What is your goal in life?
What will increase your satisfaction and skill?
What is your interest?
Which skills you have developed in your life till now?
Which training you did that can be applied to future job?
By answering these questions you will automatically come to decision.
To switch to software testing career What skills you will require? Is the most important question I think.
In my previous post what makes a good test engineer, I mentioned some of the software testing required skills.
1. Communication: Customer communication as well as team communication most important for this job. Written communication as well!
2. Technical skill: As I mentioned earlier for testing technical domain skill in languages is important.
Some of the Testing skills are:
Project life cycle,
Testing concepts,
Knowledge of testing types,
Programming languages familiarity,
Database concepts,
Test plan idea,
Ability to analyze requirements,
Documentation skill,
Testing tools
3. Leadership quality
4. Analytical and judging skill
Don’t worry if you don’t have some of the skills mentioned above. You can always learn the things if you have interest. Non-IT personas can also grow fast by gaining necessary skills.
So finally selecting testing as your career ask one question to yourself:
Are you looking for career in software testing or just a Job?
Best of luck!
Read more...In recent days this is the most asked question to me by readers. How to get software testing job? How to come in software testing field? or Can I get job in testing?
All these questions are similar and I want to give also similar answer for this. I have written post on choosing software testing as your career where you can analyze your abilities and know which are the most important skills required for software testing.
I will continue mentioning that “know your interest before going into any career field”. Just going to software testing career or any other hot career is wrong and which may result into loss of your job interest as well as your job.
Now you know your abilities, skills, interests right? and you have made decision to go for software testing career as it is your favorite career and you suit most in this career. So here is a guideline for how to get a good job in software testing field.
If you are a fresher and just passed out from your college or passing out in coming months then you need to prepare well for some software testing methodologies. Prepare all the manual testing concepts. If possible have some hands-on on some automation and bug tracking tools like winrunner and test director. It is always a good idea to join any software testing institute or class which will provide you a good start and direction of preparation. You can join any 4 months duration software testing course or can do diploma in software testing which is typically of 6 months to 1 year. Keep the preparation going on in your course duration. This will help you to start giving interviews right after getting over your course.
If you have some sort of previous IT experience and want to switch to software testing then it’s somewhat simple for you. Show your previous IT experience in your resume while applying for software testing jobs. If possible do some crash course to get idea of software testing concepts like I mentioned for freshers above. Keep in mind that you have some kind of IT experience so be prepared for some tough interview questions here.
As companies always prefer some kind of relevant experience for any software job, its better if you have relevant experience in software testing and QA. It may be any kind of software testing tools hands-on or some testing course from reputed institutes.
Please always keep in mind- Do not add fake experience of any kind. This can ruin your career forever. Wait and try for some more days to get the job by your abilities instead of getting into trap of fake experience.
Last important words, Software testing is not ‘anyone can do career!’ Remove this attitude from your mind if someone has told such kind of foolish thing to you. Testing requires in depth knowledge of SDLF, out of box thinking, analytical skill and some programming language skill apart from software testing basics.
So best luck and start preparation for your rocking career! I will continue writing this career series and what you actually need to prepare for software testing interview.
Read more...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. (Image credit)
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!!
Read more...If you are preparing for CSTE testing certification exam or thinking to give the exam in coming days then this question series will help you for preparation. Here I have included some questions from CSTE objective type question papers.
The software testing/Quality assurance professionals can also take this exam to test their testing knowledge.
You can either take printout and mark the answers or note your answers somewhere on the paper serially for all 25 questions. Verify your answers at the answer page provided at the bottom of this test page.
1. Verification is:
a. Checking that we are building the right system
b. Checking that we are building the system right
c. Performed by an independent test team
d. Making sure that it is what the user really wants
2. A regression test:
a. Will always be automated
b. Will help ensure unchanged areas of the software have not been affected
c. Will help ensure changed areas of the software have not been affected
d. Can only be run during user acceptance testing
3. If an expected result is not specified then:
a. We cannot run the test
b. It may be difficult to repeat the test
c. It may be difficult to determine if the test has passed or failed
d. We cannot automate the user inputs
4. Which of the following could be a reason for a failure
1) Testing fault
2) Software fault
3) Design fault
4) Environment Fault
5) Documentation Fault
a. 2 is a valid reason; 1,3,4 & 5 are not
b. 1,2,3,4 are valid reasons; 5 is not
c. 1,2,3 are valid reasons; 4 & 5 are not
d. All of them are valid reasons for failure
5. Test are prioritized so that:
a. You shorten the time required for testing
b. You do the best testing in the time available
c. You do more effective testing
d. You find more faults
6. Which of the following is not a static testing technique
a. Error guessing
b. Walkthrough
c. Data flow analysis
d. Inspections
7. Which of the following statements about component testing is not true?
a. Component testing should be performed by development
b. Component testing is also know as isolation or module testing
c. Component testing should have completion criteria planned
d. Component testing does not involve regression testing
8. During which test activity could faults be found most cost effectively?
a. Execution
b. Design
c. Planning
d. Check Exit criteria completion
9. Which, in general, is the least required skill of a good tester?
a. Being diplomatic
b. Able to write software
c. Having good attention to detail
d. Able to be relied on
10. The purpose of requirement phase is
a. To freeze requirements
b. To understand user needs
c. To define the scope of testing
d. All of the above
11. The process starting with the terminal modules is called -
a. Top-down integration
b. Bottom-up integration
c. None of the above
d. Module integration
12. The inputs for developing a test plan are taken from
a. Project plan
b. Business plan
c. Support plan
d. None of the above
13. Function/Test matrix is a type of
a. Interim Test report
b. Final test report
c. Project status report
d. Management report
14. Defect Management process does not include
a. Defect prevention
b. Deliverable base-lining
c. Management reporting
d. None of the above
15. What is the difference between testing software developed by contractor outside your country, versus testing software developed by a contractor within your country?
a. Does not meet people needs
b. Cultural difference
c. Loss of control over reallocation of resources
d. Relinquishments of control
16. Software testing accounts to what percent of software development costs?
a. 10-20
b. 40-50
c. 70-80
d. 5-10
17. A reliable system will be one that:
a. Is unlikely to be completed on schedule
b. Is unlikely to cause a failure
c. Is likely to be fault-free
d. Is likely to be liked by the users
18. How much testing is enough
a. This question is impossible to answer
b. The answer depends on the risks for your industry, contract and special requirements
c. The answer depends on the maturity of your developers
d. The answer should be standardized for the software development industry
19. Which of the following is not a characteristic for Testability?
a. Operability
b. Observability
c. Simplicity
d. Robustness
20. Cyclomatic Complexity method comes under which testing method.
a. White box
b. Black box
c. Green box
d. Yellow box
21. Which of these can be successfully tested using Loop Testing methodology?
a. Simple Loops
b. Nested Loops
c. Concatenated Loops
d. All of the above
22. To test a function, the programmer has to write a ______, which calls the function and passes it test data.
a. Stub
b. Driver
c. Proxy
d. None of the above
23. Equivalence partitioning is:
a. A black box testing technique used only by developers
b. A black box testing technique than can only be used during system testing
c. A black box testing technique appropriate to all levels of testing
d. A white box testing technique appropriate for component testing
24. When a new testing tool is purchased, it should be used first by:
a. A small team to establish the best way to use the tool
b. Everyone who may eventually have some use for the tool
c. The independent testing team
d. The vendor contractor to write the initial scripts
25. Inspections can find all the following except
a. Variables not defined in the code
b. Spelling and grammar faults in the documents
c. Requirements that have been omitted from the design documents
d. How much of the code has been covered
Done?
Answers:
1)- b
2)- b
3)- c
4)- d
5)- b
6)- a
7)- d
8 )- c
9) - b
10) - d
11) -b
12) - a
13) - c
14) - b
15) - b
16) - b
17) - b
18) - b
19) - d
20) - a
21) - d
22) - b
23) - c
24) - a
25) - d
Couple of months back I wrote an article on “How to keep good testers in testing position“. There I mentioned one point as to appreciate the testers for their good work.
“Reward testers for finding good quality bugs. Keep some weekly or monthly competitions such as ‘Bug of the week’ to reward them. This will help to build a successful QA team”.
The same concept is used by Eric Jacobson - a software tester, to keep motivation alive in his testing team. Eric found interesting idea to reward good testers. The idea of holding a bug contest. And decided to award the ‘Mercury’ cap to the tester who could log the most bugs in a given week. See the winner of his contest.
A small tweak I would rather suggest to make this technique more effective is to award the testers who will find the quality bug, may be called as “Bug of the week”. This way quality bugs will be the main focus of software testers rather than running behind the quantity. Obviously you should not ignore those small UI bugs also 
I am really fan of awarding testers for their good work. It may be any kind of appreciation. May be a small gift or just few kind words of appreciation from the lead or manager. This will keep the spirit alive in testers to find new and quality bugs.
If you are a team leader, manager or even a team member, what do you think is the best way to keep motivation alive in software testers?
Read more...I am in process to compile a list of good books on software testing. Soon I will share this list with you. But lately I am getting too many requests to share any book on software testing for preparing software testing interviews. So here is a quick post to share an online testing book I found “A Software Testing Primer” by Nick Jenkins.
Basically this book is an introduction to software testing. So those who are new to software testing field can start their preparation by reading this book. You will get basic idea of manual and automation testing.
Here is a summary of what this book is covering:
In all this book is a nice introduction to software testing. Author explained some key software testing concepts like Regression and Retesting difference, Alpha and beta testing etc. where many testers get confused.
Download “Testing Primer” book:
To download this book Click here
http://www.nickjenkins.net/prose/testingPrimer.pdf
These days a lot of people who pass out of engineering and science colleges are interested about software testing as a career. When I passed out at a time when the IT had started to boom back in India, most of the fresh graduates with whom I interacted didn’t even know there existed jobs or careers like software testing.
I was offered a job as a tester in a start up for 7440 rupees a month compared to fresh developers (who were picked from better institutes from where I graduated) being paid 34,500 rupees a month.
Today there isn’t such a huge difference between what testers and developers get paid and I consider this generation to be luckier than my generation without ignoring the idea that my generation might have been luckier than its previous generation.
When I started my career as a software tester, I didn’t find any training centre, which could coach me on software testing, and I lacked guidance. I didn’t know about Google and its power of search.
In the organization I worked for, there existed a senior software tester, not by designation or for the technical competence but just that he joined that organization 6 months before I did. He happened to coach me. I blindly believed all that he said about testing. I believed him and never questioned him.
By believing whatever he said I think I was becoming dumb. I looked for someone who could coach me and found two great people, one a developer and other a software architect in the organization whose ideas were much impressive than the senior software tester.
The duos were more open to questions from me as compared to the so-called senior software tester. When I questioned all things that I heard from the so-called senior software tester, I found that most of what the senior tester said was highly idiotic.
I realized that my quest in life was to see myself doing good or great testing in future. To do that, I must learn, I must learn, I must learn, I must practice, I must practice, I must practice…
What do I learn? What do I practice?
When I asked for information about software testing, some of my friends sent me material that was nothing more than, - types of testing, techniques of testing, different types of documentation, process of testing and development.
A question that I asked changed my life and you might want to know what that question is: Is there something beyond what all these people think software testing is which I can learn?
Now that leads to more questions. If it exists, where does is exist? Who has the information? How can I find it?
That lead me to discovering James Bach one of the world’s leading expert tester. His career graph is one of the most impressive career graph I have seen till date. He is a school drop out at 8th standard and yet became the youngest Test Manager of the world at the age of 20 in Apple Computers. He even helped Microsoft in Test Specification and was expert witness in court cases that involved investigations of the computer world. He has traveled to most countries where software testing is being done and has carried over consulting assignments there. He is a kind of tester that can make most testers in the world feel ashamed of their lack of skills, knowledge and maybe money. That reminds me to say, he has made lots of money.
I thought this man must have a secret with him that other software testers don’t know and I wanted to learn that. I found that James Bach is very similar to Jackie Chan as he considers skilled testing to be a mental martial art. Sorry, James doesn’t have any testing certification that you know of and he thinks certification doesn’t help, so don’t try to think of certification when you are thinking of James Bach, the great tester and guru of software testing.
I had to pass through several mental martial arts tests before I became his full time student. Let me not take you through the entire story but let you know that I reached a stage where he hired me to represent his company in India.
I don’t like comparing myself with others and run a rat race but some of my friends who were comparing with me were very disappointed as I progressed. I travel around the world speaking and coaching at international conferences. I am featured as an expert tester sometimes (which I acknowledge, I am not) in other countries. I have a fan following for my blog. I am an independent consult, working on different projects in a day and for different clients from different parts of the world. I coach, consult, speak, write, think, test, manage and learn software testing and problem solving. I was interviewed by CNBC as they considered me a problem solving expert and wrote a column for them as Expert problem solver. I was invited to manage testing for an organization products and services division with about three years of working as a software tester. I have tested over a hundred and twenty three products, so far.
Reputation means more money but if you do things just for gaining reputation you won’t get it. Reputation is a little tricky. People think it is about doing things what other people like but I think it is about other people liking what you are doing.
Don’t worry about too many “I”, I have written in this article and for the moment, think if you have so many “I” to say or probably even more, in testing that makes people to approach you for consultation, you would be making more money than you ever imagined you would make as a tester.
I want to see Indian testers make more money than what they have been making. That’s precisely why I am writing this article for you all.
To start in the journey, apply this heuristic: Question everything that - you hear, you see, you feel, you want to see, you want to hear, you want to feel, you don’t want to hear, you don’t want to feel and other things you think you missed.
How to apply this heuristic?
Let me give you an example to get you started: There is a common myth (which means something is fundamentally wrong but people blindly believe it) by which most testers to my knowledge in India live: Testing is done to improve Quality
I wish all testers read these software testing good practices. Read all points carefully and try to implement them in your day-to-day testing activities. This is what I expect from this article. If you don’t understand any testing practice, ask for more clarification in comments below. After all you will learn all these testing practices by experience. But then why not to learn all these things before making any mistake?
Here are some of the best testing practices I learned by experience:
1) Learn to analyze your test results thoroughly. Do not ignore the test result. The final test result may be ‘pass’ or ‘fail’ but troubleshooting the root cause of ‘fail’ will lead you to the solution of the problem. Testers will be respected if they not only log the bugs but also provide solutions.
2) Learn to maximize the test coverage every time you test any application. Though 100 percent test coverage might not be possible still you can always try to reach near it.
3) To ensure maximum test coverage break your application under test (AUT) into smaller functional modules. Write test cases on such individual unit modules. Also if possible break these modules into smaller parts.
E.g: Lets assume you have divided your website application in modules and ‘accepting user information’ is one of the modules. You can break this ‘User information’ screen into smaller parts for writing test cases: Parts like UI testing, security testing, functional testing of the ‘User information’ form etc. Apply all form field type and size tests, negative and validation tests on input fields and write all such test cases for maximum coverage.
4) While writing test cases, write test cases for intended functionality first i.e. for valid conditions according to requirements. Then write test cases for invalid conditions. This will cover expected as well unexpected behavior of application under test.
5) Think positive. Start testing the application by intend of finding bugs/errors. Don’t think beforehand that there will not be any bugs in the application. If you test the application by intention of finding bugs you will definitely succeed to find those subtle bugs also.
6) Write your test cases in requirement analysis and design phase itself. This way you can ensure all the requirements are testable.
7) Make your test cases available to developers prior to coding. Don’t keep your test cases with you waiting to get final application release for testing, thinking that you can log more bugs. Let developers analyze your test cases thoroughly to develop quality application. This will also save the re-work time.
8 ) If possible identify and group your test cases for regression testing. This will ensure quick and effective manual regression testing.
9) Applications requiring critical response time should be thoroughly tested for performance. Performance testing is the critical part of many applications. In manual testing this is mostly ignored part by testers due to lack of required performance testing large data volume. Find out ways to test your application for performance. If not possible to create test data manually then write some basic scripts to create test data for performance test or ask developers to write one for you.
10) Programmers should not test their own code. As discussed in our previous post, basic unit testing of developed application should be enough for developers to release the application for testers. But you (testers) should not force developers to release the product for testing. Let them take their own time. Everyone from lead to manger know when the module/update is released for testing and they can estimate the testing time accordingly. This is a typical situation in agile project environment.
11) Go beyond requirement testing. Test application for what it is not supposed to do.
12) While doing regression testing use previous bug graph (Bug graph - number of bugs found against time for different modules). This module-wise bug graph can be useful to predict the most probable bug part of the application.
13) Note down the new terms, concepts you learn while testing. Keep a text file open while testing an application. Note down the testing progress, observations in it. Use these notepad observations while preparing final test release report. This good habit will help you to provide the complete unambiguous test report and release details.
14) Many times testers or developers make changes in code base for application under test. This is required step in development or testing environment to avoid execution of live transaction processing like in banking projects. Note down all such code changes done for testing purpose and at the time of final release make sure you have removed all these changes from final client side deployment file resources.
15) Keep developers away from test environment. This is required step to detect any configuration changes missing in release or deployment document. Some times developers do some system or application configuration changes but forget to mention those in deployment steps. If developers don’t have access to testing environment they will not do any such changes accidentally on test environment and these missing things can be captured at the right place.
16) It’s a good practice to involve testers right from software requirement and design phase. These way testers can get knowledge of application dependability resulting in detailed test coverage. If you are not being asked to be part of this development cycle then make request to your lead or manager to involve your testing team in all decision making processes or meetings.
17) Testing teams should share best testing practices, experience with other teams in their organization.
18) Increase your conversation with developers to know more about the product. Whenever possible make face-to-face communication for resolving disputes quickly and to avoid any misunderstandings. But also when you understand the requirement or resolve any dispute - make sure to communicate the same over written communication ways like emails. Do not keep any thing verbal.
19) Don’t run out of time to do high priority testing tasks. Prioritize your testing work from high to low priority and plan your work accordingly. Analyze all associated risks to prioritize your work.
20) Write clear, descriptive, unambiguous bug report. Do not only provide the bug symptoms but also provide the effect of the bug and all possible solutions.
Don’t forget testing is a creative and challenging task. Finally it depends on your skill and experience, how you handle this challenge.
Over to you:
Sharing your own testing experience, tips or testing secrets in comments below will definitely make this article more interesting and helpful!!
Read more...Boundary value analysis and Equivalence partitioning, explained with simple example:
Boundary value analysis and equivalence partitioning both are test case design strategies in black box testing.
Equivalence Partitioning:
In this method the input domain data is divided into different equivalence data classes. This method is typically used to reduce the total number of test cases to a finite set of testable test cases, still covering maximum requirements.
In short it is the process of taking all possible test cases and placing them into classes. One test value is picked from each class while testing.
E.g.: If you are testing for an input box accepting numbers from 1 to 1000 then there is no use in writing thousand test cases for all 1000 valid input numbers plus other test cases for invalid data.
Using equivalence partitioning method above test cases can be divided into three sets of input data called as classes. Each test case is a representative of respective class.
So in above example we can divide our test cases into three equivalence classes of some valid and invalid inputs.
Test cases for input box accepting numbers between 1 and 1000 using Equivalence Partitioning:
1) One input data class with all valid inputs. Pick a single value from range 1 to 1000 as a valid test case. If you select other values between 1 and 1000 then result is going to be same. So one test case for valid input data should be sufficient.
2) Input data class with all values below lower limit. I.e. any value below 1, as a invalid input data test case.
3) Input data with any value greater than 1000 to represent third invalid input class.
So using equivalence partitioning you have categorized all possible test cases into three classes. Test cases with other values from any class should give you the same result.
We have selected one representative from every input class to design our test cases. Test case values are selected in such a way that largest number of attributes of equivalence class can be exercised.
Equivalence partitioning uses fewest test cases to cover maximum requirements.
Boundary value analysis:
It’s widely recognized that input values at the extreme ends of input domain cause more errors in system. More application errors occur at the boundaries of input domain. ‘Boundary value analysis’ testing technique is used to identify errors at boundaries rather than finding those exist in center of input domain.
Boundary value analysis is a next part of Equivalence partitioning for designing test cases where test cases are selected at the edges of the equivalence classes.
Test cases for input box accepting numbers between 1 and 1000 using Boundary value analysis:
1) Test cases with test data exactly as the input boundaries of input domain i.e. values 1 and 1000 in our case.
2) Test data with values just below the extreme edges of input domains i.e. values 0 and 999.
3) Test data with values just above the extreme edges of input domain i.e. values 2 and 1001.
Boundary value analysis is often called as a part of stress and negative testing.
Note: There is no hard-and-fast rule to test only one value from each equivalence class you created for input domains. You can select multiple valid and invalid values from each equivalence class according to your needs and previous judgments.
E.g. if you divided 1 to 1000 input values in valid data equivalence class, then you can select test case values like: 1, 11, 100, 950 etc. Same case for other test cases having invalid data classes.
This should be a very basic and simple example to understand the Boundary value analysis and Equivalence partitioning concept.
Read more...These days a number of web sites are deployed in multiple languages. As companies perform more and more business in other countries, the number of such global multi-lingual web applications will continue to increase.
Testing web sites supporting multiple languages has its own fair share of challenges. In this article, I will share seven tips with you that will enable you to test the multi-lingual browser-based applications in a complete way:
Tip # 1 – Prepare and use the required test environment
If a web site is hosted in English and Japanese languages, it is not enough to simply change the default browser language and perform identical tests in both the languages. Depending on its implementation, a web site may figure out the correct language for its interface from the browser language setting, the regional and language settings of the machine, a configuration in the web application or other factors. Therefore, in order to perform a realistic test, it is imperative that the web site be tested from two machines – one with the English operating system and one with the Japanese operating system. You might want to keep the default settings on each machine since many users do not change the default settings on their machines.
Tip # 2 – Acquire correct translations
A native speaker of the language, belonging to the same region as the users, is usually the best resource to provide translations that are accurate in both meaning as well as context. If such a person is not available to provide you the translations of the text, you might have to depend on automated web translations available on web sites like wordreference.com and dictionary.com. It is a good idea to compare automated translations from multiple sources before using them in the test.
Tip # 3 – Get really comfortable with the application
Since you might not know the languages supported by the web site, it is always a good idea for you to be very conversant with the functionality of the web site. Execute the test cases in the English version of the site a number of times. This will help you find your way easily within the other language version. Otherwise, you might have to keep the English version of the site open in another browser in order to figure out how to proceed in the other language version (and this could slow you down).
Tip # 4 – Start with testing the labels
You could start testing the other language version of the web site by first looking at all the labels. Labels are the more static items in the web site. English labels are usually short and translated labels tend to expand. It is important to spot any issues related to label truncation, overlay on/ under other controls, incorrect word wrapping etc. It is even more important to compare the labels with their translations in the other language.
Tip # 5 – Move on to the other controls
Next, you could move on to checking the other controls for correct translations and any user interface issues. It is important that the web site provides correct error messages in the other language. The test should include generating all the error messages. Usually for any text that is not translated, three possibilities exist. The text will be missing or its English equivalent will be present or you will see junk characters in its place.
Tip # 6 – Do test the data
Usually, multi-lingual web sites store the data in the UTF-8 Unicode encoding format. To check the character encoding for your website in mozilla: go to View -> Character Encoding and in IE go to View -> Encoding. Data in different languages can be easily represented in this format. Make sure to check the input data. It should be possible to enter data in the other language in the web site. The data displayed by the web site should be correct. The output data should be compared with its translation.
Tip # 7 – Be aware of cultural issues
A challenge in testing multi-lingual web sites is that each language might be meant for users from a particular culture. Many things such as preferred (and not preferred) colors, text direction (this can be left to right, right to left or top to bottom), format of salutations and addresses, measures, currency etc. are different in different cultures. Not only should the other language version of the web site provide correct translations, other elements of the user interface e.g. text direction, currency symbol, date format etc. should also be correct.
As you might have gathered from the tips given above, using the correct test environment and acquiring correct translations is critical in performing a successful test of other language versions of a web site.
It would be interesting to know your experience on testing multi-language web sites.
Read more...Hi All, I know I have been away from posting on this blog since long and I apologize for that. There were few things which needed to be taken care of so my blogging activity was side lined. I would try to be more regular in posting new articles on this blog now onwards.
Recently, I have been searching a lot on testing jargons and come across a list of IEEE 829 Test Plan Standards as it was something which is not known generally.
This could be the list of standards to make your test plan IEEE 829 compliant as per the source.
1. Test plan identifier.
2. Introduction.
3. Test items.
4. Features to be tested.
5. Features not to be tested.
6. Approach.
7. Item pass/fail criteria.
8. Suspension criteria and resumption requirements.
9. Test deliverables.
10. Testing tasks.
11. Environmental needs.
12. Responsibilities.
13. Staffing and training needs.
14. Schedule.
15. Risks and contingencies.
16. Approvals.
Labels: Standards, Test Planning
Yesterday I was reading this news (though the Market is volatile and unpredictable but still XYZ Share performed very well. Also one of Top A Group Share tumbled heavily. Investing in this market needs concentration and so on…), when the idea of this post struck my mind. To be honest, the mention of the words "Performed well", "Tumbled" and "Concentration" in the news caught my attention and when I finished reading the news item, I realized that why can’t I have a try to correlate it with software testing and software testers, it started making some sense to me and the following paragraphs are a result of it.
Before I continue further, let me make it clear that when I say Market Index, I am not talking about the tester rating or performance index (Class: Tester, Family: Software). Rather, I am talking about the Share Market
Note : Request to all those who considers this as gambling, kindly see this is only a try to correlate the two things using Analogy. This is just a try to articulate some stuff in order to make tester’s fundamentals more clear with perfect vision.
1. (Un)Predictability: Experts say, ‘ShareMarket is always unpredictable and this is its greatest charm’! It is very difficult to predict either to gain or to loose even in the last moment of trade. And it is the unpredictability, which makes Market so interesting. Any Share Equity might look strong or weak on a piece of pen and paper. But in Market, unpredictability reins, not the statistics. Even in the worst condition of the market, Z-Group
Coming to software testing, there could be testers who believe that it is easy and straightforward to expect some fixed output after executing a series of test steps, but I only wish; testing software was as simple as that! Echoing some experts in software testing: trying to predict the result of a test in terms of PASS or FAIL criteria can be one of those dangerous traps in software testing world, where a tester can shoot at his own feet! Irrespective of the number of test scripts (either manual test cases or automated test scripts) a tester has written, until the tester gets the application module to test, nothing can be told for sure about the state of the application and its behavior. Unpredictability is one of those things that make software testing so much fun.
2. Skills: Market is a place where only skillful investors can make their money and makes their account size bigger and bigger. I am not sure about your investments in other countries also, but if for sure if you belongs to India, chances are high that you might have seen Market movement on daily or periodically basis! People say, Market is a fever here in India. Here people are so obsessed with this stuff either directly or indirectly just to get more Return On Investment [ROI] what they did. So one can say that they not only play and watch Market but also eat, sleep and even drink Market! It’s becoming passion for new comers and caused heavy boom in the year end of 2007. I have played fair amount of Market since last 3 years. Even you might have too. But the reason, why players like Mutual Funds, Banks Investments to Market and all are considered as better ones and why people prefers that? Just because experts are involved, skills are put in order to get more ROI. There are facts that even in these days, in downtrend of market people made a lot of money who had the skills.
Likewise, in software testing too, it is the testing skill that differentiates a good tester from a mediocre one. The one, who has the better testing skills in his arsenal, can find more important defects quickly in the software that he is testing. Learning, practicing and applying are three golden rules to acquire any skill. With determination and strong willpower, nothing is impossible to learn. Fortunately, software testing is no exception! Some people just say "It is not a good work but still I accepted it. I want to go to development. What ever I am doing, any one can do and blah blah…." I will just say to them be smart enough to develop your skills. If you can get credits just by being the developer why can’t by being a tester? Isn’t it true? Yes, it is. You might have seen many of your colleagues who reports the bug and their bugs are always taken in to care, though some times they seems to be easy. Why is it so? Think. Just it is because of their skills and way of finding the things. J
3. Game Planning (Knowing the Opponent): Professional Market is all about knowing the strengths and weaknesses of the opponent
In software testing, knowing the testing mission is the first step in determining the goal of the testing effort. Without being clear about the goal, it might turn out fatal to go about testing straightaway. Once the tester is clear about the testing mission, then he can analyze his chances of success or failure depending on the availability and expertise of the resource in hand and the complexity of the testing problem. e.g. imagine a situation where the tester has to test the application to find out it’s robustness to guard against hackers and other malicious users. Knowledge of a fair deal of details about the level of attack that can be attempted against the application, can give the tester a better chance to plan out a strategy to emulate the attack and to test how the application guards against it.
4. Handling Pressure: This every one will agree that finally earning the aim of market, but still it is all about handling the pressure as well. The one should be able to handle the tremendous amount of pressure of the market when he is loosing or having less time. But still one who plays smartly even in this pressure finally wins the game and gets good return. Those people who jumped in to the market without having knowledge had made a huge losses in this year 2008. All you know this fact. This doesn’t mean that this is a bad game.
Similarly for those who think or have been told that software testing is an easy job and can be done by every Tom Dick and Harry, let me warn you, you have been terribly misguided! Testing is a career, which demands lot of intellectuality and stability of mind to work under variety of pressures (like technical pressure, pressure due to workload, managerial pressure, pressure of deadline, pressure arising from the nature of the job etc). As testers, the basic requirement of our job demands us to deliver bad news (presence of defects, buggy modules that fail miserably on testability grounds etc) to different stakeholders (the programmers, management staffs, clients) of the product under development. Nobody likes to hear bad news. Unfortunately, gone are the days when messengers were not hanged just because they brought in a bad news to the king! Hence, unless the tester is quite good at handling the pressure arising as a byproduct of his work, and is not so good at being diplomatic, he might find it tough to carry on with his job for long. On the other hand, the tester who has got the capability to handle the pressure till the end, has every chance of winning the label of Big Bull in Testing by accumulating more efficient bugs and thus by increasing your credits.. (ROI)!
5. Adaptability: If you have been watching market for sometime now, then you must be experienced enough to know that the one who have more exposure to the market have also lost just by investing in the one share and that share had fallen with huge amount. Here comes actual picture, why mutual funds are less risky than actual investment in the market. As these mutual fund companies are much adaptable with the situations and also they invests in many places. They have knowledge of many fields, many SMEs are involved in to it. The players who can adapt themselves quickly with the new environment can gain an edge in this market.
Just as none of the two A-Group Equity can be exactly identical in the performance, no two AUTs (Application Under Test) can be same. Hence, I often get surprised when I see testers trying to clean themselves off testing assignments with excuses such as:
» "I have not tested anything like this before!"» "This platform is completely new to me!"» "I am new to this technology. I can not test it!"
» "I am not a tester. I am developer by portfolio"
» "I don’t like this. What ever I am doing, any one can do."» "I am a manual tester. I can not use this test automation tool!"» "I need the domain knowledge before I can test this application!"» "Hey, you don’t have any base documents (URS, SRS, BRS blah blah…)! How can I start testing your application?"To me, this simply translates as a bad attitude of a tester, who is not ready to adapt and more importantly not ready to learn something new. For such testers, I have just one thing to say:"Don’t forget that, even big and powerful animals like the Dinosaurs and the Wooly Mammoth became extinct just because they FAILED to adapt to their changing surrounding environments; we are just testers!"
When I say so, I DON’T mean that I am a great tester who has been excellent at adaptability throughout his testing career. On the contrary, I have been through several such instances when I was stupid enough to oppose such changes and was in fact, hostile to proposed changes. And don't be too surprised when I tell you that, some of the excuses that I have mentioned above were from my own mouth! Even many are from my team mates. Don’t feel harsh if I am telling you this or if it resembles to you. However, I have learnt my lesson of adaptability in the hard, bitter way. So I just wanted to warn others who are new and passionate about testing but might commit the same mistake of lack of adaptability that many have committed in their earlier years of Software testing career.
6. Patience: Market is a game of patience. At times, a investor/player might be finding it tough to earn due to the sharp downfall in the market or bad market, tough conditions etc. But if the player has got enough temperament and patience, he might soon find it easy to not only get a single penny but ample amount of money and also get good ROI against the same bad performing share in the same market conditions. Similarly with patience and consistent good plan of investment, a investor could turn around the fate of his/her portfolio by picking up the perfect gains.
Similarly, a lot of patience is required while testing an application. There might be days when nothing seemed to work right for you and you would end up without catching a single defect in the whole testing session. There might be times when you would find yourself hitting your head on the keyboard while trying to find ways to reproduce a hard-to-reproduce defect. But you ask any expert in software testing, and he would suggest you to have patience. Putting in extra effort and having patience can help you come out of such dry days of testing. Think about it, get perfect hit on the right place to cause system errors or crash the system or to break the application. Perfect steady mind set will provide you an eagle eye to watch the application correct way and get the perfect bug on perfect time of delivery.
7. Team Game: Market is though played by a single person. But portfolio
And so is software testing. All the team members of a testing team can’t be with equal skill sets and with equal level of expertise. Having a testing team with members with different specialization can add to the versatility of the team’s overall performance. I don’t want to say that some of them are bad performers, but yeah even you know that all are for sure never be of the same strength and knowledge. I do understand that there can be testing geniuses, who are jack of all testing trades and are all-rounder’s when it comes to testing. But finding such a tester can be a tough task for any test manager. If some one is there in your team, it’s an excellent stuff in your portfolio of the team like to have a good performing share in your account. So as a workaround a good test manager might look forward to build a team which has testers specializing in different aspects of testing (functionality testing, performance/stress testing, database testing, usability testing, automation engineers, risk-based testing etc). If one of your team member is weak, don’t blame them. One who is smart enough and capable enough has to perform well in order to compensate the performance loss made by this average team member. This will make your project status green like in the market portfolio performers. J
8. Lack of Concentration can Doom you: Market requires a high level of concentration. A small mistake can put you in a heavy loss. As an investor (buyer) if you loose your concentration and buy it soon when it is falling and you have to pay more from your hard earned money. As a seller if you loose your concentration and you could wait bit longer, you might have earned some more profit. Right? These can be the situations many of us have faced. (remember! Every perfect hit gives you good ROI and increases your credits!)
Coming back to testing, imagine a tester who misses to identify a defect that just happens in front of his eyes, as he was looking for some other defect at that moment. Experts call this phenomenon as inattentional blindness. This can also happen if your mind is too tired due to continuous testing and you start loosing concentration, and in turn, start loosing defects!9.Wearing safety stuffs and Testers: One always invests in good shares as helmets to safeguard their portfolio heads from the fast coming changes in the market.
In case of software testing, unfortunately, the testers are like the safety helmet! They act as the representative of the client/end users of the project. And act as the last line of defense of the client/end users against the possible ways in which the software might fail. So as testers, start feeling proud of your profession, as you are safeguarding somebody by taking the hits yourself. By spending time with all those irritating defects while testing, you are making sure that your end user does not have to deal with them in future.
10. Learning Lessons from Failures: Even market champions like Reliance, L&T, Infosys etc… were top runners in the market for a long time and were trusted shares. But since last few months, all went down and performed bad against the similar kind of company shares. So one has to accept that profit and loss are the part of this game. Success and failures are two integral part of any game. The share once give you good profit today can put you in loss the future and vice versa.
But what differentiates a champion from an average performer is the extent to which they learn their lessons from their failures.
On a similar note, a software testing project can go terribly bad due to various reasons. I have witnessed and have been part of few such testing projects that went nowhere nearer where they were intended to go! Some were complete disasters and the whole project development had to be shut down. I am sure, if you are in testing field for sometime now, then you also might have seen, experienced, heard about such failures. But each experience, good or bad, has some lessons in it. A good tester tries to learn lessons from his past failures to make sure they are not repeated in future. The failure might not have been as a result of a mistake on the part of the tester, but still, there might be some lessons in that failure that could help the tester in becoming better at his testing in future.
If you have reached this paragraph after patiently reading through my article, then I must appreciate you for your patience. You have certainly shown a desirable skill of a good tester – patience. I would like to hear your ideas about my analogy between Market and Software Testing.
Can you think of more such points, which can link them together? Let me know your ideas by commenting. !!!
Last analogy..
Happy T---ing.
Happy Trading… Happy Testing…
Game Tester
A game tester analyzes video games to document software defects as part of a quality control process in video game development. While popularized as a dream job for gamers, interactive entertainment software testing is a highly technical field requiring computing expertise, analytic competence, thick skin, and the ability to endure long hours.
Description
Modern video and computer games take from one to three years to develop (depending on scale). Testing begins late in the development process, sometimes from halfway to 75% into development (it starts so late because, until then, there is little to nothing to playtest). Testers get new builds from the developers on a schedule (daily/weekly) and each version must be uniquely identified in order to map errors to versions. They also test the durability of the game disc through a series of tests that can include how much damage the disc can take before becoming unresponsive, and how glitches can affect how the game runs.
Once the testers get a version, they begin playing the game. Testers must carefully note any errors they uncover. These may range from bugs to art glitches to logic errors and level bugs. Some bugs are easy to document ("Level 5 has a floor tile missing in the opening room"), but many are hard to describe and may take several paragraphs to describe so a developer can replicate or find the bug. On a large-scale game with numerous testers, a tester must first determine whether the bug has already been reported before they can log the bugs themselves. Once a bug has been reported as fixed, the tester has to go back and verify the fix works.
This type of "playing" is tedious and gruelling. Usually an unfinished game is not "fun" to play, especially over and over. A tester may play the same game — or even the same level in a game — over and over for eight hours or more at a time. If testing feature fixes, the tester may have to repeat a large number of sequences just to get to one spot in the game. Understandably, burn-out is common in this field and many use the position just as a means to get a different job in game development. For this reason, game testing is widely considered a "stepping stone" position. This type of job may be taken by college students as a way to audit the industry and determine if it is the type of environment in which they wish to work professionally.
In software development quality assurance, it is common practice to go back through a feature set and ensure that features that once worked still work near the end of development. This kind of aggressive quality assurance—called regression testing—is most difficult for games with a large feature set. If a new bug is discovered in a feature that used to work, once it is fixed, regression testing has to take place "again".
Game testing becomes grueling as deadlines loom. Most games go into what is called "crunch time" near deadlines; developers (programmers, artists, game designers and producers) work twelve to fourteen hours a day and the testers must be right there with them, testing late-added features and content. Often during this period staff from other departments may contribute to the testing effort to assist in handling the load.
All console manufacturers requires that the title submitted goes through a series of rigid standards established. Failure to respect the required standard prevents the game to be published on the market. Many video game companies separate technical requirement testing from functionality testing altogether.
Types of Game Testing
Localisation testing is the testing that needs to be done to make sure the game is the correct language and all spellings, grammar and punctuation is correct. This is just a small amount that the localisation tester has to do.
Beta testing means any testing that’s done on a game that’s in the "beta" stage of development. Often, though, it means the first version of a game that anyone outside the company sees: a ‘public beta’. Public betas are effective because thousands of eager fans will often find bugs that your small group of testers couldn’t. It’s also useful to distinguish beta testers from QA testers: Beta testers might test from home, or casually on a single project, while QA testing is generally a full time, trained job.
Regression testing is a stage of testing. Once a bug has been fixed by the coders, it’s returned to the QA department for regression testing. QA checks to see whether the bug is still there (regression) and then runs similar tests to see whether the fix broke something else. That second stage is often called halo testing; it involves testing all around a bug, looking for other bugs.
Compatibility testing is for the hardware mechanics. In order to get the list of system requirements for a game, you need to test it on a bunch of different machines, each with specific video cards, amounts of RAM, operating systems, processors, and so on. You can often start with a good guess (if a game was built for Flash, it has the requirements that Flash does) but further testing is still required. Compatibility testing is generally done toward the end of development, when the game is coming together, because so much of the compatibility depends on exactly how the programmers work their magic. This means that if resources are available, it’s often good to run at least two rounds of compatibility tests: one early in beta to highlight some problems with plenty of time to fix them, and one late in beta or during GMC (gold master candidate, when the game is ready to ship) to really figure out exactly what the system requirements are.
Load testing tests the limits of a system. The system could be the number of players on an MMO server, or the number of sprites active on the screen, the amount of traffic running over an internet connection, or the number of threads running in a particular program. It’s most commonly used in the first sense, to mean the number of players or processes running on a server. Load testing generally requires a lot of people (like a beta test group) or software that fakes heavy activity.
Unit testing is run on a piece of code, often automated, to test whether it works at a basic level. For instance, if a piece of code is supposed to take in a username for an MMO and return an error if the name is already taken, then the unit test would automatically input a name that is known not to be used and one that is used and make sure that the proper response is given. Often programmers write unit tests for their own code, and QA only gets to see that part of the game once it has passed all of its unit tests. A good QA department, though, may help design unit tests to make them rigorous. Unit testing happens throughout a project at anytime the programmers are working.
Soak testing involves running a game for a long time to see whether performance degrades. Very subtle bugs like memory leaks might not come out in playing the game for five minutes but could ruin a saved game or crash the computer after an hour and a half of playing. Soak testing is often automated, with software faking mouseclicks or otherwise making sure the computer doesn’t go to sleep. Many soak test bugs end up being filed unfixed as PUB ("Psychotic User Behavior") because a normal player wouldn’t play the same Pac-man level for 175 minutes in a row.
Responsibility
In the early days of computer and video games, the developer was in charge of all the testing. Since most games were so limited in scope, this was easy and usually required no more than one or two testers. In some cases, the programmers themselves could handle all of the testing.
As games have become more complex, a larger pool of quality assurance (QA) resources is necessary (sometimes it is called "Quality Assessment"). This being the case, most publishers have a large QA staff that they have testing various games from different developers.
Usually one group of testers will work on the same game from the beginning of the QA process to the time the game ships (goes "gold"). Thus, they become experts at the game and become familiar with all its nuances and weaknesses. Normally a group of testers will work on from one to two games at a time, depending on each game's scale. As one game nears completion, they may focus more time on it as the QA requirements escalate. Near the end of development, the QA staff may relocate to the development location in order to provide intensive QA work and be easily accessible to developers.
Despite the large QA infrastructure most publishers have, many developers will retain a small group of testers to provide on-the-spot QA from time to time.
Compensation
Despite the job's difficulty, game testing doesn't pay a great deal and is usually paid hourly (around USD$10 - $12 an hour). Testing management is usually more lucrative, but this type of job usually requires years of experience and some type of college degree. For this reason, as mentioned earlier, most game testing jobs are taken as "foot in the door" positions, used as a stepping stone for more lucrative lines of work in game development. An annual survey found that testers earn an average of $39,063 annually. Testers with less than three years experience earn an average of $25,142 while testers with over six years experience earn $43,056. Testing leads with over six years experience earn on an average of $70,658 a year.
Some employers offer bonuses for the number of bugs a tester finds. While this approach may seem initially reasonable, it often leads to testers reporting game features they personally don't care for as bugs, or reporting features as bugs simply for the extra money.
