Monday, 23 January 2012

Spiral Model

This article gives the overview about Spiral Model.This is not the first model to be used to for Iteration. But this is the first model to explain why iteration matters in Software or Application Development. Normally iteration takes 6 months to 2.5 years long. Normally each phase starts with the design and ends with the Client. It means that the software or application should meet the requirement of the client. Analysis and Engineering efforts are applied in each phase of the project to keep an eye on achieving the goal.

This model is also called as Spiral Life Cycle Model is a System Development Model which was widely used in the organizations which are big and developing complex and expensive applications. This model is the combination of Prototype and Waterfall model. 

We have the following steps involved in Spiral Model:
01. The requirements of the system to be developed is gathered from the users and defined as much details as possible. We used to gather the user information by interviewing the users by explaining internal and external aspects of the available system or application.
02. A preliminary design is created for the new system.
03. Based on the preliminary design, we will develop the 1st Prototype of the system.This is a scaled down version of the system, which has the approximation of the final product.
04. A Second Prototype of the system is developed by using the following procedures.
      04.0.1. Evaluating the first prototype by means of strengths, weakness and risks.
      04.0.2  Requirements of the second prototype is defined.
      04.0.3  Plan and Design the second prototype.
      04.0.4 Second prototype is developed and tested.
05. At the customer's option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer's judgment, result in a less-than-satisfactory final product.
06.The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above
07.The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.
08.The final system is constructed, based on the refined prototype.
09.The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.
Like other models we have both advantages and disadvantages.
  1. Estimates (i.e. budget, schedule, etc.) become more realistic as work progresses, because important issues are discovered earlier.
  2. It is more able to cope with the (nearly inevitable) changes that software development generally entails.
  3. 03.Software engineers (who can get restless with protracted design processes) can get their hands in and start working on a project earlier
    1. Highly customized limiting re-usability
    2. Applied differently for each application.
    3. Risk of not meeting budget or schedule
    4. Risk of not meeting budget or schedule

Wednesday, 18 January 2012

V- Model

V model presumed to be the extension of Waterfall model. Instead of going down in linear way the process is bent upwards after coding phase to form a . V-Model clearly shows the relationship between the Development Life Cycles and the corresponding Testing phase.

We have the following phases in V-Model.
01. Requirement Analysis:
During this phase, the requirement of the software or application to be developed is gathered from the customers and analyzed based on their input. Requirements are nothing but the constraints or practicalities which are expected from the software to be developed.However,we'll not decide that how the system will built. Normally the customer is interviewed and a document called User Requirement Document will be prepared.Requirement Document clearly describe the features like functions, interfaces, security etc.
Once the document is prepared based on the user requirement one of the Business Analyst will share the document with the client. The client will carefully review the document and send it back to the Analyst. Then the document will be serving as a Baseline for the System/Application designers in the design phase.
During this phase, we used to prepared "Acceptance Test Cases".

02.System Design:
The system designers go through the requirement document and analyze the same to understand the functionalities expected from the system to be developed.  They will look for all possibilities to implement the software or application based on the user requirement. If some of the features are not feasible they'll send the details to the client. Upon their approval the Requirement document will be edited.
Once everything is finalized a document called Software Specification Document will be generated. It'll serve as a blueprint document for the Development phase. This document contains the details like functional flow, menu structure of the application and some of the sample window mock ups etc. 
We used to prepare "System Test Cases" during this phase.

03. Architecture Design:
During this phase we'll have the high level design of the application. We'll have the details like modules, brief functionality of each module, the relation between the modules,interface details between modules, database details, architectural diagrams, technical details etc.
We used to prepare the "Integration Test Cases" during this phase.

04.Module Design:
During this phase the system to be developed is divided into chunks or modules.We'll assign a developer for each module and explained the details of the modules. So, the developers can directly start the coding based on the expected functionality of the module.So, this phase can be called as low level design phase.
The low level design document or program specifications will contain a detailed functional logic of the module, in pseudocode - database tables, with all elements, including their type and size - all interface details with complete API references- all dependency issues- error message listings- complete input and outputs for a module.
We used to prepare "Unit Test Cases" during this phase.

So, based on V-Model we can conclude that the each Development Phase is having relationship with the Testing phase as mentioned below.

