Archive for category Software Testing Levels

User Acceptance Testing (UAT)

User Acceptance Testing (UAT) is the formal testing conducted to determine whether a software system satisfies its acceptance criteria and to enable buyer to determine whether to accept the system or not, Acceptance testing is designed to determine whether software is fit for use or not. Apart from functionality of application, other factors related to business environment also plays an important role

User acceptance testing is different from System Testing. System testing is invariably performed by the development team which includes developer and tester. User acceptance testing on the other hand should be carried out by the end user. This could be in the form of

  • Alpha Testing - In Alpha Testing, the users are invited at the development center where they use the application and the developers note every particular input or action carried out by the user. Any type of abnormal behavior of the system is noted and rectified by the developers
  • Beta Testing - In Beta Testing, the software is distributed as a beta version to the users and users test the application at their sites. As the users explore the software, in case if any exception/defect occurs that is reported to the developers. Beta testing comes after alpha testing. Versions of the software, known as beta versions, are released to a limited audience outside of the company. The software is released to groups of people so that further testing can ensure the product has few faults or bugs. Sometimes, beta versions are made available to the open public to increase the feedback field to a maximal number of future users

In both the cases, these testing might be assisted by software testers.

It is very important to define acceptance criteria with the buyer during the various phases of SDLC. A well defined acceptance plan will help development/QE teams by identifying user’s need during software development. Acceptance Test plan must be created or reviewed by customer. Development team and customer should work together and make sure that they have

  • Identify interim and final products for acceptance, acceptance criteria and schedule.
  • Plan how and by whom each acceptance activities will be performed.
  • Schedule adequate time for buyer’s staff to examine and review the product
  • Prepare the acceptance plan.
  • Perform formal acceptance testing at delivery
  • Make a decision based on the results of acceptance testing.

Entry Criteria

  • System Testing is completed and defects identified are either fixed or documented.
  • Acceptance plan is prepared and resources have been identified.
  • Test environment for the acceptance testing is available

Exit Criteria

  • Acceptance decision is made for the software
  • In case of any caveats, development team is notified

Tags: ,

Unit Testing

I have heard some people saying that Unit Testing is done primarily by the developers and test engineers need not know about Unit testing. But this is not the case, Unit testing is as important for test engineers as it is for developers

Probably developers will write the unit test cases but your understanding of the framework and unit testing can certainly help him/her in designing the flow for unit test cases, generating test data and making good reports. All these activities will ultimately help you in the long run as product quality will increase significantly because of the efforts you put in on the unit testing

So if you think as a test engineer, you should also learn/know about unit testing

Unit testing is the method of making sure that smallest unit of your software is working properly in isolation. You can define this smallest unit in your own term; it could be a java class or library. A more formal definition and Kent Beck wrote JUnit framework along with Erich Gamma and it became extremely useful for the Java community. JUnit made it very easy for the developers to write, organize and execute unit test cases for there java code. Success of JUnit was enough to inspire people working on other languages to come up with unit testing framework for the language of their choice. Now we probably have more than 25 Unit testing frameworks based on the XUnit architecture covering all the major languages

Tags:

Integration Testing

Objective of Integration Testing is to make sure that the interaction of two or more components produces results that satisfy functional requirement. In integration testing, test cases are developed with the express purpose of exercising the interface between the components.

Integration testing can also be treated as testing assumption of fellow programmer. During the coding phase, lots of assumptions are made. Assumptions can be made for how you will receive data from different components and how you have to pass data to different components. During Unit Testing, these assumptions are not tested. Purpose of unit testing is also to make sure that these assumptions are valid. There could be many reasons for integration to go wrong, it could be because

• Interface Misuse – A calling component calls another component and makes an error in its use of interface, probably by calling/passing parameters in the wrong sequence.

• Interface Misunderstanding – A calling component makes some assumption about the other components behavior which are incorrect.

Integration Testing can be performed in three different ways based on ‘from where you start’ testing and in which direction you are progressing.

• Big Bang Integration Testing

• Top Down Integration Testing

• Bottom Up Integration Testing

• Hybrid Integration testing

Top down testing can proceed in a depth-first or a breadth-first manner. For depth-first integration each module is tested in increasing detail, replacing more and more levels of detail with actual code rather than stubs. Alternatively breadth-first would proceed by refining all the modules at the same level of control throughout the application. In practice a combination of the two techniques would be used.

Entry Criteria

Main entry criteria for Integration testing are the completion of Unit Testing. If individual units are not tested properly for their functionality, then Integration testing should not be started.

