Social Icons

Showing posts with label Testing Stuff. Show all posts
Showing posts with label Testing Stuff. Show all posts

Monday, March 25, 2013

Life Cycle testing-Role of Testers,Test Plan,TestCase



Life Cycle testing-Role of Testers
Concept Phase:
Evaluate Concept Document,
Learn as much as possible about the product and project
Analyze Hardware/software Requirements,
Strategic Planning

Requirement Phase:
Analyze the Requirements
Verify the Requirements using the review methods.
Prepare Test Plan
Identify and develop requirement based test cases

Design Phase:
Analyze design specifications
Verify design specifications
Identify and develop Function based test cases
Begin performing Usability Tests

Coding Phase:
Analyze the code
Verify the code
Code Coverage
Unit test

Integration & Test Phase:
Integration Test
Function Test
System Test
Performance Test
Review user manuals

Operation/Maintenance Phase:
Monitor Acceptance Test
Develop new validation tests for confirming problems
Software TESTING

Test plan:
A test plan is a systematic approach to testing a system such as a machine or software.The plan typically contains a detailed understanding of what the eventual work flow will be (or)

The test plan defines the objectives and scope of the testing effort, and identifies themethodology that your team will use to conduct tests. It also identifies the hardware, software,and tools required for testing and the features and functions that will be tested. A well-roundedtest plan notes any risk factors that jeopardize testing and includes a testing schedule(or)

A test plan is a document describing the scope, approach, resources,andschedule of intended test activities. It identifies test items, the features to betested,the testing tasks, who will do each task, and any risks requiringcontingency plans. An important component of the test plan is the individualtest cases. Some form of test plan should be developed prior to any test.

TESTCASE:
A test case is a set of test inputs, execution conditions, and expected results to determine if a feature of an application is working correctly, such as to exercise a particular program path or to verify compliance with a specific requirement. Think diabolically! What are the worst things someone could try to do to your program? Write test for these.

Testing process:
The test development life cycle contains the following components/steps:
• System study-Assess development plan and status
• Collect SFS/SRS
• Develop Test plan
• Design test cases

Tests specifications: This document includes technical details ( Software requirements )required prior to the testing.
• Execute tests
• Evaluate tests
• Evaluate results
• Acceptance test
• Document results(defect reports, summary reports)
Recreating the problem is essentially important in testing so that problems that are identified can be repeated and corrected.

Testing strategy:
Test Strategy provides the road map describing the steps to be undertaken while testing, and the effort, time and resources required for the testing.
The test Strategy should incorporate test planning, test case design, test execution, resultant data collection and data analysis.

Monkey Testing:
Testing the application randomly like hitting keys irregularly and try to brake down the system there is no specific test cases and scenarios for monkey testing Verification refers to set of activities that involves reviews and meetings to evaluate documents, plans, code, requirements and specifications(to ensure that software correctly implements a specific function, imposed at the start
of that phase); this can be done with checklists, issues lists, and walkthroughs and inspection meetings.

For example, in the software for the Monopoly game, we can verify that two players cannot own the same house. Validation is the process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements. (or)

Validation refers to a different set of activities that the software that has been built is traceable to customer requirements
For example, we validate that when a player lands on “Free Parking,” they get all the money that was collected. validation always involves comparison against requirements.

In the language of V&V, black box testing is often used for validation (are we building the right software?) and white box testing is often used for verification (are we building the software right?).

Quality Assurance (QA) The system implemented by an organization which assures outside bodies that the data generated is of proven and known quality and meets the needs of the end user. This assurance relies heavily on documentation of processes, procedures, capabilities, and monitoring of such.
  • Helps establish processes
  • Identifies weaknesses in processes and improves them
  • QA is the responsibility of the entire team Quality Control (QC) Mechanism to ensure that the required quality characteristics exist in the finished product (or) It is a system of routine technical activities, to measure and control the quality of the product as it is being developed.Quality control activities may be fully automated, entirely manual, or a combination of automated tools and human interaction
  • implements the process.
  • Identifies defects for the primary purpose of correcting defects.
  • QC is the responsibility of the tester.
                                                          PREVIOUS
                                                 

