Basics of Software Testing. For Beginners. B.K.Venkata.UdayKumar

Transcription

1 Basics of Software Testing For Beginners B.K.Venkata.UdayKumar

2 Table of Contents INTRODUCTION... 4 WHAR IS ERROR, FAULT, AND FAILURE?... 4 WHAT IS SOFTWARE TESTING?... 4 WHY DOES SOFTWARE HAVE BUGS?... 4 HOW TESTING CAN BE DONE?... 4 V-V MODEL OS SOFTWARE TESTING:... 5 TYPES OF TESTING... 5 UNIT TESTING... 6 WHY DO UNIT TESTING? WHY IT IS IMPORTANT?... 6 INTEGRATION TESTING... 6 APPROACHES/METHODOLOGIES/STRATEGIES of INTEGRATION TESTING... 6 BIG BANG APPROACH... 6 INCREMENTAL APPROACH... 6 BOTTOM UP APPROACH... 6 TOP DOWN APPROACH... 6 ACCEPTANCE TESTING... 7 SANITY /SMOKE TESTING... 7 MAINTENANCE TESTING AND REGRESSION TESTING... 7 NON-FUNCTIONAL TESTING... 7 ARTIFACTS OF TESTING... 7 TEST PLAN... 7 TEST PLAN OUTLINE (IEEE 829 Format)... 7 TRACEABILITY MATRIX... 8 TEST CASE... 9 FIELDS IN TEST CASES:... 9 TEST SCRIPT... 9 TEST SUITE TEST DATA... 10

3 BUG /DEFECT DESCRIPTION OF VARIOUS STAGES WHAT IS SEVERITY AND PRIORITY OF BUG HOW WILL YOU REPORT THIS BUG EFFECTIVELY? SOME MORE TESTING TYPES HOW TO DELIVER HIGH VALUE SOFTWARE? SOFT SKILLS FOR A SCRUM TEAM: TEAM SPIRIT COMMUNICATION COMMITMENT PROBLEM SOLVING TRANSPARENCY SCRUM RESULT ROLE OF TESTER ATTITUDE OF A GOOD SOFTWARE TESTER CHALLENGES IN SOFTWARE TESTING SOFTWARE TEST AUTOMATION WHY AUTOMATION TESTING GOOD AUTOMATION FRAMEWORK PRACTICES DESIGN STEPS OF THE APPROACH FOR TEST AUTOMATION: GUIDELINES FOLLOWED FOR IDENTIFICATION OF TEST CASES FOR AUTOMATION WEB TESTING/MOBILE WEB TESTING USEFUL BOOKS AND WEBSITE LINKS... 19

4 INTRODUCTION WHAR IS ERROR, FAULT, AND FAILURE? Error people make errors. A good synonym is mistake. When people make mistakes while coding; we call these mistakes bugs. Error refers to the difference between the expected output and actual output of the software. Fault a fault is the result of an error. It is more precise to say that a fault is the representation of an error. For all practical purposes, Fault/Bug/Defect is synonymous. Failure a failure occurs when a fault executes. Failure is the inability of a system or component to perform a required function according to its specification. WHAT IS SOFTWARE TESTING? Software testing is a process used to identify the correctness, completeness, and quality of developed computer software. It includes a set of activities conducted with the intent of finding errors in software so that it could be corrected before the product is released to the end users. In simple words, software testing is an activity to check whether the actual results match the expected results and to ensure that the software system is defect free. Process of execution of a program with the intention of finding errors. Process of exercising or evaluating the system component by manual or automated means to verify that it satisfies specified requirements. WHY DOES SOFTWARE HAVE BUGS? Miscommunication or no communication Software complexity o A non-trivial application has an inherent complexity Programming errors Changing requirements o The customer may not understand the effect of changes. Improperly controlled changes may play havoc with the application Poorly documented code O Incomplete, incorrect, inadequate, vague, missing documentation leading to differing interpretations and messing up of construction or maintenance. It is tough to maintain and modify code that is badly written or poorly documented and risky too. Lack of resources, time pressures and bad practices may mean poor documentation HOW TESTING CAN BE DONE? Testing can be performed in two ways, either Manual or through Automation.

