P. 1
Software Development Life Cycle

Software Development Life Cycle


|Views: 1,509|Likes:
Published by muvvark

More info:

Published by: muvvark on Sep 08, 2010
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less






  • Software Testing - Black Box Testing Strategy
  • Software Testing - White Box Testing Strategy
  • Software Testing - Acceptance Testing
  • Software Testing - Stress Testing
  • Software Testing - An Introduction To Usability Testing
  • Software Testing - Compatibility Testing
  • Software Testing - Brief Introduction To Exploratory Testing
  • Waterfall Model in Testing
  • Software Verification & Validation Model - An Introduction
  • Spiral Model - A New Approach Towards Software Development
  • Rational Unified Process (RUP) Methodology
  • What is Rational Unified Process (RUP)
  • Quality Assurance Certification
  • Software Testing - Test Cases
  • Software Testing - Contents of a Bug
  • Software Testing - Bug Life Cycles
  • Software Testing - How To Log A Bug (Defect)
  • Software Testing Interview Questions
  • Types of Software Testing
  • Software Testing - Brief Introduction To Security Testing
  • Manual Testing Interview Questions
  • Traceability Matrix
  • Boundary Value Analysis
  • Suitability of agile methods
  • Agile methods and method tailoring
  • Measuring agility

Software Development Life Cycle (SDLC) is a procedural process, in the development of a software product.

The process is carried in a set of steps, which explains the whole idea about how to go through each product. The classification of
Software Development Life Cycle

process is as follows

1. 2. 3. 5.

4. 6.
7. 8.

Planning Analysis Design Software Development Implementation Software Testing Deployment Maintenance

Software Testing is an important factor in a product's life cycle, as the product will have greater life, only when it works correctly and efficiently according to the customer's requirements. Introduction to Software Testing Before moving further towards introduction to software testing, we need to know a few concepts that will simplify the definition of software testing.

• • • •

Error: Error or mistake is a human action that produces wrong or incorrect result. Defect (Bug, Fault): A flaw in the system or a product that can cause the component to fail or misfunction. Failure: It is the variance between the actual and expected result. Risk: Risk is a factor that could result in negativity or a chance of loss or damage.

Thus Software testing is the process of finding defects/bugs in the system, that occurs due to an error in the application, which could lead to failure of the resultant product and increase in probability of high risk. In short, software testing have different goals and objectives, which often include: 1. finding defects; 2. gaining confidence in and providing information about the level of quality; 3. preventing defects. If you are new to the field of software testing, then the article great Scope of Software Testing The primary function of software testing is to detect bugs in order to correct and uncover it. The scope of software testing includes execution of that code in various environment and also to examine the aspects of code - does the software do what it is supposed to do and
software testing for beginners

will be of help.

function according to the specifications? As we move further we come across some questions such as "When to start testing?" and "When to stop testing?" It is recommended to start testing from the initial stages of the software development. This not only helps in rectifying tremendous errors before the last stage, but also reduces the rework of finding the bugs in the initial stages every now and then. It also saves the cost of the defect required to find it. Software testing is an ongoing process, which is potentially endless but has to be stopped somewhere, due to the lack of time and budget. It is required to achieve maximum profit with good quality product, within the limitations of time and money. The tester has to follow some procedural way through which he can judge if he covered all the points required for testing or missed out any. To help testers to carry out these day-to-day activities, a baseline has to be set, which is done in the form of checklists. Read more on checklists for software tester. Software Testing Key Concepts


Defects and Failures: As we discussed earlier, defects are not caused only due to the coding errors, but most commonly due to the requirement gaps in the non-functional requirement, such as usability, testability, scalability, maintainability, performance and security. A failure is caused due to the deviation between an actual and an expected result. But not all defects result to failures. A defect can turn into a failure due to the change in the environment and or the change in the configuration of the system requirements. Input Combination and Preconditions: Testing all combination of inputs and initial state (preconditions), is not feasible. This means finding large number of infrequent defects is difficult. Static and Dynamic Analysis: Static testing does not require execution of the code for finding defects, whereas in dynamic testing, software code is executed to demonstrate the results of running tests. Verification and Validation: Software testing is done considering these two factors.   Verification: This verifies whether the product is done according to the specification? Validation: This checks whether the product meets the customer requirement?





Software Quality Assurance: Software testing is an important part of the software quality assurance. Quality assurance is an activity, which proves the suitability of the product by taking care of the quality of a product and ensuring that the customer requirements are met.

Software Testing Types: Software test type is a group of test activities that are aimed at testing a component or system focused on a specific test objective; a non-functional requirement such as usability, testability or reliability. Various types of software testing are used with the common objective of finding defects in that particular component. Software testing is classified according to two basic types of software testing: Manual Scripted Testing and Automated Testing. Manual Scripted Testing:

• Black Box Testing • White Box Testing • Gray Box Testing The levels of software testing life cycle includes : • • • • Unit Testing Integration Testing System Testing Acceptance Testing 1. Alpha Testing 2. Beta Testing

Other types of software testing are: • Functional Testing • Performance Testing 1. Load Testing 2. Stress Testing • Smoke Testing • Sanity Testing • Regression Testing • Recovery Testing • Usability Testing • Compatibility Testing • Configuaration Testing • Exploratory Testing For further explanation of these concepts, read more on
types of software testing.

Automated Testing: Manual testing is a time consuming process. Automation testing involves automating a manual process. Test automation is a process of writing a computer program in the form of scripts to do a testing which would otherwise need to be done manually. Some of the popular automation tools are Winrunner, Quick Test Professional (QTP), LoadRunner, SilkTest, Rational Robot, etc. Automation tools category also includes maintenance tool such as TestDirector and many other. Software Testing Methodologies The software testing methodologies or process includes various models that built the process of working for a particular product. These models are as follows: • • • • • • Waterfall Model V Model Spiral Model Rational Unified Process(RUP) Agile Model Rapid Application Development(RAD)
software testing methodologies.

These models are elaborated briefly in

Software Testing Artifacts Software testing process can produce various artifacts such as:

Test Plan: A test specification is called a test plan. A test plan is documented so that it can be used to verify and ensure that a product or system meets its design specification. Traceability matrix: This is a table that correlates or design documents to test documents. This verifies that the test results are correct and is also used to change tests when the source documents are changed. Test Case: Test cases and software testing strategies are used to check the functionality of individual component that is integrated to give the resultant product. These test cases are developed with the objective of judging the application for its capabilities or features. Test Data: When multiple sets of values or data are used to test the same functionality of a particular feature in the test case, the test values and changeable environmental components are collected in separate files and stored as test data. Test Scripts: The test script is the combination of a test case, test procedure and test data. Test Suite: Test suite is a collection of test cases.

• •

Software Testing Process Software testing process is carried out in the following sequence, in order to find faults in the software system: 1. 2. 3. 4. 5. 6. 7. 8. Here is a sample Test Case for you: # Software Test Case for Login Page: • Purpose: The user should be able to go to the Home page. • Pre-requisite: 1. S/w should be compatible with the Operating system. 2. Login page should appear. 3. User Id and Password textboxes should be available with appropriate labels. 4. Submit and Cancel buttons with appropriate captions should be available. Create Test Plan Design Test Case Write Test Case Review Test Case Execute Test Case Examine Test Results Perform Post-mortem Reviews Budget after Experience

• Test Data: Required list of variables and their values should be available.eg: User Id:{Valid UserId, Invalid UserId, empty}, Password:{Valid, Invalid, empty}. Test Sr.N Cas Test Case Name o e Id


Expected Results


Checking TC1. Interface requirements.

User views the page to check whether it includes UserId and User Password textboxes with Screen dispalys user appropriate labels. Also expects interface requirements that Submit and Cancel buttons according to the user. are available with appropriate captions


Textbox for UserId i)Error message is i)User types numbers into the should: displayed for numeric textbox. i)allow only alphadata. numeric characters{az, A-Z} TC2. ii)not allow special ii)Text is accepted when characters ii)User types alphanumeric data in user enters alphalike{'$','#','!','~','*',... the textbox. numeric data into the } textbox. iii)not allow numeric characters like{0-9} i)Error message is displayed when user i)User enters only two characters enters less than six Checking functionality in the password textbox. characters in the of the Password password textbox. textbox: i)Textbox for Password System accepts data ii)User enters more than six TC3. should accept more when user enters more characters in the password than six characters. than six characters into textbox. ii)Data should be the password textbox. displayed in encrypted System accepts data in ii)User checks whether his data is format. the encrypted format displayed in the encrypted else displays an error format. message. i)System i)User checks whether 'SUBMIT' 'SUBMIT' button is enabled or disabled. enabled displays button as




Checking functionality ii)System is redirected of 'SUBMIT' button. ii)User clicks on the 'SUBMIT' to the 'Home' page of button and expects to view the the application as soon 'Home' page of the application. as he clicks on the 'SUBMIT' button. displays button as clears the


TC5. Checking functionality i)System i)User checks whether 'CANCEL' of 'CANCEL' button. 'CANCEL' button is enabled or disabled. enabled. ii)User checks whether the ii)System

data available in the textboxes for UserId and UserId and Password Password are reset to blank by textbox when user clicks clicking on the 'CANCEL' button. on the 'CANCEL' button. Fault Finding Techniques in Software Testing Finding of a defect or fault in the earlier parts of the software not only saves time and money, but is also efficient in terms of security and profitability. As we move forward towards the different levels of the software, it becomes difficult and tedious to go back for finding the problems in the initial conditions of the components. The cost of finding the defect also increases. Thus it is recommended to start testing from the initial stages of the life cycle. There are various techniques involved alongwith the types of software testing. There is a procedure that is to be followed for finding a bug in the application. This procedure is combined into the life cycle of the bug in the form of contents of a bug, depending upon the severity and priority of that bug. This life cycle is named as the bug life cycles, which helps the tester in answering the question how to log a bug? Measuring Software Testing There arises a need of measuring the software, both, when the software is under development and after the system is ready for use. Though it is difficult to measure such an abstract constraint, it is essential to do so. The elements that are not able to be measured, needs to be controlled. There are some important uses of measuring the software: • Software metrics helps in avoiding pitfalls such as 1. cost overruns, 2. in identifying where the problem has raised, 3. clarifying goals. • It answers questions such as: 1. What is the estimation of each process activity?, 2. How is the quality of the code that has been developed?, 3. How can the under developed code be improved?, etc. • It helps in judging the quality of the software, cost and effort estimation, collection of data, productivity and performance evaluation. Some of the common software metrics are: • • • • • • • • Code Coverage Cyclomatic complexity Cohesion Coupling Function Point Analysis Execution time Source lines of code Bug per lines of code

methodologies and different software testing strategies. there should be some source of getting back to the older versions easily and working on them efficiently. but also prove to be beneficial for his academic performance. You can read more on how to become a video game tester . Testers play a vital role in this. controlling and improvement of the software system. you can actually get paid to test video games. varying user requirements. Video game testing is an offshoot of software testing. measurement of a software is for understanding.Certified Test Manager CSPM. Software Testing as a Career Software testing is a good career opportunity for those who are interested in the software industry. Software is subject to changes. Software Testing Certifications Software testing certifications will not only boost up ones knowledge.In short. Here is where change management comes into picture. This gives rise to the development of newer and updated versions of software. I consider that this article on software testing tutorial must have given you a clearer idea on various software testing types. changing environmental conditions.Certified Software Quality Engineer CQIA. .Certified Quality Improvement Associate Software testing is indeed a vast field and accurate knowledge is crucial to ensure the quality of the software developed. you might like to go through this extensive list of software testing interview questions. as well as configuration and compatibility issues. with respect to.Certified Software Quality Analyst Software Quality Assurance Certification CSQE. But.Certified Software Tester CSTP. If you are planning to choose the software testing industry as your career ground.Certified Software Test Professional CTM. • • • • • • • ISTQB. Believe it or not.Certified Software Project Manager CSPE. There are some software testing certification programs that can support the professional aspirations of software testers and quality assurance specialists.Certified Software Process Engineer CAST. Before you step out for a job in the testing field or before you take your first step towards becoming a software tester. There are many industries specializing in this field. Software Testing Interview Questions I hope this article has helped you gain a deeper insight into software testing.International Software Testing Qualifications Board CSTE.Certified Associate in Software Testing Quality Assurance Certifications: • • • • CSQA. you can acquire these software testing certifications.

The basic motive is to plan the total project and to estimate the merits and demerits of the project. Planning This is the first and foremost stage in the development and one of the most important stages. Based on the analysis of the project and due to the influence of the results of the planning phase. Analysis The main aim of the analysis phase is to perform statistics and requirements gathering. Once the requirements for the project are gathered.Software Development Life Cycle What is Software Development Life Cycle? The Software Development Life Cycle is a step-by-step process involved in the development of a software product. The Planning phase includes the definition of the intended system. the requirements for the project are decided and gathered. and Parallel management of the plan throughout the proceedings of the development. development of the project plan. The description of each of the steps can give a better understanding. Classification The basic classification of the whole process is as follows • • • • • • • • Planning Analysis Design Development Implementation Testing Deployment Maintenance Each of the steps of the process has its own importance and plays a significant part in the product development. they are prioritized and made ready for . A good and matured plan can create a very good initiative and can positively affect the complete project. It is also denoted as Software Development process in certain parts of the world. The whole process is generally classified into a set of steps and a specific operation will be carried out in each of the steps.

Testing The testing phase is one of the final stages of the development process and this is the phase where the final adjustments are made before presenting the completely developed software to the end-user. One of the main scenarios is the implementation of the prototype model into a full-fledged working environment. both technical and design. can be found and removed and the entire process can be redesigned. In general. it means that the software is ready to be provided to the user. Development and Implementation The development and implementation phase is the most important phase since it is the phase where the main part of the project is done. The information desk is also provided with in this phase. Proceedings after the current phase are defined. Maintenance The toughest job is encountered in the maintenance phase which normally accounts for the highest amount of money. The basic works include the design of the basic technical architecture and the maintenance of the database records and programs related to the development process. The maintenance team is decided such that they monitor on the change in organization of the software and report to the developers. This serves to maintain the relationship between the user and the creator. The test conditions which are decided in the analysis phase are applied to the system and if the output obtained is equal to the intended output. in case a need arises. which is the final product or software. the design phase begins. Most of the developers have the habit of developing a prototype of the entire software and represent the software as a miniature model. The flaws. The aim is to create the architecture of the total system. This is one of the important stages of the process and serves to be a benchmark stage since the errors performed until this stage and during this stage can be cleared here. Design Once the analysis is over.further use. . The decisions taken in the analysis phase are out and out due to the requirements analysis. the testers encounter the problem of removing the logical errors and bugs.


If you are using a test reporting tool.Check Lists For Software Tester I would like to make a note that the following checklists are defined in most generic form and do not promise to cover all processes that you are be required to go through and follow during your work. but you may come across practices where you will be assigned script based on your work load for the day or your skill to understand and execute it in least possible time. Check if you have executed all the scripts properly and updated the test reporting tool. it also addresses issues related to understanding of functionality of the system for example: if a tester registered a defect. a comment from developer might help in understanding the mistake committed by the tester. if it is required to be updated after you execute the script in the reporting tool. There may be some processes which are completely missed out from the lists or it may also contain processes which you don’t need to follow in your form of work. severity etc. For example Test Director needs script to be executed till the step where it the test script failed. it’s status. There is no specific logic used to assign scripts to testers who should execute them all. do not forget to execute the script in the tool. Use naming conventions defined as testing standards to define a bug appropriately. If your team is maintaining any type of tracking sheet. time and date found. Many test reporting tools require scripts to be executed in order to initiate the life cycle of a bug.Software Testing . Then in that case. Check the status/comments of the defect in the Test Report Tool: Once you unveil a bug. which is not an actual bug as per the programming/business logic. general practice is to confirm if any fix to a bug is successful as it also makes it sure that the tester can proceed with other tests involving deeper side of that particular functionality. functionality. try to explain the procedure you followed. its very important to keep track of the status of it as you will have to re-test the bug once it is fixed by a developer. Sometimes. The screen prints will help other testers and developers to understand how the test was executed and it will also serve as a proof for you. do not forget to update all the tracking sheets for the bug. • • • • . Update the tracking sheets with current status. test code etc. other test steps before failed test step are declared as passed. • Checks while executing scrips: • • • Update the test data sheet with all values which are required such as user name. Take screen prints for the script executed using naming conventions and provide test data that you used for the testing. If possible. status in reporting tools etc. First Things First • Check the scripts assigned to you: This is the first and foremost process in the list. Most of the times. choice of data and your understanding etc.