Saturday, February 9, 2013

Software Life Cycle Models


Software Life Cycle Models:

Iterative model - This model iterates requirements, design,, build and test phases again and again for each requirement and builds up a system iteratively till the system is completely build.
Incremental model - It is non integrated development model. This model divides work in chunks and one team can work on many chunks. It is more flexible.
Spiral model - This model uses series of prototypes in stages, the development ends when  the prototypes are developed into functional system. It is flexible model and used for large and complicated projects.
Evolutionary model - It is more customer focused model. In this model the software is divided in small units which is delivered earlier to the customers.
V-Model - It is more focused on testing. For every phase some testing activity are done. the following are the list of activity performed side by side.

Iterative model :
In the first step of iterative enhancement model, a simple initial implementation is done for a subset of the overall problem. This subset is the one that contains some of the key aspects of the problem which are easy to understand and implement, and which forms a useful and usable system. 

A project control list is created which contains, in an order, all the tasks that must be performed to obtain the final implementation. This project control list gives an idea of how far the project is at any given step from the final system.

Each step consists of removing the next step from the list. Designing the implementation for the selected task, coding and testing the implementation, and performing an analysis of the partial system obtained after this step and updating the list as a result of the analysis.

These three phases are called the design phase, implementation phase and analysis phase. The process is iterated until the project control list is empty, at the time the final implementation of the system will be available. The process involved in iterative enhancement model is shown in the figure below.



                        

The Iterative Enhancement Model
The project control list guides the iteration steps and keeps track of all tasks that must be done. The tasks in the list can be include redesign of defective components found during analysis. Each entry in that list is a task that should be performed in one step of the iterative enhancement process, and should be simple enough to be completely understood. Selecting tasks in this manner will minimize the chances of errors and reduce the redesign work.
Explain the Iterative Model?
The iterative model approach is to iterate on steps as the project progresses with requirements. Iterative model iterates Requirements, Design, Build and test phases again and again for each requirement and builds up a system iteratively till the complete system is built. The advantage is that iterative model can accommodate changes in requirements which are very common in most of the projects. It also provides an opportunity to identify and build upon any major requirement or design flaws throughout the process because of its iterative nature.

Incremental model:

Incremental model  combines elements of the waterfall model applied in an iterative fashion.
Each linear sequence produces deliverable “increments” of the software.(Ex: a Notepad delivers basic file management, editing, in the first increment More refined editing, format and printing in the second increment Find and Replace in the third increment.)

With an increment model, the first increment is often a core product.  The core product is used by the customer and after the feedback from the customer, a plan is developed for the next increment. The plan deals with the modification of the core product to better meet the needs of the customer and the delivery of additional features and functionality.
The process is repeated until the complete product is produced.

When to use Incremental model?
If it is too risky to develop the whole system at once, then the incremental development should be considered.

Advantages of Incremental model:
As product is to be delivered in parts, total cost of project is distributed.
Limited number of persons can be put on project because work is to be delivered in parts.
As development activities for next release and use of early version of product is done simultaneously, if found errors can be corrected. Customers or end users get the chance to see the useful functionality early in the software development life cycle.

Disadvantages of Incremental model:
As product is delivered in parts, total development cost is higher.
Well defined interfaces are required to connect modules developed with each phase.
The model requires well defined project planning schedule to distribute the work


"V" Model is one of the SDLC Methodologies:

