Technovation By SKS

1. What is Automation? Controlling one application for another application. 2. What is Framework? A structure which consists of all the building blocks for developing an application. 3. What is Automation Framework? You are going to use the building block of structure to develop application which is going to control another application. 4. Background – Object Oriented If you have done development in any OO programming language then you can easily understand the concept of Framework and Automation. Take a simple example of Calculator. Can we call it an automated tool? Yes it is. You know why, because it controls the simple and scientific calculations. If you are asked to develop a program like calculator in any OO language, then you are going to make use of many pre-existing library, their methods, properties to accomplish your goal. Now these library or readymade utilities can be bundles in a framework and you just make use of that framework to execute

Introduction This white paper contains information related to tool and fire-fox add-ins that are freely available for usage when doing testing for websites. Website testing tool: Pixel Ruler v3.1 – Measure Vertical and Horizontal distance (in pixels) between various section of a website or your desktop. Firefox add-ins: TAW-it – Helpful in doing Accessibility testing Web Developer Website testing tool and add-ins Pixel Ruler Functionality Know the exact size and position of any element with this screen ruler. Free and easy to use virtual screen ruler. Float over your screen. Work with all applications. Show measurements in Pixels. Rotate to horizontal or vertical position. Maximum of 1300 pixels. Choose between several skins. How to install the application Download the Setup from http://www.mioplanet.com/products/pixelruler/index.htm Run the Setup Start using Pixel Ruler The supported Operating systems are Windows 98, ME, NT4, 2000, XP, Vista.

1.Introduction Quality Center is a test management tool which provides very good features for managing both your manual and automated test cases. This paper highlights the best practices for managing your test cases. When you open Quality center, depending on your rights it display the below mentioned option in the sidebar: 1. Requirements 2. Test Plan 3. Test Lab 4. Defects 5. Dashboard 2.Requirements When you have assigned with the responsibility of developing your test cases in the quality center then you must be wondering where to start with. I am going to share my experience to overcome such a situation. You need to find the solution of some question before you start writing your test cases. 1. Is your requirement developed and available? 2. Is your requirement organized in a logical sequence? If answer to both of the above question is Yes, then you can start with Requirement option in the side bar. In case your requirement is under development, then you keep your

I am expressing my views and learning on Agility for Testing. This article highlights the challenges and solution when one has to do the testing alongwith the development. What approach for testing should be taken when “Time to market” is an important factor. The solution of course is to utilize testing time alongwith the development. But is it such an easy task for tester or developer or for management? Of course, not. To successfully overcome such a situation requires commitment and support from the entire project stakeholder but more support, coordination and commitment are required among test team and development team. The process that should be followed to overcome such a situation is mentioned below: 1. Define your Test Strategy 2. Define your team and assign responsibility 3. Do not wait for a formal process of release 4. Keep doing the testing as soon as build is ready for testing (Do not wait for formal release) 5. Always keep in mind that tester and developer are wor

From programmers to users, everyone involved in software development agrees: Testing is good. So why so many systems are so badly tested? There are several problems with the traditional approach to testing: · If testing is not comprehensive enough, errors can make it into production and cause potentially devastating problems. · Testing is often done after all the code is written, or at least after the programmer who wrote the code has moved on to other things. When you are no longer living and breathing a particular program, it takes some time and effort to back into the code enough to deal with the problems. · Often tests are written by programmers other than those who wrote the code. Since they may not understand all of the details of the code, it is possible that they may miss important tests. · If the test writers base their tests on documentation or other artifacts other than the code, any extent to which those artifacts are out of date will cause problems. · If tests are n

What are the major challenges that you come across in your day to day work because of managerial decision and sometime you really feel frustrated because of them and it effect your productivity? I hope you came across with such a situation quite often when you are asked to focus on things decided by management. I am taking a typical example, you are doing a testing of a product and you are very much motivated about your work. Suddenly something happen and you are asked to do some other thing. How do you feel at that point? Stressed, Frustrated, de-motivated… Well let’s discuss about how you can counter such a situation which may have negative impact on your productivity and thus your quality work. Some of the key points that should always be on mind of a Quality Person to keep him/her motivated all the time is mentioned below. I have learnt all these from my experience. Be flexible in your work Do not create problems and always come up with some solution If you are asked to do some oth

Introduction Risk based testing is a concept which define the roadmap for making test strategy and taking decision on release of product. This concept outlines many of the important aspect of testing when time to market and quality has to be met. How many of times you have tested your product in limited time? I hope you have done it many a times? What approach you normally take when your testing schedule has been reduced and you are asked to test the application in limited schedule? Do you follow any defined approach to overcome such a scenario? I hope many of us “not”. We know all these concepts but making use of it is really difficult as we do not know how to approach with this concept. Purpose The purpose of this article is to present a practical approach to Risk based testing based on my experience. It may be applicable or may not be applicable for your day to day activity. References • CSTE Group • Project Experience - myself Input Testing schedule and effort has been reduced. Pro

What is Unit Testing? After writing any code, every programmer will do some kind of testing to make sure the code works as expected. This testing is called 'unit testing'. Unit testing is done in different ways. Some programmers write simple test applications to test their own code. Some others simply debug the code and change the values during debugging to make sure the code works fine for different cases. Some facts about unit testing: Unit testing is done by developers. Quality department does different tests, they are not unit tests. Every programmer must do unit testing after finishing development or during development itself. Unit testing can be done by writing separate test applications to call your classes and methods to make sure the classes work as expected. This is called manual unit testing. Unit testing can be automated by writing unit test scripts. This is called Automated Unit Testing. In automated Unit Testing, after writing each class/method, you will write sev

