STLC?

It is a process of conducting software testing, means after 
programmer conducted integration testing by using white 
box testing, the integrated software build is coming to 
overall developed software testing. 

Test Requirements

• Requirement Specification documents
• Functional Specification documents
• Design Specification documents (use cases, etc)
• Use case Documents
• Test Trace-ability Matrix for identifying Test Coverage

Test Planning

• Test Scope, Test Environment
• Different Test phase and Test Methodologies
• Manual and Automation Testing
• Defect Mgmt, Configuration Mgmt, Risk Mgmt. Etc
• Evaluation & identification ? Test, Defect tracking tools

Test Environment Setup

• Test Bed installation and configuration
• Network connectivity?s
• All the Software/ tools Installation and configuration
• Coordination with Vendors and others

Test Design

• Test Traceability Matrix and Test coverage
• Test Scenarios Identification & Test Case preparation
• Test data and Test scripts preparation
• Test case reviews and Approval
• Base lining under Configuration Management

Test Automation

• Automation requirement identification
• Tool Evaluation and Identification.
• Designing or identifying Framework and scripting
• Script Integration, Review and Approval
• Base lining under Configuration Management

Test Execution and Defect Tracking

• Executing Test cases
• Testing Test Scripts
• Capture, review and analyze Test Results
• Raised the defects and tracking for its closure

Test Reports and Acceptance

• Test summary reports
• Test Metrics and process Improvements made
• Build release
• Receiving acceptance

How can be write Test Case ?

Purpose:-

Short sentence or two about the aspect of the system is being tested. If this gets too long, break the test case up or put more information into the feature descriptions. 

Prerequisite:-

Assumptions that must be met before the test case can be run. E.g., "logged in", "guest login allowed", "user test user exists".   

Test Data:-

List of variables and their possible values used in the test case. You can list specific values or describe value ranges. The test case should be performed once for each combination of values. These values are written in set notation, one per line. E.g.:

loginID = {Valid loginID, invalid loginID, valid email, invalid email, empty}

password = {valid, invalid, empty}

Steps:-

Steps to carry out the test. See step formatting rules below.

1. visit LoginPage
2. enter userID
3. enter password
4. click login
5. see the terms of use page
6. click agree radio button at page bottom
7. click submit button
8. see PersonalPage
9. verify that welcome message is correct username

Expected Results:- 

A results which you will get after run/execute of a test case.

Actual Results:-

 After run a test case manual or automatically  the result should be match with actual result if it is match with the actual result your test case goes in to pass status otherwise fail.

SDLC Phases?

The systems development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application .

 SDLC Phases:-

• Planning 

Everything starts with a concept. It could be a concept of someone, or everyone. However, there are those that do not start out with a concept but with a question, “What do you want?” they ask thousands of people in a certain community or age group to know what they want and decide to create an answer. But it all goes back to planning and conceptualization.

• Requirement

In engineering, a requirement is a singular documented need of what a particular product or service should be or perform. It is most commonly used in a formal sense in systems engineering or software engineering. It is a statement that identifies a necessary attribute, capability, characteristic, or quality of a system in order for it to have value and utility to a user.

• Design

Once planning and arguing with the manager or the owner about the plan and somehow convincing them, it is time to design or create a rough plan regarding the software.

• Implemantion

The first two stages are quite common in all SDLC models. However, things change starting on this stage. When the design and all the things that you need have been laid out, it is time to work on the plan. Some developers, especially those that follow the standard plan of developing software will work on the plan and present them for approval.

• Testing 

This could mean two things depending on an SDLC model. The first type of testing is the actual testing by users. This is usually done in models wherein implementation does not go with pre-testing with users. On the other hand, there are also testing that uses professionals in the field. This testing is aimed in cleaning the software of all the bugs altogether. For software that are set for public release, the software is first tested by other developers who were not in charge in creating the software.

• Acceptance

When the software is released to be used by a certain company, acceptance means the software is implemented as an added tool or could be replacing another software that has been found too wanting after years of use. On the other hand, when the software is implemented to the public a new software could be an added software for use. It is difficult to change public software but they are not closing their ears to new software. So developers will always have a fighting chance in the market as long as they implement good software for public use.

• Maintinance