Follow the appropriate naming conventions while logging defects. For example if there is a bug on login screen.• After you complete your days work. After submitting defects attach the screen prints for the defect on Test Reporting Tool. Note down the defect number/unique identifier and update the test tracking sheet with appropriate information. defect tracking sheet. which is blocking the execution of the script or testing of the defect. screen prints dump folder etc. confirm with your test lead if the defect is valid. for a backup. Block scripts with an New/Assigned/Fixed/Reopen) active defect (Defect status: Update the current script/defect in test reporting tool and tracking sheets with the defect number/unique identifier. Maintain a defect log. it is better to do a peer to peer review. This step is very important and often helps in finding out missing steps/processes. Checks for blocking and unblocking scripts Blocking or unblocking of a script relates to a bug which affects execution of a script. Give appropriate description and names in the defect screen prints as per naming conventions. get it reviewed by Work Lead/Team Lead. then unblock all scripts/defects blocked by it. • At the end of day. If a defect is retested successfully. send an update mail to your Team Lead/Work Lead which should include the following: • • • • Scripts executed (Number) Defects raised/closed (Number) If any comments added on defects Issues/queries if any . which is not allowing anyone enter the account after entering valid username and password and pressing OK button. Before submitting the defect. there is no way you can execute any test script which requires the account screen that comes after the login screen. • • • Confirm with your test lead/work lead if the scripts are really blocked due to an existing bug. Checks while logging defects • • • • • • • First of all.

stress testing. should know. Testing method where user is not required: Functional Testing: In this type of testing. recovery testing. ad-hoc testing. These testing types are again divided in two groups: a) Testing in which user plays a role of tester and b) User is not required. which does not need any knowledge of internal design or code etc. alpha testing. Sanity or Smoke testing. Load Testing: The application is tested against heavy loads or inputs such as testing of web sites in order to find out at what point the web-site/application fails or at what point its performance degrades.Black Box Testing Strategy What is a Black Box Testing Strategy? Black Box Testing is not a type of testing. the software is tested for the functional requirements. volume testing. Exploratory testing. As the name "black box" suggests. which checks for the stress/load the applications can withstand. The tests are written in order to check if the application behaves as expected. large number of inputs. The types of testing under this strategy are totally based/focused on the testing for requirements and functionality of the work product/software application. large number of queries etc. Usability testing. it instead is a testing strategy. Black box testing is sometimes also called as "Opaque Testing". how the system should behave in response to the particular action. In order to implement Black Box Testing Strategy. User Acceptance Testing (also known as UAT). system testing. "Functional/Behavioral Testing" and "Closed Box Testing". the tester is needed to be thorough with the requirement specifications of the system and as a user. which makes it unfit to test the application by the developer. Stress Testing: The application is tested against heavy load such as complex numerical values. no knowledge of internal logic or code structure is required.Software Testing . it is becoming common to route the Testing work to a third party as the developer of the system knows too much of the internal logic and coding of the system. beta testing etc. load testing. Various testing types that fall under the Black Box Testing strategy are: functional testing. Now a days. . The base of the Black box testing strategy lies in the selection of appropriate data as per functionality and testing it against the functional specifications in order to check for normal and abnormal behavior of the system.

Ad-hoc Testing: This type of testing is done without any formal Test Plan or Test Case creation. Alpha Testing: In this type of testing. Smoke Testing: This type of testing is also called sanity testing and is done in order to check if the application is ready for further major testing and is working properly without failing up to least expected level. Huge amount of data is processed through the application (which is being tested) in order to check the extreme limitations of the system. Recovery Testing: Recovery testing is basically done in order to check how fast and better the application can recover against any type of crash or hardware failure etc. . Type or extent of recovery is specified in the requirement specifications. Testing where user plays a role/user is required: User Acceptance Testing: In this type of testing. the software is handed over to the user in order to find out if the software meets the user expectations and works as it is expected to. Usability Testing: This testing is also called as ‘Testing for User-Friendliness’. Volume Testing: Volume testing is done against the efficiency of the application. This testing is done if User Interface of the application stands an important consideration and needs to be specific for the specific type of user. Any type of abnormal behavior of the system is noted and rectified by the developers. the users are invited at the development center where they use the application and the developers note every particular input or action carried out by the user. Exploratory Testing: This testing is similar to the ad-hoc testing and is done in order to learn/explore the application. Ad-hoc testing helps in deciding the scope and duration of the various other testing and it also helps testers in learning the application prior starting with any other testing.

. in case if any exception/defect occurs that is reported to the developers.Beta Testing: In this type of testing. the software is distributed as a beta version to the users and users test the application at their sites. As the users explore the software.

paths. ii) And it is nearly impossible to look into every bit of code to find out hidden errors. Types of testing under White/Glass Box Testing Strategy: Unit Testing: The developer carries out unit testing in order to check if the particular module or unit of code is working fine. a skilled tester is needed to carry out this type of testing. Advantages of White box testing are: i) As the knowledge of internal coding structure is prerequisite. which can bring in hidden defects. The Unit Testing comes at the very basic level as it is carried out as and when the unit of the code is developed or a particular functionality is built. Static and dynamic Analysis: Static analysis involves going through the code in order to find out any possible defect in the code. Dynamic analysis involves executing the code and analyzing the output. the tester has to deal with the code and hence is needed to possess knowledge of coding and logic i. Statement Coverage: .e. it becomes very easy to find out which type of input/data can help in testing the application effectively. In order to implement white box testing. internal working of the code.Software Testing . White box testing is also called as glass. Disadvantages of white box testing are: i) As knowledge of code and internal structure is a prerequisite. branches. ii) The other advantage of white box testing is that it helps in optimizing the code iii) It helps in removing the extra lines of code. open box or clear box testing. resulting in failure of the application. White box test also needs the tester to look into the code and find out which unit/statement/chunk of the code is malfunctioning. The tests written based on the white box testing strategy incorporate coverage of the code written. which may create problems. structural. statements and internal logic of the code etc. which increases the cost.White Box Testing Strategy What is a White Box Testing Strategy? White box testing strategy deals with the internal logic and structure of the code.