Requirement Analysis >> Acceptance Test Cases >> Acceptance Testing
System Design >>System Test Cases>>System Testing
Architecture Design >>Integration Test Cases >> Integration Testing
Module Design>>Unit Test Cases>>Unit Testing

Tuesday, 10 January 2012

Iterative model

Iterative model does not start with a full specification of requirements. Instead development begins by specifying and implementing just part of the software,which can be reviewed in order to meet the requirements. This process is repeated,which results in producing new version of the software for each cycle of the model. We have the following phases in Iterative Model.

Requirements: During this phase, the requirements of the software to be developed is gathered and analyzed.Iteration eventually result in this phase produce a complete and final requirement specifications.

Design: During this phase the architecture of the software to be developed is designed in order to reflect the the document produced during the requirement phase based on the iteration.

Implementation & Test: During this phase the software is coded, integrated and tested thoroughly.

Review phase: During this phase, the developed software is validated against the revised requirement specifications.

The key to successful use of an iterative software development life cycle is rigorous validation of requirements, and verification (including testing) of each version of the software against those requirements within each cycle of the model. The first three phases of the example iterative model is in fact an abbreviated form of a sequential V or waterfall life cycle model. Each cycle of the model produces software that requires testing at the unit level, for software integration, for system integration and for acceptance. As the software evolves through successive cycles, tests have to be repeated and extended to verify each version of the software.

Thursday, 5 January 2012

Waterfall Model

Waterfall model is the first process model to be introduced and widely followed in Software Engineering to ensure the success of the project. In this model, the software development is divided into phases. As the name suggests each phase is frozen before starting the next phase.

We have the following phases in Waterfall model.

Requirement Specification: The requirements of the system to be developed are captured in this phase. Requirements are nothing but the functionalities and constraints expected from the system to be developed. Requirements are gathered from the customer by consultation or some documents. Then the organization will analyze the validity and the possibility of the incorporation of the requirements with the system to be developed. Based on the analysis the “Requirement Specification” document will be prepared. The specification document will serve as a baseline to the next phase.

Design: This phase will take the Requirement Specification as input. Before starting the coding, it is very important to understand what we are going to create and what it should look like. The requirement specification will be studied and the system is designed based on the requirement document. Once the system is designed, the hardware will be identified. Once the system design and hardware are identified, we’ll create the complete system architecture. Creating System Architecture will freeze the design phase.

Implementation & Unit Testing: This will take the System Architecture as input which was developed during Design Phase. In this phase the system is divided into chunks/Units and the actual coding is started. The system is developed as small modules called Units, which will be integrated in next phase. Each unit is developed and tested for its functionality. We call this process as Unit Testing. Unit testing is done by the developer who is developing the corresponding Unit.  This phase is over once the individual Units are developed and tested.

Integration & System Testing: This phase will take the Units developed in “Implementation Phase” as input. During this phase each Units will be integrated with the other Units based on the system architecture. Once the Units are integrated we need to test that the functionalities of integrated Units as System. It means that we are checking, how the Units are functioning when integrated. This is called Integration Testing.  Once the integration is completed based on the system architecture we’ll call it as a “System”. Then we’ll start the system testing. During System testing, we’ll make sure that the developed system is meeting the customer requirements. The developed system will be delivered to the customers once the system testing is over.

Operations & Maintenance: This phase of Waterfall Model is virtually never ending process. Because sometimes issues are not captured during testing phase and will be captured when it’s deployed to the customer. So, we need to fix the issues and deploy it to the customer. This phase is called as Maintenance phase.

Advantages: The main advantage of the waterfall model is the departmentalization and managerial control. In this mode each phase is moved in a strict order without any overlapping or iterative steps.

Disadvantage: The main disadvantage of the model is that it doesn’t allow us to revise. Assume that the product is reached the Testing Phase and customer is requesting for a change. So, it’s very difficult to go back and do the change.  Because it’ll have impact on all phases.

Wednesday, 4 January 2012

Tips To Write Quality Test Cases