When the software is implemented, it does not mean that the software is good as it is. All SDLC models include maintenance since there are absolutely no way that a software will be working perfectly. Someone has to stay in the present software to take a look and ensure the program works perfectly. When the software is implemented in public.Software companies either set up a call center or an e-mail service to address the concerns of the consumer. As we have indicated in previous chapters, Maintenance is quiet an easy task as long as the right food and product is serve in an expected time frame. However, it is always a challenge when something goes wrong. The whole team might not be there to help the developer so addressing a major concern could never be answered.

How can be write Test Case ?

“A test case has components that describes an input, action or event and an expected response, to determine if a feature of an application is working correctly.”

A test case in software engineering is a set of conditions or variables under which a tester will determine whether an application or software system is working correctly or not. The mechanism for determining whether a software program or system has passed or failed such a test is known as a test oracle.

Level 1: 

This level you will write the basic test cases from the available specification and user documentation.
 

Level 2: 

This is the practical stage in which writing test cases depend on actual functional and system flow of the application.
 

Level 3:

 This is the stage in which you will group some test cases and write a test procedure. Test procedure is nothing but a group of small test cases maximum of 10.
 

Level 4: Automation of the project. 

This will minimize human interaction with system and thus QA can focus on current updated functionalities to test rather than remaining busy with regression testing.

What is a Test Strategy ?

How we plan to cover the product so as to develop an adequate assessment of quality.                                A good test strategy is:

• Specific
• Practical
• Justified

The purpose of a test strategy is to clarify the major tasks and challenges of the test project.Test Approach and Test Architecture are other terms commonly used to describe what I’m calling test strategy.

Example of a poorly stated (and probably poorly conceived) test strategy:
"We will use Black Box testing, cause-effect graphing, boundary testing, and white box testing to test     product against its specification."

• Creating Test Strategy
• Defining Test Strategy
• Requirements in Test Strategy
• Key points to remember

What is a test Plan?

A test plan lets you specify what you want to test and how to run those tests. A test plan can be applied to a specific iteration of your project. You can have just one default test suite for your test cases, or you can create a test suite hierarchy. You can also select the default configurations to use to run the tests in your test plan. The test configuration informs the tester of the set up that is required for these tests. You can have one or multiple default configurations. A test result is recorded every time that you run the test with a specific configuration. A test plan enables you to measure your testing progress, based on these test results for the test and configuration pairings, as shown in the following illustration. 

Bussiness Requirement Specifications (BRS) ?

In short BRS is a document which explains the expected output what exactly the client wants. This is the first document which will be referred by development team and testing team from start to end.
It contains the details of the end to end business. What are all the process they wants to implement. It could be a new feature or existing one.
In general this document will help to understand the clients requirements.

Bug Vs Error Vs Defects ?

Bug:- 

1. A software bug may be defined as a coding error that cause an unexpected defect,fault or flow.In other words if a program does not perform as intend  it is most likely a bug.
2. If that error comes at the tome of development stage before production then it is bug. 
3. A fault in a program which cause the program to perform in an unintended or unanticipated manner.  

Error:- 

1. A mismatch between the program and its specification is an error in the program.
2. The difference between expected results and actual results is error.
3. A mistake in program called error.

Defect:- 

1. Defects is the variance form a desired product attribute it can be two types.
2. Defects from the products or a variance form customer/user expectation it is a flow in the software system and has no impact until it affects the user/customer and operational system 90% of all defects can be caused by process problem.
3. If that error comes after production then we say it is defect.
4. It ts a mismatch between the requirements.It is found in last stage of production. 

Software requirement specification (SRS) ?

Software Requirements Specification (SRS) is complete description of the behavior of the system to be developed. It includes a set of use cases that describe all the interactions the users will have with the software. Use cases are also known as functional requirements. In addition to use cases, the SRS also contains non-functional (or supplementary) requirements. Nonfunctional requirements are requirements which impose constraints on the design or implementation (such as performance engineering requirements, quality standards, and design constraints).

1.      What Makes a Great Software Requirements Specification?

We have to keep in mind that the goal is not to create great specifications but to create great products and great software. Can you create a great product without a great specification? Absolutely! You can also make your first million through the lottery – but why take your chances? Systems and software these days are so complex that to embark on the design before knowing what you are going to build is foolish and risky.

2.      What are the benefits of a Great SRS?

·         Establish the basis for agreement between the customers and the suppliers on what the software product is to do.

·         Reduce the development effort.

·         Provide a basis for estimating costs and schedules.

·         Provide a baseline for validation and verification.

·         Facilitate transfer.

·         Serve as a basis for enhancement.

3.      What are the characteristics of a great SRS?