5 V-V MODEL OS SOFTWARE TESTING: The V-V means Verification and Validation. The V&V model explains the activities that are carried out during verification and validation. Basically, verification methods are static, i.e. the code is not executed. Verification methods are: reviews, inspections, code walkthroughs, etc. As seen on the left side of the V-V model. Validation activities include, executing the code, in unit testing, integration testing, system testing & acceptance testing, as seen on the right hand side of the V-V model. Advantages of the V-V -Model : Testing is carried out in parallel to the development at all phases. Closer coordination can exist between development and testing teams. Testing is done in phases. Early detection of defects. Disadvantages of the V-V -Model: In practice there could be an overlap between phases during development. Phases appropriate for a specific development project could be too long or too short for the corresponding testing activities. When there is an overlap between phases during development, the complexity of the model might increase. Too Long or too short testing activities could result in phase mismatch or idle time. TYPES OF TESTING

6 UNIT TESTING Unit testing of software applications is done during the development (coding) of an application. The objective of unit testing is to isolate a section of code and verify its correctness. In procedural programming a unit may be an individual function or procedure The goal of unit testing is to isolate each part of the program and show that the individual parts are correct. Unit testing is usually performed by the developer. WHY DO UNIT TESTING? WHY IT IS IMPORTANT? Sometimes software developers attempt to save time by doing minimal unit testing. This is a myth because skimping on unit testing leads to higher defect fixing costs during system testing, integration testing and even beta testing after the application is completed. Proper unit testing done during the development stage saves both time and money in the end. INTEGRATION TESTING In Integration Testing, individual software modules are integrated logically and tested as a group. A typical software project consists of multiple software modules, coded by different programmers. Integration testing focuses on checking data communication amongst these modules. Hence it is also termed as I & T (Integration and Testing), String Testing and sometimes Thread Testing. APPROACHES/METHODOLOGIES/STRATEGIES OF INTEGRATION TESTING Big Bang Approach : Incremental Approach: which is further divided into following o Top Down Approach o Bottom Up Approach o Sandwich Approach - Combination of Top Down and Bottom Up Below are the different strategies, the way they are executed and their limitations as well advantages. BIG BANG APPROACH Here all component are integrated together at once, and then tested. INCREMENTAL APPROACH This process is carried out by using dummy programs called Stubs and Drivers. Stubs and Drivers do not implement the entire programming logic of the software module but just simulate data communication with the calling module. Stub: Is called by the Module under Test. Driver: Calls the Module to be tested. BOTTOM UP APPROACH In the bottom up strategy, each module at lower levels is tested with higher modules until all modules are tested. It takes help of Drivers for testing TOP DOWN APPROACH In Top to down approach, testing takes place from top to down following the control flow of the software system. Takes help of stubs for testing.

7 ACCEPTANCE TESTING Acceptance test is usually done at client location, by the client, once all the defects found in System testing phase are fixed. Focus of Acceptance test is not to find defects but to check whether meet their requirements.since this is the first time, the client sees their requirements which is plain text into an actual working system SANITY /SMOKE TESTING SMOKE testing is done to check critical functionalities of the system before its is accepted for major testing. Sanity testing is quick and is non- exhaustive. Goal is not to find defects but to check system health MAINTENANCE TESTING AND REGRESSION TESTING Usually, any maintenance test done is followed by a regression test run. Once deployed, testing any further system changes, enhancements or corrections forms part of Maintenance Testing Regression testing is carried out to check modification in software has not caused unintended adverse side effects. NON-FUNCTIONAL TESTING Apart from Functional testing, non functional requirements like performance, usability, and load factor are also important. Performance testing is carried out to check & fine tune system response times. The goal of performance testing is to reduce response time to an acceptable level Security Testing (Application Security, Network Security, System Security) ARTIFACTS OF TESTING TEST PLAN A Software Test Plan is a document describing the testing scope and activities. It is the basis for formally testing any software/product in a project. TEST PLAN OUTLINE (IEEE 829 FORMAT)