In this methodology Development and Testing takes place at the same time with the same kind of information in their hands.
Typical "V" shows Development Phases on the Left hand side and Testing Phases on the Right hand side.
Development Team follow "Do-Procedure" to achive the goals of the company
and
Testing Team follow "check-Procedure" to verify them.
SRS                                                                            User Acceptance
         Design                                                      System Testing
                     HLD                                       Integration Testing
    SDLC                   LLD                    Unit Testing       STLC
                                         Coding

  • Verification process is called as Do procss and validasation phase is check procedure.
  • Development starts with information gathering. After the requirements gathering  BRS/CRS/URS will be prepared. This is done by the Business Analyst.
  • During the requirements analysis all the requirements are analyzed. at the end of this phase S/wRS is prepared. It consists of the functional (customer requirements) + System Requirements (h/w + S/w) requirements. It is prepared by the system analyst.
  • During the design phase two types of designs are done. HLDD and LLDD. Tech Leads will be involved.
  • During the coding phase programs are developed by programmers.
  • During unit testing, they conduct program level testing with the help of WBT techniques.
  • During the Integration Testing, the testers and programmers or test programmers integrating the modules to test with respect to HLDD.
  • During the system and functional testing the actual testers are involved and conducts tests based on S/wRS.
  • During the UAT customer site people are also involved, and they perform tests based on the BRS.
  • From the above model the small scale and medium scale organizations are also conducts life cycle testing. But they maintain separate team for functional and system testing.


The Spiral Model:
The process begins at the center position. From there it moves clockwise in traversals. Each traversal of the spiral usually results in a deliverable. It is not clearly defined what this deliverable is. This changes from traversal to traversal. For example, the first traversals may result in a requirement specification. The second will result in a prototype, and the next one will result in another prototype or sample of a product, until the last traversal leads to a product which is suitable to be sold. Consequently the related activities and their documentation will also mature towards the outer traversals. E.g. a formal design and testing session would be placed into the last traversal.






There are different instances of this model so far I saw it with 3 to 6 task regions. The above picture shows 4 task regions.
These regions are:
•   The planning task - to define resources, responsibilities, milestones and schedules.
•   The goal determination task - to define the requirements and constraints for the product and define possible alternatives.
•   The risk analysis task - to assess both technical and management risks.
•   The engineering task - to design and implement one or more prototypes or samples of the application.

The most outstanding distinction between the spiral model and other software models is the explicit risk evaluation task. Although risk management is part of the other processes as well, it does not have an own representation in the process model. For other models the risk assessment is a sub-task e.g. of the overall planning and management. Further there are no fixed phases for requirements specification, design or testing in the spiral model. Prototyping may be used to find and define requirements. This may then be followed by "normal" phases as they can be found in other process models to handle design and testing.

The advantages of the spiral model are that it reflects the development approach in many industries much better than the other process models do. It uses a stepwise approach which e.g. goes hand in hand with the habit of maintaining a number of hardware sample phases in cases where the product to be produced is not only software for a given environment, but also contains the development of hardware. This way the developers and the customer can understand and react much better to risks in the evolutionary process. By having an iterative process which reduces formalisms and omittable activities in the earlier phases the use of resources is optimized. Further, any risks should be detected much earlier than in other process models and measures can be taken to handle them.

The disadvantages of the spiral model are that the risk assessment is rigidliy anchored in the process. First of all it demands risk-assessment expertise to perform this task and secondly in some cases the risk assessment may not be necessary in this detail. For completely new products the risk assessment makes sense. But I dare to say that the risks for programming yet another book keeping package are well known and do not need a big assessment phase. Also if you think of the multitude of carry over projects in many industries i.e. applying an already developed product to the needs of a new customer by small changes, the risks are not a subject generating big headaches. Generally speaking the spiral model is not much esteemed and not much used, although it has many advantaged and could have even more if the risk assessment phases would be tailored down to the necessary amount.

Prototype model:

1>Based on the initial requirements a prototype is developed.
2>Prototype is demonstrated to the client and based on the prototype more requirements are gathered from the clients.
3>After getting clear requirements based on those requirements software is developed.

The goal of prototyping based development is to counter the first two limitations of the waterfall model discussed earlier. The basic idea here is that instead of freezing the requirements before a design or coding can proceed, a throwaway prototype is built to understand the requirements. This prototype is developed based on the currently known requirements. Development of the prototype obviously undergoes design, coding and testing. But each of these phases is not done very formally or thoroughly. By using this prototype, the client can get an "actual feel" of the system, since the interactions with prototype can enable the client to better understand the requirements of the desired system.

