You are on page 1of 49

Learn SCRUM Framework

In todays date SCRUM is considered as practical & more valued Agile methodology. It is easy to use & deliver incrementally high quality software on time & budget. In this article we will quickly take a look at what all steps involved in SCRUM framework like What is Product Vision, Product Backlog, Sprint Backlog, Daily SCRUM, A Sprint Burndown and Sprint Retrospective meeting etc.

Project Vision:
The goal of the project vision is to align the team around a central purpose. It is very important for the Agile SCRUM team to know what they are aiming for. Based on vision Product Owner creates ordered prioritized wish list. Requirements are broken down into User Stories by the Product Owner.

Product Backlog:
The Product Backlog is a ordered & prioritized list of item that all need to include in the product. It is dynamic & during the project items may added or deleted from this list. All items are ordered prioritized in this list. The highest priority items are completed first.

SCRUM Framework

Sprint Backlog:
In the Sprint planning meeting the team picks list of User stories from Product Backlog. These selected items moved from Product backlog to Sprint backlog. All sprint backlog user stories

are discussed items from the product backlog and team member committed to complete the assigned task within Sprint Timeboxed. Each user story is divided into smaller detailed tasks. In Sprint team work together collaboratively to complete Sprint tasks.

Daily SCRUM:
The Daily SCRUM is not used as a problem-solving or issue resolution meeting. In the Daily SCRUM each of the team members should answer three questions:

What did you do yesterday? What will you do today? Are there any obstacles in your way?

In the Daily SCRUM team share the conflicts, obstacle or impediment faced in their tasks & any possible solutions on that. On daily basis this meeting holds on same time, same location hold by Agile SCRUM team. Ideally The Daily SCRUM is conducted in the morning which helps to plan task for whole day. As Agile process & Sprint is time-boxed, similarly Daily SCRUM meeting should be time-boxed to 15 minutes max. In this meeting discussion should be quick and relevant. The SCRUMMaster always helps to maintain the focus of team to its Sprint goal.

A Sprint Burndown:
Sprint Burndown measures remaining Sprint Backlog items across the time of a Sprint. It is very effective visual indicator to get correlation between work remaining at any point of time & the actual progress of team. Prior to Daily SCRUM meeting, Sprint Burndown chart should be updated, so it will help to understand the progress of Sprint daily & makes any adjustments if needed.

Shippable Product:
The end of the Sprint can turn into an increment of potentially shippable functionality hand over to customer. This shippable functionality should be well-structured, well-written code, thoroughly tested and user operation of the functionality is documented. At the end of the Sprint features committed in Sprint are demonstrated to all stakeholders & they provide the valuable feedback to moving product in correct direction.

Sprint Retrospective:
At the end of each Sprint review and Retrospective meeting should be conducted to know what went good & bad in Sprint. Participants for this meeting is Team, SCRUMMaster & Product Owner(Listner). This meeting also timeboxed to 2-3 hours. Using this approach each team member is asked to identify specific things that the team should:

Start doing Stop doing Continue doing

Iterations are a key feature of the SCRUM process. In the next Sprint again team choose the chunk of User stories from the Product backlog & Sprint cycle started with new Sprint goals again. These cycles are continue doing unless and until Product backlog is finished or Deadline reaches or budget is used up. Agile SCRUM is ensure that all high priority task ordered top in the Product backlog so those can get completed first before the project ends.

Agile SCRUM
In few days back I have outlined points Agile values & its key principles in Agile Manifesto and Principles article. Today well talk about commonly used process for agile software development i.e. Scrum. Before start post let me tell you one thing that I always like to share practical knowledge, which can be useful to users in their career life.

What is Scrum?
Scrum is an innovative approach to getting work done in efficient way. It is iterative & incremental agile software development method. These iterations are time boxed with various iterations & each iteration is called Sprint. The Sprint is basically 2-4 week long & each sprint requires sprint planning estimation. According to latest surveys Scrum is the most popular agile project management methodology in software development. The term Scrum is formed from Rugby. Scrum is ideally used where highly emergent or rapidly changing requirements. Scrum is basically worked on a self-organizing, cross-functional team. In the overall scrum team there is no team leader who assign the task to team rather whole scrum members work as a team & they decides the task on which they will work on. Also the problem will be resolve by team. Each Agile Development Scrum team having three core scrum roles: Product Owner, Scrum Master & The Team. 1) Product Owner: The Product Owner is the person who represents the stakeholders and is the voice of the customer. Product owner writes the User Stories, ordered priorities and add in the Product Backlog. It is recommended that Agile Scrum Master should not mix with Product Owner; both members should be different as each member having its own responsibilities. 2) Scrum Master: The ScrumMaster is a facilitative team leader who ensures that the team adheres to its chosen process and removes blocking issues to deliver the sprint deliverable/goal. Scrum Master is not a team leader but act as a shield for the team from external interferences & also removes barriers. ScrumMaster facilitates the daily scrums. 3) The Team: The scrum development team is generally size of 5-9 peoples with self-organizing and cross-functional skills who do actual work like Analysis, Design, Development, Testing, Documentation etc.

In the start of every Scrum Sprint, the team members are committed to delivering few tasks from Scrum Product backlog. Over the sprint timeboxed the team work on developing, testing, integrating feature & end of the Sprint in the Sprint Review Meeting these functionality demoed to Product Owner & interested Stakeholders. In this meeting they can give feedback if any on developed product which could influence the next sprint. The main artifact in the Agile Scrum project is the product itself. The team is working efficiently on product to deliver shippable product after end of every sprint. The Product Backlog is place where all requirements are ordered and written in the user story format. These user stories are ordered & prioritized by Product Owner based on risk, business value, date needed, dependencies etc so that most valuable features picked in Sprint first. In the market lots of paid and Free scrum software available, iceScrum is one of the free platform for your agile developments, where the best of both Kanban and Scrum are proposed in iceScrum.

Key to Successful BVT How to run the Build Verification Test?


What is BVT (Build Verification Test)?

Build Verification Test is a set of pre-defined test cases run on every build to make sure that build is testable for further testing. BVT test is carried out before build pass to testing team for further testing. This test contains pre-defined Test Cases which focus on the core functionality of software application to make sure that build is stable & ok to start with actual testing. This test is done to check the Build validation & Build Acceptance. So sometimes BVT is called as Build Acceptance Test (BAT) or Smoke testing.
Why BVT to be carried out after every build?

Many of the testers are thinking of why build verification testing should be carried out once new build is received, so answer is simple To check the Stability of the build. If new build received & you are testing functionality but after spending some time you got a blocker issue which blocking all other functionality, this means test team spend time to test application but due to blocking issue test team have to carried out same operation again. So to avoid wasting valuable time of test team we can use automated Build Acceptance Test. BAT is very important to check whether due earlier fixes by developer is not causing any major problems in the build. So here all team members know right away if any serious problem in build or not, this will reduce the tester time wastage & frustration. Most of the errors are introduce in the integration of modules. Mainly BAT is to check for the project integrity and checks whether all the modules are integrated properly or not. Usually, this process is automated & if it fails then it should assign to appropriate developer to fix & parallel bug should be added. It means upon failing the BVT test build should be rejected & testing

should be carried out on previous build. So this is carried out after every new build is received to check any regression is introduced in the build or not.
Keys points to be considered while preparing build verification testing checklist:

Build Verification Testing The success of BVT test is totally depends on what all test cases included in BVT. After selecting effective build test verification test cases, it should be automated. So lets figure out what all points to be consider while selecting test cases:

Build Verification Testing should include test cases which focus on the core functionality of software application & should having more test coverage. It should not take more time to execute the test. Ideally it should be 30 to 60 minutes based on the criticality & how vast project is. It is executed on every new build & if it is fails then build should be rejected. Build verification test cases & process should not implemented in hurry. Include only stable test cases, which have known expected results and dont add unstable test cases. Timely Build Verification tests suite should be updated based on the functional changes in the application. Purpose of this test is to save the time of test team if the main core features are not working or contains defects. Most of the defects are observed in the integration of the modules which are developed by different persons, so selection of test cases is very important. This area also consider while selecting BVT test case. Try to log everything which helps to find out test Passed/Failed result.

What is process to run the build verification tests?