Exit Criteria

Integration testing is complete when you make sure that all the interfaces where components interact with each other are covered. It is important to cover negative cases as well because components might make assumption with respect to the data.

Tags:

Software Testing Levels

Have you ever thought why do you need to categorize software testing into different types? What are the benefits of dividing software testing in different types? One of the main purposes of software testing is to identify defects in the software. Defects in software testing can be defined as variance from requirement or user expectation. Based on this simple definition, it is very easy to categorize defects. For example:  If system is not functioning properly, its a functional defect, If system is not performing well, its a performance defect, If system is not usable, its a usability defect, If system is not secure, its a security defect

Identify these different defects require different skill set, different techniques and different type of test cases. Testing is divided into different types to reflect, what kind of defects can be uncovered by those activities. This division also helps management in managing these activities effectively. Also, it is very rare to have someone with skills in all the types of testing and this division helps in getting proper resources for team.

Hope you understand importance of this categorization and also how important it is to have understanding of different types. This understanding will enable you to spot more defects which in turn will improve quality and make you more effective software tester.

There are many ways in which software testing can be categorized. Some of them are described as follows:

Categorization of testing based on the knowledge of system

• Black Box Testing

• White Box Testing

• Gray Box Testing

Levels of Testing is Categorization of testing based on the time it is executed in the Software Development Life Cycle

• Unit Testing

• Integration Testing

• System Testing

• User Acceptance Testing

Different types of testing can be categorized based on the purpose of testing. This can be classified further into Functional Testing and Non Functional Testing.

• Functional Testing

In functional testing, the focus of testing activities is on functional aspects of the system. In functional testing, test cases are written to check the expected output. Functional testing is normally performed in all the test phases from unit to system testing.

The following types of test activities are normally performed under Functional Testing

o Installation Testing

o Regression Testing

o Upgrade and backward compatibility testing

o Accessibility testing

o Internationalization and localization testing

o API Testing

• Non-Functional Testing

In non-functional testing, the focus of the testing activities is on non functional aspects of the system. Non functional testing is normally carried out during the System Testing phase only. The focus of non functional testing is on the behavior and user experience of the system.

o Performance, Load and Stress Testing

o Usability Testing

o Security testing

Testing can also be categorized based on how it is executed. Execution  could be in the form of verification or static analysis or it could be validation or dynamic analysis. Verification and validation can be categorized further according to how it is done.

• Verification

In very simple terms, verification is the human examination or review of the work product. There are many forms of verification which ranges from informal verification to formal verification. Verification can be used for various phases in SDLC and can be in the form of formal inspection, walkthrough or buddy-checking.

Validation

Validation or dynamic analysis is the most frequent activity that as a tester you perform. Whether you are doing black box testing, non functional testing or any type of testing, chances are that you are performing validation or dynamic analyses. Validation or dynamic analyses is associated with the execution, and could be related to the execution of test cases or testing in general. There are many ways in which testing can be executed, for example

o Manual Scripted Testing

o Exploratory Testing

o Automated Testing

o Model Based Testing

Tags: , ,

System Testing

System Testing is probably the most important phase of complete testing cycle. This phase is started after the completion of other phases like Unit, Component and Integration testing. During the System Testing phase, non functional testing also comes in to picture and performance, load, stress, scalability all these types of testing are performed in this phase.

By Definition, System Testing is conducted on the complete integrated system and on a replicated production environment. System Testing also evaluates that system compliance with specific functional and non functional requirements both.

It is very important to understand that not many test cases are written for the system testing. Test cases for the system testing are derived from the architecture/design of the system, from input of the end user and by user stories. It does not make sense to exercise extensive testing in the System Testing phase, as most of the functional defects should have been caught and corrected during earlier testing phase.

Utmost care is exercised for the defects uncovered during System Testing phase and proper impact analysis should be done before fixing the defect. Some times, if business permits defects are just documented and mentioned as the known limitation instead of fixing it.

Progress of the System Testing also instills and build confidence in the product teams as this is the first phase in which product is tested with production environment.

System testing phase also prepares team for more user centric testing i.e. User Acceptance Testing.

Entry Criteria

  • Unit, component and Integration test are complete
  • Defects identified during these test phases are resolved and closed by QE team
  • Teams have sufficient tools and resources to mimic the production environment
  • Teams have sufficient tools and resources to mimic the production environment

Exit Criteria

  • Test cases execution reports shows that functional and non functional requirements are met.
  • Defects found during the System Testing are either fixed after doing thorough impact analysis or are documented as known limitations.

Tags: ,