Prototyping is an attractive idea for complicated and large systems for which there is no manual process or existing system to help determining the requirements. In such situations letting the client "plan" with the prototype provides invaluable and intangible inputs which helps in determining the requirements for the system. It is also an effective method to demonstrate the feasibility of a certain approach. This might be needed for novel systems where it is not clear that constraints can be met or that algorithms can be developed to implement the requirements. The process model of the prototyping approach is shown in the figure below.






Prototyping Model
The basic reason for little common use of prototyping is the cost involved in this built-it-twice approach. However, some argue that prototyping need not be very costly and can actually reduce the overall development cost. The prototype are usually not complete systems and many of the details are not built in the prototype. The goal is to provide a system with overall functionality. In addition, the cost of testing and writing detailed documents are reduced. These factors helps to reduce the cost of developing the prototype. On the other hand, the experience of developing the prototype will very useful for developers when developing the final system. This experience helps to reduce the cost of development of the final system and results in a more reliable and better designed system.

Advantages of Prototyping:

1. Users are actively involved in the development
2. It provides a better system to users, as users have natural tendency to change their mind in specifying requirements and this method of developing systems supports this user tendency.
3. Since in this methodology a working model of the system is provided, the users get a better understanding of the system being developed.
4. Errors can be detected much earlier as the system is mode side by side.
5. Quicker user feedback is available leading to better solutions.

Disadvantages:
1.Leads to implementing and then repairing way of building systems.
2.Practically, this methodology may increase the complexity of the system as scope of the system may expand beyond original plans.


                                          PREVIOUS                       NEXT

Tuesday, January 29, 2013

Manual Testing Introduction and its Overview


What is Manual Testing ?
Testing is process execution of application in controlled manner with the intent of finding the errors. It is nothing but “Detection”.
The Quality Assurance involves through out the software development process to monitor and improve the process, making sure that agreed upon standards and procedures are followed and ensuring that problems are found and dealt with it.

It is oriented for “Prevention”.Solving problems is a high-visibility process; preventing problems is low-visibility.This is illustrated by an old parable.

Software Testing Def:
Testing is a process used to help identify the correctness, completeness and qualityof developed computer software. With that in mind, testing can never completely establish the correctness of computer software.

Software Industry:
In India itself, Software industry growth has been phenomenal.
IT field has enormously grown in the past 50 years.
IT industry in India is expected to touch 10,000 crores of which software share is dramatically increasing.

Software Crisis:
Software cost/schedules are grossly inaccurate.
Cost overruns of several times, schedule slippage’s by months, or even years are common.

Productivity of people has not kept pace with demand
Added to it is the shortage of skilled people.

Quality of software is than desired
Error rates of released software leave customer dissatisfied…Threatening the very business.

Purpose of Testing:
1. The main course of testing is to check for the existence of defects or errors in a program  or project or product, based up on some  predefined instructions or conditions.
2. The Purpose of Testing is to Analyze that the Product is according to Requirements.
3. To improve the quality of the product.
4. To satisfy the customers need.
5. To provide a Bug free software.

What is Software Quality:
Quality software is reasonably bug-free, delivered on time and within budget, meets requirements and/or expectations, and is maintainable.However, quality is a subjective term. It will depend on who the ‘customer’ is and their overall influence in the scheme of things.

A wide-angle view of the ‘customers’ of a software development project might include end-users, customer acceptance testers, customer contract officers, customer management, the development organisation’s management/accountants/testers/salespeople, future software maintenance engineers, stockholders, magazine reviewers, etc. 

Each type of ‘customer’ will have their own view on ‘quality’ - the accounting department might define quality in terms of profits while an end-user might define quality as user-friendly and bug-free. 

Quality Assurance:
“Quality Assurance” measures the quality of processes used to create a quality product.
Software Quality Assurance (‘SQA’ or ‘QA’) is the process of monitoring and improving all activities associated with software development, from requirements gathering, design and reviews to coding, testing and implementation.