. It also helps in finding out which code and which strategy of coding can help in developing the functionality effectively. any code damage etc. Branch Coverage: No software application can be written in a continuous mode of coding. This type of testing needs sophisticated testing techniques. Branch coverage testing helps in validating of all the branches in the code and making sure that no branching leads to abnormal behavior of the application. Besides all the testing types given above. which deals with the code of application. the application is tested for the code that was modified after fixing a particular bug/defect.) etc. Security Testing: Security Testing is carried out in order to find out how well the system can protect itself from unauthorized access.In this type of testing the code is executed in such a manner that every statement of the application is executed at least once. Performance and Load testing (which helps in finding out how the particular code manages resources and give performance etc. at some point we need to branch out the code in order to perform a particular functionality. hacking – cracking. Incremental integration testing (which deals with the testing of newly added code in the application). there are some more types which fall under both Black box and White box testing strategies such as: Functional testing (which deals with the code in order to check its functional performance). Mutation Testing: A kind of testing in which. It helps in assuring that all the statements execute without any side effect.

Acceptance testing is also known as validation testing. 2.Software Testing . different weather conditions etc. Test cases are created with the help of business analysts. field acceptance testing or end-user testing). developers.). one at the system provider level and another at the end user level (hence called user acceptance testing.Acceptance Testing Acceptance testing (also known as user acceptance testing) is a type of testing carried out in order to verify if the product is developed as per the standards and specified criteria and meets all the requirements specified by customer. The outcome of the acceptance testing can be termed as success or failure based on the critical operating conditions the system passes through successfully/unsuccessfully and the user’s final evaluation of the system. Acceptance testing in software engineering generally involves execution of number test cases which constitute to a particular functionality based on the requirements specified by the user. the system has to pass through or operate in a computing environment that imitates the actual operating environment existing with user. developers. specialized testers. User acceptance testing is considered to be one of the most important testing by user before the system is finally delivered or handed over to the end user. business customers (end users). but evaluates the overall functioning of the system and compares it with the requirements specified by them. final testing. . Process involved in Acceptance Testing 1. 3. The user may choose to perform the testing in an iterative manner or in the form of a set of varying parameters (for example: missile guidance software can be tested under varying payload. test specialists etc. acceptance testing may be carried out at two different levels. The outputs of the test cases run are evaluated against the criterion/requirements specified by user. This type of testing is generally carried out by a user/customer where the product is developed externally by another party. During acceptance testing. end users etc. QA testing. The test cases and test criterion in acceptance testing are generally created by end user and cannot be achieved without business scenario criteria input by user. This type of testing and test case creation involves most experienced people from both sides (developers and users) like business analysts. Test cases suites are run against the input data provided by the user and for the number of iterations that the customer sets as base/minimum required test runs. And in software engineering. factory acceptance testing and application testing etc. Acceptance testing falls under black box testing methodology where the user is not very much interested in internal working/coding of the system.

4. user acceptance testing is a process of testing the system before it is finally accepted by user. Contact and Regulation Acceptance Testing: In contract and regulation acceptance testing. Acceptance testing is done in order to demonstrate the ability of system/product to perform as per the expectations of the user and induce confidence in the newly developed system/product. . Feedback from users is used to improve the system/product before it is released to other users/customers. In this type of testing. Alpha Testing & Beta Testing: Alpha testing is a type of acceptance testing carried out at developer’s site by users (internal staff). A sign-off on contract stating the system as satisfactory is possible only after successful acceptance testing. user may call it successful/unsuccessful or suggest some more test case runs. 5. the user goes on testing the system and the outcome is noted and observed by the developer simultaneously. Types of Acceptance Testing User Acceptance Testing: User acceptance testing in software engineering is considered to be an essential step before the system is finally accepted by the end user. the system is tested against the specified criteria as mentioned in the contract document and also tested to check if it meets/obeys all the government and local authority regulations and laws and also all the basic standards. Depending upon the outcome if it is as desired by the user or consistent over the number of test suites run or non conclusive. In general terms. Based on the outcome of the test runs. Beta testing is a type of testing done at user’s site. The users provide their feedback to the developer for the outcome of testing. Operational Acceptance Testing: This type of testing is also known as operational readiness/preparedness testing. the system may get rejected or accepted by the user with or without any specific condition. It is a process of ensuring all the required components (processes and procedures) of the system are in place in order to allow user/tester to use it. This type of testing is also known as field testing.

Stress Testing Stress testing has different meaning for different industries where it is used. effectively manages the load than the normal scenario and even shows effective error management under extreme conditions. Almost 90% of the software/systems are developed with an assumption that they will be operating under normal scenario. when the limit of normal operation is crossed. working under maximum requests for resource utilization of the peripheral or in the system etc. etc. heavy processes load. Need for Stress Testing Stress testing is considered to be important because of following reasons: 1. stress testing means a process of testing financial instruments to find out their robustness and level of accuracy they can maintain under extreme conditions such as sudden or continuous market crash at a certain level. is always available to perform its task. It is always better to be prepared for extreme conditions rather than letting the system/software/website crash. For medical industry. under or over clocking of underlying hardware. Stress testing in connection with websites or certain software is considered to be an effective process of determining the limit. stress testing helps find out the level of robustness and consistent or satisfactory performance even when the limits for normal operation for the system (software/hardware) is crossed. sudden or extreme change in various parameters. For a financial industry/sector. stress testing means a process that can help understand a patient’s condition. For the manufacturing industry. at which the system/software/hardware/website shows robustness. for example interest rates. Most important use of stress testing is found in testing of software and hardware that are supposed to be operating in critical or real time situation. . it is not considerably as high as it really could be.Software Testing . sudden rise or decline in the price of materials that can affect financial projections etc. And even if it is considered that the limit of normal operating conditions will be crossed. stress testing may include different parameters and operating process for testing of different systems. a mission critical software or hardware that works in real time scenario etc. 3. 2. repo and reverse repo used in the financial sector. In other words. Stress Testing in IT Industry Stress testing in IT industry (hardware as well as software sectors) means testing of software/hardware for its effectiveness in giving consistent or satisfactory performance under extreme and unfavorable conditions such as heavy network traffic. The cost or effect of a very important (critical) software/system/website failure under extreme conditions in real time can be huge (or may be catastrophic for the organization or entity owning the software/system). Such as a website will always be online and the server hosting the website must be able to handle the traffic in all possible ways (even if the traffic increases manifold).

It's not always possible to unveil possible problems or bugs in a system/software. creation and increasing degree of adverse environment) on a system/software/website and capturing values of various parameters that help confirm the robustness. The collected data (observation and parameter values) are used for further improvement of the system/software/website.. hacking and viruses etc. race condition etc. To help overcome problems like denial of service attacks. Testing carried out by the developer of the system/software/website may not be sufficient to help unveil conditions which will lead to crash of the system/software when it is actually submitted to the operating environment.4. These tools are configured to automate a process of increasing stress (i. 5. security breach related problems due to spamming. . This type of testing is mostly done with the help of various stress testing softwares available in market. running of many resource hungry applications in a computer. memory leak. unless it is subjected to such type of testing. Few of the actions involved in stress testing are bombarding a website with huge number of requests. availability and performance of the system/software/website being tested. problems arising out of conditions where software/system/website need to handle requests for resource allocation for requesting processes at the time when all the required resources are already allocated to some other process that needs some more resources to complete its work (which is called as deadlock situation). in case of web servers for a web site. Intensity of the adverse conditions is increased slowly while measuring all the parameters till the point where the system/software/website crashes. making numerous attempts to access ports of a computer in order to hack it and use it for various purposes such as spamming.e. spreading virus etc.

Any changes suggested by the tester at the time of usability testing. as mentioned above is an in-house dummy release before the actual release of the system to the intended/end user. system integration testing. usability testing is an in-house dummy-release of the system before the actual release to the end users. unit testing etc. Hence. where developer can find and fix all possible loop holes. Usability testing means a way to measure how people (intended/end user) find it (easy. In simple words.An Introduction To Usability Testing Usability Testing: As the term suggest. It is a standard statement that "Usability testing measures the usability of the system". in this endeavor he may have forgotten some error prone conditions which are uncovered only when the end user is using the system in real time. usability means how better something can be used over the purpose it has been created for. The testers try to use the system in exactly the same manner that any end user can/will do. are the most crucial points that can change the stand of the system in intended/end user’s view.Software Testing . all the standard instruction of testing are followed to make it sure that the testing is done in all the directions such as functional testing. Developer/designer of the system need to incorporate the feedbacks (here feedback can be a very simple change in look and feel or any complex change in the logic and functionality of the system) of usability testing into the design and developed code of the system (the word system may be a single object or an entire package consisting more than one objects) in order to make system more and more presentable to the intended/end user. Why Do We Need Usability Testing? Usability testing is carried out in order to find out if there is any change needs to be carried out in the developed system (may it be design or any specific procedural or programmatic change) in order to make it more and more user friendly so that the intended/end user who is ultimately going to buy and use it receives the system which he can understand and use it with utmost ease. . Developer often try to make the system as good looking as possible and also tries to fit the required functionality. Usability testing helps developer in studying the practical situations where the system will be used in real time. moderate or hard) to interact with and use the system keeping its purpose in mind. in this type of testing also. Please note that. Developer also gets to know the areas that are error prone and the area of improvement. How Usability Test Is Carried Out? Usability test. a setup is required in which developer and testers try to replicate situations as realistic as possible to project the real time usage of the system.

ability to listen to the suggestions. .The outcome/feedback is noted down based on observations of how the user is using the system and what are all the possible ways that also may come into picture. Usability testing measures various aspects such as: How much time the tester/user and system took to complete basic flow? How much time people take to understand the system (per object) and how many mistakes they make while performing any process/flow of operation? How fast the user becomes familiar with the system and how fast he/she can recall the system’s functions? And the most important: how people feel when they are using the system? Over the time period. • • • Usability testing is a very wide area of testing and it needs fairly high level of understanding of this field along with creative mind. (with keeping the main objective of usability testing in mind) in order to make it sure that testing is done in all the possible directions. Usability testing can help in uncovering potential bugs and potholes in the system which generally are not visible to developers and even escape the other type of testing. This may result in better performance and a standard system. openness to welcome any idea. Usability testing can be very economical if planned properly. Any of the models can be used to perform the test. yet highly effective and beneficial. People involved in the usability testing are required to possess skills like patience. Advantages of Usability Testing • Usability test can be modified to cover many other types of testing such as functional testing. smoke testing etc. If proper resources (experienced and creative testers) are used. and the most important of them all is that they should have good observation skills to spot and fix the problems on fly. User is also asked for his/her feedback based on what he/she thinks should be changed to improve the user interaction between the system and the end user. unit testing. many people have formulated various measures and models for performing usability testing. usability test can help in fixing all the problems that user may face even before the system is finally released to the user. and also based on the behavior of the system and how easy/hard it is for the user to operate/use the system. system integration testing.

(usually browser compatibility testing is also looked at as a user experience testing. Browser: Evaluation of the performance of system/website/application on a certain type of browser. network. motherboards etc. other systems/applications. Compatibility of a system/application being developed with. operating systems etc. Developers generally lookout for the evaluation of following elements in a computing environment (environment in which the newly developed system/application is tested and which has similar configuration as the actual environment in which the system/application is supposed to fit and start working). For example: A website is tested for compatibility with browsers like Internet Explorer. demand of the system/application etc. . hardware platforms. Hardware: Evaluation of the performance of system/application/website on a certain hardware platform. This leads to a situation where the development efforts taken by developers prove to be in vain. hardware or OS they are already using. while using it on different browsers). network. For example: If an all-platform compatible game is developed and is being tested for hardware compatibility. users prefer not to opt for an application/system just because it is not compatible with any other system/application.Compatibility Testing Compatibility testing is a non-functional software testing that helps evaluate a system/application's performance in connection with the operating environment.Software Testing . operating system and other software etc. Compatibility testing can be automated using automation tools or can be performed manually and is a part of non-functional software testing. Read on to know more about compatibility testing. users (in case if its very specific type of requirement. What is Compatibility Testing Compatibility testing is a type of testing used to ensure compatibility of the system/application/website built with various other objects such as other web browsers. Many a times. as it is related to user’s experience of the application/website. the developer may choose to test it for various combinations of chipsets (such as Intel. Compatibility testing is one of the several types of software testing performed on a system that is built based on certain criteria and which has to perform specific functionality in an already existing setup/environment. decide many things such as use of the system/application in that environment. for example. This type of testing helps find out how well a system performs in a particular environment that includes hardware. OS. such as a user who speaks and can read only a particular language). Firefox etc. Network. Macintosh GForce).

Operating System: Evaluation of the performance of system/application in connection with the underlying operating system on which it will be used. web servers. . which is set up to replicate the actual operating environment. Database compatibility testing is used to evaluate an application/system’s performance in connection to the database it will interact with. For example: printers. Peripherals: Evaluation of the performance of system/application in connection with various systems/peripheral devices connected directly or via network. fax machines. telephone lines etc. This helps in figuring out necessary changes/modifications/additions required to make the system/application compatible with the computing environment. It also helps the users to find out which system will better fit in the existing setup they are using. The most important use of the compatibility testing is as already mentioned above: to ensure its performance in a computing environment in which it is supposed to operate. For example: Windows 98 was developed with backward compatibility for Windows 95 etc.Network: Evaluation of the performance of system/application/website on network with varying parameters such as bandwidth. How helpful is it? Compatibility testing can help developers understand the criteria that their system/application needs to attain and fulfill. software and hardware etc. in order to get accepted by intended users who are already using some OS.. Softwares: Evaluation of the performance of system/application in connection with other softwares. network. Compatibility between versions: Evaluation of the performance of system/application in connection with its own predecessor/successor versions (backward and forward compatibility). For example: Software compatibility with operating tools for network. Databases: Many applications/systems operate on databases. variance in capacity and operating speed of underlying hardware etc. messaging tools etc.

even though disliked by many. and also think out of the box and attain more and more creativity. Why do we need exploratory testing? • • At times. Exploratory Testing is a learn and work type of testing activity where a tester can at least learn more and understand the software if at all he/she was not able to reveal any potential bug. A tester who does exploratory testing. as a general practice. does it only with an idea to more and more understand the software and appreciate its features. • • Who Does Exploratory Testing? Any software tester knowingly or unknowingly does it! While testing. test strategies. has found its place in the Software Testing world. helps testers in learning new methods. but he/she does the testing more with a point-of-view to explore the software features and tries to break it in order to find out unknown bugs. Along with registering the bug.Software Testing . it helps in improving our productivity in terms of covering the scenarios in scripted testing and those which are not scripted as well. During this process. he/she also tries to think of all possible scenarios where the software may fail and a bug can be revealed.Brief Introduction To Exploratory Testing Exploratory Software Testing. even though disliked by many. if a tester comes across a bug. Exploratory testing is the only type of testing that can help in uncovering bugs that stand more chance of being ignored by other testing strategies. exploratory testing helps in revealing many unknown and un-detected bugs. Exploratory testing is a type of testing where tester does not have specifically planned test cases. What is an Exploratory Testing? Bach’s Definition: ‘Any testing to the extent that the tester actively controls the design of the tests as those tests are performed and uses information gained while testing to design new and better tests.’ Which simply can be put as: A type of testing where we explore software. write and execute the test scripts simultaneously. which is very hard to find out through normal testing. tester registers that bug with the programmer. As exploratory testing covers almost all the normal type of testing. Exploratory testing. tester also tries to make it sure that he/she has understood the scenario and functionality properly and can reproduce the bug .

tester runs a test case with the same scenario replication in which the bug had occurred previously. It helps in collecting result oriented test scripts and shading of load of unnecessary test cases which do not yield and result. lets consider that a tester finds a bug related to an input text field on a form. Exploratory testing covers almost all type of testing. The only limit to the extent to which you can perform exploratory testing is your imagination and creativity. or may be some characters or a combination of character and numbers in any order. where the field is supposed to accept any digit other than the digits from 1 to 100. which are normally ignored (or hard to find) by other testing strategies. If tester finds that the bug is fixed. Exploratory testing helps tester in confirming that he/she understands the application and its functionality properly and has no confusion about the working of even a smallest part of it. tester tries to check if there is any other value from this set (0 to 100). All these test cases are thought by the tester as a variation of the type of value he/she had entered previously and represent only one test scenario. Advantages of Exploratory Testing • • Exploratory testing can uncover bugs. Once programmer fixes the bug. understand the software.e. He/she may try to enter values from 0 to 100.condition. It helps testers in learning new strategies. if the exploratory testing performed can ensure that all the possible scenarios and test cases are covered). which can cause the application to fail. he/she can safely close the defect. he/she again tries to find out if the fix can handle any such same type of scenario with different inputs. Tester now will try to test the bug with same input value (100: as he/she had found that this condition causes application to fail) in the field. For an example. along with the above given test input value. expand the horizon of their imagination that helps them in understanding & executing more and more test cases and finally improve their productivity. As in case of exploratory testing. we write and execute the test cases simultaneously. What qualities I need to posses to be able to perform an Exploratory Testing? As I mentioned above. more test cases you will be able write and execute simultaneously. any software tester can perform exploratory testing. more you can think of ways to explore. Tester logs this bug to the programmer and now is waiting for the fix. Now. hence tester can be sure of covering various scenarios once exploratory testing is performed at the highest level (i. If application rejects the number (100) entered by the tester. This testing is called exploratory testing. Once programmer fixes the bug. which it fails to and accepts the number 100. it sends it across to the tester so as to get it tested. • • • . which had revealed the bug. as the tester tried to explore and find out the possibility of revealing a bug by using any possible way. hence covering the most important part of requirement understanding.

and is working glitch free. The waterfall model in testing is one such testing procedure that has gained immense popularity over the years. The development of software is a long and arduous process. Waterfall Model Life-cycle A lot of research and development is enforced during the various growth stages of any particular software. Waterfall model in testing envelopes the use of a design concept that is also known as System Developing Life Cycle (SDLC) Model. The various waterfall model phases are as follows. right from the initial idea conception to the final usage. and without proper testing and checking. and does not get too far ahead too soon. owing to its simple understandability and elementary design. The idea of generating a standardized model of testing (like the waterfall model in testing) is to ensure that a software engineer follows the correct sequence of process development. and these define the many stages of developing a software. it cannot be sold anywhere. or the Linear Sequential Model. and each stage of the waterfall model is required to follow a standard protocol.Waterfall Model in Testing The waterfall model in testing is one of the most widely used and popular process module for developing and designing software programs to meet specific customer needs. Each line of the program needs to be checked and double checked. The process of software development is known as 'Software Development Process Models'. Every piece of software that is released needs to undergo a rigorous and extreme testing procedure before it can be released for general use. . waterfall model in software engineering defines the various stages that a software developer must undertake in order to ensure that the software is meeting customer requirements. The linear sequential properties of the model make it a universally accepted software development process model. Thus.

before the development process actually begins. so therefore all his needs and requirements need to be known in detail. and what kind of databases are necessary for the development process.The waterfall model diagram shown above illustrates the various stages of this process. The purpose of the model and a basic specifications and requirements chart is made after careful consultation with the user. Designing and Coding This is where the real work begins. A projected blueprint of sorts is created of the software. A feasibility study is then carried out to ensure that all resources are available and the actual programming of the software is possible. Requirements Analysis Next up. Requirements Gathering The first and most obvious step in software development is the gathering of all requirements of the customer. which computer language. and the developer takes a decision regarding which platform. and this is incorporated into the development process. and the algorithms and the flowcharts of the software are . these requirements are studied and analyzed closely. The primary purpose of the final program is to serve the user. Waterfall model in testing begins primarily with the gathering of all pertinent and necessary data from the customer.

Waterfall model in testing can only be done by dividing up the coded program into various manageable parts. if he is dissatisfied with certain aspects of the software. the software is reverted to the designing stage and all the deficiencies are fixed. the design of the program would be impossible. they are integrated into the final system and then this system is tested to ensure proper integration and compatibility between the various units. and the use of the waterfall model in testing would be impossible without something to actually test. Advantages of Waterfall Model in Testing The primary advantage is that it is a linear model. the design team proceeds to solve this problem.devised. Without testing the functionality of the code. the process is completed. Also. This stage defines the actual transition of the program from a mere hypothesis to a real usable software. The designing process is divided into smaller parts known as units. On the other hand. Final Acceptance Once the design has been tried and tested by the testing team. This is the most important stage of the model. Testing Now comes the litmus test of the code developed. since . This is a crucial factor in determining the model's effectiveness and suitability. and there are no loose ends anywhere in the code developed. use of waterfall model in testing also ensures that all the requirements of the customer are satisfactorily met. the actual coding of the program commences. Waterfall model in testing ensures that a high degree of professionalism is met within the development process. the customers are given a demo version of the final program. If they accept that the software is satisfactory and as per their demands and requirements. and unit testing needs to be carried out for each of these divisions individually. the importance of the testing phase in waterfall model is universally known and undoubted. all the possible bugs cannot be detected. If any flaws or bugs are detected. Now they must use the program and indicate whether they are satisfied with the product or not. It goes without saying that the final design has to meet all the necessary requirements of the customer. Moreover. Based on the data collected and the feasibility study carried out. Once the units are declared to be flaw free. and follows a proper sequence and order. and are specifically trained to carry out their responsibility. or feels that an integral component is missing. Without the information gathered in the previous two stages. The benefits of dividing the work into these various stages is that everyone knows what they are doing. Thus. and that all the parties involved in this development process are specialists in their respective fields.

it is easy to track down mistakes. if the customer is ambiguous about his needs. they could find out whether it is suitable or not. . Since they do not receive the program till it is almost completed. Customers often have a complaint that if they could get a sample of the software in the early stages. The cost of resources at each stage get minimized due to the linear sequencing as well. This factor is further highlighted by the fact that if some mistake is made in a certain stage and is not detected or tracked. Thus. deficiencies and any other problems that may arise. it becomes a little more complicated for them to offer feedback. and documentation is produced at every stage. all the subsequent steps will go wrong. Therefore the need for testing is very intense. Disadvantages of Waterfall Model in Testing As is the case with all other models.the process is following a linear sequence. a situation of complete trust from the client is essential. the design process can go horribly wrong.

‘Software Verification & Validation’ is one such model. which helps the system designers and test engineers to confirm that a right product is build right way throughout the development process and improve the quality of the software product. What is Verification? The standard definition of Verification goes like this: "Are we building the product RIGHT?" i.e. as the product . certain rules are followed at the time of development of a software product and also makes it sure that the product that is developed fulfills the required specifications. ‘Verification & Validation Model’ makes it sure that. which are unknowingly done during the development process. This reduces the risk associated with any software project up to certain level by helping in detection and correction of errors and mistakes. The software should confirm to its predefined specifications. Verification is a process that makes it sure that the software product is developed the right way.Software Verification & Validation Model .An Introduction An introduction to ‘Verification & Validation Model’ used in improvement of software project development life cycle. A perfect software product is built when every step is taken with full consideration that ‘A right product is developed in a right manner’.

Buddy Checks: This is the simplest type of review activity used to find out bugs in a work product during the verification.e. the work product (the ready part of the Software being developed and various documentations) is reviewed/examined personally by one ore more persons in order to find and point out the defects in it. The activities involved in Verification process are: Requirement Specification verification. every specification. Validation is done during or at the end of the . The bugs that are detected during the inspection are communicated to the next level in order to take care of them.development goes through different stages. one person goes through the documents prepared by another person in order to find out if that person has made mistake(s) i. Few terms involved in Verification: Inspection: Inspection involves a team of about 3-6 people.e. which may cause in failure of the project. is verified! What is Validation? Validation is a process of finding out if the product being built is right? i. an analysis is done to ensure that all required specifications are met. the presenter/author introduces the material to all the participants in order to make them familiar with it. design code etc. it should do what the user expects it to do. Functional design verification. to find out bugs which the author couldn’t find previously. audits. which formally reviews the documents and work product during various phases of the product development life cycle. Methods and techniques used in the Verification and Validation shall be designed carefully. which incorporates Software inspections. Even when the walkthroughs can help in finding potential bugs. it should satisfy all the functional requirements set by the user. The software product should functionally do what it is supposed to. The work product and related documents are presented in front of the inspection team. reviews. the member of which carry different interpretations of the presentation. In buddy check. led by a leader. internal/system design verification and code verification (these phases can also subdivided further). buddy checks etc. During the walkthrough meeting. Each activity makes it sure that the product is developed right way and every requirement. the planning of which starts right from the beginning of the development process. they are used for knowledge sharing or communication purpose. walkthroughs. whatever the software product is being developed. in each phase of verification (every phase of Verification is a phase of the Testing Life Cycle) During the Verification. Walkthroughs: Walkthrough can be considered same as inspection without formal preparation (of any presentation or documentations). This process helps in prevention of potential bugs. The Verification part of ‘Verification and Validation Model’ comes before Validation.

Functional design Verification etc. The product is validated to find out if it works according to the system specifications and satisfies all the user requirements. and System/User Acceptance Testing/Validation.development process in order to determine whether the product satisfies specified requirements. Code Validation/Testing. in stead. This helps in improvement of the final product. Integration Validation/Testing: Integration testing is carried out in order to find out if different (two or more) units/modules co-ordinate properly. Validation and Verification processes go hand in hand. . test suits and test cases are developed. Test plan. it may happen that bugs that are yet undiscovered. The phases involved in Validation process are: Code Validation/Testing.) has its corresponding Validation activity (such as Functional Validation/Testing. As the user/paid testers use the software.). All types of testing methods are basically carried out during the Validation process. Functional testing does not deal with internal coding of the project. Unit Code Validation or Unit Testing is a type of testing. In this type of testing. which the developers conduct in order to find out any bug in the code unit/module developed by them. Code testing other than Unit Testing can be done by testers or developers. but visibly Validation process starts after Verification process ends (after coding of the product ends). come up. Functional Validation/Testing: This type of testing is carried out in order to find if the system meets the functional requirements. System/Integration Validation etc. the developed product is handed over to the user/paid testers in order to test it in real time scenario. Terms used in Validation process: Code Validation/Testing: Developers as well as testers do the code validation. the system is validated for its functional behavior. This test helps in finding out if there is any defect in the interface between different modules. Functional Validation/Functional Testing. Each Verification activity (such as Requirement Specification Verification. which are communicated to the developers to be fixed. Integration Validation/Integration Testing. it checks if the system behaves as per the expectations. User Acceptance Testing or System Validation: In this type of testing. which are used during the various phases of Validation process.

this takes much of time of the next phase to solve them. which affects the success rate of the software developed by following "The Waterfall Model". In order to overcome the cons of "The Waterfall Model". it was necessary to develop a new .A New Approach Towards Software Development The Waterfall model is the most simple and widely accepted/followed software development model. Spiral Model for software development was designed in order to overcome the disadvantages of the Waterfall Model. instead all those problems related to one phase are carried out in the next phase and are needed to be resolved in the next phase. which is one of the oldest and most simple model designed and followed during software development process. but like any other system. But "Waterfall Model" has its own disadvantages such as there is no fair division of phases in the life cycle.Spiral Model . not all the errors/problems related to a phase are resolved during the same phase. In last article we discussed about "Waterfall Model". Waterfall model does have its own pros and cons. The risk factor is the most important part.

which can help in developing a cost effective project are analyzed and strategies are decided to use them. as every system has its own pros and cons. The first iteration in this model is considered to be most important. Risk Analysis and Engineering. If risks indicate any kind of uncertainty in requirements. However. alternatives and constraints of the project are determined and are documented. The radical dimensions indicate evolution of the product towards a complete system. which could help in ensuring the success of software project. developed product is passed on to the customer in order to receive customer’s comments and suggestions which can help in identifying and resolving potential problems/errors in the software developed. This phase has been added specially in order to identify and resolve all the possible risks in the project development. . constraints. requirements are identified and in the next iterations all known strategies are used to bring up a complete software system. the objectives. "The Spiral Model" does have its pros and cons too. The process progresses in spiral sense to indicate iterative path followed. This phase is very much similar to TESTING phase. which were faced in "The Waterfall Model". highly skilled people in the area of planning. development. In this phase all possible (and available) alternatives.Software Development Model. The phases in "Spiral Model" are: Plan: In this phase. Evaluation. planning and developing strategies to be followed while iterating through the phases. Risk Analysis: This phase is the most important part of "Spiral Model". There are four phases in the "Spiral Model" which are: Planning. risk analysis and mitigation. are required. This along with the fact that the process needs to be iterated more than once demands more time and is somehow expensive task. Engineering: In this phase. progressively more complete software is built as we go on iterating through all four phases. as in the first iteration almost all possible risk factors. customer relation etc. Iterating the phases helps in understating the problems associated with a phase and dealing with those problems when the same phase is repeated next time. These four phases are iteratively followed one after other in order to eliminate all the problems. As this model is developed to overcome the disadvantages of the "Waterfall Model". This model is referred as "The Spiral Model" or "Boehm’s Model". The objectives and other specifications are fixed in order to decide which strategies/approaches to follow during the project life cycle. One such model was developed which incorporated the common methodologies followed in "The Waterfall Model". the actual development of the project is carried out. to follow "Spiral Model". Customer Evaluation: In this phase. prototyping may be used to proceed with the available data and find out possible solution in order to deal with the potential changes in the requirements. but it also eliminated almost every possible/known risk factors from it. The output of this phase is passed through all the phases iteratively in order to obtain improvements in the same.

The second step or elaboration measures the architecture of the system's appropriateness based on the project needs.Rational Unified Process (RUP) Methodology The rational unified process (RUP) is a software process product designed as an objectoriented and web-enabled program development methodology by Rational Software Corporation. Components allow the use of code reuse through the use of object-oriented programming. a division acquired by IBM. while stressing strongly on object-oriented design. beta testing and the final implementation of the system. Components Large projects. Development is phased into four stages. when followed while designing any software project. They are basically six ideas. RUP methodology is highly flexible in its developmental path. Rational Unified Process (RUP) methodology is an software engineering tool which compounds development aspects such as manuals. as any stage can be updated at any time. This phase also includes the first release of the developed software. What is RUP? Rational Unified Process (RUP) methodology is fast becoming a popular software development to map business process and practices. Requirements Gathering requirements is essential to the success of any project. This article provides a brief overview of the rational unified process (RUP) methodology. by developing components and features. viability and feasibility of the program or project. since 2003. if all objectives are met. models. The first stage or inception centers on assessing needs. documents. and marks the end of the development cycle. defined stages. codes. The end users' needs have to be built into the system completely. when split into components. The third stage is the construction phase. The final stage is that of transition. will reduce errors and faults and ensure optimal productivity. This phase deals with the training of the end users. and practices within a unified framework. Design Model Visual . are easier to test and can be more methodically integrated into a larger system. etc. requirements. mechanics. Understanding RUP: Six Best Industry Practices of RUP RUP is designed to incorporate the six best software industry practices for software development. wherein the actual software system is made. The practices are listed below: Develop Iteratively Loops are created to add extra information or to facilitate processes that are added later in the development stage. with the procedural aspects of development such as techniques.

not only be discovered but addressed. guidelines. errors and performance bottlenecks can be rectified by making use of the several iterations (loops). to gauge the readiness of the project for its release. either from different locations or on different platforms need to be synchronized and verified constantly.Many projects use Unified Modeling Language (UML) to perform object-oriented analysis and designs. RUP provides a prototype at the completion of each iteration. Risks and defects can. Rational Unified Process (RUP) methodology's developmental approach has proved to be very resourceful and successful for a number of reasons. Testing Synchronized Changes All components created by separate teams. one needs to get a minimum of 62% in IBM RUP certification examination. Rational Unified Process (RUP) . Quality and Defects Management for quality and defects is an integral part of software development. and examples for all stages of program development. methodology is designed to work as an online help that provides content. and reduced or eliminated in the middle of integration process. To be a certified solution designer. The entire development process takes into account the changing requirements and integrates them. which make it easier for the developers to synchronize and implement changes. authorized to use this methodology. There are also a number of testing patterns that should be developed. which consist of diagrams to visually represent all major components. processes templates. As defects are detected along the process.

an inand-out knowledge of the system is a must. project plan and high-risk factors of the project are determined. a perfect understanding of the use-cases and an articulated vision is what this phase of elaboration looks forward to achieve. Since. This phase is to identify the work flows required by the project. factors influencing success. This is to get an understanding of the business drivers and to justify the launch of the project. Here is a simple breakdown of all the aspects related to this concept. wherein. This is an important phase. development of the remaining components and application features is performed. It keeps a check on effective project management and high-quality production of software. a division of IBM (International Business Machines Corporation). In other words. if you want to know what is rational unified process (RUP)? The concept of Rational Unified Process (RUP) came from the Rational Software Corporation. risk assessment and financial forecast.The 'Rational Unified Process' adopts the 'Unified Modeling Language' and provides the best practiced guidelines. Construction Phase As the name suggests. So. Inception Phase In the inception phase. so as to give you a brief understanding as to what is rational unified process (RUP)? There are primarily four phases or stages of development that is concluded with a release in RUP. the goal is to develop the parent idea into a product vision by defining its scope and the business case. . Architectural and planning decisions are governed by the most critical use-cases. after this phase the project is carried on to a level where any changes might cause disastrous outcome for the entire operation. The business case includes business context. influence the deciding factor in the architectural concept of the project. the phase involves construction of the software system or project. Continue reading. the performance requirements. Elaboration Phase Here the architectural foundation. adequate quality with optimization of resources is achieved rapidly. The basic methodology followed in RUP is based on a comprehensive web-enabled program development and object-oriented approach. they are integrated into the product which is moved from an architectural baseline to a completed system. Here is a quick review of all the four stages or cycles. scope and functionality of the system. It features a disciplined approach towards industry-tested practices for designing softwares and systems within a development organization. The construction phase is the first external release of the software. For establishing these objectives. In short. Here. Thereafter. templates and illustrations of all aspects for program development.What is Rational Unified Process (RUP) Rational Unified Process (RUP) is a comprehensive software engineering process. after analyzing the problem domain. the source code and the application design is created for the software for its transition to the user community.

site preparation. improved IT business. 2. users and their interaction relating to the project. The concept of rational unified process has endless explanation and description. They include • Training users and maintainers for successful operation of the system • Purchasing hardware • Converting data from old to new systems • Arranging for activities for successful launch of the product • Holding sessions of learning lessons for improving future process and tool environment. The initiative is done by testing the product before its release as a beta version. The above is just a theoretical brief explanation to the question as to what is RUP? However. Managing user requirements. higher quality. which have to be kept in mind when designing any software. Constant testing of the software quality is considered one of the best practices in any software development. higher service level and sharper adaptability. For a successful iterative development. Use and test individual components before being integrated into a larger system. 1. monitoring. . and many other benefits. These six practices are as follows. An iterative (executing the same set of instructions a given number of times or until a specified result is obtained) approach towards the software development. This stage is to ensure that the user requirements have been satisfied and met by the product. manual completion. and most importantly. Other objectives are also taken up. These practices help prevent flaws in the project development and create more scope for efficient productivity. tracking and controlling changes made to a system is essential for a team to work together as a single unit. 3. Use 'Unified Modeling Language' tool to get a visual model of the components. defect identification and improving performance and usability. a clearer and elaborated idea can be achieved once the process is put into practical use. This beta version is enhanced by bug fixing. RUP results in a reduced IT costs. Each and every important and essential considerations in a software development has been defined to its root. Rational Unified Process mentions six best practices. 4.Transition Phase Transition phase marks the transition of the project from development to production. higher ROI (return on investments).

The quality assurance process takes care of the quality of the products and ensures that customer requirements pertaining to the products are met. P-CMM. are some of the most sought after quality certifications in the IT-ITES sector. while the ISO 9002 is used for production and installation only. acquisition and maintenance of the services and products of a company is also improved with the help of CMMi. A set of proven practices are placed in a structure to assess the process area capability and organizational maturity of a company. The priorities for improvement are established and it is seen that these priorities are implemented properly with the help of CMMi. The ISO 9001 looks after the design. Total quality management is vital for the survival and profitability of business nowadays. The quality assurance certifications for the software industry. ISO 9003. International Standards Organization (ISO): It is a European standard used for quality assurance. The ISO 9000 and ISO 9003 documents contain supporting guidelines. production. the activity or process that proves the suitability of a product for the intended purpose could be described as quality assurance. . organic food. etc. The management of development. namely. and many other products are discussed in the following article. installation and maintenance/servicing.Quality Assurance Certification The process of quality assurance helps in testing the products and services as per the desired standards and the needs of customers. ISO 9002. The certifications used to assess different products have different parameters which should be understood thoroughly. ISO 9001. Capability Maturity Model Integration (CMMi): The CMMi acts as a guiding force in the improvement of the processes of an organization. The final inspection is done with the help of the ISO 9003 model. The quality assurance procedures are implemented in software testing. In short. The ISO 9000 systems makes use of different documents or procedures for quality assurance. Quality Assurance Certification (Software Industry) Certifications like the ISO and CMMi..

medical devices. etc. Processors. cosmetic products. drugs & vaccines.People Capability Maturity Model (P-CMM): The P-CMM model is similar to SW-CMM (Software Capability Maturity Model) in its approach. concrete products. health care equipment. Rigorous tests are conducted in order to award the quality assurance certificates. Private labelers. . developing. The objective of P-CMM is to improve the software development capability of an organization by means of attracting. animal drugs & food. The measurement is needed for establishing and managing the outsourcing relationships which improve continually. Retailers. Food and Drug Administration Certification The Food and Drug Administration (FDA) of the US awards quality assurance certification for the food products which comply with the performance and safety standards. The management and development of the workforce of a company is guided by the P-CMM model. home equipment. organizing and retaining the manpower or the required talent. The quality control and quality assurance certifications help in developing the trust of customers in a particular product. Canadian Standards Association (CSA) International The various products certified under the CSA are building products. The FDA certifies different types of products like the dietary supplements. QAI Certification Program The Quality Assurance International (QAI) is an agency which awards the organic certification to the Producers. It is difficult to comply with the requirements/standards of this model since it covers the security issues comprehensively and contains the control requirements that are significant in number. motivating. e Services Capability Model (eSCM): The eSCM model serves the needs of the BPO/ITES industries. The P-CMM model makes use of the best current practices used in organizational and human resource development to achieve its objectives. Distributors and other 'links' involved in the production of organic food. etc. BS 7799: It is a security standard which originated in the mid-nineties. and till the year 2000 it evolved into a model known known as BS EN ISO17799. The quality assurance certificates awarded by various agencies also act as a motivational force for industries to maintain the required standards. gas appliances. The short account of various agencies awarding the certifications would help the concerned people in the industries. heating & cooling equipment. This model is used to assist the customers in measuring the service provider's capability.

It might take more than one test case to determine the true functionality of the application being tested. Activity Activity consists of the actual test case activities. 2. name of the test case.Test Cases What are test cases in software testing. Every requirement or objective to be achieved needs at least one test case.Software Testing . read through to know more. Information Information consists of general information about the test case. Activity . test case version. purpose or brief description and test case dependencies. Information incorporates Identifier. test case creator. Test Case Structure A formal written test case comprises of three parts 1. Some software development methodologies like Rational Unified Process (RUP) recommend creating at least two test cases for each requirement or objective. What is a Test Case? A test case is a set of conditions or variables and inputs that are developed for a particular goal or objective to be achieved on a certain application to judge its capabilities or features.. one for performing testing through positive perspective and the other through negative perspective. how they are designed and why they are so important to the entire testing scenario.

3. Some follow a general step way approach while others may opt for a more detailed and complex approach. . inconsistencies and slip ups can be recovered in time as also it helps in saving your time on continuous debugging and re-testing test cases. but they are worth giving time because they can really avoid unnecessary retesting or debugging or at least lower it. It is very important for you to decide between the two extremes and judge on what would work the best for you.contains information about the test case environment. A test case should include the following information • • • • • Purpose of the test Software requirements and Hardware requirements (if any) Specific setup or configuration requirements Description on how to perform the test(s) Expected results or success criteria for the test Designing test cases can be time consuming in a testing schedule. Results Results are outcomes of a performed test case. Organizations can take the test cases approach in their own context and according to their own perspectives. step by step actions to be done while testing and the input data that is to be supplied for testing. Results data consist of information about expected results and the actual results. activities to be done after test case is performed. ambiguities. activities to be done at test case initialization. Designing proper test cases is very vital for your software testing plans as a lot of bugs. Designing Test Cases Test cases should be designed and written by someone who understands the function or technology being tested.

Subject: Description of the bug in short which will help in identifying the bug. which helps in uniquely identifying the bug reported by the tester. When a tester finds a defect.Software Testing . The contents of a bug are as given below: Project: Name of the project under which the testing is being carried out. Assigned To: Name of the developer who is supposed to fix the bug. which can help in minimizing the number of records to be searched. who then delegates the task to member of his team. Description: Detailed description of the bug. This generally starts with the project identifier number/string. . Generally this field contains the name of developer group leader. This string should be clear enough to help the reader in anticipate the problem/defect for which the bug has been reported. These fields help in identifying a bug uniquely. At the end of the summary. he/she needs to report a bug and enter certain fields. the step at which the test case fails is described along with the actual result obtained and expected result. Detected By: Name of the tester who detected/reported the bug. This generally includes the steps that are involved in the test case and the actual results. Summary: This field contains some keyword information about the bug.Contents of a Bug Complete list of contents of a bug/error/defect that are needed at the time of raising a bug during software testing. and changes the name accordingly.

Low. as per the progress of bug fixing process. Priority: Priority of the bug fixing. Pending Retest. Open. Closed in Version: This field contains the version information of the software application in which the bug was fixed.e.e. Pending Reject. Actual Date of Closure: As the name suggests. High. Deferred etc.Test Lead: Name of leader of testing team. in which the tester has to enter a valid data at the time of reporting a bug. which displays the severity of the bug. number created for the bug at the time of reporting. Severity: This is typically a numerical field. Expected Date of Closure: Date at which the bug is expected to be closed. . Status: This field displays current status of the bug. Generally Medium. Bug ID: This is a unique ID i. Detected in Version: This field contains the version information of the software application in which the bug was detected. Making a field mandatory or optional depends on the company requirements and can take place at any point of time in a Software Testing project. Rejected. date at which the bug was fixed and retested successfully. A status of ‘New’ is automatically assigned to a bug when it is first time reported by the tester. It can range from 1 to 5. Urgent are the type of severity that are used. This depends on the severity of the bug. Closed. Date Detected: Date at which the bug was detected and reported. where 1 is high severity and 5 is the lowest. Attachment: Sometimes it is necessary to attach screen-shots for the tested functionality that can help tester in explaining the testing he had done and it also helps developers in recreating the similar testing condition. Postponed. which identifies the bug uniquely. actual date of closure of the bug i. Retest. Any of above given fields can be made mandatory. further the status is changed to Assigned. Test Case Failed: This field contains the test case that is failed for the bug. This specifically depends upon the functionality that it is hindering. under whom the tester reports the bug.

Deferred. Postpone. rejected. (Right from the first time any bug is detected till the point when the bug is fixed and closed. Open. it is assigned various statuses which are New. Reject. Pending Retest. What is a Bug Life Cycle? The duration or time span between the first time bug is found (‘New’) and closed successfully (status: ‘Closed’). Retest.Software Testing . and Closed. Pending Reject. For more information about various statuses .Bug Life Cycles Various life cycles that a bug passes through during a software testing process. postponed or deferred is called as ‘Bug/Error Life Cycle’.

6) The development leader changes the status of the bug to ‘Pending Retest’ and passes on to the testing team for retest. 2) The Test lead verifies if the bug is valid or not. 5) After getting a satisfactory reply from the development side. so the tester closes the bug and marks it as ‘Closed’. you can refer to article ‘Software Testing – Bug & Statuses Used During A Bug Life Cycle’) There are seven different life cycles that a bug can passes through: < I > Cycle I: 1) A tester finds a bug and reports it to Test Lead. 2) The Test lead verifies if the bug is valid or not. 3) The bug is verified and reported to development team with status as ‘New’. 2) The Test lead verifies if the bug is valid or not. 7) The test leader changes the status of the bug to ‘Retest’ and passes it to a tester for retest. < IV > Cycle IV: 1) A tester finds a bug and reports it to Test Lead. so the tester after confirmation from test leader reopens the bug and marks it with ‘Reopen’ status. < V > Cycle V: 1) A tester finds a bug and reports it to Test Lead. 2) The Test lead verifies if the bug is valid or not. And the bug is passed back to the development team for fixing. The bug is valid and the development leader assigns a developer to it marking the status as ‘Assigned’. 5) The developer solves the problem and marks the bug as ‘Fixed’ and passes it back to the Development leader. 4) The development leader and team verify if it is a valid bug. 3) Test lead finds that the bug is not valid and the bug is ‘Rejected’. < III > Cycle III: 1) A tester finds a bug and reports it to Test Lead. 3) The bug is verified and reported to development team with status as ‘New’. 6) The development leader changes the status of the bug to ‘Pending Retest’ and passes on to the testing team for retest. 4) The development leader and team verify if it is a valid bug. 7) The test leader changes the status of the bug to ‘Retest’ and passes it to a tester for retest. 2) The Test lead verifies if the bug is valid or not. the test leader marks the bug as ‘Rejected’. < II > Cycle II: 1) A tester finds a bug and reports it to Test Lead. The bug is invalid and is marked with a status of ‘Pending Reject’ before passing it back to the testing team. The bug is valid and the development leader assigns a developer to it marking the status as ‘Assigned’. 8) The tester retests the bug and the same problem persists. 4) The development leader and team verify if it is a valid bug. 3) The bug is verified and reported to development team with status as ‘New’. 3) The bug is verified and reported to development team with status as ‘New’. 5) The developer solves the problem and marks the bug as ‘Fixed’ and passes it back to the Development leader.used for a bug during a bug life cycle. 8) The tester retests the bug and it is working fine. 4) The developer tries to verify if the bug is valid but fails in replicate the same scenario as .

