Many times it happens that testers (or other professionals) crack the technical interview round, but they are not able to clear HR round successfully. So on readers request, we are posting some “General Guidelines in Answering Interview Questions”.
Everyone is nervous on interviews. If you simply allow yourself to feel nervous, you’ll do much better. Remember also that it’s difficult for the interviewer as well.
In general, be upbeat and positive. Never be negative.
Rehearse your answers and time them. Never talk for more than 2 minutes straight.
Don’t try to memorize answers word for word. Use the answers shown here as a guide only, and don’t be afraid to include your own thoughts and words. To help you remember key concepts, jot down and review a few key words for each answer. Rehearse your answers frequently, and they will come to you naturally in interviews.
As you will read in the accompanying report, the single most important strategy in interviewing, as in all phases of your job search, is what we call: “The Greatest Executive Job Finding Secret.” And that is…
Read complete at below document:
Software Testing – Top Toughest HR Interview Questions

Free Webinars by kavinschool.com –

About KavinSchool –
Kavin School offers low cost Selenium Automation Testing Tool training for the students who have no or prior experience in Selenium. If you have already have experience is Selenium. Look for various techniques provided during the training which will eliminate the number of hours you spent to figure out to solve a specific problem. The training is designed to meet both novice as well as advanced users to learn Selenium easily and get confident to attend the interviews.

Both webinars aims to look at the tips & tricks of Selenium Data Driven Testing Using Ruby & Java. Below are the Webinars detail:

Webinar 1. Selenium Data Driven Testing Using Ruby Language – Tips and Tricks – Aug-14-2010 – Sat 8:15 AM to 12:15 PM PST – Click here to register

Webinar 2. Selenium Data Driven Testing Using Java Language – Tips and Tricks – Oct-10-10 – Sun 8:15 AM to 12:15 PM PST – Click here to register

For Details on Selenium Trainings – go http://www.kavinschool.com/content/schedules or http://www.onestopsoftwaretesting.com/training-Webinar-on-selenium-open-source-automation-testing-tool


Related Topics:

• Selenium for Functional testing of web applications
• Selenium Interview Questions

Good News for Indian QTP lovers. Tradus Books is offering Quicktest Professional Unplugged book by Tarun Lalwani @ 417 INR + Free shipping
Summary:
HP QuickTest Professional is a functional test automation tool. It supports a Record and Playback framework out of the box, where we can record and capture our interactions with the application under test and then replay those actions later. With this book you will learn – Basic concepts of QTP – Working without Object repository using Descriptive Programming – Advanced concepts of QTP – Working with external tools Microsoft Word, Outlook, Excel – Integrating QTP Scripts with Quality Center – Real life Automation problems and their solutions.
You can get the book here – http://www.tradusbooks.in/quicktest-professional-unplugged-qt-unplugged
Read Book review here: http://www.onestopsoftwaretesting.com/book-quicktest-professional-unplugged-by-tarun-lalwani
 

On readers request, we are posting following software testing templates which use can use in your projects:
1. Sample Software Tester Resume Template
2. Software Test Plan Template
3. Software Test Report template
4. Use Case Template
5. Software Testing Checklist Template
6. Software Test Strategy Template
7. Requirements Traceability Matrix template
8. Test Case Template
You can download the templates from following links:
Sample Software Tester Resume Template
http://ninjalink.com/30761pte

Software Test Plan Template
http://ninjalink.com/30762cpl

Software Test Report template
http://ninjalink.com/30763lwm
Use Case Template:
http://ninjalink.com/30764rvy

Software Testing Checklist Template:
http://ninjalink.com/30765sbi

Software Test Strategy Template:
http://bit.ly/cGAjpo

Requirements Traceability Matrix template
http://ninjalink.com/30767amd

Test Case Template:
http://bit.ly/bVWY6V

Neatly document the test plan and test strategy for the application under test. Test Plan serves as the basis for all testing activities throughout the testing life cycle. Being an umbrella activity this should reflect the customers needs in terms of milestones to be met, the test approach (test strategy), resources required etc. The plan and strategy should give a clear visibility of the testing process to the customer at any point of time.
Functional and Performance test plans if developed separately will give lot more lucidity for functional and performance testing. Performance test plan is optional if the application does not entail any performance requirements.

Below are some useful Do’s and Don’ts:
The Do’s:

• Develop test plan based on a approved Project Plan
• Document test plan with major testing milestones
• Identify and document all deliverables at the end of these milestones
• Identify the resources (Both Hardware/Software and Human) required
• Identify all other external systems, which is going to interact with the application. For example the application can get the data from any other mainframe server. Identification of such systems will help one plan for integration testing as well
• If performance testing is under the scope of testing then clearly identify the application performance requirements like number of hits/second, response time, number of concurrent user etc. Details about different testing methodologies (Spike testing, Endurance testing, stress testing, capacity testing) during the performance testing phase can also be documented.
• Get the test plan approved.
• Include Features to be tested to communicate to customer what all will be tested during the testing life cycle
• Include Features not tested to communicate to customer what all will not be tested during the testing life cycle. (As part of risk management)

The Don’ts:

• Do not use draft (unapproved) test plans for reference
• Do not ignore the test strategies identified in the test plan during testing.
• Do not make changes to any approved test plan without official change request
• Do not mix the stages of testing (Unit testing, Integration testing, System testing, Functional testing etc) with the types of testing (Regression testing, Sanity testing, User Interface testing, Smoke testing etc) in the test plan. Identify them uniquely with their respective input and exit criteria.

A must Read – Do we Really Need Test Plan Documents?
Effective Handbook for Implementing Test Strategies

The main reason of the reviewing test cases: increase test coverage and therefore product quality.

As we know testers are involved on the Requirements Specification review process to provide the SQA knowledge to the requirements written. As testers are involved on the process they become experts on the area and on the application functionality and many times their knowledge helps avoid introducing future defects into the functionality that later the developer will code (it’s the phase that we called: defect prevention).

Once the requirements are approved and baselined, testers start designing test cases whether on their mind, or writing them (test drafts). Once all the ideas or test case drafts are understood and prepared, the SQA tester will start developing test cases. When this happens, each test case written is based on a specific requirement, so with that we start assuring having traceability between requirement and test cases. This will help SQA team to manage the Requirements coverage of what is going to be tested.

Once the test cases are developed, SQA tester should share-distribute-discuss those with the same team that reviewed the requirements (SRS writer, Developers, SQA tester, Implementation team, etc). However, sometimes this is not possible, as perhaps when the Requirements are baselined, the person who is in charge of the SRS starts on another project and has not even more time to dedicate reviewing a set of test cases. The same happens with the Implementations team, as they are perhaps installing the product on a customer site. There are cases where SQA tester and developer start more or less at the same time with their work based on the Requirements. Developer starts developing code and Tester developing test cases. There are other times that SQ Tester starts thinking or having test case drafts even before the Developer starter coding. That means that developing code and test cases are and should be separate processes.

Of course that having a Requirements-Usability people reviewing test cases has a lot of value, also having the implementations team doing the same. The problem has been that these often did not happen due the lack of resources, so the test cases review would progress only with the developer involved on the same project and functionality. In any case the developer review test cases always would go in the direction of adding details, parameters or circumstances not included in the tester written test cases or well even adding new test cases but never modifying the sense of the test cases written by the tester.

This is the approach and the how the test cases defined by testers need to be reviewed by the developer. We should also notice that some times when the test cases writer is a beginner, not a senior tester, or well does not have so much knowledge about the functionality, then someone from the SQA team with more experience should check the test cases before sharing them with the developer for review.

Benefits of having test cases reviews for SQA test cases written, including on them the developers:

• Defect prevention while SRS review: SQA tester could advance during SRS reviews possible issues before any code starts

• Conceptual and Technical Coverage: Requirements- Usability ensures the coverage from the Concept point of view and Developer ensures the coverage from the Technical Point of view. The traceability coverage track is assumed by traceability tools (Quality Center)

• Defect prevention while test cases review: If the developer has the opportunity to check the test cases while implementing code, it is possible that this will help him to realize codification that may be a cause of a defect. This will help to coding in the way of potential defects.

• Developer Knowledge add to test cases: Developer has also a very good understanding of the requirement (SRS), explicit and implicit as well. Also has done a deep analysis of them since he had to accomplish the SRA. He can bring experience on understanding better details or well some cases not being considered.

After having the test cases reviewed, the SQ team receives all the feedback and decides, based on its experience and knowledge on SQA and also on the functionality if feedback is applied or not. When not applied, the reason should be explained and discussed with the developer since there should be a final agreement on the test cases written.

Author – Unknown (Let us know if you know the author – Published from our old forums and posts)