Do you know who distinguish testing from debugging? The separation of debugging from testing was initially introduced by Glenford J. Myers in 1979. Although his attention was on breakage testing ,it illustrated the desire of the software engineering community to separate fundamental development activities, such as debugging, from that of verification. Dr. Dave Gelperin and Dr. William C. Hetzel classified in 1988 the phases and goals in software testing in the following stages: Until 1956 - Debugging oriented 1957-1978 - Demonstration oriented 1983-1987 - Destruction oriented 1983-1987 - Evaluation oriented 1988-onward- Prevention oriented References: Myers, Glenford J. (1979). The Art of Software Testing. John Wiley and Sons. ISBN 0-471-04328-1 . Gelperin, D.; B. Hetzel (1988). "The Growth of Software Testing". CACM 31 (6). ISSN 0001-0782. until 1956 it was the debugging oriented period, when testing was often associated to debugging: there was no clear difference between te

Software testing is any activity aimed at evaluating an attribute or capability of a program or system and determining that it meets its required results. [Hetzel88] Although crucial to software quality and widely deployed by programmers and testers, software testing still remains an art, due to limited understanding of the principles of software. The difficulty in software testing stems from the complexity of software: we can not completely test a program with moderate complexity. Testing is more than just debugging. The purpose of testing can be quality assurance, verification and validation, or reliability estimation. Testing can be used as a generic metric as well. Correctness testing and reliability testing are two major areas of testing. Software testing is a trade-off between budget, time and quality. Software Testing is the process of executing a program or system with the intent of finding errors. [Myers79] Or, it involves any activity aimed at evaluating an attribute or cap

Regardless of the limitations, testing is an integral part in software development. It is broadly deployed in every phase in the software development cycle. Typically, more than 50% percent of the development time is spent in testing. Testing is usually performed for the following purposes: To improve quality. As computers and software are used in critical applications, the outcome of a bug can be severe. Bugs can cause huge losses. Bugs in critical systems have caused airplane crashes, allowed space shuttle missions to go awry, halted trading on the stock market, and worse. Bugs can kill. Bugs can cause disasters. The so-called year 2000 (Y2K) bug has given birth to a cottage industry of consultants and programming tools dedicated to making sure the modern world doesn't come to a screeching halt on the first day of the next century. [Bugs] In a computerized embedded world, the quality and reliability of software is a matter of life and death. Quality means the conformance to the

There is a plethora of testing methods and testing techniques, serving multiple purposes in different life cycle phases. Classified by purpose, software testing can be divided into: correctness testing, performance testing, reliability testing and security testing . Classified by life-cycle phase, software testing can be classified into the following categories: requirements phase testing, design phase testing, program phase testing, evaluating test results, installation phase testing, acceptance testing and maintenance testing . By scope, software testing can be categorized as follows: unit testing, component testing, integration testing, and system testing. Correctness testing Correctness is the minimum requirement of software, the essential purpose of testing. Correctness testing will need some type of oracle, to tell the right behavior from the wrong one. The tester may or may not know the inside details of the software module under test, e.g. control flow, data flow, etc. There

Testing is potentially endless. We can not test till all the defects are unearthed and removed -- it is simply impossible. At some point, we have to stop testing and ship the software. The question is when. Realistically, testing is a trade-off between budget, time and quality. It is driven by profit models. The pessimistic, and unfortunately most often used approach is to stop testing whenever some, or any of the allocated resources -- time, budget, or test cases -- are exhausted. The optimistic stopping rule is to stop testing when either reliability meets the requirement, or the benefit from continuing testing cannot justify the testing cost. [Yang95] This will usually require the use of reliability models to evaluate and predict reliability of the software under test. Each evaluation requires repeated running of the following cycle: failure data gathering -- modeling -- prediction. This method does not fit well for ultra-dependable systems, however, because the real field failure

Software testing is more and more considered a problematic method toward better quality. Using testing to locate and correct software defects can be an endless process. Bugs cannot be completely ruled out. Just as the complexity barrier indicates: chances are testing and fixing problems may not necessarily improve the quality and reliability of the software. Sometimes fixing a problem may introduce much more severe problems into the system, happened after bug fixes, such as the telephone outage in California and eastern seaboard in 1991. The disaster happened after changing 3 lines of code in the signaling system. In a narrower view, many testing techniques may have flaws. Coverage testing, for example. Is code coverage, branch coverage in testing really related to software quality? There is no definite proof. As early as in [Myers79] , the so-called "human testing" -- including inspections, walkthroughs, reviews -- are suggested as possible alternatives to traditional testin

Fundamental Issues in Software Testing (Part 1/3) (BBST) Fundamental Issues in Software Testing (Part 2/3) (BBST) Fundamental Issues in Software Testing (Part 3/3) (BBST)

Risk-Based Software Testing (Part 1/5) (BBST) Risk-Based Software Testing (Part 2/5) (BBST) Risk-Based Software Testing (Part 3/5) (BBST) Risk-Based Software Testing (Part 4/5) (BBST) Risk-Based Software Testing (Part 5/5) (BBST)

Quality Cost Analysis in Software Testing (Part 1/1) (BBST)

Becoming a Software Testing Expert