8 TRACEABILITY MATRIX

9 A traceability matrix is a table that correlates requirements or design documents to test documents. It is used to change tests when related source documents are changed, to select test cases for execution when planning for regression tests by considering requirement coverage. TEST CASE Test case is the document and is designed by the tester based on the SRS document and Usecase document. Test case is set of activites with expected and actual results executed in secquence to validate the feature of an application. Test cases is a sequence of steps to test the correct behavior of a functionality/feature of an application. Test cases is a sequence of steps to test the correct behavior of a functionality/feature of an application FIELDS IN TEST CASES: Test case id: Pre-Condition: Test data(input Values): Description: Steps to be Executed: Expected Result: Actual Result: Status of the Test(Pass/Fail): Comments: TEST SCRIPT A test script is a short program written in a programming language used to test part of the functionality of a software system. A written set of steps that should be performed automatically can also be called a test script, however this is more correctly called a test case. Any test that is written as a short program is regarded as an automated test. Test scripts written as a short program can either be written using a special manual functional GUI test tool or in a well-known programming language (such as C++, C#, Tcl, Expect, Java, Perl, Python, or more recently, Ruby). Automated test tools can test many areas of system functionality such as the user interface, performance of the system, the system code and the requirements.

10 TEST SUITE A test suite, less commonly known as a validation suite, is a collection of test cases that are intended to be used to test a software program to show that it has some specified set of behaviours. A test suite often contains detailed instructions or goals for each collection of test cases and information on the system configuration to be used during testing. A group of test cases may also contain prerequisite states or steps, and descriptions of the following tests. TEST DATA Test data is the data that is used in tests of a software system. In order to test a software application you need to enter some data for testing most of the features. Any such specifically identified data which is used in tests is known as test data. Test data is generated by testers or by automation tools which support testing. Most of the times in regression testing the test data is re-used, it is always a good practice to verify the test data before reusing it in any kind of test. BUG /DEFECT From discovery to resolution a defect moves through a definite lifecycle called the defect lifecycle In software development process, the bug has a life cycle. The bug should go through the life cycle to be closed. A specific life cycle ensures that the process is standardized. The life cycle of the bug can be shown diagrammatically as follows: The different states of a bug can be summarized as follows: 1. New 2. Open 3. Assign 4. Test 5. Verified 6. Deferred 7. Reopened 8. Duplicate 9. Rejected, and

11 10. Closed DESCRIPTION OF VARIOUS STAGES 1. New: When the bug is posted for the first time, its state will be NEW. This means that the bug is not yet approved. 2. Open: After a tester has posted a bug, the lead of the tester approves that the bug is genuine and he changes the state as OPEN. 3. Assign: Once the lead changes the state as OPEN, he assigns the bug to corresponding developer or developer team. The state of the bug now is changed to ASSIGN. 4. Test: Once the developer fixes the bug, he has to assign the bug to the testing team for next round of testing. Before he releases the software with bug fixed, he changes the state of bug to TEST. It specifies that the bug has been fixed and is released to testing team. 5. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software. 6. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to REJECTED. 7. Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to DUPLICATE. 8. Verified: Once the bug is fixed and the status is changed to TEST, the tester tests the bug. If the bug is not present in the software, he approves that the bug is fixed and changes the status to VERIFIED. 9. Reopened: If the bug still exists even after the bug is fixed by the developer, the tester changes the status to REOPENED. The bug traverses the life cycle once again. 10. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to CLOSED. This state means that the bug is fixed, tested and approved. While defect prevention is much more effective and efficient in reducing the number of defects, most organization conducts defect discovery and removal. Discovering and removing defects is an expensive and inefficient process. It is much more efficient for an organization to conduct activities that prevent defects. WHAT IS SEVERITY AND PRIORITY OF BUG Severity: How bad the defect and it s reflected or impact on the s/w application with respect to the custom requirement and on the user. Severity given by the test engineer. Priority: How important the bug when it is to fix it should be fixed on the basis of importance of requirement. Priority of the defect decides by the Development team member. Severity& Priority Levels of a Bug 1. Critical / Show Stopper An item that prevents further testing of the product or function under test can be classified as Critical Bug. No workaround is possible for such bugs. Examples of this include a missing menu option or security permission required to access a function under test. 2. Major / High A defect that does not function as expected/designed or cause other functionality to fail to meet requirements can be classified as Major Bug. The workaround can be provided for such bugs. Examples of this include inaccurate calculations; the wrong field being updated, etc.

12 3. Average / Medium The defects which do not conform to standards and conventions can be classified as Medium Bugs. Easy workarounds exists to achieve functionality objectives. Examples include matching visual and text links which lead to different end points. 4. Minor / Low Cosmetic defects which does not affect the functionality of the system can be classified as Minor Bugs. HOW WILL YOU REPORT THIS BUG EFFECTIVELY? Your Bug Report should contain following information Attribute Bug Name Bug ID Area Path Description Application crash on clicking the SAVE button while creating a new user. (It will be automatically created by the BUG Tracking tool once you save this bug) USERS menu > New Users Build Number Version Number Severity HIGH (High/Medium/Low) or 1 Priority HIGH (High/Medium/Low) or 1 Assigned to Reported By Reported On Reason Status Developer-X Your Name Date Defect New/Open/Active (Depends on the Tool you are using) Environment Windows 2003/SQL Server 2005 Environment Windows 2003/SQL Server 2005 Description Steps To Reproduce Expected Result Actual Result Attachment Application crash on clicking the SAVE button while creating a new user, hence unable to create a new user in the application. 1. Logon into the application 2. Navigate to the Users Menu > New User 3. Filled all the user information fields 4. Clicked on Save button 5. Seen an error page ORA1090 Exception: Insert values Error 6. See the attached logs for more information (Attach more logs related to bug..if any) 7. And also see the attached screenshot of the error page. On clicking SAVE button, should be prompted to a success message New User has been created successfully.() What is the Result you got on executing the testcase.here the result is "Application Crash" Attach Screen shot or logs if any for reference. Save the defect/bug in the BUG TRACKING TOOL. You will get a bug id, which you can use for further bug reference. Default New bug mail will go to respective developer and the default module owner (Team leader or manager) for further action Software Testing. SOME MORE TESTING TYPES Types of Testing Description of Testing

13 Agile Testing Black box Testing Ad-hoc Testing API Testing Compatibility Testing Concurrency Testing Exploratory Testing Functional Testing GUI software Testing Localization Testing Negative Testing Regression Testing Unit Testing User Interface Testing Software testing practice that follows the principles of the agile manifesto, emphasizing testing from the perspective of customers who will utilize the system. It is usually performed by the QA teams. A method of software testing that verifies the functionality of an application without having specific knowledge of the application's code/internal structure. Tests are based on requirements and functionality. It is performed by QA teams. Testing performed without planning and documentation - the tester tries to 'break' the system by randomly trying the system's functionality. It is performed by the testing teams. Testing technique similar to unit testing in that it targets the code level. API Testing differs from unit testing in that it is typically a QA task and not a developer task. Testing technique that validates how well a software performs in a particular hardware/software/operating system/network environment. It is performed by the testing teams. Multi-user testing geared towards determining the effects of accessing the same application code, module or database records. It it usually done by performance engineers. Black box testing technique performed without planning and documentation. It is usually performed by manual testers. Type of black box testing that bases its test cases on the specifications of the software component under test. It is performed by testing teams. The process of testing a product that uses a graphical user interface, to ensure it meets its written specifications. This is normally done by the testing teams. Part of software testing process focused on adapting a globalized application to a particular culture/locale. It is normally done by the testing teams. Also known as "test to fail" - testing method where the tests' aim is showing that a component or system does not work. It is performed by manual or automation testers. Type of software testing that seeks to uncover software errors after changes to the program (e.g. bug fixes or new functionality) have been made, by retesting the program. It is performed by the testing teams. Software verification and validation method in which a programmer tests if individual units of source code are fit for use. It is usually conducted by the development team. Type of testing which is performed to check how user-friendly the application is. It is performed by testing teams. HOW TO DELIVER HIGH VALUE SOFTWARE? Scrum is a software development process. In today s rapid world stakeholders want immediate return on their investments. They don t want to wait for longer periods to get full featured product. As a result, nowadays new software development and testing framework are catching momentum i.e. Scrum approach. In scrum, projects are divided in small features to be developed and tested in specific time-frames called as sprint (small cycles). Features should get developed and tested in specified small time-frames. This agile scrum team is handled by scrum master.

14 Scrum is an iterative, incremental framework for projects and products or application development. Scrum has become more and more popular software development and testing framework among organizations. Many small to large sized IT companies have started to embrace Scrum framework, as this can create excellent quality products in less time than other traditional methodologies. This framework can save companies both time and money. SOFT SKILLS FOR A SCRUM TEAM: What Soft Skills are required to be a Successful Scrum Team? When we start our regular (Agile) sprints (Cycles of work), we usually find some of the challenges with our team members. These challenges are not part of technical difficulties. It usually occurs with team member s mindset or their soft skills. Many successful Scrum projects taught us that the success of scrum depends on how team members support whole heartedly towards the Sprint. Let us discuss some of the pre-requisite soft skills for a Scrum Team. TEAM SPIRIT Cross functional Team work is at the heart of Scrum. There is no my work, I have finished my work and your work. On a Scrum team we find only Our work, we have completed our Sprint. Individuals will have helping tendency for sharing technical knowledge. Scrum Members are always available to team members rather than locked away behind closed doors. Scrum Master will always motivate the teams and create a Supporting learning environment. Team will always be sprintoriented and often discuss smooth run of the sprint. A scrum team s job is to self-organize around the challenges and management s job is to remove impediments to self-organization. COMMUNICATION Good communication must exist among team members of development team, testing team, business analysts and stake holders. There must be highly collaborative interaction between client and the delivery teams. More client involvement implies more suggestions or changes from the client. It implies more bandwidth for communication. COMMITMENT Agile Teams needs periodic re-energizing to renew their commitments to their purpose and to each other. Scrum Masters can help by ensuring that the team embraces the concept of whole-team responsibility and whole-team commitment to deliver working software at the end of each sprint. With the whole-team commitment, the team member who has completed his tasks will help the one who has not completed so that hopefully each finishes on time. PROBLEM SOLVING Scrum does not simply focus on developing just any type of end product. Instead, the Scrum method allows the team to focus on creating a product that fulfils the customer s highest value priorities which are defined by product owners. TRANSPARENCY

15 Transparency among team members and management gives a real momentum to the scrum team. Scrum Master encourages people to ask for help, surface roadblocks, and give public recognition for those brave enough to do so. At the same time, Scrum Master also understands the time wasted and impact on the team when individuals sit on or ignore problems. SCRUM RESULT If scrum team follows some of above said soft skills, team velocity will increase significantly. In turn, customers will appreciate the results or updates and also can react quickly to any potential problems. Team can deliver high value software features in a short time period keeps everyone on top of changing business conditions. ROLE OF TESTER Generally Roles and Responsibilities of a Testing Engineer may vary, depending upon the working company. But here we are going to discuss about the general and important roles and responsibilities of a Testing Engineer. 1) Analyzing the Requirements from the client 2) Participating in preparing Test Plans 3) Preparing Test Scenarios 4) Preparing Test Cases for module, integration and system testing 5) Preparing Test Data s for the test cases 6) Preparing Test Environment to execute the test cases 7) Analyzing the Test Cases prepared by other team members 8) Executing the Test Cases 9) Defect Tracking 10) Giving mandatory information of a defect to developers in order to fix it 11) Preparing Summary Reports 12) Preparing Lesson Learnt documents from the previous project testing experience 13) Preparing Suggestion Documents to improve the quality of the application 14) Communication with the Test Lead / Test Manager 15) Conducting Review Meetings within the Team ATTITUDE OF A GOOD SOFTWARE TESTER If it is hard to find a good software developer, it is harder to find for a good software tester. What does it take to become an excellent software test professional? There are certain attitudes and qualities that one must possess to become an effective software testing person. Here are five qualities that would define a good software tester. 1. Attitude Matters: In any kind of endeavour attitude is always the key to success. The innate passion for what you do would always define your enthusiasm and interest toward your work. Successful and efficient software testers often describe themselves as tenacious, thorough, and uncompromising and have strong passion for analysis and testing. Generally, passion is an innate substance in a person rather than acquired characteristic.

