MANUAL TESTING

Project(Application): Project development is done with respective particular client requirements or single client requirements Ex: Bank Applications, Hospital Applications etc. Product: - Product development is done assuming a wide range of customers and their needs. This type of development involves customers from all domains and collecting requirements from many different environments. Ex: MS Office, VB, Operating System etc. QUALITY: - Quality means satisfaction of the customer. To define good quality of software, the company people will concentrate on two factors such as. Technical factor Customer requirements in terms of functionalities Customer expectations (Look and feel, Ease of use, right output, speed of processing, security) Non-technical factor Low cost to purchase Time to market. SDLC: - (Software Development Life Cycle

SDLC (Software Development Life Cycle) is the process of developing software through business needs, analysis, design, implementation and maintenance. Software has to go through various phases before it is born which are as follows:

(i) Generating a Concept A concept comes from the users of the software. The user will specify what kind of software he would need and will specify his requirements. (ii) Requirements analysis Once the user requirements are known, they are given to a software team (company) who will analyse the requirement and prepare requirement document that will explain every functionality. This document will be the main document for developers, testers and database administrators. In other words, this is the main document that will be referred by everyone. (iii) Development: In this stage, developers start writing their code (program) for their modules. On the other hand, the testers in the QA (Quality Assurance) Department start writing Test Plans (one module=1 test plan), test cases and get ready for testing. (iv) Testing: Once the code (programs) is ready, they are compiled together and to make a build. This build is now tested by the software testers (QA Testers) (v) Production: After testing, the application (software) will be handed over to the owner. (vi) End

SDLC MODELS:1. WATERFALL MODEL: - This is the most common and classic of life cycle models, also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed before the next phase can begin. At the end of each phase, a review takes place to determine if the project is on the right path and whether to continue or discard the project.

2. V MODEL: - The V-model is a software development model which can be presumed to be the extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing.

V stands for Verification and Validation

VERIFICATION PHASES: a) Requirements analysis: - Usually, the users are interviewed and a document called the user requirements document is generated. The user requirements document will typically describe the systems functional, physical, interface, performance, data, security requirements etc. as expected by the user. It is one which the business analysts use to communicate their understanding of the system back to the users. The users carefully review this document as this document would serve as the guideline for the system designers in the system design phase. The user acceptance tests are designed in this phase. b) System Design: - This is the phase where system engineers analyse and understand the business of the proposed system by studying the user requirements document. They figure out possibilities and techniques by which the user requirements can be implemented. If any of the requirements are not feasible, the user is informed of the issue. A resolution is found and the user requirement document is edited accordingly.

c) Architechture design: - This phase of the design can also be referred to as high-level design. The integration testing design is carried out in the particular phase. d) Module Design:- This phase can also be referred to as low-level design. The designed system is broken up into smaller units or modules and each of them is explained so that the programmer can start coding directly. The low level design document or program specifications will contain a detailed functional logic of the module. The unit test design is developed in this stage.

VALIDATION PHASES: a) Unit testing: - Unit testing is conducted with respect to Low Level Designs(LLDs).The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remaining code, and determine whether it behaves exactly as you expect. Each unit is tested separately before integrating them into modules to test the interfaces between modules. Unit testing has proven its value in that a large percentage of defects are identified during its use. The most common approach to unit testing requires drivers and stubs to be written. The driver simulates a calling unit and the stub simulates a called unit. The investment of developer time in this activity sometimes results in demoting unit testing to a lower level of priority and that is almost always a mistake. Even though the drivers and stubs cost time and money, unit testing provides some undeniable advantages. It allows for automation of the testing process, reduces difficulties of discovering errors contained in more complex pieces of the application, and test coverage is often enhanced because attention is given to each unit. Drivers and stubs can be reused so the constant changes that occur during the development cycle can be retested frequently without writing large amounts of additional test code. In effect, this reduces the cost of writing the drivers and stubs on a per-use basis and the cost of retesting is better controlled. Testing is usually a White Box Testing.

b) Integaration testing: - - Integartion testing is conducted with respect to High Level Designs(HLDs). Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. Integration testing identifies problems that occur when units are combined.

Errors discovered when combining units are likely related to the interface between units. Testing is usually a Black Box Testing. You can do integration testing in a variety of ways but the following are three common strategies: Top-Down Approach: -The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for Stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality. Bottom- Up Approach: -The bottom-up approach requires the lowestlevel units be tested and integrated first. These units are frequently referred to as utility modules. By using this approach, utility modules are tested early in the development process and the need for stubs is minimized. The downside, however, is that the need for Drivers complicates test management and high-level logic and data flow are tested late. Like the top-down approach, the bottom-up approach also provides poor support for early release of limited functionality. Hybrid Approach: - (Umbrella Approach or Sandwich Approach)This requires testing along functional data and control-flow paths. First, the inputs for functions are integrated in the bottom-up pattern discussed above. The outputs for each function are then integrated in the top-down manner. The primary advantage of this approach is the degree of support for early release of limited functionality. It also helps minimize the need for stubs and drivers. The potential weaknesses of this approach are significant, however, in that it can be less systematic than the other two approaches, leading to the need for more regression testing. c) System Testing: - System testing will compare the system specifications against the actual system. After the integration test is completed, the next test level is the system test. System testing checks if the integrated product meets the specified requirements. System testing falls within the scope of Black Box Testing. In the previous test levels, the testing was done against technical specifications, i.e., from the technical perspective of the software producer. The

system test, looks at the system from the perspective of the customer and the future user. The testers validate whether the requirements are completely and appropriately met. e) User Acceptance Testing (UAT): - A Smoke test is used as an acceptance test prior to introducing a new build to the main testing processUser Acceptance Testing (UAT) is a process to obtain confirmation that a system meets customer requirements. The owner or client of the object under test, provides such confirmation after trial or review. In software development, UAT is one of the final stages of a project and often occurs before a client or customer accepts the new system. Types of acceptance testing: Alpha Testing: This takes place at developers' sites, and involves testing of the operational system by internal staff, before it is released to external customers. Beta Testing:- This takes place at customers' sites, and involves testing by a group of customers who use the system at their own locations and provide feedback, before the system is released to other customers. - Test (Alpha Test) Software Application. By Real customer. At development site. - Test (Beta Test) Software Product. By Model customer. At customer site.

f) Release Testing: - It is also known as Port Testing Release testing is a phase that determines if the software is suitable for the organisation of the end-user. How is compatibility with other systems ensured? The Project Management will establish Release Team with few Developers, few Testers and One (or) two Hardware Engineers. This selected team can go to customer site and install or launch the corresponding software and will concentrate on below factors. Complete installation Overall functionality i/p device handling ex: keyboard, mouse etc o/p device handling ex: monitor, printers etc

 Secondary storage device handling ex: external hard drive, pen drives etc Operating system support Co-existence with other existing software After completion of above observation the release team is providing required training sessions to the customers to understand about the project.

3) FISH MODEL: -