·         Correct

·          Unambiguous

·          Complete

·          Consistent

·          Ranked for importance and/or stability

·          Verifiable

·          Modifiable

·          Traceable

4.      Difference between a design requirement and software requirement?

The SRS should not include any design requirements. However, this is a difficult discipline. For example, because of the partitioning and the particular RTOS you are using, and the particular hardware you are using, you may require that no task use more than 1 ms of processing prior to releasing control back to the RTOS. Although that may be a true requirement and it involves software and should be tested – it is truly a design requirement and should be included in the Software Design Document or in the Source code.

Consider the target audience for each specification to identify what goes into what documents.

Marketing/Product Management

Creates a product specification and gives it to Systems. It should define everything Systems needs to specify the product

Systems

Creates a System Specification and gives it to Systems/Software and Mechanical and Electrical Design.

Systems/Software

Creates a Software Specification and gives it to Software. It should define everything Software needs to develop the software.

Thus, the SRS should define everything explicitly or (preferably) by reference that software needs to develop the software. References should include the version number of the target document. Also, consider using master document tools which allow you to include other documents and easily access the full requirements.

Advantage and Disadvantage of SDLC modals?

SDLC models Advantages & disadvantages

Advantages of Waterfall Model

1. Clear project objectives.
2. Stable project requirements.
3. Progress of system is measurable.
4. Strict sign-off requirements.

Disadvantages of Waterfall Model

1. Time consuming
2. Never backward (Traditional)
3. Little room for iteration
4. Difficulty responding to changes

Advantages of Spiral Model

1. Avoidance of Risk is enhanced.
2. Strong approval and documentation control.
3. Implementation has priority over functionality.
4. Additional Functionality can be added at a later date.

Disadvantages of Spiral Model

1. Highly customized limiting re-usability
2. Applied differently for each application
3. Risk of not meeting budget or schedule
4. Possibility to end up implemented as the Waterfall framework

Advantages of Prototype model

1. Strong Dialogue between users and developers
2. Missing functionality can be identified easily
3. Confusing or difficult functions can be identified
4. Requirements validation, Quick implementation of, incomplete, but
functional, application
5. May generate specifications for a production application
6. Environment to resolve unclear objectives
7. Encourages innovation and flexible designs

Disadvantages of Prototype model

1. Contract may be awarded without rigorous evaluation of Prototype
2. Identifying non-functional elements difficult to document
3. Incomplete application may cause application not to be used as the
full system was designed
4. Incomplete or inadequate problem analysis
5. Client may be unacknowledged
6. Approval process and requirement is not strict
7. Requirements may frequently change significantly

Software Development Life Cycle Modals ?

Methodologies:-

Agile :-Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.

Rad Modal:- Its Minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements.

Spiral Modal:-The spiral methodology extends the waterfall model by introducing prototyping. It is generally
chosen over the waterfall approach for large, expensive, and complicated projects.At a high-level, the steps in the spiral model are as follows:

• The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.
• A preliminary design is created for the new system.
• A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.

 















                                      Figure1                                                                         Figure2                           


Waterfall Method:-The name of the waterfall lifecycle model comes from its physical appearance, shown in Figure , and the process by which the results from one phase flow into the next. An alternative name for this model is the “Big Bang” lifecycle because working results first appear near the end of the process, something like how scientists describe the Big Bang theory of how the universe was created. The waterfall model is simple, easy to learn, and easy to use.

 V Modal :- All the necessary steps of Software Development Life Cycle (SDLC) are followed. Most importantly, the phase of Software Quality Assurance (SQA) is executed with utmost care. The life cycle used by us for application development is as follows.

Nature of Test?

• Verification of requirement(Review)
• Architecture of design.
• Detailed design.
• Database design

•  User Interface testing.

•  Load testing 
• Stress testing
• Disaster  Recovery testing.
• Installation testing
• Configuration Testing

• Functional testing

• Unit testing 
• Structural Testing

• Integration testing
• System testing

• User Acceptance testing

How does Software Testing work in orgainization?

What is a softawre engineering?

The application of a systematic disciplined quantitive approach
to the development,maintenance and operations of software the application of engineering of software.

Objective of Testing ?

1-Testing is basically a task of locating error.
2-Testing can show presence of errors not their absence.
3-In short,Maximum coverage of through minimum test cases is
the biggest chalange of testing.
4-Software defects can not be prevented because software development and
testing continue to be a manual process.