16 2. Intellectual and Technical Capability: He must have a good (maybe above average) analytical and logical ability. He must be able to deal with complicated logic and must be able to carry out at a high level in this type of setting in short a good software tester must be smart. Aside from intellectual capability, a good test engineer must have a excellent background in coding in order to grasp the concept of the system being tested. 3. Flexibility: Ability to adapt and willingness to learn is one of the most essential qualities of a good software tester. He must have an embedded inclination to be continuing learners and have dedication in upgrading and developing their skills. For instance, the Visual Basic platform change dramatically from VB6 to VB.Net, a good software tester must be flexible enough to cope with the changes of new technology. 4. Communication Skills: An effective test engineer should have strong written and verbal communication skills. He should have the ability to listen critically and speak rationally convey the message clearly in person-to-person meetings. A good software tester must be able to read and analyze product documentation, write test plans, write clear bug reports, write coherent status reports to management both in formal reports and ad hoc reports. 5. Business Sense: It is important for good software to have a good business sense. He should have the ability to see the larger picture of a company's overall business strategy. This enables a great software tester to actively participate at a level higher than just an individual contributor. CHALLENGES IN SOFTWARE TESTING 1. Domain knowledge: Software testing can be effective only when testers understand customer s business, in order to understand customer s business one has to have good knowledge of Customer s business domain. Poor domain knowledge of testers will result in ineffective Test Scenarios, test scripts and more UAT and post implementation defects. 2. Time: Time has always posed a challenge for Software testers, especially to execute Regression tests. During testing phase, testers are asked to perform multiple rounds of Regression tests and these regression test cases can be of few 100s to 1000s depending on the size of the application. However regression test cannot be left out, so the best way to manage multiple rounds of regression testing is by automating regression tests that are not subject to direct change as part of the current release. 3. Test Estimation: There are several industry acknowledged Test Estimation methods. Deriving accurate test estimates is one of most important factors for success of Software Testing Phase. Good Test Estimates will include and estimate time for all the activities performed during Software Test Life Cycle be it small or big task. 4. Test Data setup: Test Data setup will be more challenging when data setup involves mainframe or multiple applications or databases. Test Data creation for Load or performance testing will require writing scripts or SQL Procedures. 5. Test Automation: Challenge is test automation is not scripting, instead it s more on effort estimation, designing framework, creating reusable components and most 4hallenging task of is reducing effort required for test script maintenance. 6. Test environment setup: In most of the bigger organizations, Test environment setup is done by Operations / Technical support team. However in smaller or mid sized organizations, Test