Build verification test case should be executed once new build is received. If BVT passes then Build should be ACCEPTED & start actual testing activities. If BVT fails then Build should be REJECTED.

Results should be send to Team Lead or Project Manager. Results should be analyzed by Team Lead or Project Manager. Find out the root cause of the problem (if any). If there is defect then relevant information should be send to respective developers to fix the problem. Bug should address to Developer & fix it as early as possible. Upon fixing defect, Build verification test case should be executed once new build is received (This is continuous process if build is failed again).

Build verification testing is failed is due to developer is not always true. There are many several reasons which cause failing BAT test case like:

If the test case automated & used some coding which may introduce any coding errors. Use of Automation Tool to execute automated BAT test suite but if defects in the Automation Tool may introduce errors which cause failing of BAT test suite. Infrastructure error may cause issues in the BAT test suite execution. Failure of Hardware or software which may cause issues in the BAT test suite execution.

Key point to success of BVT:


BVT test cases should not be written in hurry, Spend significant amount of time for writing BVT test cases scripts. Only stable test cases should be included to BVT, this will reduce the probability of failing BVT due to unstable area of software. BVT process should be automated, try to automate as much as you can. Add log details as much as you can so it helps to analyze the BVT pass or fails result. This log will further helps for developer to fix the defect.

What is Black Box Testing?


Firstly we will learn what is Black Box Testing? Here we will discuss about how black box testing is perform, different BBT Techniques used in testing.

Black Box Testing Method:


Black box testing is the Software testing method which is used to test the software without knowing the internal structure of code or program. Most likely this testing method is what most of tester actual perform and used the majority in the practical life. Basically software under test is called as Black-Box, we are treating this as black box & without checking internal structure of software we test the software. All testing is done as customers point of view and tester is only aware of what is software is suppose to do but how

these requests are processing by software is not aware. While testing tester is knows about the input and expected outputs of the software and they do not aware of how the software or application actually processing the input requests & giving the outputs. Tester only passes valid as well as invalid inputs & determines the correct expected outputs. All the test cases to test using such method are calculated based on requirements & specifications document. The main purpose of the Black Box is to check whether the software is working as per expected in requirement document & whether it is meeting the user expectations or not. There are different types of testing used in industry. Each testing type is having its own advantages & disadvantages. So fewer bugs cannot be find using the black box testing or white box testing. Types of Black Box Testing Techniques: Following black box testing techniques are used for testing the software application.

Boundary Value Analysis (BVA) Equivalence Class Partitioning Decision Table based testing Cause-Effect Graphing Technique Error Guessing

1) Boundary Value Analysis (BVA): Boundary Value Analysis is the most commonly used test case design method for black box testing. As all we know the most of errors occurs at boundary of the input values. This is one of the techniques used to find the error in the boundaries of input values rather than the center of the input value range. Boundary Value Analysis is the next step of the Equivalence class in which all test cases are design at the boundary of the Equivalence class. Let us take an example to explain this: Suppose we have software application which accepts the input value text box ranging from 1 to 1000, in this case we have invalid and valid inputs:
Invalid Input 0 less Valid Input 1 1000 Invalid Input 1001 above

Here are the Test cases for input box accepting numbers using Boundary value analysis: Min value 1 0

Min Value Min value + 1 Normal Value Max value 1 Max value Max value +1

1 2 1 1000 999 1000 1001

This is testing techniques is not applicable only if input value range is not fixed i.e. the boundary of input is not fixed. 2) Equivalence Class Partitioning The equivalence class partition is the black box test case design technique used for writing test cases. This approach is use to reduce huge set of possible inputs to small but equally effective inputs. This is done by dividing inputs into the classes and gets one value from each class. Such method is used when exhaustive testing is most wanted & to avoid the redundancy of inputs. In the equivalence partitioning input are divided based on the input values:

If input value is Range, then we one valid equivalence class & two invalid equivalence classes. If input value is specific set, then we one valid equivalence class & one invalid equivalence classes. If input value is number, then we one valid equivalence class & two invalid equivalence classes. If input value is Boolean, then we one valid equivalence class & one invalid equivalence classes.

Top 10 Common Problems in Bug Tracking and Solutions


Tracking of Bug is the most important part in Software development life cycle. In recent article we have seen about What should be done after a bug is found?. But common few problems may possibly lead towards the improper Bug Tracking. Let discuss what top 10 common problems faced by the team members while keeping the transparency in the reported bug: 1) Improper bug logging process: Basic rule in bug reporting is bug should properly described & it should be self explainable. In the Bug all required fields should be provided which help to communicate bug to developers. If the bug is not properly reported means missing of few required fields like Incorrect Defect Title, Missing Expected Result, Error from log file or Steps to reproduce etc. which increase the defect life cycle process.

Top 10 common problems in bug tracking 2) Use of different bug tracking template: If all team member are using different Issue Tracking template to report the issues which may lead to discrepancy at a later stages. Due to this reason standard bug tracking or logging template should be used, which could help a lot in the report generation. 3) Improper Defect Triage Process: Bug Triage process to allow you to discuss about all open defects & take actions on them. The participants of this meeting are developers, managers & testers. They gather together in one place (Physically or virtually) to analyze all defects and taking decisions on action items. All issues reported by tester must have common understanding over all peoples. Without this meeting it is very difficult to understand the reason for blocking test execution. 4) Bug Tracking Tools: Currently in the market many more open source Test/Defect management tools available. Some of the project affords to buy Commercial Issue Tracking Softwares. The defect management process may vary from tool to tool. Even if freeware or open source tool if the process is not well defined or tester is not aware of the process of tool then they have to face many challenges to handle defects. 5) Improper set up of Severity & Priority: Defect Priority signifies how important & urgently it is to fix this defect. In other words Priority means how fast it has to be fixed and Defect Severity means the degree of impact that a defect has on the development or operation of a component or system. The defect severity & priority may vary from defect to defect; also the fixing time of defect will be not same all the time. The fixing of the defect is totally based on the

priority of the defect. Usually testing and development teams are not well educated on severity and priority of the defect which could affect the bug tracking in defect life cycle. 6) SPOC (Single Point of Contact): Many of the times a keen Single Point of Contact not present in team to talk about defects to the stakeholders. 7) No Control on Test Environment: Sometimes testers dont have control on test environment & they are not aware of what all is deployed in the current deployed build & what not. Also development team make informal changes in the test environment which fixes or added new issues in the test environment which testers not aware of. Not full control on test environment causes a retesting & regression testing which affects quality level of software application. 8) If team is using their own medium to convey the defects to developers like Email or Phone which cause bad impact on Bug tracking and this is totally a bad practice. Tester should report all defects via defect tracking tools which help to understand the stability of the software application & these statistics will help a lot for managing upcoming releases. 9) If maintaining of defects statuses is not proper then it could affect the defect tracking i.e. even if bug is Fixed and Verified still showing is in open status in the Bug Tracking Report. This could give incorrect statistics in the bug statistic report. 10) Did you notice that Point #10 has been kept blank, so why dont you come up with What all problems you faced in the Issue Tracking? Feel free to let me hear your problems by commenting below.

System Testing: What? Why? & How?


What is System Testing?

System testing is the testing of behavior of a complete and fully integrated software product based on the software requirements specification (SRS) document. In main focus of this testing is to evaluate Business / Functional / End-user requirements. This is black box type of testing where external working of the software is evaluated with the help of requirement documents & it is totally based on Users point of view. For this type of testing do not required knowledge of internal design or structure or code. This testing is to be carried out only after System Integration Testing is completed where both Functional & Non-Functional requirements are verified. In the integration testing testers are concentrated on finding bugs/defects on integrated modules. But in the Software System Testing testers are concentrated on finding bugs/defects based on software application behavior, software design and expectation of end user.

Why system testing is important:

a) In Software Development Life Cycle the System Testing is perform as the first level of testing where the System is tested as a whole. b) In this step of testing check if system meets functional requirement or not. c) System Testing enables you to test, validate and verify both the Application Architecture and Business requirements. d) The application/System is tested in an environment that particularly resembles the effective production environment where the application/software will be lastly deployed. Generally, a separate and dedicated team is responsible for system testing. And, System Testing is performed on staging server which is similar to production server. So this means you are testing software application as good as production environment.
Different Hierarchical levels of testing:

As with almost any technical process, software testing has a prescribed order in which things should be done. Different levels of testing are used in the testing process; each level of testing aims to test different aspects of the system. The following is lists of software testing categories arranged in sequentially organize.

Hierarchical levels of testing

Unit testing Testing is done in the development process while developer completes the unit development. The object of this testing is to verify correctness of the module. The purpose of unit testing is to check that as individual parts are functioning as expected. Basically Unit testing is typically carried out by the developer. Integration testing System Integration Testing is started after the individual software modules are integrated as a group. A typical software project consists of multiple modules & these are developed by different developers. So in integration testing is focuses to check that after integrating modules Is two modules are communicating with each other or not. It is critical to test every modules effect on the entire program model. Most of the issues are observed in this type of testing. System testing This is the first time end to end testing of application on the complete and fully integrated software product before it is launch to the market. Acceptance testing User acceptance is a type of testing performed by the Client to certify the system with respect to the requirements that was agreed upon. This is beta testing of the product & evaluated by the actual end users. The main purpose of this testing is to validate the end to end business flow.
Entry Criteria for System Testing:

Unit Testing should be finished. Integration of modules should be fully integrated. As per the specification document software development is completed. Testing environment is available for testing (similar to Staging environment)

How to do System Testing?

In Software System Testing following steps needs to be executed: Step 1) First & important step is preparation of System Test Plan: The what all points to be cover in System Test plan may vary from organization to organization as well as based on project plan, test strategy & main test plan. Nevertheless, here is list of standard point to be considered while creating System Test Plan:

Goals & Objective Scope Critical areas Area to focus Test Deliverable Testing Strategy for System testing Testing Schedule Entry and exit criteria Suspension & resumption criteria for system testing Test Environment

Roles and Responsibilities Glossary

Step 2) Second step is to creation Test Cases: It is very much similar functional test case writing. In test case writing you should write the test scenarios & use cases. Here you should consider different type of testing like Functional testing, Regression testing, Smoke testing, Sanity testing, Ad-hoc testing, Exploratory testing, Usability testing, GUI software testing, Compatibility testing, Performance testing, Load testing, Stress testing, Volume testing, Error handling testing, Scalability testing, Security testing, Capacity testing, Installation testing, Recovery testing, Reliability testing, Accessibility testing etc While writing test case you need to check that test cases are covering all functional, nonfunctional, technical & UI requirements or not. Sample Test Case Format: Test Test Suite Name How to Test? Case ID
Test Data Expected Result Actual Result

Pass/Fail

Step 3) Creation of test data which used for System testing. Step 4) Automated test case execution. Step 5) Execution of normal test case & update test case if using any test management tool (if any). Step 6) Bug Reporting, Bug verification & Regression testing. Step 7) Repeat testing life cycle (if required). In System testing now you have clear about What is System Testing?, Importance of system testing, different levels of testing and How & what criteria needs to be consider in System Testing. If you think any points is missed or to be added in System testing then you

V Model
In the basic Waterfall model process seen some disadvantages or limitations in the model which started a new SDLC model. As we seen in the Waterfall model the issues found in the end of the SDLC, this is due to the testing is occurred in the end phases of the you SDLC. To overcome this problem the V-Model is comes into the picture. It is always better to introduce testing in the

early phase of SDLC, as in this model the testing activity gets started from the early phase of the SDLC. Before starting the actual testing, testing team has to work on various activities like preparation of Test Strategy, Test Planning, Creation of Test cases & Test Scripts which is work parallel with the development activity which help to get the test deliverable on time.
V Model Software Development Life Cycle

V Model - Software Development Life Cycle In the V Model Software Development Life Cycle, based on same information(requirement specification document) the development & testing activity is started. Based on the requirement document developer team started working on the design & after completion on design start actual implementation and testing team starts working on test planning, test case writing, test scripting. Both activities are working parallel to each other. In Waterfall model & V-model they are quite similar to each other. As it is most popular Software Testing Life Cycle model so most of the organization is following this model. The V-model is also called as Verification and Validation model. The testing activity is perform in the each phase of Software Testing Life Cycle phase. In the first half of the model validations testing activity is integrated in each phase like review user requirements, System Design document & in the next half the Verification testing activity is come in picture. Typical V-model shows Software Development activities on the Left hand side of model and the Right hand side of the model actual Testing Phases can be performed. In this process Do-Procedure would be followed by the developer team and the CheckProcedure would be followed by the testing team to meets the mentioned requirements. In the V-Model software development life cycle different steps are followed however here we will taking a most common type of V-model example. The V-model typically consist of the following phases: 1. Unit Testing: Preparation of Unit Test Cases 2. Integration Testing: Preparation of Integration Test Cases 3. System Testing: Preparation of System test cases 4. Acceptance Testing: Preparation of Acceptance Test Cases

What if there isn't enough time for thorough testing?


In previous article we have learn about What can be done if requirements are changing continuously? In todays software testing class you will learn about What can be done if short time frame is available to thorough testing application? If we have enough time to test the application then it is not a problem at all. But if there isnt enough time for through testing of application, in this situation it wont possible to test each & every combination of scenario. The Risk analysis is playing vital role in Software Testing, we recommend that you should use risk analysis to determine where testing should be focused.

Not enough time for thorough testing To help you identify the risks involved in all your requirements, consider the following aspects:

Test functionality which has largest financial impact on users Test functionality which has largest safety impact Test most visible functionality to the user Test most important functionality which projects intended purpose Test most important feature in terms of customers view Test most visible functionality which has Complex functions Test most important feature that are developed with new tools Test functionality which has lot of bug fixes or updates Test most important feature that are most important to the stakeholders Test functionality which has developed under extreme time pressure. Test functionality which is implemented in rush & panic mode, which may leads to more errors in the code. Test complex functionality which may leads to more errors in the code. As per previous experience test functionality which cause problems in previous project. As per previous experience test functionality which cause major maintenance aspects of project. Test the feature of application which would create bad impact in terms of the publicity. Test the functionality which has highest-risk part of the application

This is typical question to be asked in Software testing interview. I observed that many of testers are come up with answer like Prioritize the test cases & execute test cases based on the High Priority. This is little bit correct but not detailed answer, it should be more detailed. If the limited time to test application then you go with following strategy: Its not possible to test everything when short time frame available to thorough testing application. You should go with Risk based testing & Requirement based testing. The strategy starts with a risk analysis to determine the functions (requirements) with the highest risk,

and plan your test activities guided by this analysis. This strategy helps you to get list of test to be executed first & in which sequence. So it covers the testing of essential part of software application.

Tips/Guidelines for writing test cases


Writing good test cases is a talent and it can be achieved by experience and comprehensively studying application under test. In this article I will talk about basics tips on how to write test cases, what is test case, why use Test Case Management Tools, test case template & How to handle Test case maintenance. So lets begin with first point which is part of testers daily day to day life activity:
What is a test case?

Test case is set of activities with expected and actual results executed in sequence to validate the feature of an application. Test case is the document and is designed by the tester based on the SRS document and Use case document. Definition by Wikipedia: Test case
How to write test cases? 1. First understand the requirements & while writing test cases do not assume any requirements by your own. Raise the question which is not clear in requirement or requirements are misleading or incomplete, feel free to ask questions to your business analyst or client. Dont ask to developers on this. 2. Prior to design the test cases figure out all features of application. 3. Ensure that test case should cover all functionality mention in requirement document. Use traceability matrix to make sure that all requirements are left untested. 4. Avoid repetition of test cases which help to get exact scope of testing. 5. Generic test cases should be collected & combine together in test suite, which helps to minimize the effort of writing standard common test cases every time and can be used over the project life cycle. 6. Testing Priority should be assign to each test case. Select the Test case priority depending upon how important the test case is for that Feature, component or the product. In execution queue, high priority test cases should be picked first then medium and then Low priority test cases. 7. As end users or clients are always interested in reports, so test cases should be group properly (PhaseI, II wise, Module wise, Sprint wise or User story wise if Agile methodology), so end user will come to know about Quality of the product based on test case execution (number of test cases Pass/Failed). 8. While writing test cases Keep in mind all your test cases should be simple and easy to understand. Dont write explanations like essays. Be to the point. 9. Keep in mind input data for test cases is very important part in testing, your test cases should validate range of input data. Also check how system behaves in the normal & abnormal conditions.