5) The tester also fails to re-generate the scenario in which the bug was found. any bug that is found ends up with a status of Closed. then it is given a status as ‘Deferred’. . the solution and retest of the bug is postponed for indefinite time and it is marked as ‘Postponed’. < VII > Cycle VII: 1) If the bug does not stand importance and can be/needed to be postponed. < VI > Cycle VI: 1) After confirmation that the data is unavailable or certain functionality is unavailable.was at the time of testing. Deferred or Postponed. And developer rejects the bug marking it ‘Rejected’. but fails in that and asks for help from testing team. This way. Rejected.

. How to report a bug? It’s a good practice to take screen shots of execution of every step during software testing. keep track of current status of the defect. Date Detected. Summary. Test Lead. Description. The screen-shots taken at the time of execution of test case are attached to the bug for reference by the developer. Expected Date of Closure. all the mandatory fields from the contents of bug (such as Project. find out if any such defect (similar defect) was ever found in last attempts of testing etc. Priority and Bug ID etc. Actual Date of Closure. At the time of reporting a bug. In any case. Closed in Version. the life cycle of the defect starts and it becomes very important to communicate the defect to the developers in order to get it fixed. Severity. Detected in Version. As a tester tests an application and if he/she finds any defect. it needs to be failed in the bug-reporting tool and a bug has to be reported/logged for the same.) are filled and detailed description of the bug is given along with the expected and actual results. which help in tracking and managing bugs in an effective way. Status. the Bug ID that is generated for the reported bug should be attached to the test case that is failed. and keep a log of defects for future reference etc. The tester can choose to first report a bug and then fail the test case in the bug-reporting tool or fail a test case and report a bug. previously manually created documents were used.Software Testing . As we already have discussed importance of Software Testing in any software development project (Just to summarize: Software testing helps in improving quality of software and deliver a cost effective solution which meet customer requirements). If any test case fails during execution. Assigned To. track the defect. which were circulated to everyone associated with the software project (developers and testers). For this purpose. Detected By. now a days many Bug Reporting Tools are available. it becomes necessary to log a defect in a proper way.How To Log A Bug (Defect) A brief introduction to how a bug/defect/error is reported during software testing.