17 environment setup feels complicated as it could require installing Operating System, Drivers, Installation, configuration and fine tuning of Database, Installation and configuration of Web server or application servers or firewalls, SSL Certificates, finally installation and configuration of the application being tested. Environment setup is one the tasks that requires knowledge of various softwares, testers usually find it as one of the challenging tasks. 7. Performance Testing: Identifying Performance Test Scenarios, creating of Test Data required for performance testing and analyzing reports are the most challenging part of Performance testing. In fact creation of performance test script is the easier among all activates performed during performance testing. 8. Metrics: Metrics becomes a challenge when goals of a particular metric is not defined and understood during initial stage of Software Test Life Cycle. E.g.:- Consider you want to create metrics on Test Case Creation Efficiency, consider this metric provides details on the number of test cases created per day and number of review comments provided by reviewer. Incase there was no goal defined or the testers were not aware of this metric or testers do not make a conscious effort against the metric goals then the end result will be an ir-reversible and metrics that reflects badly on testing team/testers. 9. Unavailability of right Tools: Unavailability of right tools poses a great challenge for testing team. Availability of right tools again depends on the project budget availability and funding. Tools for Test Case creation and execution, Defect management, test automation, version control etc., For e.g.:- Test Cases and defects can be written and maintained in spread sheets as well as Test Management softwares like QTP or Clear Quest but think of the additional effort required and challenges you will face in using spread sheet Vs Test Management software. Usage of right tools helps testers to reduce the time required to perform their tasks. 10. Team at Multi location: If Business Analysts and development teams are located in locations different than the time zone of testing team. Testers will get a very little time to discuss with their onsite counter parts or with other teams or will have to work extended hours to get clarifications or attend meetings. Difference in time zone can lead to wait time. Incase development team is at different location in different time zone and testers are unable to proceed with testing due to showstopper defect then they lose entire day as there is nobody from development team at the same location to quickly fix the Critical/show stopper issue and provide a new build so that testers can resume with testing. Remember one day lost in this scenario is cutting into the test schedule. SOFTWARE TEST AUTOMATION WHY AUTOMATION TESTING Automated software testing is the best way to increase the effectiveness, efficiency and coverage of your software testing. Automated Software Testing Saves Time and Money. Automated Software Testing Improves Accuracy. Automated Software Testing Increases Test Coverage. Automated Software Testing Helps Developers and Testers. GOOD AUTOMATION FRAMEWORK PRACTICES Following common coding structure for all the scripts Consistent coding conventions