10. While writing test cases you should concentrate on real life scenarios first which end user going to use day to day life activity and accordingly test cases should be prepare. 11. Every test case may or may not have defect linked but each defect should have test case linked. What should be format of test case?

The test case template is may vary from company to company, here I am explaining standard test case format:

Test case id (Unique Identifier) Test case Title (Short description of test case & should be effective to convey the test case) Test case Summary (Detailed description of test case & additional information needed for the test case to execute) Pre-condition/Test data (Any pre-requisite required to execute the test case) Test Steps (Actual step to be followed or executed) Excepted Result (Result which is expected as a normal behavior) Actual result (Result which we actually get after we execute the test step) Test Case Status(Pass/Fail) Comments (Additional Comments or any note required to while executing test case or special note to tester which need to be consider)

More explanation on test case template fields: Test case title: 1. Many of the times the test case title is not clear, which leads to difficulty to understand what is the test case is all about. As a tester you make sure that it is gives complete idea about the test cases. 2. Test cases are nothing but users action on the application. So while writing test cases make sure that user is performing those actions. Cross verify that user is able to login, Verify that user be able to perform the necessary tasks. 3. Try to follow following format whenever possible:
o o o o

[Verify] If writing Functional test cases [Using] IF test case is about use of Tool name, Tag name, Dialog, etc. [With]- If test is related to any condition [To]- If test case talking about what is returned, shown, demonstrated etc.

Test Case Summary:


Test case summary means describe the test case in short. Make sure that you document the additional information needed for the test case to execute, such as Assumptions, Test data location, URLs and test credentials.

Test case Steps:

Its very important to write each and every step.

If its not possible to write each and every test case, then combine the test steps logically but do not skip them.

Test case Expected Result:

As a consequence of the execution of the test cases, something has to be observed in the application. That will lead test executor to decide whether execution was successful or not.
Test Case Management tools: Design & write test cases for complex application is challenging task. Even if effective Test cases written but if it is not well maintained then it could leads to confusion of execution & completion of test cases. So best options is to use Test management tools which allow you to manage & maintain test cases. In the market many more open source & commercial tools available. Using popular Test Management tools like Quality Center and JIRA you can manage test cases in efficient way. Also if you prepare set of generic test cases this can be used in different releases. Failed test cases will allow us to link to defect & defects assigns to developer & send automatic email notifications. Upon executing test cases the result can be easily obtain in predefined & custom graphs & reports. Most important thing is tractability, it means Requirements, Test cases, Execution of Test cases are all interlinked through the tools and each case can be traced against each other to check test coverage. How to handle Test case maintenance?

Todays fast growing world software application requirements of keeps on changing on every software upgrade. So in every upgrade test suite needs to be updated or maintained based on new requirements. While updating test cases following key points needs to be considered: Add new test cases: Add new test cases in the test suite for new requirements which introduced in this release. While testing, tester may found scenario for white test case is not added in test suite; hence such missing test case should be created & added in the test suite. Test cases for Production defects: Upon releasing the software on production, the end user may report defects which observed on production environment. This is due to comprehensive test cases are not written for particular area, as a result defects are observed in production. Hence based on defects found during previous release, new test cases should be added or modified which are missed to add in previous release. Remove obsolete test cases: Upon changes in the requirements, it could add new features & same time few exiting features no longer valid or not supported in this release, so such obsolete test cases should be removed from current test suite. Remove unnecessary test cases: In test case design phase there is a chance to create duplicate test case or added different test case which functioning similarly in testing. Presence of such test

cases may lead wrong status of testing. So it is important to clean up such duplicate test case to get real picture of testing.

Why testing should start early in software development life cycle?


One of the software testing principles say that Start Testing Early in the software development life cycle, so in this article we will see what all advantages & practical reasons if we start testing early in SDLC. It has been observed that most of the errors are identified in the testing phase which is already introduced in the requirement or design phase. Defects identified later in SDLC are expensive to fix than defects identified in early stage. So testing should start early to avoid the introduction of defects in the early phase. First lets see normal software development life cycle process planning:

Software Development Life Cycle Planning

In SDLC first step is Planning in which planning of entire project where all requirements are captured, discuss if any queries & got clarified from Client. Requirements are finalized & entire planning is prepared. Upon finalizing requirements, start requirement analysis & system is designed as per the Planned Time. In this planning all steps are dependent on previous phase. Unless and until previous step is not completed then not to start the next step. In this step actual implementation (Coding) starts. Finally upon completion of Coding actual Testing starts here.

This is standard process to be followed in Software development life cycle. But it may vary from project to project. Most likely the project life cycle goes as below:

Planned activities wont go smooth, so time take to complete Planning, Analysis and Design & Coding would take more than the estimated time which causes issues in the overall project planning. If the project timing is flexible then this is not an issue at all. But if the release date is fixed & not gonna change then it make direct impact on the quality of the software application, as very less time get to test entire application. Also the promises have been made to customers; project managers are going to lose their bonuses if they deliver later past deadline. Also to fix the bugs which are found at later stages are costlier than found in early stage.
Cost Effectiveness:

So start testing early in the software development would solve the problem, as the earlier you find a bug, the cheaper it is to fix it.

Price of Buggy Code [Image credit: Loadstorm.com] In the requirement phase if we found issue or conflict in the requirements itself then it wont take to much time to fix the issue. But if bug found in early stage of SDLC then to fix this bug would take 50 times cheaper than fixing bug in actual testing. It would be more costly if bug is found in maintenance phase means after going to product live.

Advantages of starting early testing:


In the requirements stage, testing projects requirements can be a cost-effective & useful to avoid bugs afterward. Completion of writing test cases early will help to fix the test cases if later changes in requirements. You will get enough to quantify the problems scope. Early preparation of test environment, thereby preventing any delays and unknown risks will have enough time to deal with. Many times test team not get enough time to test the software application, so they have to squeeze the testing time which affects the Quality of the product. So one soluyion is to start testing early so test team will get enough time to test software application so need not to squeeze your testing time. You may find that few items may not be tested, since they may not be impacted. This input can cut down on your Testing phase.

Its said, Quality is built in, not added on. So Early Testing would be better option to go on!!! So This is what you should do as testing is concern:

Testing should be planned for each phase of SDLC.


Testing should involve in all phases of SDLC. Test planning should be started from beginning of the project. Once the requirements are baselined, System testing plan ( or UAT ) and test cases should be prepared. This will also help in uncovering the gaps in requirements process. Test preparation should be done before actual testing starts. Start finding defects from requirement gather phase. Keep on doing that throughout analysis and design phase. As you move forward and complete the Design, you should complete the Integration testing cases and also to some extent Unit test cases. Ensure that testing becomes part of the development process.

What is Black Box Testing?


Firstly we will learn what is Black Box Testing? Here we will discuss about how black box testing is perform, different BBT Techniques used in testing.

Black Box Testing Method:


Black box testing is the Software testing method which is used to test the software without knowing the internal structure of code or program. Most likely this testing method is what most of tester actual perform and used the majority in the practical life. Basically software under test is called as Black-Box, we are treating this as black box & without checking internal structure of software we test the software. All testing is done as customers point of view and tester is only aware of what is software is suppose to do but how these requests are processing by software is not aware. While testing tester is knows about the input and expected outputs of the software and they do not aware of how the software or application actually processing the input requests & giving the outputs. Tester only passes valid as well as invalid inputs & determines the correct expected outputs. All the test cases to test using such method are calculated based on requirements & specifications document. The main purpose of the Black Box is to check whether the software is working as per expected in requirement document & whether it is meeting the user expectations or not. There are different types of testing used in industry. Each testing type is having its own advantages & disadvantages. So fewer bugs cannot be find using the black box testing or white box testing. Types of Black Box Testing Techniques: Following black box testing techniques are used for testing the software application.

Boundary Value Analysis (BVA) Equivalence Class Partitioning Decision Table based testing Cause-Effect Graphing Technique Error Guessing

1) Boundary Value Analysis (BVA): Boundary Value Analysis is the most commonly used test case design method for black box testing. As all we know the most of errors occurs at boundary of the input values. This is one of the techniques used to find the error in the boundaries of input values rather than the center of the input value range.

