What is the outline of test plan? What are test specification items?

There is an outline that should be followed while writing a test plan. It consists of the following:
- The Background
- The Introduction
- The Assumptions
- The Test Items to be tested.
- The Features to be tested.
- The Features not to be tested.
- The Approach that is to be followed.
- Item Pass/Fail Criteria which is an itemized list of expected output and tolerances.
- The Suspension or Resumption Criteria.
- Test Deliverable which includes beside software, what else would be delivered?
- Testing Tasks which consists of functional and administrative tasks.
- Environmental needs like security clearance, office space and equipment, hardware and software requirements.
- Responsibilities.
- Staffing and Training
- Schedule
- Resources
- Risks and Contingencies
- Approvals

Test specifications are developed from test plan and are a part of second phase of test development life cycle. How to implement the test cases is explained through test specifications. It consists of following:
- Case Number
- Title of Test
- ProgName which consists of program name containing test.
- Author
- Date
- Background which consists of Objectives, Assumptions, References, Success Criteria.
- Expected Errors
- References
- Data that flows between the implementation under test and test engine.
- Script

What is a bug and bug life cycle? What are guidelines for deciding severity of bugs?

A bug is defined as a defect or some abnormal behavior of software. Testing plays an important part in the removal of bug. Bug has to travel the whole bug life cycle until it is closed. The cycle includes following stages:
- New
When the bug is posted for first time and not yet approved.
- Open
When tester approves that bug is genuine.
- Assign
Bug is assigned to the developer.
- Test
After fixing the bug, it is assigned to testing team to re-test it.
- Deferred
When the bug is changed to deferred state, the bug is expected to be fixed in next releases.
- Rejected
If the developer feels that the bug is not genuine, he can reject the bug.
- Duplicate
If bug is repeated twice or two bugs gives the same concept, then one bug is labeled duplicate.
- Verified
Once the bug is fixed, it is verified that no bug is present and status is changed to verified.
- Reopened
In this stage, the bug traverses the bug cycle once again because the bug still exists.
- Closed
If the bug is fixed and does not exist, the tester changes the status to closed.

SEVERITY AND PRIORITY OF THE BUG HAS TO FOLLOW GUIDELINES:
- Critical bug prevents further testing of the product under test. No work around is possible for such bugs.
- Major bug is in which defect does not function as expected or cause other functionality to fail.
- Medium or average bug in which defects do not conform to standards and conventions.
- Minor or low bugs do not affect the functionality of the system.

To write bug description, follow these guidelines:
- Be specific.
- Use present tense.
- No unnecessary words.
- No exclamation points.
- Do not use all CAPS.
- Mention steps.

If the bug is found, what should be done ?

Test cases are written to detect if a feature of an application is working correctly. It is a document which consists of input, action and expected output. After a bug is found, the developers are informed about the bug and are asked to fix it. After it gets fixed, the module is re-tested and it is checked whether it has not created any problem.

- Information of the bug and its severity.
- Bug identifier.
- Bug status.
- Application name.
- The name of the module, function, object etc. where the bug occurred.
- Environment factors.
- Test case name and identifier.
- One line bug description.
- Full bug description.
- If the bug is not covered by test case, steps are described again.
- Names of file used in test.
- Severity level
- Can the bug be reproduced.
- Tester name and test date.
- Name of developer.
- Description of cause of the problem.
- Description of the fix.
- Date of fix.
- Application version that contains the fix.
- Description about tester.
- Date of retest.
- Results of retest.
- Requirements of regression testing.
- Tester who has done regression tests.
- Results of regression testing.

Sometimes, the software is so buggy that it becomes impossible to test it. In order to handle this type of situation, the testers should report whatever bugs they are coming across, focusing more on critical bugs. It depicts deeper problems in the software development process.

Why is documentation necessary in QA? What steps are needed to develop and run software tests?

Documentation is very necessary in quality assurance. Everything should be documented. User manuals, test plans, bug reports, business reports, code changes, specifications, design and all other reports should be documented. Any changes in the process should be documented.
A properly documented requirement specification is very necessary. Requirements are the details of what is to be done. Requirements should be clear, complete, detailed, testable. Details should be determined and organized in an efficient way but it can be difficult to handle. Some type of documentation with detailed requirements is very important to properly plan and execute tests.