18 Use of Reusability for making code efficient and minimal Efficient use of Object Repository Use of Error and Exception handling Functions Use of Data table object, Environment variables for using data DESIGN STEPS OF THE APPROACH FOR TEST AUTOMATION: Identification of Test Cases for Automation Identification of Common Functionality Coding Standards, Naming Conventions & Templates Building the Re-Usable Library for example: o o o o Application Login, Logout, Common Functionality Related code etc Tool & Application Settings, Restoring, Object Repository, Recovery, House Keeping etc General library containing String handling, Date handling, File Handling, Data Table handling Error handling, Log Reporting, messaging etc Script Development using Record & Play back Deliver the script after Verification & Validation GUIDELINES FOLLOWED FOR IDENTIFICATION OF TEST CASES FOR AUTOMATION Tests that need to run once and those that need frequent human intervention are usually not worth the investment to automate and have not been considered for automation. As Automated testing can be used to verify the performance of application paths that are used with a high degree of frequency when the software is running in full production e.g. creating customer records, Invoicing and other high volume activities where software failure would occur frequently have been considered. Mission critical processes like core activities like sales order processing are prime candidates for automated testing and have been considered for automation. Repetitive Testing. Applications with Long Life span Longer the application in production greater the benefits from automation. Avoiding dynamic screens. Though possible to automate this increases the complexity of the script. Avoiding screens where objects are created dynamically Avoiding business scenarios where complex hardware is involved Selecting a row in a table results in an additional challenge from. Some automation tools provide the facility to read each row in a table and for focusing on a specific row. If the numbers of rows were very high the execution time of the script would be high. This leads to performance issues of the recorded script. Hence, it is better to prove the business scenario wherein tables with row selections figure by identifying a fixed row number. This scenario is faced very frequently in enterprise applications as in pricing tables and leads to the complexity of the script and subsequently the effort. Avoiding scenarios that require high degree of coding while automating so that script s complexity is reduced and high maintainability of the script is ensured.

19 WEB TESTING/MOBILE WEB TESTING Website Testing or Mobile Web Testing involves different types of Testing. To my knowledge this is the checklist to follow when performing any mobile Web or Web application. Functionality Testing Usability testing Interface testing Compatibility testing Performance testing Security testing USEFUL BOOKS AND WEBSITE LINKS Links: Books: Agile Testing: A Practical guide for Testers and Agile Teams by Lisa Crispin.