Boundary Value Analysis is the next step of the Equivalence class in which all test cases are design at the boundary of the Equivalence class. Let us take an example to explain this: Suppose we have software application which accepts the input value text box ranging from 1 to 1000, in this case we have invalid and valid inputs:
Invalid Input 0 less Valid Input 1 1000 Invalid Input 1001 above

Here are the Test cases for input box accepting numbers using Boundary value analysis: Min value 1 Min Value Min value + 1 Normal Value Max value 1 Max value Max value +1 0 1 2 1 1000 999 1000 1001

This is testing techniques is not applicable only if input value range is not fixed i.e. the boundary of input is not fixed. 2) Equivalence Class Partitioning The equivalence class partition is the black box test case design technique used for writing test cases. This approach is use to reduce huge set of possible inputs to small but equally effective inputs. This is done by dividing inputs into the classes and gets one value from each class. Such method is used when exhaustive testing is most wanted & to avoid the redundancy of inputs. In the equivalence partitioning input are divided based on the input values:

If input value is Range, then we one valid equivalence class & two invalid equivalence classes. If input value is specific set, then we one valid equivalence class & one invalid equivalence classes. If input value is number, then we one valid equivalence class & two invalid equivalence classes. If input value is Boolean, then we one valid equivalence class & one invalid equivalence classes.

What is a White Box Testing?


In the previous Software Testing Class I have explain about Black Box testing. In this section I am introducing the What is White Box Testing, What do you verify in White Box Testing, White

box testing techniques, white box testing definition, types of white box testing, white box testing example, advantages and disadvantages of white box testing etc. White Box Testing (WBT) is also known as Code-Based Testing or Structural Testing. White box testing is the software testing method in which internal structure is being known to tester who is going to test the software.
White Box Testing Definition:

Testing based on an analysis of the internal structure of the component or system. In this method of testing the testcases are calculated based on analysis internal structure of the system based on Code coverage, branches coverage, paths coverage, condition Coverage etc.

White Box Testing White box testing involves the testing by looking at the internal structure of the code & when you completely aware of the internal structure of the code then you can run your test cases & check whether the system meet requirements mentioned in the specification document. Based on derived test cases the user exercised the test cases by giving the input to the system & checking for expected outputs with actual output. In this is testing method user has to go beyond the user interface to find the correctness of the system. Typically such method are used at Unit Testing of the code but this different as Unit testing done by the developer & White Box Testing done by the testers, this is learning the part of the code & finding out the weakness in the software program under test.

For tester to test the software application under test is like a white/transparent box where the inside of the box is clearly seen to the tester (as tester is aware/access of the internal structure of the code), so this method is called as White Box Testing. The White-box testing is one of the best method to find out the errors in the software application in early stage of software development life cycle. In this process the deriving the test cases is most important part. The test case design strategy include such that all lines of the source code will be executed at least once or all available functions are executed to complete 100% code coverage of testing.
What do you verify in White Box Testing ?

In the White box testing following steps are executed to test the software code:

Basically verify the security holes in the code. Verify the broken or incomplete paths in the code. Verify the flow of structure mention in the specification document Verifyt the Expected outputs Verify the all conditional loops in the code to check the complete functionality of the application. Verify the line by line or Section by Section in the code & cover the 100% testing.

Above steps can be executed at the each steps of the STLC i.e. Unit Testing, Integration & System testing. In the White Box Testing verify the flow of the application. The pre designed test cases are executed with the help of input data & compare the output with the expected one & found mismatch if any means you found a bug.
White Box Testing Techniques

Here are some white box testing techniques used in White Box Testing? In the White box testing the Code Coverage analysis is main part. Code Coverage analysis helps to identifying the gaps in a test case suite. It allows you to find the area in the code to which is not executed by given set of test cases. Upon identifying ht gaps in the test case suite you can add the respective test case. So it helps to improve the quality of the software application. In the market lots of white box testing tools are available to perform Code Coverage analysis. Here are some White Box Testing Techniques Statement Coverage: In this white box testing technique try to cover 100% statement coverage of the code, it means

while testing the every possible statement in the code is executed at least once. Tools: To test the Statement Coverage the Cantata++ can be used as white box testing tool. Decision Coverage: In this white box testing technique try to cover 100% decision coverage of the code, it means while testing the every possible decision conditions like if-else, for loop and other conditional loops in the code is executed at least once. Tools: To cover the Decision Coverage testing in the code the TCAT-PATH is used. This supports for the C, C++ and Java applications. Condition Coverage: In this white box testing techniquie try to cover 100% Condition coverage of the code, it means while testing the every possible conditions in the code is executed at least once. Decision/Condition Coverage: In this mixed type of white box testing technique try to cover 100% Decision/Condition coverage of the code, it means while testing the every possible Decisions/Conditions in the code is executed at least once. Multiple Condition Coverage: In this type of testing we use to cover each entry point of the system to be execute once. In the actual development process developers are make use of the combination of techniques those are suitable for there software application. Using above mentions testing white box testing techniques the 80% to 90% code coverage is completed which might be sufficient with white box testing.
How do you perform White Box Testing?

Let take a simple website application. The end user is simply access the website, Login & Logout, this is very siple and day 2 days life example. As end users point of view user able to access the website from GUI but inside there are lots of things going on to check the internal things are going right or not, the white box testing method is used. To explain this we have to divide this part in two steps. This is all is being done when the tester is testing the application using White box testing techniques. STEP 1) UNDERSTAND OF THE SOURCE CODE Step 2) CREATE TEST CASES AND EXECUTE STEP 1) UNDERSTAND OF THE SOURCE CODE The first & very important steps is to understand the source code of the application is being test. As tester should know about the internal structure of the code which helps to test the application. Better knowldge of Source code will helps to indentify & write the important test case which

causes the security issues & also helps to cover the 100% test coverage. Before doing this the tester should know the programming languange what is being used in the developing the application. As security of application is primary objective of application so tester should aware of the security concerns of the project which help in testing. If the tester is aware of the security issues then he can prevents the security issues like attacks from hackers & users who are tring to inject the macious things in the application. Step 2) CREATE TEST CASES AND EXECUTE In the second step invovles the actual writing of test cases based on Statement/Decision/Condition/Branch coverage & actual execution of test cases to cover the 100% testing coverage of the software appliction. The Tester will write the test cases by diving the applications by Statement/Decision/Condition/Branch wise. Other than this tester can include the trial and error testing, manual testing and using the Software testing tools as we covered in the previous article.
Advantages and Disadvantages of Waterfall Model:

Advantages of White Box Testing

To start the testing of the software no need to wait for the GUI, you can start the White Box Testing. As covering all possible paths of code so this is a thorough testing. It helps in removing the . Tester can ask about implementation of each section, so it might be possible to remove unused lines of code which might be causing introduction of bug. By executing equivalence use to approximates the partitioning. As the tester is aware of internal coding structure, then it is helpful to derive which type of input data is needed to testing software application effectively. White box testing allows you to help in the code optimization.

Disadvantages of White Box Testing

To test the software application a highly skilled resource is required to carry out testing who know the deep knowledge of internal structure of the code which increase the cost. Update test script is required if changing the implementation too frequently. If the application under test large is size then exhaustive testing is impossible. It is not possible for testing each and every path/condition of software program, which might miss the defects in code. White box testing very expensive type of testing. To analyze each line by line or path by path is nearly impossible work which may introduce or miss the defects in the code. To test each paths or conditions may require different input conditions, so to test full application tester need to create fill range of inputs which may be a time consuming.

Gray Box Testing


What is Gray Box Testing?

Gray box testing is the testing of software application using effective combination of both White box testing & Black box testing method. This is nice & powerful idea to test the application. The white box testing means tester is aware of internal structure of code but the black box tester doesnt aware the internal structure of code. In the Gray box testing tester is usually has knowledge of limited access of code and based on this knowledge the test cases are designed and the software application under test treat as a black box & tester test the application from outside. Dont confuse with White box & Gray box, as in the Gray box testing is tester doesnt have the knowledge in detailed. Also the Gray box testing is not a black box testing method because the tester knows some part of the internal structure of code. So Gray Box Testing approach is the testing approach used when some knowledge of internal structure but not in detailed. The name is comes because the application for tester is like a gray box like a transparent box and tester see inside it but not fully transparent & can see partially in it. As tester doesnt require the access to code the gray box testing is known as unbiased & non-intrusive. To test the Web Services application usually the Gray box testing is used.
Gray Box Testing Example:

We will take example of web application testing. To explore gray testing will take a simple functionality of web application. You just want to enter email id as input in the web form & upon submitting the valid email id user & based on users interest (fields entered) user should get some articles over email. The validation of email is using Java Script on client side only. In this case if tester doesnt knows the internal structure of the implementations then you might test the web application of form with some cases like Valid Email Id, Invalid Email ID & based on this will check whether functionality is working or not. But tester is aware of some internal structure & if system is making the assumptions like

System will not get Invalid email ID System will not send email to invalid email ID System will not receive failure email notifications.

In this type of testing you have to test the application by disabling the Java Script, it might be possible due to any reason Java Script is failed & System get Invalid email to process & all assumptions made by system will failed, as a result incorrect inputs are send to system, so

System will get Invalid email ID to process System will send email to invalid email ID

System will receive failure email notifications.

Note: The Gray box Testing is also spell as Grey Box Testing so both GrayBox Testing & GreyBox Testing are the same one.

Functional Testing
What is Functional Testing?

In Functional testing we need check the each components are functioning as expected or not, so it is also called as Component Testing.
Functional Testing definition:

Functional testing is to testing the functionality of the software application under test. Basically, it is to check the basic functionality mentioned in the functional specification document. Also check whether software application is meeting the user expectations. We can also say that checking the behavior of the software application against test specification. This type of testing is mandatory and irrespective of what type of application this should be exercised.
What all need to be check in Functional Testing:

Is software is functioning as it should do? Is software is not functioning as it should not do? Is software is not doing as it not intended to do?

To test the software application many tools for the functional testing are available, you can get list here Functional testing tools.

Functional Testing Vs Non-Functional Testing


In previous articles we have seen separate articles for Functional Testing & Non-Functional testing. But in todays article we will see the actual difference between Functional Testing Vs Non-Functional Testing.
What is Functional Testing?

Functional Testing is the type of testing done against the business requirements of application. It is a black box type of testing.

It involves the complete integration system to evaluate the systems compliance with its specified requirements. Based on the functional specification document this type of testing is to be carried out. In actual testing, testers need to verify a specific action or function of the code. For functional testing either manual testing or automation tools can be used but functionality testing would be easier using manual testing only. Prior to non Functional testing the Functional testing would be executed first. Five steps need to be keeping in mind in the Functional testing:
1. 2. 3. 4. 5. Preparation of test data based on the specifications of functions Business requirements are the inputs to functional testing Based on functional specifications find out of output of the functions The execution of test cases Observe the actual and expected outputs

To carry out functional testing we have numerous tools available, here is the list of Functional testing tools. In the types of functional testing following testing types should be cover:

Unit Testing Smoke testing Sanity testing Integration Testing Usability Testing Interface Testing System Testing Regression Testing UAT

What is non Functional Testing?

The non Functional Testing is the type of testing done against the non functional requirements. Most of the criteria are not consider in functional testing so it is used to check the readiness of a system. Non-functional requirements tend to be those that reflect the quality of the product, particularly in the context of the suitability perspective of its users. It can be started after the completion of Functional Testing. The non functional tests can be effective by using testing tools. The testing of software attributes which are not related to any specific function or user action like performance, scalability, security or behavior of application under certain constraints. Non functional testing has a great influence on customer and user satisfaction with the product. Non functional testing should be expressed in a testable way, not like the system should be fast or the system should be easy to operate which is not testable.

Basically in the non functional test is used to major non-functional attributes of software systems. Lets take non functional requirements examples; in how much time does the software will take to complete a task? or how fast the response is. Following testing should consider in non functional testing types:

Availability Testing Baseline testing Compatibility testing Compliance testing Configuration Testing Documentation testing Endurance testing Ergonomics Testing Interoperability Testing Installation Testing Load testing Localization testing and Internationalization testing Maintainability Testing Operational Readiness Testing Performance testing Recovery testing Reliability Testing Resilience testing Security testing Scalability testing Stress testing Usability testing Volume testing

Smoke Testing
What is Smoke Testing?

Smoke testing is the initial testing process exercised to check whether the software under test is ready/stable for further testing. The term Smoke Testing is came from the hardware testing, in the hardware testing initial pass is done to check if it did not catch the fire or smoked in the initial switch on. Prior to start Smoke testing few test cases need to created once to use for smoke testing. These test cases are executed prior to start actual testing to check critical functionalities of the program is working fine. This set of test cases written such a way that all functionality is verified but not in deep. The objective is not to perform exhaustive testing, the tester need check the navigations & adding simple things, tester needs to ask simple questions Can tester able to

access software application?, Does user navigates from one window to other?, Check that the GUI is responsive etc. Here are graphical representation of Smoke testing & Sanity testing in software testing:

Smoke Sanity Testing Diagram The test cases can be executed manually or automated; this depends upon the project requirements. In this types of testing mainly focus on the important functionality of application, tester do not care about detailed testing of each software component, this can be cover in the further testing of application. The Smoke testing is typically executed by testers after every build is received for checking the build is in testable condition. This type of testing is applicable in the Integration Testing, System Testing and Acceptance Testing levels.
Advantages of Smoke testing:

It helps to find issues introduced in integration of modules. It helps to find issues in the early phase of testing. It helps to get confidence to tester that fixes in the previous builds not breaking major features (off course, only features exercised by smoke testing).

Conclusion:

In these article we covered Smoke Testing definition, description, advantages. Hope this will help to understand the Smoke. I will explain What is Sanity Testing? in my next article, keep eye on it.

Sanity Testing
After sharing information on Smoke testing in the previous articles, in todays Software testing class I am explaining about the Sanity testing. In this post I will explain the What is a sanity testing, Sanity Testing definition and tips on Sanity testing.
What is a Sanity Testing?

After receiving a Software build with the minor issues fixes in code or functionality, Sanity testing is carry out to check whether the bugs reported in previous build are fixed & there is regression introduced due to these fixes i.e. not breaking any previously working functionality. The main aim of Sanity testing to check the planned functionality is working as expected. Instead of doing whole regression testing the Sanity testing is perform. Sanity tests helps to avoid wasting time and cost involved in testing if the build is failed. Tester should reject the build upon build failure. After completion of regression testing the Sanity testing is started to check the defect fixes & changes done in the software application is not breaking the core functionality of the software. Typically this is done nearing end of SLDC i.e. while releasing the software. You can say that sanity testing is a subset of acceptance testing. We can also say Tester Acceptance Testing for Sanity testing. Sanity testing is narrow & deep approach of testing, it needs to concentrate limited & main features of testing in detailed. Here are the few consolidated points of Sanity testing:

Sanity testing follows narrow and deep approach with detailed testing of some limited features. Sanity testing is typically non-scripted. Sanity testing is a sub-set of regression testing. Sanity testing is cursory testing to prove software application is working as mention in the specification documents & meets the user needs. Sanity testing is used to verify the requirements of end users are meeting or not. Sanity testing to check the after minor fixes the small section of code or functionality is working as expected & not breaking related functionality.

Hope you get clear idea of Sanity testing in the above article & cleared any confusions on Sanity testing.

Regression testing definition


What is regression testing?

Regression testing is type of testing carried out to ensure that changes made in the fixes or any enhancement changes are not impacting the previously working functionality. It is executed after enhancement or defect fixes in the software or its environment. It can be difficult to determine how much re-testing is needed, especially near the end of the development cycle. This type of testing typically carried out by testing specialist peoples. The automated testing methods are the best and safe option to carry out the Regression testing. In the market there are many free as well as free (open source) software testing tools are available. In the larger software development project the Regression testing is commonly used. Some of the most commonly used regression testing tools list:

QTP Regression Tester Selenium Rational Functional Tester Watir Winrunner actiWate AdventNet QEngine SilkTest vTest

It is a verification method & mainly done in system testing but it applicable to all levels of software testing (Unit testing, Integration testing, System testing and Acceptance testing.) Good Regression tester need to aware of what all features to be focus on changes in the software application. The main aim of regression testing to make sure that changed component is not impacting the unchanged part of the component.