This article gives some basic ideas to write the complete test cases.
Before writing the test cases the tester should know the complete functionality of the module. Then only we can develop both positive and negative test cases.We can divide the test case relation as Test Scenario > Test Case > Test Steps.
Test Scenario: It comes directly from the requirements or user story. It represents the list of test cases and often their sequences.
Test Case: It consists of the list of test steps need to be performed. And may linked to environmental situations, link to bugs etc.
Test Step: It represents the action to be performed and the expected result from the application.
So, as a tester, we need to make sure that the quality test cases are in place to test against the application and deliver it with high quality.
I am trying to give some of the tips to write quality test cases here. 
01. We need have one complete template to create the test cases. We can have template in the form of excel spread sheet or some customized tool.
02. Test cases should be descriptive and specific. The title of the test case should be short , concise and   descriptive. Test case should clearly define the purpose and scope of the operations.
03.Test cases should be reusable in many situations.
04.We should create both positive and negative test cases. So, it’s important to remember the order of test  cases. Positive test cases should cover the expected behavior of the application. In turn negative test cases should cover the un expected behavior of the application. So,it is always better to keep the relationship between the positive and negative test cases.
05.Test cases should be atomic in nature. Assume that the test case is too long and doing too much of dependency checks. It’ll be a nightmare for a tester to all dependency check each and every time and also reducing the tester’s motivation and vigilance.
06.We need to refactor the test cases. It means that we need to re write or update the test cases whenever there is a change in functionality. It should be strictly followed by all testers to make sure that the test cases are always matching or covering all functionalities in the project.
07.As a tester, we should always have the test data for the complex as well as easy test cases. The test data should be attached in the form of binary data along with the test cases.
08. We need to make sure that all required configurations are in place before executing the test cases. We can have a list of checklist to make sure that the required configurations are in place.
09.It’s always better to have the review with the peers as well as product analyst. It’ll help in big time to make sure that we are not missing anything.

Monday, 2 January 2012

Advantages and Disadvantages Of Automation Testing

This article start with brief Introduction to Automated Testing, Different methods in Automated Testing, Benefits of Automated Testing and the guidelines that Automated testers must follow to get the benefits of automation.

Advantages of Automated Testing
"Automated Testing" is automating the manual testing process currently in use. This requires that a formalized "manual testing process", currently exists in the company or organization. 
Automation is the use of strategies, tools and artifacts that augment or reduce the need of manual or human involvement or interaction in unskilled, repetitive or redundant tasks.
Minimally, such a process includes:
·         Detailed test cases, including predictable "expected results", which have been developed from Business Functional Specifications and Design documentation
·         A standalone Test Environment, including a Test Database that is restorable to a known constant, such that the test cases are able to be repeated each time there are modifications made to the application.
The following types of testing can be automated
·         Functional - testing that operations perform as expected.
·         Regression - testing that the behavior of the system has not changed.
·         Exception or Negative - forcing error conditions in the system.
·         Stress - determining the absolute capacities of the application and operational infrastructure.
·         Performance - providing assurance that the performance of the system will be adequate for both batch runs and online transactions in relation to business projections and requirements.
·         Load - determining the points at which the capacity and performance of the system become degraded to the situation that hardware or software upgrades would be required.

Benefits of Automated Testing
Reliable: Tests perform precisely the same operations each time they are run, thereby eliminating human error
Repeatable: You can test how the software reacts under repeated execution of the same operations. 
Programmable: You can program sophisticated tests that bring out hidden information from the application.
Comprehensive: You can build a suite of tests that covers every feature in your application.
Reusable: You can reuse tests on different versions of an application, even if the user interface changes.
Better Quality Software: Because you can run more tests in less time with fewer resources
Fast: Automated Tools run tests significantly faster than human users.
Cost Reduction: As the number of resources for regression test are reduced.

Choosing the right tools for the job and targeting the right areas of the organization to deploy them can only realize these benefits. The right areas where the automation fit must be chosen.

The following areas must be automated first
1. Highly redundant tasks or scenarios
2. Repetitive tasks that are boring or tend to cause human error
3. Well-developed and well-understood use cases or scenarios first
4. Relatively stable areas of the application over volatile ones must be automated.

Automated testers must follow the following guidelines to get the benefits of automation:

Concise: As simple as possible and no simpler.
  Self-Checking: Test reports its own results; needs no human interpretation.
  Repeatable: Test can be run many times in a row without human intervention.
  Robust: Test produces same result now and forever. Tests are not affected by changes in the external environment.
  Sufficient: Tests verify all the requirements of the software being tested.
  Necessary: Everything in each test contributes to the specification of desired behavior.
  Clear: Every statement is easy to understand.
 Efficient: Tests run in a reasonable amount of time.
 Specific: Each test failure points to a specific piece of broken functionality; unit test failures provide "defect triangulation".
  Independent: Each test can be run by itself or in a suite with an arbitrary set of other tests in any order.
 Maintainable: Tests should be easy to understand and modify and extend.
  Traceable: To and from the code it tests and to and from the requirements.

Disadvantages of Automation Testing
Though the automation testing has many advantages, it has its own disadvantages too. Some of the disadvantages are:
 • Proficiency is required to write the automation test scripts.
• Debugging the test script is major issue. If any error is present in the test script, sometimes it may lead to deadly consequences.
• Test maintenance is costly in case of playback methods. Even though a minor change occurs in the GUI, the test script has to be rerecorded or replaced by a new test script.
• Maintenance of test data files is difficult, if the test script tests more screens.
Some of the above disadvantages often cause damage to the benefit gained from the automated scripts. Though the automation testing has pros and corns, it is adapted widely all over the world. 

Sunday, 1 January 2012

Top 10 Negative Test Cases

Negative test cases are designed to test the software in ways it was not intended to be used, and should be a part of your testing effort.  Below are the top 10 negative test cases you should consider when designing your test effort:
  1. Embedded Single Quote - Most SQL based database systems have issues when users store information that contain a single quote (e.g. John's car).  For each screen that accepts alphanumeric data entry, try entering text that contains one or more single quotes.

  1. Required Data Entry - Your functional specification should clearly indicate fields that require data entry on screens.  Test each field on the screen that has been indicated as being required to ensure it forces you to enter data in the field.

  1. Field Type Test - Your functional specification should clearly indicate fields that require specific data entry requirements (date fields, numeric fields, phone numbers, zip codes, etc).  Test each field on the screen that has been indicated as having special types to ensure it forces you to enter data in the correct format based on the field type (numeric fields should not allow alphabetic or special characters, date fields should require a valid date, etc).

  1. Field Size Test - Your functional specification should clearly indicate the number of characters you can enter into a field (for example, the first name must be 50 or less characters).  Write test cases to ensure that you can only enter the specified number of characters. Preventing the user from entering more characters than is allowed is more elegant than giving an error message after they have already entered too many characters.

  1. Numeric Bounds Test - For numeric fields, it is important to test for lower and upper bounds. For example, if you are calculating interest charged to an account, you would never have a negative interest amount applied to an account that earns interest, therefore, you should try testing it with a negative number.   Likewise, if your functional specification requires that a field be in a specific range (e.g. from 10 to 50), you should try entering 9 or 51, it should fail with a graceful message.

  1. Numeric Limits Test - Most database systems and programming languages allow numeric items to be identified as integers or long integers.  Normally, an integer has a range of -32,767 to 32,767 and long integers can range from -2,147,483,648 to 2,147,483,647.  For numeric data entry that do not have specified bounds limits, work with these limits to ensure that it does not get an numeric overflow error.

  1. Date Bounds Test - For date fields, it is important to test for lower and upper bounds. For example, if you are checking a birth date field, it is probably a good bet that the person's birth date is no older than 150 years ago.  Likewise, their birth date should not be a date in the future.

  1. Date Validity - For date fields, it is important to ensure that invalid dates are not allowed (04/31/2007 is an invalid date).  Your test cases should also check for leap years (every 4th and 400th year is a leap year).

  1. Web Session Testing - Many web applications rely on the browser session to keep track of the person logged in, settings for the application, etc.  Most screens in a web application are not designed to be launched without first logging in.   Create test cases to launch web pages within the application without first logging in.  The web application should ensure it has a valid logged in session before rendering pages within the application.

  1. Performance Changes - As you release new versions of your product, you should have a set of performance tests that you run that identify the speed of your screens (screens that list information, screens that add/update/delete data, etc).   Your test suite should include test cases that compare the prior release performance statistics to the current release.  This can aid in identifying potential performance problems that will be manifested with code changes to the current release.

Back To Top