Software Testing Interview Questions

Test scenarios and/or cases are prepared by reviewing functional requirements of the release and preparing logical groups of functions that can be further broken into test procedures. Test procedures define test conditions, data to be used for testing and expected results, including database updates, file outputs, report results.

. Test cases and scenarios are designed to represent both

The test strategy is a formal description of how a software product will be tested. A test strategy is developed for all levels of testing, as required. The test team analyzes the requirements, writes the test strategy and reviews the plan with the project team. The test plan may include test cases, conditions, the test environment, a list of related tasks, pass/fail criteria and risk assessment.

A software testing methodology is the use of a three step process of:
1. Creating a test strategy;
2. Creating a test plan/design; and
3. Executing tests.

This methodology can be used and molded to your organization’s needs. Using this methodology is important in the development and in ongoing maintenance of the customers’ applications.

I met with my team’s automation experts a few weeks back to get their input on when to automate and when to manually test. The general rule of thumb has always been to use common sense. If you’re only going to run the test one or two times or the test is really expensive to automation, it is most likely a manual test. But then again, what good is saying “use common sense” when you need to come up with deterministic set of guidelines on how and when to automate?

Pros of Automation

1. If you have to run a set of tests repeatedly, automation is a huge win for you
2. It gives you the ability to run automation against code that frequently changes to catch regressions in a timely manner
3. It gives you the ability to run automation in mainstream scenarios to catch regressions in a timely manner (see What is a Nighlty)
4. Aids in testing a large test matrix (different languages on different OS platforms). Automated tests can be run at the same time on different machines, whereas the manual tests would have to be run sequentially.

Cons of Automation

1. It costs more to automate. Writing the test cases and writing or configuring the automate framework you’re using costs more initially than running the test manually.
2. Can’t automate visual references, for example, if you can’t tell the font color via code or the automation tool, it is a manual test.

Pros of Manual

1. If the test case only runs twice a coding milestone, it most likely should be a manual test. Less cost than automating it.
2. It allows the tester to perform more ad-hoc (random testing). In my experiences, more bugs are found via ad-hoc than via automation. And, the more time a tester spends playing with the feature, the greater the odds of finding real user bugs.

Cons of Manual

1. Running tests manually can be very time consuming
2. Each time there is a new build, the tester must rerun all required tests - which after a while would become very mundane and tiresome.

Other deciding factors

1. What you automate depends on the tools you use. If the tools have any limitations, those tests are manual.
2. Is the return on investment worth automating? Is what you get out of automation worth the cost of setting up and supporting the test cases, the automation framework, and the system that runs the test cases?

Criteria for automating
There are two sets of questions to determine whether automation is right for your test case:

Is this test scenario automatable?

1. Yes, and it will cost a little
2. Yes, but it will cost a lot
3. No, it is no possible to automate

How important is this test scenario?

1. I must absolutely test this scenario whenever possible
2. I need to test this scenario regularly
3. I only need to test this scenario once in a while

If you answered #1 to both questions – definitely automate that test
If you answered #1 or #2 to both questions – you should automate that test
If you answered #2 to both questions – you need to consider if it is really worth the investment to automate

What happens if you can’t automate?
Let’s say that you have a test that you absolutely need to run whenever possible, but it isn’t possible to automate. Your options are

1. Reevaluate – do I really need to run this test this often?
2. What’s the cost of doing this test manually?
3. Look for new testing tools
4. Consider test hooks

===================================

Author - saraford

http://blogs.msdn.com/saraford/archive/2005/02/07/368833.aspx

Original post by Ahamad and software by Elliott Back

The Key Process Areas (KPAs) define “building blocks” based on industry best practices. The
ultimate goal is to establish “continual improvement” of the software engineering process and the resulting products. The KPAs of lower levels focus mainly on management processes (and industry minimal standards). While the KPAs of higher levels focus more on organizational and technical processes (and

Title of the post should ideally be “Responsibilities of a Test Engineer”
− Understand project requirements.
− Prepare / Update the Test case document for testing of the application from all aspects.
− Prepare the test setup.
− Deploy the build in the required setup.
− Conduct the Testing including Smoke, Sanity, and Bug Bash / Execute the Test cases.
− Update the Test Result document.

Implement QA processes slowly over time.

Use consensus to reach agreement on processes and adjust and experiment as an organization grows and matures. Productivity will be improved instead of stifled. Problem prevention will lessen the need for problem detection. Panics and burnout will decrease and there will be improved focus and less wasted effort.

At the same time, attempts should be made