Regression-testing Every time after making changing in the existing working code, a suite of test case have to executed to ensure that changes are not breaking working features and not introduced any bugs in the software. It is essential to prepare such test suite & executed on every newer version of software. Also to automate the regression testing this test suite will help to create a automated testing script. In the Software regression testing, tester has to do only the execution of previously executed test cases & compare the result with previously test execution result. If there is not conflict between results then we can say that the regression testing is passed. In this type of testing new test cases are not created but previously created test suite is executed to find regression defects.
How to define the scope of regression testing?

The scope of testing is based on the how large fixes or enhancements of features. If this is impacting in the larger area of the application then scope will increase proportionally & it requires the deep testing of application including relevant test cases execution. But to analyze this tester should get the correct inputs from developer to decide the scope. But if you are testing GUI applications the doing regression testing is very difficult. If the changes made in the GUI then all test cases written will not reused. In case if the project is big then it is very hectic work to update the GUI test cases. You have to write it again different test case for updated GUI once again. Software testing resources: To get more learning on how regression test is used in the actual environment, here are some useful resources for learning about regression testing in the Software Testing Class: 1) Regression testing is one step ahead than retesting: Many of the testers are confused about the terminology. In this class I am explore on difference between the two terms & how regression and retesting is relate to each other with the regression testing examples. 2) How to select effective test cases in Regression testing? 3) Simple steps to for automate the regression testing

User Acceptance Testing: What? Why? & How?


In previous article we discussed on What/Why/How System testing can be performed. As we know before starting the System testing the whole Integration Testing should be completed. But

what next if the System Testing is completed. Yes you are correct User Acceptance Testing should get started after this. In this article I am writing about about What/Why/How User Acceptance testing is done in actual testing.
What is User Acceptance Testing?

User Acceptance testing is the software testing process where system tested for acceptability & validates the end to end business flow. Such type of testing executed by client in separate environment (similar to production environment) & confirm whether system meets the requirements as per requirement specification or not. UAT is performed after System Testing is done and all or most of the major defects have been fixed. This testing is to be conducted in the final stage of Software Development Life Cycle (SDLC) prior to system being delivered to a live environment. UAT users or end users are concentrating on end to end scenarios & typically involves running a suite of tests on the completed system. The Acceptance testing is black box tests, means UAT users doesnt aware of internal structure of the code, they just specify the input to the system & check whether systems respond with correct result.

Levels of testing User Acceptance Testing User Acceptance testing also known as Customer Acceptance testing (CAT), if the system is being built or developed by an external supplier. The CAT or UAT are the final confirmation from the client before the system is ready for production. The business customers are the primary owners of these UAT tests. These tests are created by business customers and articulated in

business domain languages. So ideally it is collaboration between business customers, business analysts, testers and developers. It consists of test suites which involve multiple test cases & each test case contains input data (if required) as well as the expected output. The result of test case is either a pass or fail. Acceptance Testing Definition: Acceptance Testing is a level of the software testing process where a system is tested for acceptability.
Prerequisites of User Acceptance Testing:

Prior to start the UAT following checkpoints to be considered:


The Business Requirements should be available. The development of software application should be completed & different levels of testing like Unit Testing, Integration Testing & System Testing is completed. All High Severity, High Priority defects should be verified. No any Showstoppers defects in the system. Check if all reported defects should be verified prior to UAT starts. Check if Traceability matrix for all testing should be completed. Before UAT starts error like cosmetic error are acceptable but should be reported. After fixing all the defects regression Testing should be carried out to check fixing of defect not breaking the other working area. The separate UAT environment similar to production should be ready to start UAT. The Sign off should be given by System testing team which says that Software application ready for UAT execution.

TYPES OF ACCEPTANCE TEST

Why Alpha and Beta Testing? The software application may use different users on different way & it impossible to developer or tester to predict what all possible scenarios or test data end user will use & how customer actually use the software application. So most of software venders are use the term like Alpha testing and Beta Testing which help to uncover the errors that may occurs in the actual test environment. In this testing method the software application release over limited end users rather than testing professionals to get feedback from them. A] Alpha Testing Alpha testing is conducted by Customer at the developers site, it is performed by potential users like developer, end users or organization users before it is released to external customers & report the defects found while Alpha testing. This software product testing is not final version of software application, after fixing all reported bug (after bug triage) the new version of software application will release. Sometimes the Alpha

Testing is carried out by client or an outsider with the attendance of developer and tester. The version of the release on which Alpha testing is perform is called Alpha Release. B] Beta Testing Most if times we have the sense of hearing term Beta release/version, so it is linked to Beta Testing. Basically the beta testing is to be carried out without any help of developers at the end users site by the end users &, so it is performed under uncontrolled environment. Beta testing is also known as Field testing. This is used to get feedback from the market. This testing is conducted by limited users & all issues found during this testing are reported on continuous basis which helps to improve the system. Developers are taking actions on all issues reported in beta testing after bug triage & then the software application is ready for the final release. The version release after beta testing is called Beta Release. This is last stage of the testing where product is sent outside the company or for trial offer to download.
What to Test in User Acceptance Testing?

Based on the Requirements definition stage use cases the Test cases are created. Also the Test cases are created considering the real world scenarios for the application. The actual testing is to be carried out in environments that copy of the production environment. So in the type of testing is concentrating on the exact real world use of application. Test cases are designed such that all area of application is covered during testing to ensure that an effective User Acceptance Testing.

What are the key deliverable of User Acceptance Testing?

The completion of User Acceptance Testing is the significant milestone for traditional testing method. The following key deliverable of User Acceptance Testing phase:

Test Plan: This outlines the Testing Strategy UAT Test cases: The Test cases help the team to effectively test the application in UAT environment. Test Results and Error Reports: This is a log of all the test cases executed and the actual results. User Acceptance Sign-off: This is the system, documentation, and training materials have passed all tests within acceptable margins. Installation Instructions: This is document which helps to install the system in production environment. Documentation Materials: Tested and updated user documentation and training materials are finalized during user acceptance testing

What is Installation Testing?


Installation testing is check that software application is successfully installed & it is working as expected after installation. This is testing phase prior to end users will firstly interact with the actual application. Installation testing is also called as Implementation Testing. This is most important as well as most interesting step in the Software testing life cycle. Few points need to check in the prior to Installation testing:

Verify the pre-requisites needed to software install the application if any. Installation should be run at default location & it should present to user with default location with user can able to change the default location. Verify that user should able to install software from different location like over network, online installation, installation from CD etc. Verify software installation without giving the administrative privileges. Verify to check working of Installer.exe is executing smoothly on clean state. Verify to check is the Installer.exe is calculating the disk space needed to successfully install the application prior to install the application. Verify the software installation on multiple platforms, before doing this need to confirm the supported list of platforms. Verify that successful Silent installation. In the Silent installation messages in the process of installation are not displayed on UI, all messages are added in log files and based on messages occurred is used as input in the installation process. Verify if the Interactive installation, GUI screen presented to user & user needs to provide input parameters in installation. This is majorly used in product installation. Verify that after successful installation of software is it working as per mention in specification document & meet user needs. Upon un-installation of software application check for the all previously installed files and registry entries are removed or not. Verify that is user able to uninstall or repair the software application.

Customer will happy on successful installation of software, Definitely yes. But you think of other way round if it fails to install. Upon failure of installation our software will not work but it might be possible that the data present on customers machine may affect badly. As a result, it makes bad impression on customer. This is due to the incomplete installer testing. What all things you need to make good impression on customer? The installation testing of software should be done on different platforms with manual or automated method. But to complete this time is the major concern. It is time consuming task & to execute a single test case on multiple platform might requires lots of time. And there are multiple test cases to execute. So we will see how to perform the manual Installer testing as well as automated process below: Before starting the software installation test figure out on how many configurations installer needs to be supported. Make it one Hard Disk Drive (HDD) formatted. Install a new operating system on it. Add all pre-requisites required prior to install the software application. So it is