There are some steps that are needed to develop and run software tests:
- The requirements, design specifications are necessary.
- Budget and cost should be known.
- What people will be responsible, responsibilities, standards and processes should be listed.
- Risk aspects should be determined.
- Test approaches should be defined.
- Test environment should be defined.
- Tasks should be identified.
- Inputs should be determined.
- Test plan document should be prepared.
- Test cases should be written.
- Test environment and test ware should be prepared.
- Tests are performed and results are evaluated.
- Problems are tracked, re-testing is done and test plans are maintained and updated.

What is ad hoc testing ? What is the need for this sort of testing ?

Typically, when we talk about software testing, we typically talk about testing plans and test cases. As we get into more detail, we can get into various type of testing strategies, and explore the many testing practices that are sought to be employed during the course of testing. So, there are many testing terms such as Black Box testing, White Box testing, Automation testing, and so on.
However, there is another sort of testing called 'Ad hoc testing' that is totally contrasting to all these strategies and practices. So, what is Ad hoc testing ? Ad hoc testing is a process of testing that does not incorporate the use of test cases or any formal document that lists down software testing processes. Ad hoc testing is a form of Black Box testing, since the tester has no idea of the internals of the application, and even less idea of the API and code structure of the application.
Typically this sort of testing is done by a tester who is already experienced with the software product, and can be done in different cases - It can be done when there is a round of testing that is already done in a systematic way, or it can be done when there is not enough time to do a complete round of formal testing.
Why would we do Ad hoc testing ? Well, many teams go ahead for ad hoc testing when they have already completed their rounds of formal testing, and it has been found that when regular testers also go in for ad hoc testing, they can use their instinct to focus on areas of the application where they feel that things are a bit less secure, and find more bugs in that area. However, when a team goes in for ad hoc testing when they have not had time for regular testing, then they are getting into a high risk zone where there will be bugs in the application.
Ad hoc testing is useful also when an interim release of the software has to be handed over for demos or some other situations where it is not required that the software be of perfect quality, but embarrassing defects should not be there in the application.

What makes a good Software Test Engineer, SQA Engineer, Test Manager?

A good software test engineer has the following qualities:
- a software engineer should focus on having a high quality product.
- a software engineer should understand customer's needs and requirements.
- a software engineer should maintain a tactful and diplomatic relationship with developers.
- a software engineer should maintain a good relationship with non technical people.
- a software engineer should be able to have a judgment skill when needed.

A good Software Quality Assurance engineer has the following qualities:
- a software quality assurance engineer should focus on having a high quality product.
- a software quality assurance engineer should understand customer's needs and requirements.
- a software quality assurance engineer should maintain a tactful and diplomatic relationship with developers.
- a software quality assurance engineer should maintain a good relationship with non technical people.
- a software quality assurance engineer should be able to have a judgment skill when needed.
- a software quality assurance engineer should have a proper understanding of software development life cycle.
- a software quality assurance engineer should understand business approach and goals.
- a software quality assurance engineer should have good communications skills.
- a software quality assurance engineer should be able to find problem areas.

A good QA/Test Manager has the following properties
- he should have a good understanding of software development life cycle.
- he should have a good and healthy relation with the technical and non technical people.
- he should be able to increase his team's productivity and efficiency.
- he should be able to create enthusiasm about work among team members.
- he should be able to make correct and quick decisions.
- he should be good at handling pressure.
- he should have diplomatic skills.

What are some of the problems when doing Black Box Testing ?

Black Box testing is one of the significant methods of doing testing, especially in cases where the tester is not really supposed to know details about the internals of the application (code, API's, etc), and instead is mainly worried about the inputs or outputs. The tester will have a set of valid and invalid inputs, and corresponding outputs based on these inputs. This removed the need for testers who need to know the code (which would typically mean the developers who actually wrote the code need not be involved in the testing process). In addition, Black Box testing tends to replicate the process followed by the end users, and will help in reproducing the problems faced by the end users.
However, there are certain problems that are found during the Black Box testing, and people involved in Black Box testing should be fully aware of some of these challenges:
- Black Box testing almost is never able to cover all the areas of the application, since the number of combinations of input variables can be pretty huge
- There is a cost involved in the development and testing process, whereby the earlier you find the problem, the better it is. So code review is cheaper, unit testing is more expensive, and actual black box testing is more expensive - teams need to ensure that they have factored this as part of their planning
- Testers are dependent on the language of the test cases to ensure that test cases are comprehensive. If the exact requirement stated in the test case is not clear, then there is a chance that future testers could miss some of the input-output cases; it is clear from a number of examples that converting specifications to test cases in terms of languages can lead to errors and missed situations
- In some cases, Black Box testing can never be enough, you need to employ a combination of Black Box testing and White Box testing