Jump to content
ChetanaSforum

yogindernath

Members
  • Content count

    49
  • Joined

  • Last visited

Community Reputation

0 Neutral

About yogindernath

  • Rank
    Advanced Member
  • Birthday 08/10/1984

Contact Methods

  • Website URL
    http://www.softwaretestinggenius.com
  • ICQ
    0

Profile Information

  • Gender
    Male
  • Location
    New Delhi
  • Interests
    Software Testing & Quality Assurance
  1. These days when tools & technology are available in abundance, automated testing is considered the prime resource to improve the efficiency of any software testing process. Sound planning, clear definition of roles of people involved in automated testing, adequate tools, their implementation & control are essential for the success of the automated tests in an organization.Automated testing tools must not be misunderstood as replacement of testers, nor they will make their work simpler. Actually their effort will be redirected to essential activities of the test automation process. That is why, it is essential to groom up the group, because the success of automated testing depends predominantly on their skills. Test-Stages Automation: When the automation can not be applied to the entire test process, it can be conveniently used to execute the punctual tests. This occurs normally with some types of tests – like load and performance tests; simply because they are truly difficult to be performed without the help of a tool, requiring big effort and many computational resources.
  2. We use Automated-testing tools to optimize our manual testing processes. But in order to reap full benefits of any automated testing tool, we must know the complete ins and outs of the tool otherwise it would be a huge waste of money spent on automation. We have to learn the automation tool very thoroughly. We also need to learn the language of the automation tool to do coding more effectively and efficiently. I believe that a software testing tool is as good as the person who is actually using it. I have been getting so many emails from my esteemed readers asking about HP QuickTest Professional tutorials, QTP tips and tricks etc. Some readers even complain that their QTP scripts are too slow to execute. This time I decided to write a post on how to use QTP more effectively which means how to make our QTP scripts perform better. In order words, this post will throw light on some points, which will optimize your QTP scripts. Some of the QTP optimization tips can be:Tip – 1: You should not use hard coded wait statement until absolutely necessary. Instead of the wait statement, you should use either exist or synchronization (sync) statements. The wait statement waits for the number of seconds, which have been provided. For example using wait(5) will wait for 5 seconds even if the browser gets into a ready state even after 2 seconds which means a waste of 3 seconds. Imagine how much time would be wasted if you have say 10 wait statements per script and you are running a batch of 500 scripts. A better alternative is using sync or exist statements for example:Browser("").Page("").Syncvar=Browser("").Page("").Exist(2)Never use the exist statement without a value as it will take the default object synchronization timeout value from QTP settings. You can navigate to these settings from File->Settings and then go to Run tab. So use Exist(0) instead of Exist(10). Moreover, I will suggest to set the global object synchronization timeout to 1 second.Tip – 2: Use declared variables instead of using variables on the fly. In order to enforce this in your scripts, use Option Explicit statement which forces the variable declaration. Moreover, using declared variables, scripts perform a bit faster. Also if you are using Option Explicit, it has to be the very first line of the code otherwise you will get an error.Tip – 3: Using QTP for a longer period of time has a direct impact on the performance. It has been observed that a lot of Random Access Memory(RAM) gets consumed by QTP if QTP is running scripts for prolonged time. QTP starts eating system memory(memory leak) and sooner or later it will get hanged and we will be required to kill the qtpro.exe process and restart QTP all over again. In such a case, I will suggest you is to use QTP on computers with particular good amount of RAM and equally good clock speed.Tip – 4: Do not load all addins while opening QTP. Use only the addins, which are required. This directly impacts QTP performance.Tip – 5: I have personally experienced that opening QTP through a vbs file is faster than loading QTP through the icon.Tip – 6: Switch to fast run mode. You can view this option in Tools->Options->Run. In fast mode, QuickTest Professional does not display the execution marker. In case you are running your scripts from Quality Center or QC, by default they will be run through fast mode. Tip – 7: Disable the Smart identification feature.Tip – 8: Switch off the video record option unless required as it will require fewer system resources. You can see this Option in QTP by navigating here Tools->Options->Run.Tip – 9: Use of Active screen feature should be avoided, so that we increase QTP Tool performance.Tip – 10: Instead of keeping the entire code in the same script, try to increase modularity by creating reusable components (Actions or functions) so that the code size can be reduced and also easier to maintain. To disable Action screen in QTP 11, go to Tools->Options->Active Screen and set the capture level to "None".Tip – 11: Destroy the objects when you no longer need them. As objects take up relatively large amount of system resources, it is better to destroy them when you don’t need them anymore. For example, please refer the following code:Set objFSO = CreateObject("Scripting.FileSystemObject")Set objRootFolder = objFSO.GetFolder("C:\")Set objFSO = NothingMsgbox "The folder was last modified on :"& objRootFolder.DateLastModifiedSet objRootFolder=NothingNotice from the above code that we need objFSO code just to retrieve the handle of "C" folder. As soon as you get the handle, you no longer need the objFSO folder. So instead of destroying this object reference at the last line, you should destroy when you don’t need the object reference anymore. You should follow the principle of limiting object lifetime as much as possible. Tip – 12: Creating an object reference increases the performance. For example, please refer the following QTP code:oEdit = Browser("Google").Page("Google").WebEdit("q")oEdit.Set "Optimize QTP Scripts"'The above code is definitely better in terms of performance than using the QTP code:Browser("Google").Page("Google").WebEdit("q").Set "Optimize QTP Scripts"You will not see major performance difference in this two liner code. To see a noticeable difference, you need to have hundreds of lines of QTP where you will see the difference. The reason is setting an object reference reduces the call to the Object repository.Tip – 13: I have also seen that using With statement in HP QTP increases performance but only upto a very small extent. In order to add With statement from QTP IDE, navigate to Tools->Options->General tab and select the option “Automatically Generate “With” statements after recording” option. Tip – 14: Having too many objects in the Object repository/shared object repository slows down the QTP scripts. So the best option is to have only the desired objects in the Object Repository.Tip – 15: Use local variables in functions rather than using global variables. The best practice is to limit the scope of a variable as much as possible.Tip – 16: Try to make sure that your QTP code does not wait for events, which have already been executed. For example see the below QTP code:iTimer = TimerobjWindow.Close Do If Dialog("micclass:=Dialog").Exist(0) Then _ Dialog("micclass:=Dialog").Type MicEsc Loop Until (Not objWindow.Exist) Or (Timer-iTimer>20)Instead of having a loop which will wait for 20 seconds for an event to occur, you should have a loop similar to the above. This loop will continue to loop until either of the condition is met: Either the timer has crossed 20 seconds or the window no longer exists.I hope the above article has touched lot many QTP optimization tips. I don't claim to be an expert on QTP, however I have made an attempt to share the above tips based upon my experience with this great tool. Please feel free to add some points in the comment section if I happen to miss any. I will be glad to update this article giving appropriate credit to the people.
  3. Software design errors and faults can be discovered and software designs validated by two techniques like: 1) Requirements-based test case design being the primary technique 2) Another important technique being the early design-based test case design. In design-based test case design the information for deriving them is taken from the software design documentation. Design-based test cases focus on the data and process paths within the software structures. Internal interfaces, complex paths or processes, worst-case scenarios, design risks and weak areas, etc. are all explored by constructing specialized test cases and analyzing how the design should handle them and whether it deals with them properly. In software testing effort, requirements-based and design-based test cases provide specific examples that can be used in design reviews or walkthroughs. Together they provide a comprehensive and rich resource for design based software testing. Design Testing Metrics: Increasingly, formal design reviews are adopting metrics as a means of quantifying test results and clearly defining expected results. The metrics (measures that are presumed to predict an aspect of software quality) vary greatly. Some are developed from scored questionnaires or checklists. For example, one group of questions may relate to design integrity and system security. Typical Integrity Questions can be like the following Q.1: Are security features controlled from independent modules? Q.2: Is an audit trail of accesses maintained for review or investigation? Q.3: Are passwords and access keywords blanked out? Q.4: Does it require changes in multiple programs to defeat the access security? Each reviewer would answer these questions, and their answers would be graded or scored. Over time, minimum scores are established and used as pass/ fail criteria for the integrity metric. Designs that score below the minimum are reworked and subjected to additional review testing before being accepted. Another example of a metric-based design test that can be used effectively is a test for system maintainability. An important consideration in evaluating the quality of any proposed design is the ease with which it can be maintained or changed once the system becomes operational. Maintainability is largely a function of design. Problems or deficiencies that produce poor maintainability must be discovered during design reviews; it is usually too late to do anything to correct them further along in the cycle of software testing. To test the maintainability we develop a list of likely or plausible requirements changes (perhaps in conjunction with the requirements review). Essentially, we want to describe in advance what about the system we perceive is most apt to be changed in the future. During the design review a sample of these likely changes is selected at random and the system alterations that would be required are walked through by the reviewers to establish estimates for how many programs and files or data elements would be affected and the number of program statements that would have to be added and changed. Metric values for these estimates are again set on the basis of past experience. Passing the test might require that 80 percent of the changes be accomplished by changes to single programs and that the average predicted effort for a change be less than one man-week. Designs that score below these criteria based on the simulated changes are returned, reworked, and re-subjected to the maintainability test before being accepted. This is just one example of an entire class of metrics that can be built around what-if questions and used to test any quality attribute of interest while the system is still being designed. Design for Testing: In addition to the testing activities we perform to review and test the design, another important consideration is the features in the design that simplify or support testing. Part of good engineering is building something in a way that simplifies the task of verifying that it is built properly. Hardware engineers routinely provide test points or probes to permit electronic circuits to be tested at intermediate stages. In the same way, complex software must be designed with "windows" or hooks to permit the testers to "see" how it operates and verify correct behavior. Providing such windows and reviewing designs to ensure their testability is part of the overall goal of designing for testability. With complex designs, testing is simply not effective unless the software has been designed for testing. Testers must consider how they are going to test the system and what they will require early enough in the design process so that the test requirements can be met. Design Testing Tools and Aids: Automated tools and aids to support design testing play an important role in a number of organizations. As in requirements testing, our major testing technique is the formal review; however there is a greater opportunity to use automated aids in support of design reviews. Software testing tools in common use include design simulators (such as the data base and response time simulators; system charters that diagram or represent system logic; consistency checkers that analyze decision tables representing design logic and determine if they are complete and consistent; and data base dictionaries and analyzers that record data element definitions and analyze each usage of data and report on where it is used and whether the routine inputs, uses, modifies, or outputs the data element. None of these software testing tools performs direct testing. Instead, they serve to organize and index information about the system being designed so that it may be reviewed more thoroughly and effectively. In the case of the simulators, they permit simplified models to be represented and experimentation to take place, which may be especially helpful in answering the question of whether the design solution is the right choice. All the tools assist in determining that the design is complete and will fulfill the stated requirements. Read Many more Flambuoyant Articles on Test Design
  4. Hello Friends, Quick Start to preparation for ISTQB Foundation Level Exam You want to shape up your career in testing? & Aspiring to appear in ISTQB Foundation level exam? & Do not wish to undergo a formal expensive training course? If Yes !!! Come on & read further. A) Important Facts you must know 1) ISTQB Foundation Certificate (Certified Tester Foundation Level) is an entry qualification for the ISTQB Advanced Certificate exam. 2) The ISTQB Certified Tester Foundation Level Syllabus has been updated in 2010. Following quick start tips are based upon the latest syllabus. 3) ISTQB Foundation Level exam is intended to check your knowledge of the entire discipline of software testing in a broader sense. 4) The Foundation Level syllabus is aimed it at people with varying levels of experience in testing, including persons with no experience at all. 5) The Foundation Level syllabus is freely available for download from www.istqb.org K-Levels related to topics in the Foundation Level Syllabus: Every topic in the syllabus corresponds to certain level of understanding, represented by the term K1, K2, K3 or K4 1) Level K1 refers to the ability to recall, so that you should be able to remember but not necessarily use or explain. 2) Level K2 refers to the ability to explain a topic or to classify information or make comparisons. 3) Level K3 refers to the ability to apply a topic in a practical scenario. 4) Level K4 refers to the ability to analyze a situation or a set of information to determine what action to take. C) K-Levels & associated levels of difficulty: 1) K1, K2, K3 and K4 levels do not reflect on being easy, moderate or hard. The K level identifies the level of understanding being tested, not the difficulty of the question. 2) It is possible that K2 questions might be more difficult (in the sense of being more challenging to answer) than a K3 question. 3) Generally K1 questions will be the most straightforward and if you are aware of the content of the syllabus, you won’t have difficulty in answering any K1 question. D) Breakup of Questions in the CTFL exam: 1) One-hour exams comprises of 40 multiple-choice questions. Every question has the same value. 2) 26 correct answers will guarantee a pass. There are no negative marking for the wrong answers. 3) The breakup of questions as per K-Levels is as under: a) K1 50%, 20 Questions a) K2 30%, 12 Questions c) K3 and K4 20%, i.e. 8 questions E) Type of Questions in the exam: Following shall generally apply. 1) All questions will contain a ‘stem’, which states the question, and four optional answers. 2) One and only one of the optional answers will be correct. The remaining options shall be incorrect. 3) If you are not sure of the correct answer you will possibly find one or more alternatives equally right. 4) Questions will be stated as clearly as possible, even emphasizing keywords by emboldening or underlining where this will add clarity. 5) There can be few negative questions (e.g. which of the following is not true?) and any negative questions included will be worded so that there is no ambiguity. 6) Questions will be set to test your knowledge of the content of the topics covered in the syllabus and not your knowledge of the syllabus itself. 7) Generally K1 questions will be of the straightforward type. 8) There will not be any K-Level label on the questions in the exam. F) Main Sections of Foundation Level Syllabus: The syllabus is broken down into six sections 1) Section 1: Fundamentals of testing – 7 Questions 2) Section 2: Testing throughout the software life cycle – 6 Questions 3) Section 3: Static techniques – 3 Questions 4) Section 4: Test design techniques – 12 Questions 5) Section 5: Test management – 8 Questions 6) Section 6: Tool support for testing – 4 Questions Above proportions of questions is approximate and the exact breakdown is not mandatory, but exams are by & large structured as per these & are quite close to these proportions as far as possible. G) Relation between K-Levels & Different Topics in Testing: 1) Level K4: It deals with statement and decision coverage. You can expect maximum two K4 questions and more likely only one, and the topic will be assessing statement and/or decision coverage for completeness with respect to meeting the specified exit criteria. 2) Level K3: Majority of K3 questions are likely to be based on Section 4 of the syllabus, hence most K3 questions will be about applying test design techniques. 3) Level K2: K2 questions shall be with more searching stem. The common type of K2 question is known as the Roman type. This is suited to questions involving comparisons or testing the candidate's ability to identify correct combinations of information. Topics can be examined at any level up to the maximum described in the syllabus for the particular topic. Hence a K3 topic can be examined at the K1 or the K2 level as well. H) Tips for better performance in the exam: 1) Read the syllabus carefully & you should be quite familiar with it. Generally the questions come directly from the syllabus and usually even the wording too is similar to that used in the syllabus. 2) Solve as many example questions as you can so that you become familiar with the wording of questions as well as types of questions. 3) It is a short duration exam, hence you will not be able to study the entire paper in depth. Hence to begin with, study the entire paper answering those questions that are straightforward and for which you know the answer. After finishing this simple task you will have a smaller task to complete and you will probably have taken less than a minute for each question that you have already answered, giving you more time to concentrate on those that you will need more time to answer. 4) If you have prepared well, you can answer 40 questions in less than 45 minutes. J) How to prepare for the CTFL Exam in the shortest possible time & without any formal training: Step –1: Deep study of the software testing basics as covered in the latest CTFL Syllabus by preparing from the Crash course study material available absolutely free. Download 30 Parts of Complete Study Material - ISTQB Foundation Level Exam
  5. You are the Best Judge of your own Capabilities & Potentials. No one else knows about you more than yourself. Try to Introspect & Discover yourself the Qualities / Potentials / Experience & Confidence you possess, & honestly try to assess the slot where you deserve to be placed as on date; from where upon you can improve to be an Excellent Manager of tomorrow. Here is a practical tool to introspect & know as to where you stand as a tester. This methodology can help you improve your testing abilities & excel in your career in testing. What you need to do is? Step -1: Carefully go through the following twenty-five questions or situations. Step -2: With a cool mind, try to figure out, if any situation or question fits on you as on date. If Yes !!! – Allocate "1" – Mark, otherwise allocate "0" – Mark against that question. Step -3: Continue allocation of marks till the end of questionnaire. Most Important – Please don’t jump to the end of the questionnaire to see the score calculation methodology; which could otherwise impose a bias in your assessment. Now carry on with the self-assessment exercise: Q. 1: Am I able to verify & say that it is possible to accomplish a particular task that appears difficult to many? Q. 2: Am I able to detect problems either in the process or the product faster than many? Q. 3: Am I able to identify & prevent potential problems before they come to the surface? Q. 4: Am I able to look back as to how the problems & bugs ended up in the product? Q. 5: Do I have understanding of general technologies in using & implementing my product? Q. 6: Do I have an attitude to break the things by which I may be able to learn more? Q. 7: Do I have an inquisitive mindset of asking questions especially the right ones, with an objective of learning? Q. 8: Do I optimize scarce resources & focus my attention on where I can find bugs? Q. 9: Do I have a habit of creating my own set good questions about the software and then looking for their answers? Q. 10: Do I tactfully react over the possible cause of the bugs or likely source of the bugs? Q. 11: Do I tend to go deeper into the code of the application prior to testing & restrain any impulse to use ad-hoc techniques and simplistic tools? Q. 12: Do I tend to understand as to how the users will exploit the program's features & the type of errors they are likely to make? Q. 13: Do I have an average intelligence but a high caliber as a tester? Q. 14: Do I tend to capture minute things usually ignored or missed by many? Q. 15: Do I tend to look for major or minor symptoms compared to bugs? Q. 16: Am I socially smart & diplomatic having good inter personnel skills to deal with programmers, especially the senior ones? Q. 17: Do I avoid reaching compromises and consensus in an effort to be socially adept smart? Q. 18: Do I prefer to use files, databases & checklists etc. compared to depending upon my razor sharp memory? Q. 19: Do I believe that I too can make mistakes, hence tend to double-check my findings prior to reporting? Q. 20: Am I organized & report my bugs accompanied by facts & evidence in support? Q. 21: Do I believe that manual testing is error prone & try to devise my own ways to reduce such methods may be by some sort of automation? Q. 22: Do I maintain a good standard of behavior? Meaning thereby total restraint on finger pointing, laughing at something found odd, undermining other persons work. Q. 23: Do I tend to perform test inspections in a way programmers do their code inspection? Q. 24: Do I have an appetite for applicable technology? Q. 25: Do I tend to dig out problems in the code by cooperating with developers aiming to identify further issues? Comments supporting some of the questions listed above: Q. 4: Such information can be used to improve the process in future Q. 7: Asking questions is the best way to learn, but at the same time question must not be stupid. Q. 9: Asking questions about software, thoroughly interrogating it greatly helps in escalating the knowledge of the code the tester is working on. Q. 10: Being tactful refers to an ability to peep into the source of the bugs and quickly understanding the possible cause of them – like the management, designers or the developers. Q. 15: Usually symptoms are not bugs. Symptoms don’t have categories like major or minor, whereas the bugs have. Q. 16: Diplomacy could refer to good inter personnel skills, being thick skinned & having a good sense of humor. Q. 21: Initiative to improve the quality of own work may be by automation, by devising own ways to eliminate error-prone methods is a positive trait. Q. 22: Attributes of poor behavior are finger pointing, laughing at something found odd, undermining other persons work. Read the full article & your scorecard at: http://www.softwaretestinggenius.com/artic...ils.php?qry=769
  6. Brief Introduction to Keyword based Framework: Keyword-based software test automation framework can reduce the cost and time of test design, automation and execution. It allows members of a testing team to focus on what they do best, but also allows non-technical testers and business analysts to write automated tests. Keyword-based test design and test automation is founded on the premise that the discrete functional business events that make up any application can be described using a short text description (keyword) and associated parameter value pairs (arguments). For example, most applications require users to log in; the keyword for this business event could be "Logon User" and the parameters could be "User Id" and "Password". By designing keywords to describe discrete functional business events, testers begin to build up a common library of keywords that can be used to create keyword test cases. This is really a process of creating a language (keywords) to describe a sequence of events within the application (test case). When properly implemented and maintained, keywords present a superior return on investment because each business event is designed, automated and maintained as a discrete entity. These keywords can then be used to design keyword test cases, but the design and automation overhead for the keyword has already been paid. When a change occurs within any given keyword, the affected test cases can easily be found and updated appropriately. And once again, any design or automation updates to the keyword are performed only once. Compare this to the Record and Playback approach, which captures a particular business event or part of the business event each time a test case traverses it. (If there are 100 test cases that start with logging on, then this event will have automated 100 times and there will be 100 instances to maintain.) Read the complete article at http://www.softwaretestinggenius.com/artic...ils.php?qry=766
  7. IEEE 829 standard prescribes many specifications related documents. Three such documents are 1) Test Design Specifications 2) Test Case Specifications 3) Test Procedure Specifications Let us go a bit deeper into the salient features of each of these documents being crucially important in any testing effort. 1) Test Design Specifications The objective of compiling test design specifications is to identify set of features or a combination of features to be tested and to identify the group of test cases that will adequately test those features. In addition to these it contains all types of refinements done to the approach described in the test plan. The test design specification consists of following essential parts: 1) Test design specification identifier: A unique identifier is to be allocated so that the test design specification document can be distinguished from all other documents. 2) Features to be tested: It describes the test items and the features that are the object of this test design specification. 3) Approach refinements: It describes the test techniques to be adopted for this test design. 4) Test identification: It describes a comprehensive list of test cases associated with this test design. It provides a unique identifier and a short description for every test case. 5) Acceptance criteria: It describes the criteria to confirm as to whether each feature has passed or failed during testing. Read the complete article at http://www.softwaretestinggenius.com/artic...ils.php?qry=764
  8. Prima facie, a software application appears more validated by the presence of a test plan. Although plenty of IEEE standards are in use by the testing industry, still there is no hard & fast rule to stick to any one in particular. Many times company specific test plans customized to suit ones own requirement prove to be more useful & acceptable to the testing personnel. A good Tester is the one who prepares a “Test Plan” for every level of testing, and clearly describes its objectives & most important aspect is that he/she operates on it. The test plan can have several parts but the most important aspect is the simple presence of the test plan itself. Reason being this becomes the starting point from which the entire process gets kick started & it contains the scope of the entire testing assignment. A test plan has systematic outline of all features & functionality that are continuously checked based upon the matrix of responsibilities & risks associated with the process. An effective test plan comprises of the following parts: 1) Test plan identification: A unique identifier is to be allocated so that the test plan document can be distinguished from all other documents. 2) Brief Introduction: A summary of the software to be tested. A brief description and history may be included to set the context. References to other relevant documents useful for understanding the test plan are appropriate. Definitions of unfamiliar terms may be included. 3) Items to be tested: A comprehensive list of software items that are to be tested is to be documented. It is the gist of software application areas that is the object of testing. 4) Features to be tested: A comprehensive list of characteristics of all the items to be tested. These include functionality, performance, security, portability, usability, etc. 5) Features not to be tested: Identifies characteristics of the items that need not be covered under our testing effort along-with brief outline of reasons of not doing so. Read the complete article at http://www.softwaretestinggenius.com/artic...ils.php?qry=763
  9. If you want to acquire any of the HP certifications like QTP HPO-M16, Quality Center HPO-M15, LoadRunner HPO-M18 or HPO-M19 or Performance Center HPO-M17, it is essential to obtain HP Learner ID beforehand. Although some of the Prometric Centers may permit examination even without HP Learned ID, but a success in such an exam shall not be worthwhile, since you won’t get the HP certification. Hence it is wise to go in for HP Learner ID, and, proceed smilingly on the highway to your dream certification. Step-by-step process to obtain the HP Learner ID Enjoy possessing your hard earned HP Learner ID (But for this event you may have to wait for 6 business days after you register).
  10. Complete information on ISTQB Certification is being provided in the form of easily understandable 12 Nos. Questions & Answers. Q. 1: What is ISTQB? ISTQB stands for “International Software Testing Qualifications Board”. It is Belgium based International body legally established in the year 2002. Software testing professionals from all over the world joined hands in formulating standardized contents for further education in the field of Software Testing. It is a multiple-choice exam & is an education program offered in 38 countries <<<<<< =================== >>>>>> Q. 2: How many Levels of Certification are provided by ISTQB? The ISTQB has come out with an International Qualification Scheme called "ISTQB Certified Tester". Presently there are two levels of exams leading to the specific levels of certification. 1) Foundation Level Certification: Name of this certification is “Certified Tester Foundation Level” (CTFL). This is the only one foundation level exam. This is an entry level certification meant for people entering the field of testing and for experienced professionals desiring to move up the ladder of ISTQB certifications. Foundation Level Certification offers evidence that the certified person has a broad understanding of the key concepts & fundamental best practices of software testing. 2) Advanced Level Certification: Name of this certification is “Certified Tester Advanced Level” (CTAL). This is the intermediate level certification. Eligibility for this exam is Foundation level certification i.e. CTFL certificate & 5 years experience of software testing. The candidate must have a Bachelor’s Degree in IT or Computer Science or related field from a recognized institution; this can be substituted by two years of work experience in Software Testing. Advanced Level Certification offers evidence that the certified person is a committed testing professional and has thorough understanding of key concepts & advanced best practices of software testing. Following 3 - interrelated Advanced Level Certification Exams are available: Candidate can go in for either or all of these advanced level certifications. a) Advanced Level Functional Tester: This advanced level certification is meant for software testers especially part of independent test teams involved in business-oriented testing. It provides the users the much needed & detailed information related to specifics of different testing techniques like behavioral testing or Black Box testing / White Box testing etc. Advanced Level Test Manager: This advanced level certification is meant for test managers, development managers, and project managers responsible for testing. c) Advanced Level Technical Tester: This advanced level certification is meant for testers and programmers involved in non functional testing, structural testing or White Box Testing & for testers involved in automation. Additional Advanced Level Certification: After completing the above three advanced level certifications, one can go in for an additional Advanced Level Certification by the name “Advanced Level (CTAL) – Full Advanced Level”. This is an exam of 1.5 hours duration. 3) Expert Level Certification: Has not started yet. Expert Level Certification is meant for leaders of the field of software testing with eight or more years of experience. Expert Level Certification offers evidence that the certified person is a seasoned testing professional and has consistent understanding & execution of proven cutting edge techniques in testing. <<<<<< =================== >>>>>> Q. 3: Who provides the ISTQB Certification? Q. 4: What is the period of validity of ISTQB Certifications? Q. 5: What are the Advantages of ISTQB Certifications? Q. 6: What are the Salient Features of the Foundation Level (CTFL) Exam? Q. 7: What is the Structure of Foundation Level (CTFL) Exam? Q. 8: What is the Syllabus for various ISTQB certifications Exams? Q. 9: How do I prepare for the ISTQB Exams? How can I download the Study Material etc.? Q. 10: Whether certification exam is same everywhere? Q. 11: How to register for the Foundation Level (CTFL) Exam with ITB? Q. 12: Whether ITB / ISTQB certification can be taken Online? Other useful Information like: ISTQB Certification Schemes at a Glance Useful Tips & Tricks for success in ISTQB exam: Detailed understanding of Various Knowledge Levels Download the Largest Database of Unique Sample Question Papers Read the Detailed Answers & explanation of all the above Questions
  11. First of all let us see how IEEE defines the terms Verification & Validation A) Software Verification: "it is the process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase." OR "it is the process of evaluating, reviewing, inspecting and doing desk checks of work products such as requirement specifications, design specifications and code". OR "It is a human testing activity as it involves looking at the documents on paper." Software Validation: "It is defined as the process of evaluating a system or component during or at the end of development process to determine whether it satisfies the specified requirements. It involves executing the actual software. It is a computer based testing process." Both verification and validation (V&V) are complementary to each other. Hence good testing expects more than just running a program. To demonstrate this statement let us examine an example cum tutorial for leap-year function working on MS SQL (Server Data Base) CREATE FUNCTION f_is_leap_year (@ ai_year small int) RETURNS small int AS BEGIN --if year is illegal (null or -ve), return -1 IF (@ ai_year IS NULL) or (@ ai_year <= 0) RETURN -1 IF (((@ ai_year % 4) = 0) AND ((@ ai_year % 100)< > 0)) OR ((@ ai_year % 400) = 0) RETURN 1 --leap year RETURN 0 --Not a leap year END Now let us execute the above program with different inputs as described in following Database table: Test_leap_year Sr. Year (Year to Test) Expected Result Observed Result Match 1 -1 -1 -1 Yes 2 -400 -1 -1 Yes 3 100 0 0 Yes 4 1000 0 0 Yes 5 1800 0 0 Yes 6 1900 0 0 Yes 7 2010 0 0 Yes 8 400 1 1 Yes 9 1600 1 1 Yes 10 2000 1 1 Yes 11 2400 1 1 Yes 12 4 1 1 Yes 13 1204 1 1 Yes 14 1996 1 1 Yes 15 2004 1 1 Yes There are 15 sets of inputs in the above database table. We may feel that these 15 cases are sufficient for such a small program. We may write 100 such cases and show that this program behaves as per specifications. However, this is not testing. By testing any program, we mean adding value to it. Adding value means raising the quality or reliability of the program. And raising the reliability means finding and removing faults. Hence, our objective should not be to show that the program works as per specifications. But, we should do testing with the assumption that there are faults and our aim is to remove these faults at the earliest. If our goal is to demonstrate that a program has faults, our inputs selection should have a higher probability of finding faults. We should concentrate only on weak and critical areas of the program. The critical areas for the above leap year program are as under 1) Removing statement ((@ ai_year % 400) = 0 would result in Y2K problem. 2) Entering year in float format e.g., 2007.12. 3) Entering year as a character or as a string. 4) Entering year as NULL or zero (0). We may think of so many situations, which are quite risky for this leap-year function. These are critical areas. And the results are very strange with these inputs. Our objective is to identify weak situations of any program and design test cases that makes the program to fail under such simple circumstances that no one would tolerate. If we are not able to remove faults, then proper warning messages should be introduced at proper places in the program. Hence we can say that a good tester is the one who gets the most faults fixed. Read Many More Excellent Articles on Software Verification & Validation (V&V) Download the complete Information & Study Material for ISTQB Certification
  12. Q. 1: What sort of errors are covered by the Regression Testing? Regression testing includes mainly, four types of errors 1) Data Corruption Errors: Due to sharing of data these errors result in side effects. 2) Inappropriate Control Sequencing Errors: Due to the changes in the execution sequences, these errors result in side effects. For example, an attempt to remove an item from a queue before it is placed into the queue. 3) Resource Contention: Potential bottlenecks and deadlocks are some examples of these types of errors. 4) Performance Deficiencies: Timing errors and storage utilization errors are some examples of these types of errors. <<<<<< =================== >>>>>> Q. 2: What is Criticality Analysis? It is a method to locate and reduce high-risk problems. It is performed at the beginning of the project. It identifies the functions and modules that are required to implement critical program functions or quality requirements like safety, security etc. Following steps are used in criticality analysis: Step - 1: Develop a block diagram or control flow diagram of the system and its software elements. Each block or control flow box represents a system or software function (module). Step - 2: Trace each critical function or quality requirements through the block or control flow diagram. Step - 3: Classify all traced software functions (modules) as critical to either the proper execution of critical software functions or the quality requirements. Step - 4: Focus additional analysis on these traced critical software functions (modules). Step - 5: Repeat criticality analysis for each life-cycle process / activity to determine whether the implementation details shift the emphasis of the criticality. <<<<<< =================== >>>>>> Q. 3: What is Traceability Analysis? Traceability analysis traces each software requirement back to the system requirements. This is done to ensure that each requirement correctly satisfies the system requirements. This analysis will also determine whether any derived software requirements are consistent with the original objectives, physical laws and technologies described in the system document. <<<<<< =================== >>>>>> Q. 4: What is Interface Analysis? It is a detailed examination of the interface requirements specifications. The evaluation criteria here are on the interfaces between the software and other hardware, user and external software. Criticality analysis is continued and updated for the software. Criticality is assigned to each software requirement. When requirements are combined into functions, the combined into functions, the combined criticality of requirements form the criticality for the aggregate function. The criticality analysis is updated periodically as requirement changes are introduced as such changes can cause a functions criticality to increase or decrease depending on the how the revised requirements impacts system criticality. <<<<<< =================== >>>>>> Q. 5: Describe the tool support for review processes. As tools become available to perform some of the tasks previously done by humans, the cost effectiveness of review processes increases. For example, utilization of a compiler to detect syntax errors in code and thus alleviating this task for the reviewers. Another example is the design and specification consistency checkers. <<<<<< =================== >>>>>> Q. 6: Describe some techniques to find the types of errors. Some of the techniques are described below: 1) Algorithm Analysis: It examines the logic and accuracy of the software requirements by translating algorithms into some language or structured format. The analysis involves re-deriving equations or evaluating the suitability of specific numerical techniques. Algorithm analysis examines the correctness of the equations and numerical techniques, truncation and sounding effects, numerical precision of word storage and variables and data typing influences. 2) Analytic Modeling: It provides performance evaluation and capacity planning information on software design. It represents the program logic and processing of some kind of model and analyzes it for efficiency. 3) Control Flow Analysis: It is used to show the hierarchy of main routines and their sub-functions. It checks that the proposed control flow is free of problems like unreachable or incorrect code. 4) Database Analysis: It ensures that the database structure and access methods are compatible with the logical design. It is done on programs with significant data storage to ensure that common data and variable regions are used consistently among all calling routines, that integrity of the entire data is maintained. At the same time it is ensured that no accident is able to overwrite any variable or any portion of the data by any data tables which happen to overflow. It is ensured that all data typing & its use are consistent all across the program. <<<<<< =================== >>>>>> Q. 7: What is Desk Checking? It involves the examination of the software design or code by an individual. It includes 1) Looking over the code for defects. 2) Checking for correct procedure interfaces. 3) Reading the comments and comparing it to external specifications and software design. <<<<<< =================== >>>>>> Q. 8: What are Petri-nets? Petri-nets model system to assure software design adequacy for catastrophic failure. The system is modeled using conditions and events represented by STDs. They can be executed to see how the software design will actually work under certain conditions. <<<<<< =================== >>>>>> Q. 9: What is program slicing ? Slicing is a program decomposition technique used to trace an output variable back through the code to identify all code statements relevant to a computation in the program. <<<<<< =================== >>>>>> Q. 10: What is Test Certification? It ensures that the reported test results are the actual finding of the tests. Test related tools, media & documentation are certified to ensure maintainability and repeatability of tests. This technique is also used to show that the delivered software product is identical to the software product that was subjected to V&V. It is used in critical software systems to verify that the required tests have been executed and that the delivered software product is identical to the product subjected to software V&V. Read Many More Excellent Articles on Software Verification & Validation (V&V) Download the complete Information & Study Material for ISTQB Certification
  13. Are you appearing for IBM Rational Functional Tester for Java Certification IBM RFT 000-842 exam? If yes !!! You would certainly like to review your knowledge before appearing in the exam. The Question Bank contains special Objective Type questions compiled by persons who have already cleared IBM RFT 000-842 Exam. These will be of great help to all of you in your pursuit for IBM RFT Certification. Download the Complete Question Bank on RFT Other Useful Study Material on Rational Functional Tester Download Tutorials on RFT - Rational Functional Tester Download Interview Preparation Questions on RFT Brought to you by: Yogindernath http://www.softwaretestinggenius.com A Storehouse of Complete Knowledge on Software Testing & QA under one Roof
  14. Are you planning to appear for ISTQB Certification exam? If yes !! You would certainly like to catch the starting point Get the answers to the two key questions like Question – 1: Where can I get the complete information on ISTQB Foundation Level Certification Download Complete Information on ISTQB Certification If you had downloaded many question papers from several places, but several of them are full of questions repeating time & again. In the beginning downloading several hundred questions is exciting – but becomes frustrating when you realize gradually that majority of these questions are duplicates & triplicates. Question – 2: Is there any place where I can get complete study material & unique questions may be small in numbers. This Question Bank contains around Six Hundred – Absolutely Unique Objective Type questions compiled to help aspirants for ISTQB certification exam. Download the Largest Dump of Unique ISTQB Sample Question Papers Yogindernath
  15. Planning to appear in HPO-M16 exam for Certification on HP QuickTest Professional 9.2 software? Have a quick pre exam review of your knowledge to assure you of a good score. The Question Bank contains 100 Nos. Special High Quality Objective Type Questions with answers, which are constantly being updated by us. A thorough practice from this knowledge base will help you acquire deeper understanding of HP QTP 9.2 software & get success in certification exam HPO-M16 as well. Download the QTP Question Bank Download Complete Information you would like to know on QTP Certification You can write to software.testing.genius@gmail.com for any clarification & any other information on QTP Certification Yogindernath
×