ready to first install test on your newly prepared configuration. Wait, before going further make an image of your base HDD, so we will called as base image & it will be use for testing onward. You can create a backup of base configuration (you can use Norton Ghost to make this copy, its easy & fast). The copy of this base configuration will be used in each time of testing, it will save time a lot. Lets take a simple e.g. if 1 hour is required to make formatting of system & to make it new configuration. But by creating the image of base configuration will take hardly 10mins, here you are saving approximately 50 mins on each restoration of systemJ, so you can test it over multiple platforms with various scenarios in time. Make sure that the un-installation scenario also needs to be executed on different platform combination.

Installation testing tips with some broad test cases: To get Installation testing in step by step I have used flow chart diagram to explain in details:

1) Install Full Version Of Application: In case if you upgrading the application or previously installed a basic version now installing the full version on same path then system should allow you to install full version application without any error. Before installing newer version it should display a message on GUI saying old version is detected & do you want to continue. 2) Automate testing efforts: The flow chart below is useful to create the automated scripts, using this flow chart you can easily make out the automated script for installation testing. 3) After executing every test case use of disk image (created above) to be installing on dedicated machine which will save time. 4) Required Disk Space check in installation: This is most critical scenario in the installation testing. In the installation process check for Is installer checking for minimum required disk space check prior to installation? If for installing a software application the installer required space of 4MB then in the initial steps installer need to check whether the selected destination location have free space of 4MB at least to complete the installation. Also verify that the after successful installation, 4MB space is utilized by the installed system & if the more space is utilized then error should trigger. The Disk space checking is done using automated and manual testing method. You can verify calculated disk space by installer is correct or not by using manually or automated tools. 5) On different file system format the disk space may vary like on NTFS, FAT32, and FAT16 etc. so this case should be grouped in multi-platform test cases. 6) Use of Distributed Testing Environment: To executing test cases effectively you can use of distributed testing environment, which will save your cost & time. Using such master & slave model will help to execute different installation test cases on different platform simultaneously. Using distributed environment master model simultaneously trigger to salves for different platform & consolidated execution result collected at center location in Master model. 7) Automate the check of files installed after installation: You can use of automated script to check the all required file are got installed successfully. So you can use this script for checking completeness of installed application. In manual methods you can check free disk space available on drive before installation and disk space reported by installer script to check whether installer is calculating and reporting disk space accurately. 8) Confirm for registry changes after installation: You have to check for registry changes after the installation of software. This is to check whether expected changes are reflected in registry files. In the market many registry checking softwares are available for free. 9) Negative testing in Installation Testing: Intensely try to break the installation process to check the behavior of application under such condition. Such negative test cases should be executed on every step in Installation testing. The most important check is to confirm that state

of system should change to original state. Make it dedicated system for installation of software will help to save time & get testing complete in faster. Also check system behavior installation in low disk space conditions. 10) Uninstallation testing: You should also check for un-install testing to check whether the user is able to uninstall the application with out any error & removing the all folders & files relate to installation. Also need confirm that not impacting the other working features in the system which was previously working fine.

What is Exploratory Testing? - Interesting types of testing


In todays Software testing class I am talking on interesting part in the Software Testing i.e. Exploratory testing. In this Software testing article I am covering the importance of exploratory testing, Advantages, disadvantages and how to use it on your actual testing. Also key tips on how allow you to start understanding and applying Exploratory Testing in actual testing. Basic question in testers mind is what is exploratory testing in software testing? As name suggest that the exploratory testing means testing of software without any specific plans and schedules. This is formal testing process where we dont have any test cases or test planning documents to test the application. Identify the functionality of application by exploring the application and exploring & learning the application testers design the test cases & simultaneously execute them as well.

What is Exploratory Testing?


Exploratory testing definition

Exploratory Testing is a testing approach that allows you to apply your ability and skill as a tester in a powerful way.Testers have to understand the application first by exploring the application and based on this understand they should come up with the test scenarios. After that start actual testing of application.

Key tips to remember in Exploratory testing techniques:


Preparation of test scenarios validates the software stability. Exhaustively testing of the software based on the identified requirements. Find out the requirements as well as functionality of the software application. Find out the limitation of the software application. Identify the scope of the project.

In this type of testing the testers have to do minimum effort for planning but maximum execution cover so that tester gets exact functionality of application. This can be helpful for tester to decide what can be next to test.During testing the tester learns about behavior of the software application, start creating test plan or test scenarios. There are different exploratory testing tools in the market. One of the Exploratory testing tool is Session Tester that can be used as for managing and recording Session-Based Testing. The creation of test scenarios is totally based on the experience and learning of application under test. In this type of testing tester have freedom in testing. The finding bug is not only depends on experience of tester but also on the skill of the tester. Many of testers are thinking of when this type of testing is comes in the picture, so here are points when we can use the exploratory testing:

When you dont have a requirement or testing document or minimal documents. When you want to complete your application testing in short period of time When you have to test the application in the early stage of SDLC

Advantages

It doesnt require preparation for testing as we dont have documents for testing. In this type of testing time saves due to all task are doing simultaneously like Testing, Designing test scenarios and executing test scenarios. Tester can report many issues due to incomplete requirement or missing requirement document.

Disadvantages

Few issues cannot be catch in this type of testing. There is review of test planning & designing of test cases/scenario while testing may cause issues. Testers have to remember the scenario what he is executing because if any bug is found then tester should report a bug with proper steps to reproduce Difficulty to perform the exact manner especially for new found bugs.

I think I have addressed all major points in the Exploratory testing method. To get software testing articles in your inbox click here to Subscribe with your email address or add you email address below:

Software Testing Tools List


Now days we can get lots of Software Testing Tools in the market. Selection of tools is totally based on the project requirements & commercial (Proprietary/Commercial tools) or free tools (Open Source Tools) you are interested. Off Course, free Testing Tools may have some limitation in the features list of the product, so its totally based on what are you looking for & is that your requirement fulfill in free version or go for paid Software Testing Tools. The tools are divided into different categories as follows:

Test Management tools Functional Testing Tools Load Testing Tools

Here you can get a most popular free and paid Testing Tools list used in the actual testing of the software application.

Software Testing Tools List


1) Open Source Tools a) Test Management tools

TET (Test Environment Toolkit)

The goal behind creating the Test Environment Toolkit (TET) was to produce a test driver that accommodated the then current and anticipated future testing needs of the test development community. To achieve this goal, input from a wide sample of the community was used for the specification and development of TETs functionality and interfaces. TETware o The TETware is the Test Execution Management Systems which allows you to do the test administration, sequencing of test, reporting of the test result in the standard format (IEEE Std 1003.3 1991) and this tools is supports both UNIX as well as 32-bit Microsoft Windows operating systems, so portability of this is with test cases you developed. The TETware tools allow testers to work on a single, standard, test harness, which helps you to deliver software projects on time. This is easily available for download on ftp download. Test Manager o The Test Manager is an automated software testing tool is used in day to days testing activities. The Java programming language is used to develop this tool. Such Test Management tools are used to facilitate regular Software Development activities, automate & mange the testing activities. Currently Test Manager 2.1.0 is ready for download. If you want to learn more information of Test Manager, Click here to get a latest copy for free. RTH o RTH is called as Requirements and Testing Hub. This is a open source test management tool where you can use as requirement management tool along with this it also provides the bug tracking facilities. From here you can download the latest version of RTH.

b) Functional Testing Tools


Selenium Soapui Watir HTTP::Recorder WatiN Canoo WebTest Webcorder Solex Imprimatur SAMIE Swete ITP WET WebInject

c) Load Testing Tools


Jmeter FunkLoad

2) Proprietary/Commercial tools a) Test Management tools


HP Quality Center/ALM QA Complete T-Plan Professional Automated Test Designer (ATD) Testuff SMARTS QAS.TCS (Test Case Studio) PractiTest Test Manager Adaptors SpiraTest TestLog ApTest Manager DevTest

b) Functional Testing Tools


QuickTest Pro Rational Robot Sahi SoapTest Badboy Test Complete QA Wizard Netvantage Functional Tester PesterCat AppsWatch Squish actiWATE liSA vTest Internet Macros Ranorex

c) Load Testing Tools


HP LoadRunner LoadStorm NeoLoad Loadtracer WebLOAD Professional Forecast ANTS Advanced .NET Testing System vPerformer

Webserver Stress Tool preVue-ASCII Load Impact

You might also like