What is Software Life Cycle?

A software life cycle model (SLCM) is a representation of the major components of software development work and their interrelationships in a graphical framework that can be easily understood and communicated.
The Software Life Cycle begins when an application is first conceived and ends when it is no longer in use. It includes aspects such as initial concept, requirements analysis, functional design, internal design, documentation planning, test planning, coding, document preparation, integration, testing, maintenance, updates, retesting, phase-out, and other aspects.
You must have a defined SLCM for your project to:

• Determine project milestones at which project performance can be evaluated
• Define the sequence of work units
• Provide a framework for definition and storage of the deliverables produced by the project
• Communicate your development strategy to project stakeholders
  

A SLCM achieves this by:

• Providing a simple graphical representation of the work to be performed
• Allowing focus on important features of the work, downplaying excessive detail
• Providing a standard work unit hierarchy for progressive decomposition of the work into manageable chunks
• Providing for changes (tailoring) at low cost

Few More Interview Questions.

• What is the structure of the company?
• Who is going to do the interview-possible background information of interviewer?
• What kinds of assignments might I expect in the first six months of the job?
• What do you like best about your company?
• What is the employer's environment (platforms, tools, etc.)?
• What are the employer's methods and processes used in software arena?
• What is the employer's philosophy?
• What is the project all about you are interviewing for-as much information as possible.
• Any terminologies that the company may use.
  What is the structure of the software testing team?
• What are the responsibilities of the software testing team members?
• How many computers are in the software testing lab?
• What kinds of software testing tools are installed in the software testing lab?
• What is the ratio between software developers and testers in the company?
• What development and QA methodologies is the company using?
• What are your growth projections for next year?
• Have you cut your staff in the last three years?
• Is this a new position or am I replacing someone?
• What types of documents would you need for QA, QC, and Testing?
• What did you include in a test plan?
• What is Software Quality Assurance?
  Quality Assurance makes sure the project will be completed based on the previously agreed specifications, standards and functionality required without defects and possible problems. It monitors and tries to improve the development process from the beginning of the project to ensure this. It is oriented to "prevention

How to Write Effective Bug Reports?

The Purpose Of A Bug Report:
When we uncover a defect, we need to inform the developers about it. Bug report is a medium of such communication. The primary aim of a bug report is to let the developers see the failure with their own eyes.
If you can't be with them to make it fail in front of them, give them detailed instructions so that they can make it fail for themselves.
The bug report is a document that explains the gap between the expected result and the actual result and detailing on how to reproduce the scenario.

After Finding The Defect
* Draft the bug report just when you are sure that you have found a bug, not after the end of test or end of day. It might be possible that you might miss out on some point. Worse, you might miss the bug itself.
* Invest some time to diagnose the defect you are reporting. Think of the possible causes. You might land up uncovering some more defects. Mention your discoveries in your bug report. The programmers will only be happy seeing that you have made their job easier.
* Take some time off before reading your bug report. You might feel like re-writing it.

Defect Summary : The summary of the bug report is the reader’s first interaction with your bug report. The fate of your bug heavily depends on the attraction grabbed by the summary of your bug report. The rule is that every bug should have a one-liner summary. It might sound like writing a good attention-grabbing advertisement campaign. But then, there are no exceptions.
A good summary will not be more than 50-60 characters. Also, a good summary should not carry any subjective representations of the defect.

The Language
* Do not exaggerate the defect through the bug report. Similarly, do not undertone it.
* However nasty the bug might be, do not forget that it’s the bug that’s nasty, not the programmer.
* Keep It Simple & Straight. You are not writing an essay or an article, so use simple language.
* Keep your target audience in mind while writing the bug report. They might be the developers, fellow testers, managers, or in some cases, even the customers. The bug reports should be understandable by all of them. Steps