testing

MONDAY, N OVEMBER 27, 2006 Testing Framework Testing Framework Through experience they determined, that there should be 30 defects per 1000 lines of code. If testing does not uncover 30 defects, a logical solution is that the test process was not effective. 1.0 Introduction Testing plays an important role in today’s System Development Life Cycle. During Testing, we follow a systematic procedure to uncover defects at various stages of the life cycle. This framework is aimed at providing the reader various Test Types, Test Phases, Test Models and Test Metrics and guide as to how to perform effective Testing in the project. All the definitions and standards mentioned in this framework are existing one’s. I have not altered any definitions, but where ever possible I tried to explain them in simple words. Also, the framework, approach and suggestions are my experiences. My intention of this framework is to help Test Engineers to understand the concepts of testing, various techniques and apply them effectively in their daily work. This framework is not for publication or for monetary distribution. If you have any queries, suggestions for improvements or any points found missing, kindly write back to me. The chart below describes the Life Cycle verification activities. Life Cycle Phase Verification Activities Requirements · Determine verification approach.· Determine adequacy of requirements.· Generate functional test data.· Determine consistency of design with requirements. Design · Determine adequacy of design.· Generate structural and functional test data.· Determine consistency with design Program (Build) · Determine adequacy of implementation· Generate structural and functional test data for programs. Test · Test application system. Installation · Place tested system into production. Maintenance · Modify and retest. Throughout the entire lifecycle, neither development nor verification is a straightline activity. Modifications or corrections to a structure at one phase will require modifications or re-verification of structures produced during previous phases. 2.0 Verification and Validation Testing Strategies 2.1 Verification Strategies The Verification Strategies, persons / teams involved in the testing, and the deliverable of that phase of testing is briefed below: Verification Strategy Performed By Explanation Deliverable Requirements Reviews Users, Developers, Test Engineers. Requirement Review’s help in base lining desired requirements to build a system. Reviewed and approved statement of requirements. Design Reviews Designers, Test Engineers Design Reviews help in validating if the design meets the requirements and build an effective system. System Design Document, Hardware Design Document. Code Walkthroughs Developers, Subject Specialists, Test Engineers. Code Walkthroughs help in analyzing the coding techniques and if the code is meeting the coding standards Software ready for initial testing by the developer. Code Inspections Developers, Subject Specialists, Test Engineers. Formal analysis of the program source code to find defects as defined by meeting system design specification. Software ready for testing by the testing team. 2.1.1 Review’s The focus of Review is on a work product (e.g. Requirements document, Code etc.). After the work product is developed, the Project Leader calls for a Review. The work product is distributed to the personnel who involves in the review. The main audience for the review should be the Project Manager, Project Leader and the Producer of the work product. Major reviews include the following: 1. In Process Reviews 2. Decision Point or Phase End Reviews 3. Post Implementation Reviews Let us discuss in brief about the above mentioned reviews. As per statistics Reviews uncover over 65% of the defects and testing uncovers around 30%. So, it’s very important to maintain reviews as part of the V&V strategies. In-Process Review In-Process Review looks at the product during a specific time period of a life cycle, such as activity. They are usually limited to a segment of a project, with the goal of identifying defects as work progresses, rather than at the close of a phase or even later, when they are more costly to correct. Decision-Point or Phase-End Review This review looks at the product for the main purpose of determining whether to continue with planned activities. They are held at the end of each phase, in a semiformal or formal way. Defects found are tracked through resolution, usually by way of the existing defect tracking system. The common phase-end reviews are Software Requirements Review, Critical Design Review and Test Readiness Review. · The Software Requirements Review is aimed at validating and approving the documented software requirements for the purpose of establishing a baseline and identifying analysis packages. The Development Plan, Software Test Plan, Configuration Management Plan are some of the documents reviews during this phase. · The Critical Design Review baselines the detailed design specification. Test cases are reviewed and approved. · The Test Readiness Review is performed when the appropriate application components are near completing. This review will determine the readiness of the application for system and acceptance testing. Post Implementation Review These reviews are held after implementation is complete to audit the process based on actual results. Post-Implementation reviews are also known as Postmortems and are held to assess the success of the overall process after release and identify any opportunities for process improvement. They can be held up to three to six months after implementation, and are conducted in a format. There are three general classes of reviews: 1. Informal or Peer Review 2. Semiformal or Walk-Through 3. Format or Inspections Peer Review is generally a one-to-one meeting between the author of a work product and a peer, initiated as a request for import regarding a particular artifact or problem. There is no agenda, and results are not formally reported. These reviews occur on an as needed basis throughout each phase of a project. 2.1.2 Inspections A knowledgeable individual called a moderator, who is not a member of the team or the author of the product under review, facilitates inspections. A recorder who records the defects found and actions assigned assists the moderator. The meeting is planned in advance and material is distributed to all the participants and the participants are expected to attend the meeting well prepared. The issues raised during the meeting are documented and circulated among the members present and the management. 2.1.3 Walkthroughs The author of the material being reviewed facilitates walk-Through. The participants are led through the material in one of two formats; the presentation is made without interruptions and comments are made at the end, or comments are made throughout. In either case, the issues raised are captured and published in a report distributed to the participants. Possible solutions for uncovered defects are not discussed during the review. 2.2 Validation Strategies The Validation Strategies, persons / teams involved in the testing, and the deliverable of that phase of testing is briefed below: Validation Strategy Performed By Explanation Deliverable Unit Testing. Developers / Test Engineers. Testing of single program, modules, or unit of code. Software unit ready for testing with other system component. Integration Testing. Test Engineers. Testing of integrated programs, modules, or units of code. Portions of the system ready for testing with other portions of the system. System Testing. Test Engineers. Testing of entire computer system. This kind of testing usually includes functional and structural testing. Tested computer system, based on what was specified to be developed. Production Environment Testing. Developers, Test Engineers. Testing of the whole computer system before rolling out to the UAT. Stable application. User Acceptance Testing. Users. Testing of computer system to make sure it will work in the system regardless of what the system requirements indicate. Tested and accepted system based on the user needs. Installation Testing. Test Engineers. Testing of the Computer System during the Installation at the user place. Successfully installed application. Beta Testing Users. Testing of the application after the installation at the client place. Successfully installed and running application. 3.0 Testing Types There are two types of testing: 1. Functional or Black Box Testing, 2. Structural or White Box Testing. Before the Project Management decides on the testing activities to be performed, it should have decided the test type that it is going to follow. If it is the Black Box, then the test cases should be written addressing the functionality of the application. If it is the White Box, then the Test Cases should be written for the internal and functional behavior of the system. Functional testing ensures that the requirements are properly satisfied by the application system. The functions are those tasks that the system is designed to accomplish. Structural testing ensures sufficient testing of the implementation of a function. 3.1 White Box Testing White Box Testing; also know as glass box testing is a testing method where the tester involves in testing the individual software programs using tools, standards etc. Using white box testing methods, we can derive test cases that: 1) Guarantee that all independent paths within a module have been exercised at lease once, 2) Exercise all logical decisions on their true and false sides, 3) Execute all loops at their boundaries and within their operational bounds, and 4) Exercise internal data structures to ensure their validity. Advantages of White box testing: 1) Logic errors and incorrect assumptions are inversely proportional to the probability that a program path will be executed. 2) Often, a logical path is not likely to be executed when, in fact, it may be executed on a regular basis. 3) Typographical errors are random. White Box Testing Types There are various types of White Box Testing. Here in this framework I will address the most common and important types. 3.1.1 Basis Path Testing Basis path testing is a white box testing technique first proposed by Tom McCabe. The Basis path method enables to derive a logical complexity measure of a procedural design and use this measure as a guide for defining a basis set of execution paths. Test Cases derived to exercise the basis set are guaranteed to execute every statement in the program at least one time during testing. 3.1.2 Flow Graph Notation The flow graph depicts logical control flow using a diagrammatic notation. Each structured construct has a corresponding flow graph symbol. 3.1.3 Cyclomatic Complexity Cyclomatic complexity is a software metric that provides a quantitative measure of the logical complexity of a program. When used in the context of a basis path testing method, the value computed for Cyclomatic complexity defines the number for independent paths in the basis set of a program and provides us with an upper bound for the number of tests that must be conducted to ensure that all statements have been executed at lease once. An independent path is any path through the program that introduces at least one new set of processing statements or a new condition. Computing Cyclomatic Complexity Cyclomatic complexity has a foundation in graph theory and provides us with extremely useful software metric. Complexity is computed in one of the three ways: 1. The number of regions of the flow graph corresponds to the Cyclomatic complexity. 2. Cyclomatic complexity, V(G), for a flow graph, G is defined as V (G) = E-N+2 Where E, is the number of flow graph edges, N is the number of flow graph nodes. 3. Cyclomatic complexity, V (G) for a flow graph, G is also defined as: V (G) = P+1 Where P is the number of predicate nodes contained in the flow graph G. 3.1.4 Graph Matrices The procedure for deriving the flow graph and even determining a set of basis paths is amenable to mechanization. To develop a software tool that assists in basis path testing, a data structure, called a graph matrix can be quite useful. A Graph Matrix is a square matrix whose size is equal to the number of nodes on the flow graph. Each row and column corresponds to an identified node, and matrix entries correspond to connections between nodes. 3.1.5 Control Structure Testing Described below are some of the variations of Control Structure Testing. 3.1.5.1 Condition Testing Condition testing is a test case design method that exercises the logical conditions contained in a program module. 3.1.5.2 Data Flow Testing The data flow testing method selects test paths of a program according to the locations of definitions and uses of variables in the program. 3.1.6 Loop Testing Loop Testing is a white box testing technique that focuses exclusively on the validity of loop constructs. Four classes of loops can be defined: Simple loops, Concatenated loops, nested loops, and unstructured loops. 2. Explain WinRunner testing process? Ans:) - WinRunner testing process involves six main stages o Create GUI Map File so that WinRunner can recognize the GUI objects in the application being tested o Create test scripts by recording, programming, or a combination of both. While recording tests, insert checkpoints where you want to check the response of the application being tested. o Debug Test: run tests in Debug mode to make sure they run smoothly o Run Tests: run tests in Verify mode to test your application. o View Results: determines the success or failure of the tests. o Report Defects: If a test run fails due to a defect in the application being tested, you can report information about the defect directly from the Test Results window. SQA and testing frequently asked definitions Black box testing ==================== not based on any knowledge of internal design or code. Tests are based on requirements and functionality. White box testing based on knowledge of the internal logic of an application’s code. Tests are based on coverage of code statements, branches, paths, conditions. Unit testing ==================== the most ‘micro’ scale of testing; to test particular functions or code modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. Not always easily done unless the application has a well-designed architecture with tight code; may require developing test driver modules or test harnesses. Incremental integration testing continuous testing of an application as new functionality is added; requires that various aspects of an application’s functionality be independent enough to work separately before all parts of the program are completed, or that test drivers be developed as needed; done by programmers or by testers. Integration testing ==================== testing of combined parts of an application to determine if they function together correctly. The ‘parts’ can be code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems. Functional testing ==================== black-box type testing geared to functional requirements of an application; this type of testing should be done by testers. This doesn’t mean that the programmers shouldn’t check that their code works before releasing it (which of course applies to any stage of testing.) System testing ==================== black box type testing that is based on overall requirement specifications; covers all combined parts of a system. 9/10/2006 2:31 AM more Sanity testing ======================== typically an initial testing effort to determine if a new software version is performing well enough to accept it for a major testing effort. For example, if the new software is crashing systems every 5 minutes, bogging down systems to a crawl, or destroying databases, the software may not be in a ’sane’ enough condition to warrant further testing in its current state. Regression testing ======================== re-testing after fixes or modifications of the software or its environment. It can be difficult to determine how much re-testing is needed, especially near the end of the development cycle. Automated testing tools can be especially useful for this type of testing. Acceptance testing ======================== final testing based on specifications of the end-user or customer, or based on use by end-users/customers over some limited period of time. Load testing ======================== testing an application under heavy loads, such as testing of a web site under a range of loads to determine at what point the systems response time degrades or fails. Stress testing ======================== term often used interchangeably with ‘load’ and ‘performance’ testing. Also used to describe such tests as system functional testing while under unusually heavy loads, heavy repetition of certain actions or inputs, input of large numerical values, large complex queries to a database system, etc. Performance testing ======================== term often used interchangeably with ’stress’ and ‘load’ testing. Ideally ‘performance’ testing (and any other ‘type’ of testing) is defined in requirements documentation or QA or Test Plans. 9/10/2006 2:33 AM Usability testing =========================== testing for ‘user-friendliness’. Clearly this is subjective, and will depend on the targeted end-user or customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers and testers are usually not appropriate as usability testers. Security testing =========================== testing how well the system protects against unauthorized internal or external access, willful damage, etc; may require sophisticated testing techniques. Compatibility testing =========================== testing how well software performs in a particular hardware/software/operating system/network/etc. environment. Exploratory testing =========================== often taken to mean a creative, informal software test that is not based on formal test plans or test cases; testers may be learning the software as they test it. Ad-hoc testing =========================== similar to exploratory testing, but often taken to mean that the testers have significant understanding of the software before testing it. User acceptance testing =========================== determining if software is satisfactory to an end-user or customer. Comparison testing comparing software weaknesses and strengths to competing products. Alpha testing =========================== testing of an application when development is nearing completion; minor design changes may still be made as a result of such testing. Typically done by end-users or others, not by programmers or testers. Beta testing =========================== testing when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end-users or others, not by programmers or testers. S O F TWA R E T ES T I N G GU I D E Saturday, November 18, 2006 What are the contents in an effective Bug report? Project, Subject, Description, Summary, Detected By (Name of the Tester), Assigned To (Name of the Developer who is supposed to the Bug), Test Lead ( Name ), Detected in Version, Closed in Version, Date Detected, Expected Date of Closure, Actual Date of Closure, Priority (Medium, Low, High, Urgent), Severity (Ranges from 1 to 5), Status, Bug ID, Attachment, Test Case Failed (Test case that is failed for the Bug) P O S T E D B Y JE R R Y R U B A N A T 4 : 5 9 P M 3 C O M M E N T S What is Bug Life Cycle? Bug Life Cycle is nothing but the various phases a Bug undergoes after it is raised or reported.  New or Opened  Assigned    Fixed Tested Closed P O S T E D B Y JE R R Y R U B A N A T 4 : 2 7 P M 1 C O M M E N T S What is Error guessing and Error seeding ? Error Guessing is a test case design technique where the tester has to guess what faults might occur and to design the tests to represent them. Error Seeding is the process of adding known faults intentionally in a program for the reason of monitoring the rate of detection & removal and also to estimate the number of faults remaining in the program. P O S T E D B Y JE R R Y R U B A N A T 3 : 3 5 P M 0 C O M M E N T S Thursday, November 09, 2006 What is the difference between Bug, Error and Defect? Error : It is the Deviation from actual and the expected value. Bug : It is found in the development environment before the product is shipped to the respective customer. Defect : It is found in the product itself after it is shipped to the respective customer. P O S T E D B Y JE R R Y R U B A N A T 1 : 0 2 P M 0 C O M M E N T S What is Test bed and Test data ? Test Bed is an execution environment configured for software testing. It consists of specific hardware, network topology, Operating System, configuration of the product to be under test, system software and other applications. The Test Plan for a project should be developed from the test beds to be used. Test Data is that run through a computer program to test the software. Test data can be used to test the compliance with effective controls in the software. P O S T E D B Y JE R R Y R U B A N A T 1 2 : 4 5 P M 1 C O M M E N T S Thursday, October 12, 2006 What is Negative testing? Negative testing - Testing the system using negative data is called negative testing, e.g. testing the password where it should be minimum of 8 characters so testing it using 6 characters is negative testing. P O S T E D B Y JE R R Y R U B A N A T 2 : 1 4 P M 0 C O M M E N T S Explain Load, Performance and Stress Testing with an Example. Load Testing and Performance Testing are commonly said as positive testing where as Stress Testing is said to be as negative testing. Say for example there is a application which can handle 25 simultaneous user logins at a time. In load testing we will test the application for 25 users and check how application is working in this stage, in performance testing we will concentrate on the time taken to perform the operation. Where as in stress testing we will test with more users than 25 and the test will continue to any number and we will check where the application is cracking. P O S T E D B Y JE R R Y R U B A N A T 1 1 : 4 2 A M 0 C O M M E N T S Monday, September 18, 2006 What are SDLC and STLC ? Explain its different phases. SDLC   Requirement phase Designing phase (HLD, DLD (Program spec))     Coding Testing Release Maintenance STLC  System Study   Test planning Writing Test case or scripts   Review the test case Executing test case   Bug tracking Report the defect P O S T E D B Y JE R R Y R U B A N A T 3 : 1 5 P M 1 C O M M E N T S Wednesday, September 13, 2006 What is Ad-hoc testing? Ad hoc testing is concern with the Application Testing without following any rules or test cases. For Ad hoc testing one should have strong knowledge about the Application. P O S T E D B Y JE R R Y R U B A N A T 3 : 1 9 P M 0 C O M M E N T S Monday, September 11, 2006 Describe bottom-up and top-down approaches in Regression Testing. Bottom-up approach : In this approach testing is conducted from sub module to main module, if the main module is not developed a temporary program called DRIVERS is used to simulate the main module. Top-down approach : In this approach testing is conducted from main module to sub module. if the sub module is not developed a temporary program called STUB is used for simulate the submodule. P O S T E D B Y JE R R Y R U B A N A T 3 : 2 2 P M 0 C O M M E N T S What is the difference between structural and functional testing? Structural testing is a "white box" testing and it is based on the algorithm or code. Functional testing is a "black box" (behavioral) testing where the tester verifies the functional specification. P O S T E D B Y JE R R Y R U B A N A T 3 : 1 8 P M 0 C O M M E N T S Saturday, September 09, 2006 What is Re- test ? What is Regression Testing ? Re- test - Retesting means we testing only the certain part of an application again and not considering how it will effect in the other part or in the whole application. Regression Testing - Testing the application after a change in a module or part of the application for testing that is the code change will affect rest of the application. P O S T E D B Y JE R R Y R U B A N A T 1 1 : 2 3 A M 0 C O M M E N T S What is UAT testing? When it is to be done? UAT testing - UAT stands for 'User acceptance Testing. This testing is carried out with the user perspective and it is usually done before the release. P O S T E D B Y JE R R Y R U B A N A T 1 1 : 2 0 A M 0 C O M M E N T S Friday, September 08, 2006 What are the basic solutions for the software development problems?  Basic requirements - clear, detailed, complete, achievable, testable requirements has to be developed. Use some prototypes to help needed. pin down requirements. In nimble environments, continuous and close coordination with customers/end-users is  Schedules should be realistic - enough time to plan, design, test, bug fix, re-test, change, and document in the given schedule.  Adequate testing – testing should be started early, it should be re-tested after the bug fixed or changed, enough time should be spend for testing and bug-fixing.  Proper study on initial requirements – be ready to look after more changes after the development has begun and be ready to explain the changes done to others. Work closely with the customers and end-users to manage expectations. This avoids excessive changes in the later stages.  Communication – conduct frequent inspections and walkthroughs in appropriate time period; ensure that the information and the documentation is available on up-to-date if possible electronic. More emphasize on promoting teamwork and cooperation expectations. inside the team; use prototypes and proper communication with the end-users to clarify their doubts and P O S T E D B Y JE R R Y R U B A N A T 1 1 : 1 4 A M 0 C O M M E N T S What are the common problems in the software development process?  Inadequate requirements from the Client - if the requirements given by the client is not clear, unfinished and not testable, then problems may come.  Unrealistic schedules – Sometimes too much of work is being given to the developer and ask him to complete in a Short duration, then the problems are unavoidable.  Insufficient testing – The problems can arise when the developed software is not tested properly. Given another work under the existing process – request from the higher management to work on another project or task will bring some problems when the project is being tested as a team.   Miscommunication – in some cases, the developer was not informed about the Clients requirement and expectations, so there can be deviations. P O S T E D B Y JE R R Y R U B A N A T 1 0 : 2 6 A M 0 C O M M E N T S Why does software have bugs?  Miscommunication or no communication – about the details of what an application should or shouldn't do Programming errors – in some cases the  programmers can make mistakes.  Changing requirements – there are chances of the end-user not understanding the effects of changes, or may understand and request them anyway to redesign, rescheduling of engineers, effects of other projects, work already completed may have to be redone or thrown out.  Time force - preparation of software projects is difficult at best, often requiring a lot of guesswork. When deadlines are given and the crisis comes, mistakes will be made. P O S T E D B Y JE R R Y R U B A N A T 1 0 : 1 8 A M 0 C O M M E N T S Friday, September 01, 2006 What software testing types can be considered? Black box testing – This type of testing doesn’t require any knowledge of the internal design or coding. These Tests are based on the requirements and functionality. White box testing – This kind of testing is based on the knowledge of internal logic of a particular application code. The Testing is done based on the coverage of code statements, paths, conditions. Unit testing – the 'micro' scale of testing; this is mostly used to test the particular functions or code modules. This is typically done by the programmer and not by testers; it requires detailed knowledge of the internal program design and code. It cannot be done easily unless the application has a well-designed architecture with tight code; this type may require developing test driver modules or test harnesses. Sanity testing or Smoke testing – This type of testing is done initially to determine if a new software version is performing well enough to accept it for a major testing effort. For example, if the new software is crashing the systems in every 5 minutes or corrupting databases, the software may not be in a 'sound’ condition to proceed for further testing in its current state. Functional testing – This a commonly used black-box testing geared to check the functional requirements of an application; this type of testing should be done by testers. Integration testing – This testing is combining the ‘parts’ of an application to determine if they function together correctly. The 'parts' can be code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to the client/server and distributed systems. Incremental Integration testing – This is continuous testing of an application when a new functionality is added the existing ones; it checks the application functionality by verifying whether it works separately before all parts of the program are completed, in this type it will be checked whether to introduce test drivers or not; this is done by programmers or by testers. Regression testing – This is testing the whole application again after the fixes or the modifications are done on the software. This is mostly done at the end of the Software development life cycle. Mostly Automated testing tools are used for these type of testing. System testing – This is a type of black-box type testing that is based on overall requirements specifications; covers all combined parts of a system. End-to-end testing – This is similar to system testing; this involves testing of a complete application environment such as interacting with a database, using network communications, or interacting with other hardware, applications and so on. UAT ( User Acceptance Testing ) – This type of testing comes on the final stage and mostly done on the specifications of the end-user or client. Usability testing – This testing is done to check the 'user-friendliness' of the application. This depends on the targeted end-user or customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers and testers are usually not appropriate as usability testers. Compatibility testing – Testing how well the software performs in a particular hardware, software, operating system, network etc. Comparison testing – This is nothing comparing the software strengths and weakness with another competing product. Mutation testing – This is another method for determining if a set of test data or test cases is useful, by purposely introducing various code changes or bugs and retesting with the original test data or cases to determine whether the 'bugs' are detected. P O S T E D B Y JE R R Y R U B A N A T 5 : 1 0 P M 0 C O M M E N T S How do you decide when you have 'tested enough’? Common factors in deciding when to stop are:   Deadlines (release deadlines, testing deadlines, etc.) Test cases completed with certain percentage passed   Test budget depleted Coverage of code/functionality/requirements reaches a specified point   Bug rate falls below a certain level Beta or alpha testing period ends P O S T E D B Y JE R R Y R U B A N A T 5 : 0 8 P M 0 C O M M E N T S Describe the Software Development Life Cycle It includes aspects such as initial concept, requirements analysis, functional design, internal design, documentation planning, test planning, coding, document preparation, integration, testing, maintenance, updates, retesting, phase-out, and other aspects. P O S T E D B Y JE R R Y R U B A N A T 1 0 : 0 1 A M 0 C O M M E N T S Describe the difference between validation and verification Verification is done by frequent evaluation and meetings to appraise the documents, policy, code, requirements, and specifications. This is done with the checklists, walkthroughs, and inspection meetings. Validation is done during actual testing and it takes place after all the verifications are being done. Wednesday, August 30, 2006 What is quality assurance? Software QA involves the entire software development PROCESS - monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to 'prevention'. Manual Testing - no more a shit job ! Hi Reader, Oops , I chose a very controversial topic of whether Manual Testing is a brainy job or a shit job and fortunately or unfortunately as you have started reading this stuff, I reccomend you to go through it completely. ( later think on it if possible ) Note : This post is targetted to 0-3 years of experience readers who still remain naive. Others, this maybe the one you wanted to speak out. There is a misconception about Manual Testing and as a passionate Tester, here is my effort to make it clear. After reading this if you disagree with me , send me your CV, I shall look for an Automation Testing job for you. __ Manual Testing no more a shit job ! __ Automation has its own merits and de-merits and so does Manual Testing but people are partially blind and look into De-merits alone. Isn't it a responsiblity of we people who have been into Manual Testing to show them "Its half glass full and not half glass empty alone". Moreover, you cannot apply automation everywhere ... most of you must be dealing with software that runs on a PC or a similar platform but you should be aware that there are a zillion number of products we use in our daily lives which are not software and also don't run on a PC. If you look at the sky from the well , you will be able to measure the diameter of sky, count the number of stars in the night and also see the shining sun for a few minutes in the 12 hours that it is available. Hope this post acts as a rope hanging in the well through which you shall climb and ..... ( don't look back at the well ) As I mentioned there are a zillion ( just a big number I cant think of ) products that cannot be automated and I am sure if you are testing something, despite a tool doing it, you are hired because it needs a manual effort. Loadrunner , Winrunner , QTP , Silk , Cotton , Wool .. whatever maybe, it still needs _____ ( fill your name , spelling mistakes are permitted ) What a tool cant do , which you can - programmed to and I am sure the tool will have more limitations than you. 2. A Tool is not worried about the product it is Testing but I am sure, you are, worried since you want to progress as a Tester. 1. A Tool can have limited intelligence and does execute and report whatever it is 3. A Tool doesn't care about its appraisal but I am sure most of us do and we perform or 4. A Tool put to work overnight gives you sleep but if it failed midway on a Thursday night, 6. A Tool is thrown away if a different project comes up and a new tool is purchased based on requirements, Are you thrown out because a project got over ? Well the above points are made in order to make the Manual Tester realize that they are an important element for an organization when compared to a tool. Now for some more gyaan ... Why is Manual Testing a brainy job ? ( You V/s Tool ) outperform. you miss your girlfriend the same weekend. 5. A Tool is purchased and can be used illegaly too, can you be exploited illegaly ? executing the same cases as yours , can you tell me who will report the most number of bugs ? can you also tell me who will be able to validate/investigate/reproduce/create new test cases after one cycle of testing. Is it going to be you or the tool. The tool may overtake you in finishing the test cases but tell your manager you are a tortoise and not hare. 2. You know more about testing than the tool , isnt it true ? then who is a better tester , you or the tool ? Tool is identified by its release number and you by your skills. ( This point should ideally hit those testers who worship tools and ill-treat those who Manually Test ) 3. A tool can always replace a tester who just executes the test cases but can never replace those planning/documenting and analyzing test plan/design/cases. 4. People obssesed about tools are the person with whom you should not be talking anything about testing, they are like people from the well and they seek for help to come out and in turn pull you inside. 5. Tools are like aliens , they come in , influence you , evade you and rule you... When are you going to celebrate your Independence Day. 6. Some decades before Robots and Automatic Machines replaced people at work but I am amazed to look at the software industry where such Automated tools make the company hire more people to work on it. :D cos the so called automated tools require more manual work. ( Some communist party is supporting these tools I guess ) 7. All Automation Testers are Manual Testers but all Manual Testers are not Automation Testers. ( pretty confusing , that's what I wanted ) 8. Say a demon came and told you "I will erase some part of your brain , which do you want to sacrifice - your knowledge about tools or your testing skill?" What would be your choice .. ( of course, the demon will not earase the memories of the girl/guy who rejected you ) __ Manual Testing no more a shit job ! __ Please be aware that I am not against any Automation Testers because I see that they too are Manual Testers but as a matter of fact they may not agree as their pride and ego doesn't permit them to admit. Tools are a vital part but you and your testing skills are more than vital to any project. I give you two choices Choice 1 - No, I was not conviced { sorry for wasting your valuable automation testing time and reccomend you to waste 5 more mins looking at this } 1. Assume you are Manually Testing a product and parallely an automation framework is Choice 2 - Yes, I was convinced. { you should then spend 5 more minutes reading this } "Respect a Manual Tester , God will gift you free tools" Why do you need to be a Tester? Wherever you are … Hi Reader, In the past few days I have had great learning and I am trying to digest it before I present it for you. In the mean time I would like to share one of the incident where my testing skills came handy for a problem that was not solved for quite sometime. __ Why do you need to be a Tester? Wherever you are … __ One of my cousins joined an Ozone System Manufacturing company and his first task was to inspect a few systems that had been installed. While his inspection and training, he was briefed about a problem that occurred frequently with the system that was costing more on maintenance. The Ozone system in short – A Shell containing electrodes forms the heart of the system. An inlet pipes takes in oxygen from an oxygen cylinder/pump and another inlet to the shell takes in potable water to form a watercooling circuit, which is shielded from the electrodes. When a high voltage is passed to the electrodes and oxygen mixed in particular proportion ozone oozes out through the outlet pipe. Did I forget to inform you that a Teflon envelope covers the Aluminian Electrodes? Now the problem is (was) – The Teflon envelope, which had a guarantee of 6 months, was facing fatigue and had to be replaced every month in order to produce efficient ozone production. My cousin is one among those who is confident about my Testing skills and took special permission from his manager to allow me to visit a real time plant. The excitement within me was at peak and especially when I came to know that I would be inspecting the ozone plant of a very famous Multiplex in Bangalore, excitement shot up further. Testing skills put to use – (this way, down) Phase – 1 (Study) * Started off studying the system, theory part of course. * Being an Instrumentation Engineer (as per my degree certificate), I put the theory learnt to use by inspecting the meters and its calibration. * Asked the personnel who are in the maintenance job to explain me the process of maintenance they carry over. * Asked the personnel to show me some sample Teflon envelops – both new ones and the ones that had given up their life. Phase – 2 (Analysis) I made an analysis between the documented maintenance procedure and the procedure in practice, later observed and informed the deviation with the two. I made an analysis that the water-cooling circuit could be the culprit since in any engineering plant when water-cooling system is deployed a problem of corrosion/rust comes into picture. ( Although Teflon is non corrosive …) I also observed a salt formation over Teflon and hence suggested to scrap the salt formed over and subject it to a chemistry lab test to find out what is the chemical composition of the salt. Of course this result could let anyone know who is any other culprit if any. Phase – 3 (My progression towards bettering my testing skills) I admitted that my suggestions are limited to my understanding of the system and my understanding could not be exhaustive as I spent only some time on it. Also I asked them not to put my suggestions to work on a real infrastructure whereas to go ahead and implement my suggestions on an emulated infrastructure, Test it for a month before taking it into the real time infrastructure. (I should be thanking James Bach here without whom I would have taken a longer time to put such good things into my Testing virtue.) __ Why do you need to be a Tester? Wherever you are … __ “When a Tester is walking on a road, stay away, he might be Testing the tar laid on …” Regards, Pradeep Soundararajan Pradeep.srajan@gmail.com