It involves the entire software development process - monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with, at the earliest possible stage. 

Unlike testing, which is mainly a ‘detection’ process, QA is ‘preventative’ in that it aims to ensure quality in the methods & processes – and therefore reduce the prevalence of errors in the software.

What’s the difference between QA and testing?
TESTING means “Quality Control”; and
QUALITY CONTROL measures the quality of a product; while
QUALITY ASSURANCE measures the quality of processes used to create a quality product.

Difference between static and dynamic testing?
  • Static testing is about prevention dynamic testing is about cure.
  • The static tools offer greater marginal benefits.
  • Static testing is many times more cost-effective than dynamic testing.
  • Static testing beats dynamic testing by a wide margin.
  • Static testing is more effective!
  • Static testing gives you comprehensive diagnostics for your code.
  • Static testing achieves 100 statement coverage in a relatively short time while dynamic testing often often achieves less than 50 statement coverage because dynamic testing finds bugs only in parts of the code that are actually executed.
  • Dynamic testing usually takes longer than static testing. Dynamic testing may involve running several test cases each of which may take longer than compilation.
  • Dynamic testing finds fewer bugs than static testing.
  • Static testing can be done before compilation while dynamic testing can take place only after compilation and linking.
  • Static testing can find all of the followings that dynamic testing cannot find: syntax errors code that is hard to maintain code that is hard to test code that does not conform to coding standards and ANSI violations.
  • Ya Dynamic testing invoves functional testing also.

Software Engineering Process
  • Consists of Three generic Phases:

Definition, Development, and Maintenance.
1. Definition (What)
Customer Contact, Planning, Requirement Analysis.
2. Development Phase (How)
Design, Coding, Testing.
3. Maintenance Phase (Change)
Correction, Adaptation, Enhancement, Reengineering.
4. Support Activities
Quality Assurance, Configuration Management.

                                                        NEXT

Monday, January 28, 2013

Types of Testing For an Application


MANUAL TESTING TYPES

Quality:  It is defined as the conformance to the customer specification.

Testing:  A Tester should suppose to identify the defects.

White box testing: Based on knowledge of the internal logic of an application’s code. Tests are based on coverage of code statements, branches, paths, conditions.

Test case:  Test case is a description of what to be tested, what data to be given and what actions to be done to check the actual result against the expected result.

Black box testing:  Not based on any knowledge of internal design or code. Tests are based on requirements and functionality.

Functionality testing:  Testing whether the functionality of the application is working or not and whether all the requirements have covered are not.

System testing:  The entire application tested according to the requirements.

Sanity testing:  Initial testing conducted on the application to check the proper behavior on the application.

Smoke testing:  Initial testing is conducted on over all application to check whether all the functionalities available to conduct detail testing on them.

Regression testing:  Retesting the bug after fixing or any modifications or enhancement done to the application and testing whether the existing functionalities are effecting to the privies functionalities or not.

Integration testing:  All the modules are integrated together and testing how modules are couple together and communication between the modules.
Usability testing: - Checking whether it is user friendliness or not.
i.              To check for the look and feel of application.
ii.             Where the end user can understand and can easily use the application.

User acceptance testing:  After all the bugs are fixed we have to test once again to make shore that the application meets the user requirements.

Severity:  how much the bug is effecting the application.

Priority:  When the bug is to be fixed.

Unit testing:  After completion of their reviews, programmer concentration on coding, to physically construct a soft ware. In this level, their will test every program through white box testing.

Recovery testing:  It is also known as reliability testing during this test, testing engineers validates that whether our application build change from abnormal state to normal state or not.

Compatibility testing:  It is also known as portability testing. During this test, testing engineer validates that whether our application build run on customer expectation platform or not.

Configuration testing: It is also known as hardware compatibility testing. During this test testing engineer validates that whether our application support different technology hardware devises or not.

                                                PREVIOUS                      NEXT