the tester can report a new bug and fail the test case for the newly raised bug. The expected and actual results are written for each step and the test case is failed for the step at which the test case fails. which is then associated with the failed test case. a unique Bug ID is generated by the bug-reporting tool. If yes. it becomes very important for the tester to find out if any bug has been reported for similar type of defect. And if there is no such bug reported previously. the test case is written in a tabular manner in a file with four columns containing Test Step No. the test case has to be executed once the bug is fixed). it becomes important keep updated information of the bug that was raised till the time it is closed. which goes on changing as the bug fixing process progresses. If no bug-reporting tool is used. then the test case has to be blocked with the previously raised bug (in this case. If more than one tester are testing the software application. it is assigned a status of ‘New’. it becomes a possibility that some other tester might already have reported a bug for the same defect found in the application. In such situation. This file containing test case and the screen shots taken are sent to the developers for reference. . Expected Result and Actual Result. After the bug is reported. then in that case.After reporting a bug. As the tracking process is not automated. This Bug ID helps in associating the bug with the failed test case. Test Step Description.

Quality Control etc. Typically. Hence. There are several types of software testing and software testing methodologies.Software Testing Interview Questions If you are looking for a job in software testing industry. yet very keen about making a career in the software field. Quality Assurance (QA). it is imperative that you have a sound understanding of the field you are hoping to venture in. hence. you must also be equipped with the answers for the most likely questions you'll be facing during an interview. we have divided the questions into five common categories. Remember. it is imperative that along with a sound knowledge of the corresponding field. Software testing field offers several job positions in testing. Preparing for the Interview Before applying for any IT job. you should also keep yourself abreast with the latest tools and trends in the software testing industry. before going for an interview. software testing is a volatile field. If you are the kind of a person. the things that you learned in your curriculum may have become obsolete by the time you are ready for a job. which you must be thorough with. Interview Questions for Software Testing . so as to improve your chances of acquiring a job in this particular industry. who are interested in pursuing a career in the software industry. who does not enjoy software development. We have compiled here a list of some common software testing interview questions.. your set of interview questions for software testing would depend upon the particular area of software testing you are interested in. then software testing could be the right option for you.. Besides being technically sound. Software testing industry presents a plethora of career opportunities for candidates. More on job interview tips. Have a look. However. you need to have your basics in place.

2? • Explain Release Acceptance Testing. Explain System Integration Testing.Software Testing Interview Questions on Product Testing • What will be the test cases for product testing? Give an example of test plan template. Can you explain the term in a few words? What are the major components of the risk? • When do you say your project testing is completed? Name the factors. • What are the advantages of working as a tester for a product based company as opposed to a service based company? • Do you know how a product based testing differs from a project based testing? Can you give a suitable example? • Do you know what is exactly meant by Test Plan? Name its contents? Can you give a sample Test Plan for a Login Screen? • How do you differentiate between testing a product and testing any web-based application? • What is the difference between Web based testing and Client server testing? • How to perform SOAP Testing manually? • Explain the significance of Waterfall model in developing a product. Software Testing Interview Questions on Quality Assurance • How do you ensure the quality of the product? • What do you do when there isn't enough time for thorough testing? • What are the normal practices of the QA specialists with perspective of a software? • Can you tell the difference between high level design and low level design? • Can you tell us how Quality Assurance differs from Quality Control? • You must have heard the term Risk. • What do you mean by a walk through and inspection? • What is the procedure for testing search buttons of a web application both manually and using Qtp8. • How does compatibility testing differ while testing in Internet explorer and testing in Firefox? Software Testing Interview Questions on Testing Scenarios • How do you know that all the scenarios for testing are covered? . Explain Forced Error Testing. Explain Data Integrity Testing.

test planning report. if it is a 'Migrating Project'? • Explain the difference between smoke testing and sanity testing? • What are all the scenarios to be considered while preparing test reports? • What is an 'end to end' scenario? • Other than requirement traceability matrix.• Can you explain the Testing Scenario? Also explain scenario based testing? Give an example to support your answer. what are the other factors that we need to check in order to exit a testing process ? • What is the procedure for finding out the length of the edit box through WinRunner? Software Testing Interview Questions on Automated Testing • What automated testing tools are you familiar with? • Describe some problems that you encountered while working with an automated testing tool. • Consider a yahoo application. • What types of scripting techniques for test automation are you aware of? • Name the principles of good testing scripts for automation? • What tools can you use for support of testing during the software development life cycle? . What are the test cases you can write? • Differentiate between test scenario and test case? • Is it necessary to create new Software requirement document. • What is the procedure for planning test automation? • What is your opinion on the question that can a test automation improve test effectiveness? • Can you explain data driven automation? • Name the main attributes of test automation? • Do you think automation can replace manual testing? • How is a tool for test automation chosen? • How do you evaluate the tool for test automation? • What are the main benefits of test automation according to you? • Where can test automation go wrong? • Can you describe testing activities? • What testing activities you need to automate? • Describe common issues of test automation.

the solutions. if the bug was not reproducible? • How can you tell if a bug is reproducible or not? • On what basis do we give priority and severity for a bug. Provide an example for high priority and low severity and high severity and low priority? • Explain Defect Life Cycle in Manual Testing? • How do you give a BUG Title & BUG Description for ODD Division? • Have you ever heard of a build interval period? Software testing is a vast field and there is really no dearth of software testing interview questions. • Can you explain the difference between a Bug and a Defect? Explain the phases of bug life cycle • What are the different types of Bugs we normally see in any of the projects? Also include their severity. You can explore the Internet for more software testing interview questions and of course.e high priority and low severity? Justify your answer. • What is the difference between Bug Resolution Meeting and Bug Review Committee? Who all participate in Bug Resolution Meeting and Bug Review Committee? • Can you name some recent major computer system failures caused by software bugs? What do you mean by 'Reproducing a bug'? What do you do. Hope this article helps you to get the job of your dreams.• Can you tell us it the activities of a test case design be automated? • What are the drawbacks of automated software testing? • What skills are needed to be a good software test automator? Software Testing Interview Questions on Bug Tracking • Can you have a defect with high severity and low priority and vice-versa i. Good Luck! .

For example. It also helps to identify the defects / flaws / errors that may appear in the application code. testing turns to be mandatory.e. Need of Software Testing Types Types of Software Testing. when we go out. if its writing. we do check it before purchasing them for our satisfaction and to get maximum benefits. which needs to be fixed. which when conducted help to eliminate defects from the program. When the end product is given to the client. It is the process of analyzing or operating software for the purpose of finding bugs. hardware or any product. So. pens. Defect in software is the variance between the actual and expected results. depends upon different types of defects. For example: • Functional testing is done to detect functional defects in a system. we test the pen before actually purchasing it i.Types of Software Testing Software Testing is a process of executing software in a controlled manner. grey box software testing strategy. though its the software. Testing not only means fixing the bug in the code. etc. shopping any product such as vegetable. but also to check whether the program is behaving according to the given specifications and testing strategies. What is Software Testing? Software Testing is a process of verifying and validating whether the program is performing correctly with no bugs. etc. Testing is a process of gathering information by making observations and comparing them to expectations. when we intend to buy a pen. . There are different types of software testing. it should work correctly according to the specifications and requirements of the software. etc. There are various types of software testing strategies such as white box testing strategy. clothes. – Dale Emery In our day-to-day life. does it work in extreme climatic conditions. black box testing strategy. does it break if it falls.

The list goes on as we move on towards different layers of testing. To determine the true functionality of the application being tested. Checklists for software tester sets a baseline that guides him to carry on the day-to-day activities. The V. Software bug testing or software testing to log a bug. Performance testing depends upon the Load and Stress Testing. reporting of the bugs/defects. in which test cases are designed and reviewed by the team. before executing it. defect management.• Performance Testing is performed to detect defects when the system does not perform according to the specifications • Usability Testing to detect usability defects in the system. This can be done with the help of various bug tracking tools such as Bugzilla and defect tracking management tools like the Test Director. that is internally or externally applied to the system. test cases are designed to help the developers. here is some information on software testing . This checks whether the application is behaving according to the specification. This model contains software development life cycle on one side and software testing life cycle on the other hand side. • Security Testing is done to detect bugs/defects in the security of the system. Software testing includes two basic types of software testing. without considering how the system generates the output.Model i. . Load Testing : In this type of performance testing. Performance Testing: This type of testing checks whether the system is performing properly.e Verification and Validation Model is a perfect model which is used in the improvement of the software project. viz. executing test cases. It is also called as Behavioral Testing. Black Box Testing It explains the process of giving the input to the system and checking the output. Test cases provide you with the guidelines for going through the process of testing the software. Those who are new to this subject. which can be applied to various parts of a software process such as test case management. • Automated Testing: This software testing type applies automation in the testing. Manual Scripted Testing and Automated Testing. explains the contents of a bug that is to be fixed. Types of Software Testing Various software testing methodologies guide you through the consecutive software testing types. according to the user's requirements. Functional Testing: In this type of testing.how to go about for beginners. the software is tested for the functional requirements. Other Software Testing Types Software testing life cycle is the process that explains the flow of the tests that are to be carried on each step of software testing of the product. • Manual Scripted Testing: This is considered to be one of the oldest type of software testing methods. The bug life cycle helps the tester in deciding how to log a bug and also guides the developer to decide on the priority of the bug depending upon the severity of logging it. 1. the system is raised beyond the limits in order to check the performance of the system when higher loads are applied.

Regression Testing: Regression testing is one of the most important types of testing. when huge amount of data is processed through the application. Read more on exploratory testing. Read more on compatibility testing. Manual-Support Testing: This type of software testing is an interface between people and application system. in which it checks whether a small change in any component of the application does not affect the unchanged components. Read more on introduction to usability testing. That means. catastrophic problems or any type of system crash. Recovery Testing: Recovery testing is very necessary to check how fast the system is able to recover against any hardware failure. . Error-Handling Testing: This software testing type determines the ability of the system to properly process erroneous transactions. and is performed to explore the software features. Smoke Testing: Smoke testing is used to check the testability of the application. with various combinations of hardware and software packages. Stress Testing : In this type of performance testing. Testing is done by re-executing the previous versions of the application. Installation Testing: This type of software testing identifies the ways in which installation procedure leads to incorrect results. Sanity Testing: Sanity testing checks for the behavior of the system. Compatibility Testing: Compatibility Testing determines if an application under supported configurations perform as expected. It is also called 'Build Verification Testing or Link Testing'. procedures and guidelines. Inter-Systems Testing: This type of software testing method is an interface between two or more application systems. Volume Testing: This testing is done. Exploratory Testing: Exploratory Testing is a type of software testing. without dealing with the finer details. and determines the effect of adding or modifying resources such as memory. Parallel Testing: Parallel testing is done by comparing results from two different systems like old vs new or manual vs automated. disk drives and CPU. it checks whether the application is ready for further major testing and working. Compliance Testing: This type of testing checks whether the system was developed in accordance with standards. which is similar to ad-hoc testing. Configuration Testing: This testing is done to test for compatibility issues. This testing checks the ease of use of an application. the system is tested beyond the normal expectations or operational capacity Usability Testing: This type of testing is also called as 'Testing for User Friendliness'. It determines minimal and optimal configuration of hardware and software.2. This type of software testing is also called as Narrow Regression Testing.

which is one of the important parts of the white box testing. is not mandatory. It is mandatory for a tester to have the knowledge of the source code. This testing includes Alpha and Beta testing. System Testing: System testing is the testing conducted on a complete. to generate the output. to evaluate the system's compliance with the specified requirements. Statement Coverage: This type of testing assures that the code is executed in such a way that every statement of the application is executed at least once. The user should be able to use the application. This testing is done after system testing. in dynamic analysis the code is executed and analyzed for the output. User Acceptance Testing: Acceptence Testing is performed to verify that the product is acceptable to the customer and it's fulfilling the specified requirements of that customer. Unit testing deals with testing the unit as a whole. how the system processes the input. how user-friendly the application is. Path Coverage: Each and every path within the code is executed at least once to get a full path coverage. Beta Testing: This type of software testing is done at the customer's site by the customer in the open environment. The presence of the developer. it is required to go through the code in order to find out any possible defect in the code. Static and Dynamic Analysis: In static analysis. Whereas. rather than artificial combinations that are obtained through domain or combinatorial test design. integrated system. Decision Coverage: This type of testing helps in making decision by executing the application. 2. White Box Testing It is the process of giving the input to the system and checking. This mostly focuses in the design and . This is considered to be the last step in the software development life cycle as the product is almost ready. in each of the ways at least once. each and every condition is executed by making it true and false.Scenario Testing: This type of software testing provides a more realistic and meaningful combination of functions. Alpha Testing: Alpha testing is performed at the developer's site by the customer in a closed environment. at least once to judge whether it results in true or false. Integration Testing: Integration testing is performed when various modules are integrated with each other to form a sub-system or a system. Unit Testing: This type of testing is done at the developer's site to check whether a particular piece/unit of code is working fine. Condition Coverage: In this type of software testing. This type of software testing validates that the system meets its functional and non-functional requirements and is also intended to test beyond the bounds defined in the software/hardware requirement specifications. 1. User Interface Testing: This type of testing is performed to check. while performing these tests. without any assistance by the system personnel.

2.construction of the software architecture. You could go through some software testing interview questions. as it tests the top level modules are tested and the branch of the module are tested step by step using 'Stubs' until the related module comes to an end. or willful damage of code. Bottom-Up Integration Testing: In this type of integration testing. means security testing of the system. Mutation Testing: In this type of software testing. Top-Down Integration Testing: This is totally opposite to bottom-up approach. . Security testing assures that the program is accessed by the authorized personnel only. Software testing is indeed a vast subject and one can make a successful carrier in this field. to prepare yourself for some software testing tutorials. and helps you check if the software satisfies the requirement of the customer. These various software testing methods show you the outputs. 1. Integration testing is further classified into Bottom-Up Integration and Top-Down Integration testing. Security Testing: Testing that confirms how well a system protects itself against unauthorized internal or external. the application is tested for the code that was modified after fixing a particular bug/defect. the lowest level components are tested first and then alleviate the testing of higher level components using 'Drivers'. using the above mentioned software testing types. Software testing methodologies and different software testing strategies help to get through this software testing process.

Security Testing helps in finding out all the possible vulnerabilities of the system and help developers in fixing those problems. . Security testing ensures that the systems and applications used by the organizations are secure and not vulnerable to any type of attack. it also ensures that people in your organization understand and obey security policies. Security Testing doesn’t only include conformance of resistance of the systems your organization uses. What are the different types of Security Testing? Following are the main types of security testing: • Security Auditing: Security Auditing includes direct inspection of the application developed and Operating Systems & any system on which it is being developed. The information that is stored in these storage devices and the applications that run on the computers are highly important to the organization from the business.Software Testing . security and even efforts point of view). which might result into loss/theft of highly sensitive information or destruction of the system by an intruder/outsider. Hence adding up to the organization-wide security. Security Testing helps in improving the current system and also helps in ensuring that the system will work for longer time (or it will work without hassles for the estimated time). Who need Security Testing? Now a day.Brief Introduction To Security Testing Security testing is an important process in order to ensure that the systems/applications that your organization is using meet security policies and are free from any type of loopholes that can cause your organization a big loss. security and survival point of view. need to secure the information it possesses and the applications it uses in order to protect its customer’s information safe and suppress any possible loss of its business. Security Testing of any developed system (or a system under development) is all about finding out all the potential loopholes and weaknesses of the system. security testing can help in eliminating the flaws into design and implementation of the system and in turn help the organization in blocking the potential security loopholes in the earlier stage. This is beneficial to the organization almost in all aspects (financially. If involved right from the first phase of system development life cycle. This also involves code walk-through. Any organization small or big in size. Need of Security Testing • • • • Security test helps in finding out loopholes that can cause loss of important information and allow any intruder enter into the systems. almost all organizations across the world are equipped with hundreds of computers connected to each other through intranets and various types of LANs inside the organization itself and through Internet with the outer world and are also equipped with data storage & handling devices.

hence contributing towards the security conformance. During security scanning. • Posture Assessment & Security Testing: This is a combination of Security Scanning. Ethical hacking involves number of penetration tests over the wide network on the system under test. a tester tries to forcibly access and enter the application under test. • Risk Assessment: Risk assessment is a method of analyzing and deciding the risk that depends upon the type of loss and the possibility/probability of loss occurrence. a tester may try to enter into the application/system with the help of some other application or with the help of combinations of loopholes that the application has kept open unknowingly. Penetration test is highly important as it is the most effective way to practically find out potential loopholes in the application. applications and network(s). It helps in finding out and preparing possible backup-plan for any type of potential risk. auditors inspect and try to find out the weaknesses in the OS. In the penetration testing. Risk Assessment and Ethical Hacking in order to reach a conclusive point and help your organization know its stand in context with Security. • Penetration Testing: In this type of testing. This scanning is generally done through various vulnerability scanning software. • Vulnerability Scanning: Vulnerability scanning involves scanning of the application for all known vulnerabilities. Risk assessment is carried out in the form of various interviews. • Ethical Hacking: It’s a forced intrusion of an external element into the system & applications that are under Security Testing. . discussions and analysis of the same.• Security Scanning: It is all about scanning and verification of the system and applications.


Manual testing is one of the types of software testing which is an important component of the IT job sector and does not use any automation methods and is therefore tedious and laborious. software testing needs to be done to test for its effectiveness and it is for this purpose that manual testing is required. Manual testing requires a tester who needs to have certain qualities because the job demands it .he needs to be observant. Read to know more. skillful and possess certain other qualities that will help him with his job. Whenever a new software is invented.Manual Testing Interview Questions The following article takes us through some of the most common manual testing interview questions. creative. Manual Testing Interview Questions for Freshers The following are some of the interview questions for manual testing. innovative. • • • • • • • • • • • • • What What What What What What What What What What What What What is is is is is is is is is is is is is the accessibility testing? Ad Hoc Testing? the Alpha Testing? Beta Testing? Component Testing? Compatibility Testing? Data Driven Testing? Concurrency Testing? Conformance Testing? Context Driven Testing? Conversion Testing? Depth Testing? Dynamic Testing? . patient. read the following article to know what some interview questions on manual testing are. This will give you a fair idea of what these questions are like. but what some of the manual testing interview questions are. In the following article we shall not be concentrating on what a tester is like. open-minded. Manual testing is one of the oldest and most effective ways in which one can carry out software testing. So if you have a doubt in this regard. speculative. resourceful.

let us now move on to other forms of manual testing questions. • Can you explain the V model in manual testing? • What is the water fall model in manual testing? • What is the structure of bug life cycle? • What is the difference between bug.• • • • • • • • • • • • • • • • • • • • • • • • • What is End-to-End testing? What is Endurance Testing? What is Installation Testing? What is Gorilla Testing? What is Exhaustive Testing? What is Localization Testing? What is Loop Testing? What is Mutation Testing? What is Positive Testing? What is Monkey Testing? What is Negative Testing? What is Path Testing? What is Ramp Testing? What is Performance Testing? What is Recovery Testing? What is the Regression testing? What is the Re-testing testing? What is Stress Testing? What is Sanity Testing? What is Smoke Testing? What’s the Volume Testing? What’s the Usability testing? What is Scalability Testing? What is Soak Testing? What’s the User Acceptance testing? These were some of the manual testing interview questions for freshers. error and defect? • How does one add objects into the Object Repository? • What are the different modes of recording? • What does 'testing' mean? • What is the purpose of carrying out manual testing for a background process that does not have a user interface and how do you go about it? • Explain with an example what test case and bug report are. • How does one go about reviewing a test case and what are the types that are available? • What is AUT? • What is compatibility testing? • What is alpha testing and beta testing? • What is the V model? . Software Testing Interview Questions for Freshers Here are some software testing interview questions that will help you get into the more intricate and complex formats of this form of manual testing.

right? . • What is the fish model? • What is port testing? • Explain in detail the difference between smoke and sanity testing. • What is the difference between usability testing and GUI? • Why does one require object spy in QTP? • What is the test case life cycle? • Why does one save .• What is debugging? • What is the difference between debugging and testing? Explain in detail. and if you're from this field then you'll know what I'm talking about. The career opportunities that an IT job provides is greater that what many other fields provide.vsb in library files in qtp winrunner? • When do we do update mode in qtp? • What is virtual memory? • What is visual source safe? • What is the difference between test scenarios and test strategy? • What is the difference between properties and methods in qtp? Why do these manual testing interview questions help? They help you to prepare for what lies ahead.

re-estimating.com Books page. and frequent re-scheduling. and re-prioritizing is expected. QA and test personnel are also required to be an integral part of the project team. Programmers are expected to write unit and functional test code first . Test code is under source control along with the rest of the code. Customers are expected to be an integral part of the project team and to help develope scenarios for acceptance/black box testing. .before writing the application code. Acceptance tests are preferably automated. Testing ('extreme testing') is a core aspect of Extreme Programming. Detailed requirements documentation is not used. and are modified and rerun for each of the frequent development iterations. It was created by Kent Beck who described the approach in his book 'Extreme Programming Explained' (See the Softwareqatest.Extreme Programming (XP) What is Extreme Programming and what's it got to do with testing? Extreme Programming (XP) is a software development approach for small teams on riskprone projects with unstable requirements.).

It is often used with high-level requirements (sometimes known as marketing requirements) and detailed requirements of the software product to the matching parts of high-level design. In other . Zero values indicate that no relationship exists. Large values imply that the item is too complex and should be simplified. a traceability matrix is a table that correlates any two baselined documents that require a many to many relationship to determine the completeness of the relationship. a mark is placed in the intersecting cell. The number of relationships are added up for each row and each column. The requirements are each listed in a row of the matrix and the columns of the matrix are used to identify how and where each requirement has been addressed. detailed design. When an item in the left column is related to an item across the top. Contents:        Definition Description Requirements of Traceability Matrix Baseline Traceability Matrix Building a Traceability Matrix Useful Traceability Matrices Sample Traceability Matrix Definition In a software development process. The identifiers for the other document are placed across the top row.Traceability Matrix A method used to validate the compliance of a process or product with the requirements for that process or product. Common usage is to take the identifier for each of the items of one document and place them in the left column. it is advisable to add the relationships to the source documents for both backward traceability and forward traceability. and test cases. test plan. It must be determined if one must be made. This value indicates the mapping of the two items. To ease with the creation of traceability matrices.

Size and Format For each requirement. spreadsheets.words. identify the component in the current stage that responds to the requirement. or a section of a design specification. databases. Description Description A table that traces the requirements to the system deliverable component for that stage that responds to the requirement. A traceability matrix is created by associating requirements with the work products that satisfy them. it's easy to see what needs to be changed in the other. Tests are associated with the requirements on which they are based and the product tested to meet the requirement. when an item is changed in one baselined document. or even with tables or hyperlinks in a word processor. . The requirement may be mapped to such items as a hardware component. Traceability Matrix Requirements Traceability matrices can be established using a variety of tools including requirements management software. an application unit.

that all lower level requirements come from higher level requirements. or many-to-many. There can be more things included in a traceability matrix than shown. . an application unit. Traceability is also used to manage change and provides the basis for test planning. Size and Format Document each requirement to be traced. Baseline Traceability Matrix Description A table that documents the requirements of the system for use in subsequent stages to confirm that all requirements have been met. Traceability ensures completeness. and that all higher level requirements are allocated to lower level requirements.Above is a simple traceability matrix structure. one-to-many. In traceability. Numbers for products are established in a configuration management (CM) plan. the relationship of driver to satisfier can be one-to-one. Traceability requires unique identifiers for each requirement and product. or a section of a design specification. The requirement may be mapped to such things as a hardware component. many-to-one.

such as process models and data models • improve the quality of a system by identifying requirements that are not addressed by configuration items during design and code reviews and by identifying extra configuration items that are not required. One method is to: • • • create a two-dimensional table allow one row for each requirements specification paragraph (identified by paragraph number from the requirements document) allow one column per identified configuration item (such as software module or hardware device) . Use a Traceability Matrix to Match Requirements to a Deliverable There are many ways to relate requirements to the deliverables for each stage of the system life cycle. A requirement that cannot be mapped to a deliverable is an indication that something is missing from the deliverable. a deliverable that cannot be traced back to a requirement may mean the system is delivering more than required. Need for Relating Requirements to a Deliverable Taking the time to cross-reference each requirement to a deliverable ensures that a deliverable is consistent with the system requirements. Likewise. Examples of configuration items are software modules and hardware devices • • provide input to change requests and future project plans when missing requirements are identified provide a guide for system and acceptance test plans of what needs to be tested.Building a Traceability Matrix Use a Traceability Matrix to: • • verify and validate system specifications ensure that all final deliverable documents are included in the system specification.

System test plan to functional specification ensures you have identified a test case or test scenario for each process and each requirement in the functional specification. What information the report contains depends on your need. a top level configuration item. Workstation. CPU. • • Design specification to functional specification verifies that each function has been covered in the design. Although the construction and maintenance of traceability matrices may be time-consuming. may be one of the configuration items that satisfies the function Input Order Information. Workstation. On the matrix. each configuration item would be written down the left hand column and each function would be written across the top. • Top level configuration item to functional specification: For example. and network interface card. • Low level configuration item to top level configuration item: For example. they are a quick reference during verification and validation tasks. Useful ones include: • Functional specification to requirements document: It shows that each requirement (obtained from a preliminary requirements statement provided by the customer or produced in the Concept Definition stage) has been covered in an appropriate section of the functional specification. Sample Traceability Matrix A traceability matrix is a report from the requirements database or repository. keyboard. may contain the low level configuration items Monitor.• put a check mark at the intersection of row and column if the configuration item satisfies the stated requirement Useful Traceability Matrices Various traceability matrices may be utilized throughout the system life cycle. Information requirements determine . the top level configuration item.

" Tracing S12 to its source makes it clear this requirement is erroneous: it must be eliminated. or the traceability corrected. . Requirements management tools capture associated information or provide the capability to add it. Reporting needs should be determined at the start of the effort and documented in the requirements management plan. A variety of reports are necessary to manage requirements. User requirement identifiers begin with "U" and system requirements with "S. rewritten.the associated information that you store with the requirements. the requirements must be of good quality. Requirements of poor quality transfer work to subsequent phases of the SDLC. The examples show forward and backward tracing between user and system requirements. increasing cost and schedule and creating disputes with the customer. For requirements tracing and resulting reports to work.

Contents:      Introduction What is Boundary Value Analysis? Purpose Applying Boundary Value Analysis Performing Boundary Value Analysis Introduction Testing experience has shown that especially the boundaries of input ranges to a software component are liable to defects.g.g. has in his code a line checking for this range. stands for the month January to December in a date.g. which e. the range 1 to 12 at an input. .Boundary Value Analysis Overview Boundary value analysis is a software testing design technique to determine test cases covering off-by-one errors. This may look like: if (month > 0 && month < 13) But a common programming error may check a wrong range e. starting the range at 0 by writing: if (month >= 0 && month < 13) For more complex range checks in a program this may be a problem which is not so easily spotted as in the above simple example. A programmer implement e. The boundaries of software component input ranges are areas of frequent problems.

. As well.... a programmer may specify >.. Applying Boundary Value Analysis To set up boundary value analysis test cases you first have to determine which boundaries you have at the interface of a software component.. -2 -1 0 1 . The trick is to concentrate software testing efforts at the extreme ends of the equivalence classes. when the requirement states > or =).. Boundary value analysis generates test cases that highlight errors better than equivalence partitioning.. This has to be done by applying the equivalence partitioning technique... For the example of the month in a date you would have the following partitions: .. At those points when input values change from valid to invalid errors are most likely to occur..... it takes into account the output specifications when deriving test cases. boundary value analysis broadens the portions of the business requirement document used to generate tests.Definition Boundary value analysis is a methodology for designing test cases that concentrates software testing effort on cases near the limits of valid ranges Boundary value analysis is a method which refines equivalence partitioning.. Unlike equivalence partitioning....g. (e. Boundary value analysis and equivalence partitioning are inevitably linked together. 12 13 14 15 .. --------------|-------------------|--------------------invalid partition 1 valid partition invalid partition 2 . Purpose The purpose of boundary value analysis is to concentrate the testing effort on error prone areas by accurately pinpointing the boundaries of conditions.

n-1.g. Even if this critical natural boundary is clearly within an equivalence partition it should lead to additional test cases checking the range around zero.which is strictly checking a software component at its interfaces. 0. In the above example this would be 0 and 1 for the lower boundary as well as 12 and 13 for the upper boundary.n+1 for the lower limit. programmers tend to have weaknesses in their programs in this range. Performing Boundary Value Analysis There are two steps: .n+1 for the upper limit and n.Applying boundary value analysis you have to select now a test case at each side of the boundary between two partitions. The boundary value analysis can have 6 testcases. this could be a division by zero problem where a zero value may occur although the programmer always thought the range started at 1. A further natural boundary is the natural lower and upper limit of the data type itself. But looking closer at the subject. n-1. Each of these pairs consists of a "clean" and a "dirty" test case. It could be a sign problem when a value turns out to be negative in some rare cases. After determining the necessary test cases with equivalence partitioning and subsequent boundary value analysis.n. A good test strategy would also check how the program reacts at an input of -1 and 0 as well as 255 and 256.g. If you are working with signed values this is especially the range around zero (-1. although the programmer always expected it to be positive. A "dirty" test case should lead to a correct and specified input error treatment such as the limiting of values. it has to lead to warning and request to enter correct data. there are cases where it applies also to white box testing. A solid testing strategy also has to consider the natural boundaries of the data types used in the program. E. A "clean" test case should give you a valid operation result of your program. +1). e. Similar to the typical range check faults. The tendency is to relate boundary value analysis more to the so called black box testing . an unsigned 8-bit value has the range of 0 to 255. the usage of a substitute value. A further set of boundaries has to be considered when you set up your test cases. without consideration of internal structures of the software. it is necessary to define the combinations of the test cases when there are multiple inputs to a software component. or in case of a program with a user interface.

you derive test cases from the equivalence classes. the valid test case quantity on hand is -9.999 through 9. The process is similar to that of equivalence partitioning but the rules for designing test cases differ. write test cases that include: 1. For example. For example. The invalid class (total quantity on hand <0) 8. then you d add the following classes to the ones you found previously: 6. With equivalence partitioning. you focus your attention on cases close to the edges of the range.999 ) STEP 2: DESIGN TEST CASES In this step. create valid test cases for each end of the range and invalid test cases just beyond each end of the range. However. The valid class ( 0 < = total quantity on hand < = 999. if a valid range of quantity on hand is -9. STEP 1: IDENTIFY EQUIVALENCE CLASSES Follow the same rules you used in equivalence partitioning.999 .999. Design test cases. if the output specifications for the inventory system stated that a report on inventory should indicate a total quantity for all products no greater than 999. If the condition is a range of values.999.999 ) 7. The invalid class (total quantity on hand> 999. you may select any test case within a range and any on either side of it with boundary analysis. Identify the equivalence classes. 2. consider the output specifications as well. Rules for Test Cases 1.1.

the invalid test case total quantity on hand is 1. A similar rule applies where the. just as you did with equivalence partitioning. Design tests that highlight the first and last records in an input or output file. and two invalid test cases. the invalid test case quantity on hand is -10.999 3. . condition states that the number of values must lie within a certain range select two valid test cases.999 3. the invalid test case total quantity on hand is -1 and 4.000 and 4. the valid test case total quantity on hand is 999. one for each boundary of the range. In our inventory example the output conditions generate the following test cases: 1.000. once again. 4. and generate a test for each of them.000 2. the invalid test case quantity on hand is 10. one just below and one just above the acceptable range. Look for any other extreme input or output conditions.000 You may combine valid classes wherever possible. the valid test case total quantity on hand is 0 2. you may not combine invalid classes. Don�t forget to consider output conditions as well. 3. and. the valid test case quantity on hand is 9.2.

coding. business analysts. An iteration may not add enough functionality to warrant releasing the product to market but the goal is to have an available release (without bugs) at the end of each iteration. Most agile teams are located in a single open office sometimes referred to as a bullpen. or the clients). This has resulted in criticism of agile methods as being undisciplined. Software developed during one unit of time is referred to as an iteration. Combined with the preference for face-to-face communication. and documentation.Agile Testing Introduction Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project. most minimize risk by developing software in short amounts of time. technical writers. At the end of each iteration. At a minimum. Each iteration is an entire software project: including planning. they may be product managers . requirements analysis. Agile methods also emphasize working software as the primary measure of progress. this includes programmers and their "customers" (customers define the product. Agile methods emphasize face-to-face communication over written documents. design. The office may include testers. which may last from one to four weeks. Contents:         History Principles behind agile methods — The Agile Manifesto Comparison with other methods Suitability of agile methods Agile data Agile methods and method tailoring Agile methods Measuring agility . and managers. testing. the team re-evaluates project priorities. interaction designers. agile methods produce very little written documentation relative to other methods. There are many agile development methods.

Agile methods emphasize face-to-face communication over written documents. There are many agile development methods. or the clients)." Later. The modern definition of agile software development evolved in the mid 1990s as part of a reaction against "heavyweight" methods. micro-managed use of the waterfall model of development.  Criticism Agile Principles History Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project. This has resulted in criticism of agile methods as being undisciplined. testing. A case can be made that agile and iterative development methods are a return to development practice seen early in the history of software development. . coding. At the end of each iteration. and adopted the name "agile methods. design. Combined with the preference for face-to-face communication. this includes programmers and their "customers" (customers define the product. Each iteration is an entire software project: including planning. business analysts. the team re-evaluates project priorities. some of these people formed The Agile Alliance. they may be product managers. interaction designers. The processes originating from this use of the waterfall model were seen as bureaucratic. agile methods were called "lightweight methods. and documentation. demeaning." In 2001. and managers. Software developed during one unit of time is referred to as an iteration. which may last from one to four weeks. Most agile teams are located in a single open office sometimes referred to as a bullpen. a non-profit organization that promotes agile development. regimented. slow. as typified by a heavily regulated. agile methods produce very little written documentation relative to other methods. and inconsistent with the ways that software developers actually perform effective work. Utah. An iteration may not add enough functionality to warrant releasing the product to market but the goal is to have an available release (without bugs) at the end of each iteration. At a minimum. requirements analysis. The office may include testers. most minimize risk by developing software in short amounts of time. Initially. Agile methods also emphasize working software as the primary measure of progress. prominent members of the community met at Snowbird. technical writers.

While that project was eventually canceled. and DSDM (1995). Extreme Programming (1996). not a single approach to software development. daily cooperation between business people and developers Face-to-face conversation is the best form of communication Projects are built around motivated individuals. who should be trusted Continuous attention to technical excellence and good design Simplicity Self-organizing teams Regular adaptation to changing circumstances . widely regarded as the canonical definition of agile development. Crystal Clear. They created the Agile Manifesto.Methodologies similar to Agile created prior to 2000—include Scrum (1986). including a book in 1999. Extreme Programming (usually abbreviated as "XP") was created by Kent Beck in 1996 as a way to rescue the struggling Chrysler Comprehensive Compensation (C3) project. continuous delivery of useful software Working software is delivered frequently (weeks rather than months) Working software is the principal measure of progress Even late changes in requirements are welcomed Close. 17 prominent figures in the field of agile development (then called "light-weight methodologies") came together at the Snowbird ski resort in Utah to discuss ways of creating software in a lighter. Feature Driven Development. the methodology was refined by Ron Jeffries' full-time XP coaching. and accompanying agile principles. Elements of Extreme Programming appear to be based on Scrum and Ward Cunningham's Episodes pattern language. Adaptive Software Development. more people-centric way. faster. Some of the principles behind the Agile Manifesto are • • • • • • • • • • • Customer satisfaction by rapid. Principles Agile methods are a family of development processes. public discussion on Ward Cunningham's Portland Pattern Repository wiki and further work by Beck. In 2001.

this time — and wrote an addendum.The publishing of the manifesto spawned a movement in the software industry known as agile software development. In 2005. Alistair Cockburn and Jim Highsmith gathered another group of people — management experts. . known as the PM Declaration of Interdependence.

Adaptive methods focus on adapting quickly to changing realities. Agile development differs from other development models as in this model time periods are measured in weeks rather than months and work is performed in a highly collaborative manner. or a statement of expected value vs. Agile methods have much in common with the "Rapid Application Development" techniques from the 1980/90s as espoused by James Martin and others Contrasted with other iterative development methods Most agile methods share other iterative and incremental development methods' emphasis on building releasable software in short time periods. An adaptive team will have difficulty describing exactly what will happen in the future. The further away a date is. When the needs of a project change. an adaptive team may only be able to report the mission statement for the release. When asked about a release six months from now. focus on planning the future in detail. An adaptive team can report exactly what tasks are being done next week. The plan is typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently. Agile methods exist on the "adaptive" side of this continuum. as it implies that agile methods are "unplanned" or "undisciplined". This distinction is misleading. Predictive teams have difficulty changing direction. A predictive team can report exactly what features and tasks are planned for the entire length of the development process. the more vague an adaptive method will be about what will happen on that date. but only which features are planned for next month. an adaptive team changes as well. Predictive methods. in contrast. and most agile methods also differ by treating their time period as a strict timebox. Predictive teams will often institute a change control board to ensure that only the most valuable changes are considered. A more accurate distinction is to say that methods exist on a continuum from "adaptive" to "predictive".Comparison with other methods Agile methods are sometimes characterized as being at the opposite end of the spectrum from "plan-driven" or "disciplined" methodologies. cost. .

This means that the waterfall model is likely to be unsuitable if requirements are not well understood or are likely to change radically in the course of the project. and testing in a strict. . As of 2004. produce completely developed and tested features (but a very small subset of the whole) every few weeks or months. The degradation of well-intended procedures can lead to activities often categorized as cowboy coding. design. Iterations are expensive. The more rigid controls systematically embedded within a process offer stronger levels of accountability of the users. Some agile teams use the waterfall model on a small scale. the waterfall model is still in common use. and continually improving it/adding further functionality throughout the life of the project. code reviews and the like.Contrasted with the waterfall model Agile development does not have much in common with the waterfall model. repeating the entire waterfall cycle in every iteration. Agile methods. analysis. The waterfall model is the most predictive of the methodologies. coding. Contrasted with Cowboy Coding Cowboy coding is the absence of a defined method: team members do whatever they feel is right. and it is difficult to react to changes in requirements. most notably Extreme Programming teams. design documents. The main problem of the waterfall model is the inflexible nature of the division of a project into separate stages. work on activities simultaneously. in contrast. so that commitments are made early on. Agile development's frequent re-evaluation of plans. Agile teams. do follow defined (and often very disciplined and rigorous) processes. the skill and experience of the users define the degree of success and/or abuse of such activity. stepping through requirements capture. As with all methodologies. emphasis on face-to-face communication. Other teams. and relatively sparse use of documents sometimes causes people to confuse it with cowboy coding. pre-planned sequence. Progress is generally measured in terms of deliverable artifacts—requirement specifications. The emphasis is on obtaining the smallest workable piece of functionality to deliver business value early. test plans. however.

communication. Similarly. Another serious problem is that initial assumptions or overly rapid requirements gathering up front may result in a large drift from an optimal solution. they share a number of common characteristics. From a product perspective. From an organizational perspective.. and often do. it's easy for a single "dominant" developer to influence or even pull the design of the target in a direction not necessarily appropriate for the project. If not. with fewer than 20 to 40 people. given the nature of human behaviour. face-to-face communication becomes more difficult. including iterative development. or even appropriate feedback. As size grows. impose solutions on a client then convince the client of the appropriateness of the solution. and the reduction of resource-intensive intermediate artifacts. they are less suitable for systems that have high criticality. and communication. Large scale agile software development remains an active research area. In relation to these areas a number of key success factors have been identified (Cohen et al. the error could be magnified rapidly.Suitability of agile methods Although agile methods differ in their practices. only to find at the end that the solution is actually unworkable. people. 2004): • • • • • The culture of the organization must be supportive of negotiation People must be trusted Fewer staff. The suitability of agile methods in general can be examined from multiple perspectives. the suitability can be assessed by examining three key dimensions of an organization: culture. . with higher levels of competency Organizations must live with the decisions developers make Organizations need to have an environment that facilitates rapid communication between team members The most important factor is probably project size. In theory. reliability and safety requirements. the developers can. though there is no complete consensus on this point. Therefore. agile methods are more suitable when requirements are emergent and rapidly changing. especially if the client defining the target product has poorly formed ideas of their needs. and a focus on interaction. the rapidly iterative nature should limit this. but it assumes that there's a negative feedback. most agile methods are more suitable for projects with small teams. Historically.

or by keeping the client in the loop during development by having them continuously trying each release. for example. In general a sense of project speed. complexity. A comparison of agile methods will reveal that they support different phases of a software development life-cycle to varying degrees. are claimed to be suitable for any agile software development project. regardless of situational characteristics. Distributed development efforts (non-co-located teams). provides a so-called ‘suitabilityfilter’ for this purpose. Strategies have been described in Bridging the Distance and Using an Agile Software Process with Development • • Mission.and life-critical efforts Command-and-control company cultures Offshore It is worth noting that several large scale project successes have been documented by organisations such as BT which have had several hundred developers situated in the UK. a more sophisticated analysis is required.This can be alleviated by separating the requirements gathering into a separate phase (a common element of Agile systems). In order to determine the suitability of agile methods individually. and challenges will guide you to the best agile methods to implement and how completely to adopt them. as well as Beck. This individual characteristic of agile methods can be used as a selection criterion for selecting candidate agile methods. . most clients are unwilling to invest this much time. The DSDM and Feature Driven Development (FDD) methods. It also makes QAing a product difficult since there are no clear test goals that don't change from release to release. Agile development's applicability to the following scenarios is open to question: • • Large scale development efforts (>20 developers). below. The problem there is that in the real world. Agile development has been widely documented (see Experience Reports. The DSDM approach. thus insulating it from the developer's influence. though scaling strategies and evidence to the contrary have been described. and Boehm and Turner as working well for small (<10 development developers) co-located teams. Agile is expected to be particularly suitable for teams facing unpredictable or rapidly changing requirements.

Barry Boehm and Richard Turner suggest that continuum has its own home ground: Agile home ground: • • • • • Low criticality Senior developers Requirements change very often Small number of developers Culture that thrives on chaos risk analysis be used to choose between adaptive ("agile") and predictive ("plan-driven") methods. it would appear that scale or geography. .Ireland and India. Models for data serve another purpose. are not necessarily barriers to success. Typically this is where projects hit legacy systems and legacy requirements. The agile framework seeks as much as possible to remove these bottlenecks with techniques such as generative data models making change fast. working collaboratively on projects and using Agile methodologies. Typically the database world will be at odds with agile development. Many times working with data systems requires lengthy requests to teams of specialists who are not used to the speed of an agile project and insist on exact and complete specifications. The authors suggest that each side of the Plan-driven home ground: • • • • • High criticality Junior developers Requirements don't change too often Large number of developers Culture that demands order Agile data One of the most challenging parts of an agile project is being agile with data. by themselves. While questions undoubtedly still arise about the suitability of some Agile methods to certain project types. often a change of one table column can be a critical issue requiring months to rebuild all the dependent applications.

It still isn't the end of the world because if you can build your data dependencies to be agile regardless of legacy systems you will start to prove the merit of the approach as all other systems go through tedious changes to catch up with data changes while in the protected agile data system the change would be trivial. There are also no experience reports in which all the XP practices have been adopted. and dynamic interplays between contexts. a partial adoption of XP practices. consisting of a number of principles. almost all agile methods are suitable for method tailoring. At a more extreme level. and method fragments determine a system development approach for a specific project situation. as suggested by Beck. As such agile projects are best suited where projects don't contain big legacy databases. But ultimately relational data issues will be important for agile projects and are a common blockage point. Potentially. has been reported on several occasions.An agile approach would try to encapsulate data dependencies to go fast and allow change. but rather practices should be tailored to the needs of individual projects. Situation-appropriateness can be considered as a distinguishing characteristic between agile methods and traditional software development methods. ‘method fragment adaptation’ and ‘situational method engineering’. intentions. could be adapted (Aydin. 2004). Agile methods and method tailoring In the literature. with the latter being relatively much more rigid and prescriptive. In the case of XP the need for method adaptation is made explicit. Practices are concrete activities and products which are part of a method framework. . the philosophy behind the method. Even the DSDM method is being used for this purpose and has been successfully tailored in a CMM context. including ‘method tailoring’. Instead. The practical implication is that agile methods allow project teams to adapt working practices according to the needs of individual projects. One of the fundamental ideas of XP is that there is no process that fits every project as such. different terms refer to the notion of method adaptation. Method tailoring is defined as: A process or capability in which human agents through responsive changes in.

in contrast. 2005). based on predefined sets of criteria. during the execution of a project (Aydin et al.Use of generic skill sets which are common across the team not reliance on specific skill sets which are scarce Test Driven Development (TDD) Feature Driven Development (FDD) Behavior Driven Development (BDD) Essential Unified Process (EssUP) Other approaches: . In such a case prescriptive route maps are not appropriate. Dynamic method adaptation. The key assumption behind static method adaptation is that the project context is given at the start of a project and remains fixed during project execution. This also means that a project context is not fixed. but changing during project execution. The result is a static definition of the project context. An emergent context implies that a project has to deal with emergent factors that affect relevant conditions but are not predictable.A distinction can be made between static method adaptation and dynamic method adaptation. assumes that projects are situated in an emergent context. route maps can be used in order to determine which structured method fragments should be used for that particular project. Given such a definition. The practical implication of dynamic method adaptation is that project managers often have to modify structured fragments or even innovate new fragments. Agile Methods Some of the well-known agile software development methods: • • • • • • • • • • • Agile Modeling Agile Unified Process (AUP) Agile Data Daily kickoff and review of goals short release cycles Responsive Development Generalism .

Another study using fuzzy mathematics has suggested that project velocity can be used as a metric of agility. Many of the criticisms.• • • • • • Software Development Rhythms Agile Documentation ICONIX Process Microsoft Solutions Framework (MSF) Agile Data Method Database refactoring Measuring agility While agility is seen by many as a means to an end. scores developments against five dimensions of a software project (duration. Criticism Agile development is sometimes criticized as cowboy coding. novelty. however. Extreme Programming is reviewed and critiqued by Matt Stephens's and Doug Rosenberg's Extreme Programming Refactored. a number of approaches have been proposed to quantify agility. the practical application of such metrics has yet to be seen. The similarly-named Agility Measurement Index. risk. effort. While such approaches have been proposed to measure agility. Other techniques are based on measurable goals. In particular. Criticisms include: • Lack of structure and necessary documentation . such as McBreen and Boehm and Turner. such as pair programming and continuous design. are believed by Agile practitioners to be misunderstandings of agile development. Extreme Programming's initial buzz and controversial tenets. Agility Index Measurements (AIM) score projects against a number of agility factors to achieve a total. and interaction). have attracted particular criticism.

Whereas if a plan was there to be followed. Agile Principles There are ten principles of Agile Testing: Agile Principle #1: Active user involvement is imperative It's not always possible to have users directly involved in development projects. because at the beginning of the project no one knows the entire scope/requirements Drastically increases the chances of scope creep due to the lack of detailed requirements documentation The criticisms regarding insufficient software design and lack of documentation are addressed by the Agile Modeling method which can easily be tailored into agile processes such as XP. Agile software development has been criticized because it will not bring about the claimed benefits when programmers of average ability use this methodology. particularly if the Agile Development project is to build a product where the real end users will be external customers or consumers. the same programming may need to be done several times over. and most development teams are indeed likely to be made up of people with average (or below) skills. a single area of code is expected to be written once.• • • • • Only works with senior-level developers Incorporates insufficient software design Requires too much cultural change to adopt Can lead to more difficult contractual negotiations Can be very inefficient -. . • • Impossible to develop realistic estimates of work effort needed to provide a quote.if the requirements for one area of code change through various iterations.

Not convinced? Here's 16 reasons why! • • • • • • • • • • • • • • • • Requirements are clearly communicated and understood (at a high level) at the outset Requirements are prioritised appropriately based on the needs of the user and market Requirements can be clarified on a daily basis with the entire project team.business and technical .work together! Agile Principle #2: Agile Development teams must be empowered . issues. it’s not a customer-supplier relationship but a joint team effort Timely decisions can be made. the whole team . the team is responsible together for delivery of the product Individuals are accountable. priorities. reporting for themselves in daily updates that involve the user/business When the going gets tough. sharing progress openly with the user/business every day There is complete transparency as there is nothing to hide The user/business shares responsibility for issues arising in development. rather than resorting to lengthy documents that aren't read or are misunderstood Emerging requirements can be factored into the development schedule as appropriate with the impact and trade-off decisions clearly understood The right product is delivered As iterations of the product are delivered. and when the product is ready Responsibility is shared.In this event it is imperative to have a senior and experienced user representative involved throughout. about features. that the product meets user expectations The product is more intuitive and easy to use The user/business is seen to be interested in the development on a daily basis The user/business sees the commitment of the team Developers are accountable.

users are educated that it’s much more expensive to change or add requirements during or after the software is built. Active user involvement is one of the key principles to enable this. The project team must be empowered to make decisions in order to ensure that it is their responsibility to deliver the product and that they have complete ownership. Agile Principle #3: Time waits for no man! In Agile Development. The team must establish and clarify the requirements together. However this is a key principle for me. because it’s much more efficient. Traditionally. Somehow we’ve all been trained over the years that we must be 100% efficient (or more!) and having the whole team involved in these kick-off steps seems a very expensive way to do things. This is in stark contrast to a traditional development project. Some organisations quote some impressive statistics designed to frighten users into freezing the scope. the team feels a real sense of ownership. The result: It . Any interference with the project team is disruptive and reduces their motivation to deliver. and estimate the effort involved together. It may seem expedient to skip this level of team involvement at the beginning. and make them on a timely basis. but timescales are fixed. where one of the earliest goals is to capture all known requirements and baseline the scope so that any other changes are subject to change control. prioritise them together. something that later pays dividends. And then it's doesn't seem so expensive. When challenges arise throughout the project. agree to the tasks required to deliver them together. It ensures the buy-in and commitment from the entire project team from the outset.requirements evolve. It’s tempting to get a subset of the team to do this (maybe just the product owner and analyst). so the user or user representative from the business must be closely involved on a daily basis.An Agile Development project team must include all the necessary team members to make decisions.

with change control processes designed to minimise and resist change wherever possible. . Traditional projects fight change. requirements are allowed to evolve. It does. however. Agile Development projects accept change. in fact they expect it. to build the right solution using a traditional approach to software development. Because the only thing that’s certain in life is change. In Agile Development projects. So to include a new requirement. but the timescale is fixed. it is impossible to think of everything. Ironically. this will always be the case because you cannot really know for sure what you want until you see and use the software. And in the time you would have spent analysing and reviewing requirements and designing a solution. Equally. Agile Development works on the premise that requirements emerge and evolve. Agile Development works on a completely different premise. because we all know Phase 2’s are invariably hard to get approved once 80% of the benefits have been realised from Phase 1. users may actually use only a tiny proportion of any software product. yet many projects start life with a bloated scope. also pre-suppose that there’s enough nonmandatory features included in the original timeframes to allow these trade-off decisions to occur without fundamentally compromising the end product. There are different mechanisms in Agile Development to handle this reality. it’s all important for the first release. even if the requirements are carefully analysed and prioritised. By contrast.becomes imperative to include everything they can think of – in fact everything they ever dreamed of! And what’s more. and that however much analysis and design you do. or to change a requirement. So if you believe that point – that no-one can really know what the right solution is at the outset when the requirements are written – it’s inherently difficult. and things are understood differently by different people. This ensures the team can remain focused on the agreed timescale. In part. and allows the product to evolve into the right solution. external conditions could also have changed. the user or product owner must remove a comparable amount of work from the project in order to accommodate the change. perhaps even practically impossible. this is because no-one is really sure at the outset which 20% of the product their users will actually use. things change. perhaps as low as 20% or less.

. In Agile Development. just-in-time for each feature to be developed. JFDI! That approach is not so much Agile but Fragile! Although Agile Development is much more flexible than more traditional development methodologies. it’s imperative to start development (dependencies permitting) with the core. highest priority features. i. not the cost and timescale.So what does the business expect from its development teams? Deliver the agreed business requirements. it is always the scope (or features of the product) that are variable. and can make plans based on a launch date that is certain.e. The rationale for this is to minimise the time spent on anything that doesn’t actually form part of the end product. Something must be variable in order for the project to succeed. All software development professionals will be well aware that you cannot realistically fix all of these factors and expect to meet expectations. based on the resources it can afford to invest in the project. the result is that the business has a fixed budget. Although the scope of an Agile Development project is variable. Agile Development does nevertheless have quite a bit of rigour and is based on the fairly structured approach of lean manufacturing as pioneered by Toyota. For this philosophy to work. the absolute minimum required to enable development and testing to proceed with reasonable efficiency. you just make things up as you go along – in other words. Agile Principle #4: Agile requirements are barely sufficient! Agile Development teams capture requirements at a high level and on a piecemeal basis. it is acknowledged that only a fraction of any product is really used by its users and therefore that not all features of a product are really essential. Agile requirements are ideally visual and should be barely sufficient. Agile Development can be mistaken by some as meaning there’s no process. Unlike most traditional software development projects. on time and within budget. and of course to an acceptable quality. making sure they are delivered in the earliest iterations.

whereas the features are variable. perhaps for example as a storyboard of the user interface. you can stand around the T-card system and whiteboard discussing progress. why. requirements should be understood enough to determine the outline scope of the product and produce high level budgetary estimates and no more. working together in a highly collaborative way so that all team members understand the requirements as well as each other. Requirements are broken down into very small pieces in order to achieve this. An Agile Development team (including a key user or product owner from the business) visualises requirements in whiteboarding sessions and creates storyboards (sequences of screen shots. It is not necessarily the remit of one person. visuals. The advantage this has over lengthy documentation is that it's extremely visual and tangible. on a card and use a T-card system to allow stories to be moved around easily as the user/business representative on the project adjusts priorities. And just as importantly. These are fundamentally similar to Use Cases but are lightweight and more simplistic in their nature. issues and priorities. and actually the fact it’s going on a card forces it to be broken down small. sketches or wireframes) to show roughly how the solution will look and how the user’s interaction will flow in the solution. A common approach amongst Agile Development teams is to represent each requirement. use case or user story. challenge and understand what’s needed. There is no lengthy requirements document or specification unless there is an area of complexity that really warrants it. Otherwise the storyboards are just annotated and only where necessary. Ideally. . At this stage.However any requirements captured at the outset should be captured at a high level and in a visual format. the user/business representative physically has to remove a comparable amount of work from scope before they can place the new card into the project. The timeframe of an Agile Development is fixed. Should it be necessary to change priority or add new requirements into the project. to gather the requirements independently and write them all down. like the Business Analyst in more traditional projects. XP (eXtreme Programming) breaks requirements down into small bite-size pieces called User Stories. Agile Development teams capture these high level requirements in workshops. it’s a joint activity of the team that allows everyone to contribute.

delivering small. Cards can of course be backed up by documentation as appropriate. Analyse. accept change. incremental *releases* and iterating. 2 working days) and preferably no more than 8 hours. Develop. Test . requirements (or features or stories.first gathering all known requirements for the whole product. being able to release the product whenever it's deemed good enough. and so on. Test. one feature at a time.This is a big contrast to a common situation where the business owner sends numerous new and changed requirements by email and/or verbally. In more traditional software development projects. doing each step for each feature. then developing all elements of the software. in fact they expect it. and always broken down into very small units. so progress can be measured objectively on a daily basis.. the cycle is Analyse. one of the most common reasons for software development projects to fail. then testing that the entire product is fit for release. Using the Scrum agile management practice. by contrast. Develop. agile software development projects are delivered in small bitesized pieces. Test. but always the principle of agile development is to document the bare minimum amount of information that will allow a feature to be developed. But they manage change by fixing the timescales and trading-off features.e. whatever language you prefer to use) are broken down into tasks of no more than 16 hours (i. Traditional project teams that don't control changes can end up with the dreaded scope creep. the (simplified) lifecycle is Analyse. Develop. rather than having to wait for all intended features to be ready . Advantages of this iterative approach to software development include: • • Reduced risk: clear visibility of what's completed to date throughout a project Increased value: delivering some benefits early. Agile Principle #5: How d'you eat an elephant? One bite at a time! Likewise. Agile teams.. somehow expecting the new and existing features to still be delivered in the original timeframes. In agile software development.

Only when you've completed all your must-have features. quality and readiness for release.as in agile software development. In a truly agile world. whereas later features of the software are increasingly less sophisticated as time runs out. a 3-6 month project is strategic! Nowhere is this more true than on the web. Building the features of the software ”broad but shallow” is also advisable for the same reason. And with the luxury of centrally hosted solutions. there's every opportunity to break what would have traditionally been a project into a list of features. like all-too-many software development projects. . and only then move on to the could-haves. the timescales are fixed. Ideally each item on the list should always be something of value to the user. not necessarily in a logical order by function. user stories. Try to keep your product backlog or feature list expressed in terms of use cases. you run over budget. to the extent that it's ready to be shipped.not technical tasks. or features . gone are the days of the 12 month project.• • More flexibility/agility: can choose to change direction or adapt the next iterations based on actually seeing and using the software Better cost management: if. Another practicality is to make sure features are developed in *priority* order. In an agile world. each feature must be fully developed. Otherwise you could run out of time. Otherwise you can get into a situation where your earlier features are functionally rich. and always deliverables rather than activities so you can 'kick the tyres' and judge their completeness. you don't have to scrap the whole thing if you run short of funds For this approach to be practical. some value can still be realised. before moving on. The web is a fast moving place. having built some of the less important features .ideally even feature by feature. Agile Principle #6: Fast but not so furious! Agile software development is all about frequent delivery of products. and deliver incrementally on a very regular basis . move on to the shouldhaves.

why wouldn't you want to derive some benefits early? Why wouldn't you want to hear real user/customer feedback before you build 'everything'? Why wouldn't you want to look at your web metrics and see what works. "done" doesn't really mean "DONE!". It doesn't necessarily mean styled. So how frequent is *frequent*? Scrum says break things into 30 day Sprints. In this situation. with traditional projects of 612 months+. And it certainly doesn't usually mean accepted by the product owner. and so on. before building 'everything'? And this is only really possible due to some of the other important principles of agile development.0 world. requirements being lightweight and captured just-intime. . Too often in software development. should be 100% complete by the end of the Sprint. It just means developed. The iterative approach. Features developed within an iteration (Sprint in Scrum). being feature-driven. It doesn't mean tested.On the web. That's certainly frequent compared to most traditional software development projects. Consider a major back-office system in a large corporation. it's increasingly accepted for products to be released early (when they're basic. testing integrated throughout the lifecycle. not when they're faulty!). Agile Principle #7: "done" means "DONE!" In agile development. Particularly in the Web 2. and what doesn't. and all the implications of a big rollout and potentially training to hundreds of users. 30 days is a bit too frequent I think. "done" should really mean "DONE!". The overhead of releasing the software is just too large to be practical on such a regular basis. it's a kind of perpetual beta.

But the feature on its own merit should be shippable.In an ideal situation. The feature may rely on other features being completed before the product could really be shipped. each iteration or Sprint should lead to a release of the product. tested.. in agile development. It's also important to really complete each feature before moving on to the next. So. On projects it's not feasible to do a release after every Sprint. do not move on to a new feature until the last one is shippable. This is important to ensure the overall product is in a shippable state at the end of the Sprint. not in a state where multiple features are 90% complete or untested. styled. as is more usual in traditional development projects. Of course multiple features can be developed in parallel in a team situation. and accepted by the product owner before counting it as "DONE!". Certainly that's the case on BAU (Business As Usual) changes to existing products. however completing each feature in turn enables a very precise view of progress and how far complete the overall project really is or isn't. And if there's any doubt about what activities should or shouldn't be completed within the Sprint for each feature. So if you're ever unsure if a feature is 'done enough'. But within the work of each developer. ask one simple question: "Is this feature ready to be shipped?". make sure that each feature is fully developed.. "done" really should mean "DONE!". . "DONE!" should mean shippable. In agile development.

testing the software continuously throughout its development. we should try to apply the 80/20 rule. Agile Principle #9: Agile testing is not for dummies! In agile development.not literally 80/20 but certainly the principle that the majority of your results will often come from the minority of your efforts. is going the extra mile and has a diminishing return that may not be worthwhile. if you have control over the scope. and if speed-to-market is of primary importance. It just means that developing some features. why not seek to deliver the important 80% of your product in just 20% of the time? In fact. In agile development. . in that particular scenario. or the richness of some features. seeking to focus on the important 20% of effort that gets the majority of the results. The theory is about the law of distribution and how many things have a similar distribution curve. that doesn't mean your product should be fundamentally flawed. This means that *typically* 80% of your results may actually come from only 20% of your efforts! areto's law can be seen in many situations . a bad or full of faults. So does that statement conflict with my other recent post: "done means DONE!"? Not really. testing is integrated throughout the lifecycle. So the really smart people are the people who can see (up-front without the benefit of hindsight) *which* 20% to focus on. If the quality of your application isn't life-threatening. Because within each Sprint or iteration. what you *do* choose to develop *does* need to be 100% complete within the iteration.Agile Principle #8: Enough's enough! Pareto's law is more commonly known as the 80/20 rule. you could ask why you would ever bother doing the last 20%? user experience.

so integration is done as you go too. iterative. so it can be shipped whenever it's appropriate. and the emphasis on conversation and collaboration to clarify requirements more than the traditional approach of specifications and documentation. Apart from being geared towards better quality software. With automated repeatable unit tests. Although requirements can be clarified in some detail in agile development (as long as they are done just-in-time and not all up-front). testing can be done as part of the build. ensuring that all features are working correctly each time the build is produced. at least daily. The purpose of these principles is to keep the software in releasable condition throughout the development. writing tests before writing the software. so how can they possibly test it? . The XPeXtreme Programming) agile methodology goes further still. There is still a very important role for professional testers. There are considerable advantages having testers involved from the outset This is compounded further by the lightweight approach to requirements in agile development. incremental releases.Agile development does not have a separate test phase as such.particularly from those moving from a much more formal environment . XP recommends test driven development. Developers are much more heavily engaged in testing. it is quite possible for this to result in some ambiguity and/or some cases where not all team members have the same understanding of the requirements. into a role more akin to quality assurance than purely testing. this is also important to support the principle of small. as we all know "developers can't test for toffee!" :-) The role of a tester can change considerably in agile development. So what does this mean for an agile tester? A common concern from testers moving to an agile development approach . They don't have a detailed spec to test against.is that they don't know precisely what they're testing for. writing automated repeatable unit tests to validate their code. And builds should be regular. But testing shouldn't only be done by developers throughout the development.

Even in a more traditional development environment, I always argued that testers could test that software meets a spec, and yet the product could still be poor quality, maybe because the requirement was poorly specified or because it was clearly written but just not a very good idea in the first place! A spec does not necessarily make the product good! In agile development, there's a belief that sometimes - maybe even often - these things are only really evident when the software can be seen running. By delivering small incremental releases and by measuring progress only by working software, the acid test is seeing the software and only then can you really judge for sure whether or not it's good quality. Agile testing therefore calls for more judgement from a tester, the application of more expertise about what's good and what's not, the ability to be more flexible and having the confidence to work more from your own knowledge of what good looks like. It's certainly not just a case of following a test script, making sure the software does what it says in the spec. And for these reasons, agile testing is not for dummies!

Agile Principle #10: No place for snipers!

Agile development relies on close cooperation and collaboration between all team members Agile development principles and include keeping requirements and stakeholders. documentation

lightweight, and acknowledging that change is a normal and acceptable reality in software development. This makes close collaboration particularly important to clarify requirements just-in-time and to keep all team members (including the product owner) 'on the same page' throughout the development. You certainly can't do away with a big spec up-front *and* not have close collaboration. You need one of them that's for sure. And for so many situations the latter can be more effective and is so much more rewarding for all involved!

In situations where there is or has been tension between the development team and business people, bringing everyone close in an agile development approach is akin to a boxer keeping close to his opponent, so he can't throw the big punch! :-) But unlike boxing, the project/product team is working towards a shared goal, creating better teamwork, fostering team spirit, and building stronger, more cooperative relationships. There are many reasons to consider the adoption of agile development, and in the near future I'm going to outline "10 good reasons to go agile" and explain some of the key business benefits of an agile approach.

If business engagement is an issue for you, that's one good reason to go agile you shouldn't ignore.

Software Development Life Cycle Models
I was asked to put together this high-level and traditional software life cycle information as a favor for a friend of a friend, so I thought I might as well share it with everybody.

The General Model
Software life cycle models describe phases of the software cycle and the order in which those phases are executed. There are tons of models, and many companies adopt their own, but all have very similar patterns. The general, basic model is shown below: General Life Cycle Model

Each phase produces deliverables required by the next phase in the life cycle. Requirements are translated into design. Code is produced during implementation that is driven by the design. Testing verifies the deliverable of the implementation phase against requirements.

Business requirements are gathered in this phase. This phase is the main focus of the project managers and stake holders. Meetings with managers, stake holders and users are held in order to determine the requirements. Who is going to use the system? How will they use the system? What data should be input into the system? What data should be output by the system? These are general questions that get answered during a requirements gathering phase. This produces a nice big list of functionality that the system should provide, which describes functions the system should perform, business logic that processes data, what data is stored and used by the system, and how the user interface should work. The overall result is the system as a whole and how it performs, not how it is actually going to do it.

The software system design is produced from the results of the requirements phase. Architects have the ball in their court during this phase and this is the phase in which their focus lies. This is where the details on how the system will work is produced. Architecture, including hardware and software, communication, software design (UML is produced here) are all part of the deliverables of a design phase.

Code is produced from the deliverables of the design phase during implementation, and this is the longest phase of the software development life cycle. For a developer, this is the main focus of the life cycle because this is where the code is produced. Implementation my overlap with both the design and testing phases. Many tools exists (CASE tools) to actually automate the production of code using information gathered and produced during the design phase.

while system tests act on the system as a whole. each phase must be completed in its entirety before the next phase can begin. also referred to as a linear-sequential life cycle model. Waterfall Life Cycle Model Advantages • • • • Simple and easy to use. Disadvantages • • Adjusting scope during the life cycle can kill a project No working software is produced until late during the life cycle. . Unlike what I mentioned in the general model. Unit tests act on a specific component of the system. It is very simple to understand and use. At the end of each phase. that is a very basic overview of the general software development life cycle model. Unit tests and system/acceptance tests are done during this phase. Waterfall Model This is the most common and classic of life cycle models.Testing During testing. a review takes place to determine if the project is on the right path and whether or not to continue or discard the project. Easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process. In a waterfall model. Phases are processed and completed one at a time. the implementation is tested against the requirements to make sure that the product is actually solving the needs addressed and gathered during the requirements phase. Now lets delve into some of the traditional and widely used variations. Works well for smaller projects where requirements are very well understood. So in a nutshell. phases do not overlap in a waterfall model.

Testing is emphasized in this model more so than the waterfall model though. The high-level design phase focuses on system architecture and design. during each of the phases preceding implementation. the V-Shaped life cycle is a sequential path of execution of processes. Works well for small projects where requirements are easily understood.• • • • High amounts of risk and uncertainty. Each phase must be completed before the next phase begins. a system test plan is created. V-Shaped Model Just like the waterfall model. V-Shaped Life Cycle Model Advantages • • • • Simple and easy to use. and unit tests are created in this phase as well. Higher chance of success over the waterfall model due to the development of test plans early on during the life cycle. The testing procedures are developed early in the life cycle before any coding is done. again. The implementation phase is. Before development is started. Requirements begin the life cycle model just like the waterfall model. Once coding is complete. Poor model where requirements are at a moderate to high risk of changing. Poor model for complex and object-oriented projects. The low-level design phase is where the actual software components are designed. The test plan focuses on meeting the functionality specified in the requirements gathering. Each phase has specific deliverables. where all coding takes place. Poor model for long and ongoing projects. An integration test plan is created in this phase as well in order to test the pieces of the software systems ability to work together. Disadvantages . the path of execution continues up the right side of the V where the test plans developed earlier are now put to use.

Subsequent iterations build on the initial software produced during the first iteration. Cycles are divided up into smaller. so you have working software early on during the software life cycle. Model doesn’t provide a clear path for problems found during testing phases. Incremental Model The incremental model is an intuitive approach to the waterfall model. A software project . A working version of software is produced during the first iteration. Easier to manage risk because risky pieces are identified and handled during its iteration. Spiral Model The spiral model is similar to the incremental model. more easily managed iterations.• • • • Very rigid. like the waterfall model. Each iteration passes through the requirements. so no early prototypes of the software are produced. Each iteration is an easily managed milestone. Software is developed during the implementation phase. Problems may arise pertaining to system architecture because not all requirements are gathered up front for the entire software life cycle. More flexible – less costly to change scope and requirements. Multiple development cycles take place here. with more emphases placed on risk analysis. Risk Analysis. implementation and testing phases. design. Incremental Life Cycle Model Advantages • • • • • Generates working software quickly and early during the software life cycle. Easier to test and debug during a smaller iteration. Disadvantages • • Each phase of an iteration is rigid and do not overlap each other. making the life cycle a “multi-waterfall” cycle. Engineering and Evaluation. Little flexibility and adjusting scope is difficult and expensive. The spiral model has four phases: Planning.

The baseline spiral. Each subsequent spirals builds on the baseline spiral. Software is produced early in the software life cycle. and the radius of the spiral represents cost. Spiral Life Cycle Model Advantages • • • High amount of risk analysis Good for large and mission-critical projects. starting in the planning phase. requirements are gathered and risk is assessed. a process is undertaken to identify risk and alternate solutions. Software is produced in the engineering phase. The evaluation phase allows the customer to evaluate the output of the project to date before the project continues to the next spiral. along with testing at the end of the phase. . the angular component represents progress. A prototype is produced at the end of the risk analysis phase.repeatedly passes through these phases in iterations (called Spirals in this model). Requirements are gathered during the planning phase. In the spiral model. In the risk analysis phase.

Doesn’t work well for smaller projects. . Risk analysis requires highly specific expertise.Disadvantages • • • • Can be a costly model to use. Project’s success is highly dependent on the risk analysis phase.

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->