Saturday, 1 September 2012
Wednesday, 29 August 2012
Monday, 27 August 2012
Wednesday, 25 July 2012
QTP Check Points
A Checkpoint is a confirmation or verification point in which the value of some property which is expected at a particular step is compared with the actual value which is displayed in the application. Based on the expected values Checkpoints are classified as follows
- Page Checkpoint : A Standard Checkpoint created for a web page can be called a Page Checkpoint. It is used to check total number of links & images on a web page. Page Checkpoints can be used to check Load Time i.e. time taken to load a web page.
- Bitmap Checkpoint helps a user in checking the bitmap of an image or a full web page. It does a pixel by pixel comparison between actual and expected images.
- Image Checkpoint enable you to check properties like source file location of a web image. Unlike , Bitmap Checkpoint you can not check pixels(bitmaps) using image checkpoint.
- Text Checkpoint is Used to check expected text in a web-page or application. This text could be from a specific region of the application or a small portion of text displayed
- Accessibility Checkpoints verifies compliance with World Wide Web Consortium (W3C) instructions and guidelines for Web-based technology and information systems. These Guidelines make it easy for disabled to access the web.
- Database Checkpoints create a query during record time and database values are stored as expected values. Same query is executed during run time and actual & expected values are compared.
- In Table Checkpoint , you dynamically can check the contents of cells of a table (grid) appearing in your environment. You can also check various table properties like row height , cell width and so on. Table Checkpoint is similar to Database Checkpoint
- Using XML Checkpoints you can verify XML Data ,XML Schema, XML Data
Tuesday, 24 July 2012
V-Model description
the V-Shaped life cycle is a sequential path of execution of processes. Each phase must be completed before the next phase begins. Testing is emphasized in this model more so than the waterfall model though. The testing procedures are developed early in the life cycle before any coding is done, during each of the phases preceding implementation.
Requirements begin the life cycle model just like the waterfall model. Before development is started, a system test plan is created. The test plan focuses on meeting the functionality specified in the requirements gathering.
The high-level design phase focuses on system architecture and design. An integration test plan is created in this phase as well in order to test the pieces of the software systems ability to work together.
The low-level design phase is where the actual software components are designed, and unit tests are created in this phase as well.
The implementation phase is, again, where all coding takes place. Once coding is complete, the path of execution continues up the right side of the V where the test plans developed earlier are now put to use.
Advantages
a. Simple and easy to use.
b. Each phase has specific deliverables.
c. Higher chance of success over the waterfall model due to the development of test plans early on during the life cycle.
d. Works well for small projects where requirements are easily understood.
Disadvantages
a. Very rigid, like the waterfall model.
b. Software is developed during the implementation phase, so no early prototypes of the software are produced.
c. Model doesn’t provide a clear path for problems found during testing phases.
WHY NOT EXPLORATORY TESTING
Why not Exploratory Testing?
Most of the Test Managers says, "Testing without Test Plans is a crime". The Testers should know what is being built and he should analyse the way to proceed. He/ She will have to prepare the Test Plans based upon that to proceed with Testing the Application. Good knowledge of Exploratory Testing is necessary for reading this article. For those who dont have much idea about Exploratory Testing , a small intro is given here.
"The plainest definition of exploratory testing is test design and test execution at the same time. Exploratory software testing is a powerful and fun approach to testing. In some situations, it can be orders of magnitude more productive than scripted testing. I haven’t found a tester yet who didn’t, at least unconsciously, perform exploratory testing at one time or another. Yet few of us study this approach, and it doesn’t get much respect in our field. It’s high time we stop the denial, and publicly recognize the exploratory approach for what it is: scientific thinking in real time. Friends, that’s a good thing".
–James Bach
There are lots of myths that is behind the Exploratory Testing and the objective of this writing is to expose them. There are lots of proofs which tells that Exploratory Testing is the best among the other testing techniques. The user of this article is recommended to have some idea about the advantages of Exploratory Testing. If the user is a beginner then he can gather information about what are all the circumstances, one can go for an Exploratory Testing, without knowing the reason behind it.
"A test that reveals a problem is a success. A test that did not reveal a problem was a waste of time"
- Cem Kaner
In this Internet arena, in an organization with no Software Configuration Management, Projects are built without any kind of Documentations. If they are available also, they are not going to get updated, as and when the modifications from the client is received. The Project Manager conveys the modifications to his/her team by word of mouth and gets the modifications done without getting them updated in the documentation. It is inevitable for him to get the modifications updated in the documentation, but at the same time, when he prioritizes to get the changes implemented in the code, the former gains low priorities serially and that goes out of his mind, if the code is done. This is going to have a direct impact on the Testing Process. If you are deriving the Test Cases out of the documentations, your Test Cases are going to get aged soon. It is not worth to look back at them. We cannot use them as it has no relevance with the Code. The time invested in preparing the Test Cases is wasted, here.
Let us consider that the requirement is going to get changed frequently, say 4-5 modifications per day. It is the tendency of the people to forget about the documentions and to concentrate more on the implementation part. These are all happening because of the time and cost associated with that. Though they are all inevitable from the angle of LAW, the need of rigor and to satisfy the customer at time pushes the Project Manager to forego this activity, as he/she considers it as a overhead. Finally, they got approval for doing this from the Top Management also. The project life travels in a planned undocumented way and how we can expect the testing should happen in a planned documented, properly scripted WAY?
"If you think you can fully test a program without testing its response to every possible input, fine. Give us a list of your test cases. We can write a program that will pass all your tests but still fail spectacularly on an input you missed. If we can do this deliberately, our contention is that we or other programmers can do it accidentally"
- Cem Kaner
A well documented Test Scripts can also miss bugs. Unplanned Adhoc Testing can also miss bugs. For the former, Time + Money is invested for finding the bugs. As every process is having its own entropy associated with that, this is not an odd process. This have its own entropy, leaving some bugs, covered. The same applies for the latter too. In an organization with no Software Configuration Management, experience proves that the number of bugs covered by well planned Test Scripts is less than the Unplanned Adhoc Testing. But when tried to put a Cost Benefit analysis, the Test Manager is pushed to follow an Unplanned Adhoc Testing approach. Instead of going to an Unplanned Adhoc Testing, why not Exploratory Testing?
"Myers described a much simpler program in 1979. It was just a loop and a few IF statements. In most languages, you could write it in 20 lines of code. This program has 100 trillion paths; a fast tester could test them all in a billion years"
- Cem Kaner
Testing cannot be claimed that it is completed. Testers cannot claim that the program is 100% error free. 20 lines of code is having 100 trillion paths. We normally deal with Klocs, that gives a very big figure, when extrapolated. If we wanna uncover most of the bugs, we have to select Test Cases from the Test Cases for trillion paths, which is trillion*n in number. Planning these type of tests requires more time, which we cannot think if we are in Web Time. If no time is available, then the tests become Uplanned and Adhoc. Started with a good plan, morphed to Unplanned and Adhoc at the end. Instead of welcoming this, Why not Exploratory Testing?
"If you want and expect a program to work, you will be more likely to see a working program – you will miss failures. If you expect it to fail, you'll more likely to see the problems. If you are punished for reporting failures, you will miss failures. You won't only fail to report them – you will not notice them"
- Cem Kaner
Testing relies on the mindset of the testers. It is an art. Most of them says that tests have to be well planned and executed. Let us take a case that we are well planning 100 tests for a program which is going to leave, say 20 bugs covered. Testing is a creative work. It the testers have to go by these well planned 100 tests, they will not be exploratory while executing them. Instead they are required to be more exploratory, while they are executing the tests. They have to be exploratory to find the remaining 20 bugs. If that 20 bugs are going to be very major ones and these 100 tests are going to give only very little number of minor bugs, then what is the advantage in investing a huge amount of money in designing those 100 tests. Instead of this strategy, why not exploratory testing?
Testing is creative work. Agreed, the exploratory nature of the tester is needed very much while designing the tests. At the same time, it is needed very much more than while designing the tests. We cannot deny the fact that exploration is not needed while executing the tests and we cannot categorize that under Unplanned Adhoc testing. This world has got its electric light because of the exploration of Thomas Alwa Edison. This world has got its Air Traffic because of the exploration of Right Brothers. Exploration is the one which is going to fetch good results and remarkable results at the end. Exploration at the time of designing the tests is very much needed for a complex application to plan for the areas which is new for the tester and the areas which are old to him need not to be planned for test as he is good enough with finding bugs with Exploratory Testing for those areas. Even if the tests for that complex parts of the application are not planned also, they can be done at the time of execution if the tester is having expertise in testing and that too in Exploratory Testing, very much.
Designing the tests is also an art and it also involves creativity in itself. It is the different ways of thinking of the tester as an individual which is put into papers and termed as Test Plan. Testing is a mindset. The interpretation of the information differs from people to people. If this is the case then coverage of testing can be achieved by more than one people testing the same piece of code. Thus with the different ways of exploration, we can achieve the coverage.
Summary :
If the exploration is done on Test Application for testing that, then that is termed as Exploratory Testing. If the exploration is done on Test Application for designing the tests then that is termed as Test Planning. Whatever the terms used, Exploration in testing is very much in need.
Most of the Test Managers says, "Testing without Test Plans is a crime". The Testers should know what is being built and he should analyse the way to proceed. He/ She will have to prepare the Test Plans based upon that to proceed with Testing the Application. Good knowledge of Exploratory Testing is necessary for reading this article. For those who dont have much idea about Exploratory Testing , a small intro is given here.
"The plainest definition of exploratory testing is test design and test execution at the same time. Exploratory software testing is a powerful and fun approach to testing. In some situations, it can be orders of magnitude more productive than scripted testing. I haven’t found a tester yet who didn’t, at least unconsciously, perform exploratory testing at one time or another. Yet few of us study this approach, and it doesn’t get much respect in our field. It’s high time we stop the denial, and publicly recognize the exploratory approach for what it is: scientific thinking in real time. Friends, that’s a good thing".
–James Bach
There are lots of myths that is behind the Exploratory Testing and the objective of this writing is to expose them. There are lots of proofs which tells that Exploratory Testing is the best among the other testing techniques. The user of this article is recommended to have some idea about the advantages of Exploratory Testing. If the user is a beginner then he can gather information about what are all the circumstances, one can go for an Exploratory Testing, without knowing the reason behind it.
"A test that reveals a problem is a success. A test that did not reveal a problem was a waste of time"
- Cem Kaner
In this Internet arena, in an organization with no Software Configuration Management, Projects are built without any kind of Documentations. If they are available also, they are not going to get updated, as and when the modifications from the client is received. The Project Manager conveys the modifications to his/her team by word of mouth and gets the modifications done without getting them updated in the documentation. It is inevitable for him to get the modifications updated in the documentation, but at the same time, when he prioritizes to get the changes implemented in the code, the former gains low priorities serially and that goes out of his mind, if the code is done. This is going to have a direct impact on the Testing Process. If you are deriving the Test Cases out of the documentations, your Test Cases are going to get aged soon. It is not worth to look back at them. We cannot use them as it has no relevance with the Code. The time invested in preparing the Test Cases is wasted, here.
Let us consider that the requirement is going to get changed frequently, say 4-5 modifications per day. It is the tendency of the people to forget about the documentions and to concentrate more on the implementation part. These are all happening because of the time and cost associated with that. Though they are all inevitable from the angle of LAW, the need of rigor and to satisfy the customer at time pushes the Project Manager to forego this activity, as he/she considers it as a overhead. Finally, they got approval for doing this from the Top Management also. The project life travels in a planned undocumented way and how we can expect the testing should happen in a planned documented, properly scripted WAY?
"If you think you can fully test a program without testing its response to every possible input, fine. Give us a list of your test cases. We can write a program that will pass all your tests but still fail spectacularly on an input you missed. If we can do this deliberately, our contention is that we or other programmers can do it accidentally"
- Cem Kaner
A well documented Test Scripts can also miss bugs. Unplanned Adhoc Testing can also miss bugs. For the former, Time + Money is invested for finding the bugs. As every process is having its own entropy associated with that, this is not an odd process. This have its own entropy, leaving some bugs, covered. The same applies for the latter too. In an organization with no Software Configuration Management, experience proves that the number of bugs covered by well planned Test Scripts is less than the Unplanned Adhoc Testing. But when tried to put a Cost Benefit analysis, the Test Manager is pushed to follow an Unplanned Adhoc Testing approach. Instead of going to an Unplanned Adhoc Testing, why not Exploratory Testing?
"Myers described a much simpler program in 1979. It was just a loop and a few IF statements. In most languages, you could write it in 20 lines of code. This program has 100 trillion paths; a fast tester could test them all in a billion years"
- Cem Kaner
Testing cannot be claimed that it is completed. Testers cannot claim that the program is 100% error free. 20 lines of code is having 100 trillion paths. We normally deal with Klocs, that gives a very big figure, when extrapolated. If we wanna uncover most of the bugs, we have to select Test Cases from the Test Cases for trillion paths, which is trillion*n in number. Planning these type of tests requires more time, which we cannot think if we are in Web Time. If no time is available, then the tests become Uplanned and Adhoc. Started with a good plan, morphed to Unplanned and Adhoc at the end. Instead of welcoming this, Why not Exploratory Testing?
"If you want and expect a program to work, you will be more likely to see a working program – you will miss failures. If you expect it to fail, you'll more likely to see the problems. If you are punished for reporting failures, you will miss failures. You won't only fail to report them – you will not notice them"
- Cem Kaner
Testing relies on the mindset of the testers. It is an art. Most of them says that tests have to be well planned and executed. Let us take a case that we are well planning 100 tests for a program which is going to leave, say 20 bugs covered. Testing is a creative work. It the testers have to go by these well planned 100 tests, they will not be exploratory while executing them. Instead they are required to be more exploratory, while they are executing the tests. They have to be exploratory to find the remaining 20 bugs. If that 20 bugs are going to be very major ones and these 100 tests are going to give only very little number of minor bugs, then what is the advantage in investing a huge amount of money in designing those 100 tests. Instead of this strategy, why not exploratory testing?
Testing is creative work. Agreed, the exploratory nature of the tester is needed very much while designing the tests. At the same time, it is needed very much more than while designing the tests. We cannot deny the fact that exploration is not needed while executing the tests and we cannot categorize that under Unplanned Adhoc testing. This world has got its electric light because of the exploration of Thomas Alwa Edison. This world has got its Air Traffic because of the exploration of Right Brothers. Exploration is the one which is going to fetch good results and remarkable results at the end. Exploration at the time of designing the tests is very much needed for a complex application to plan for the areas which is new for the tester and the areas which are old to him need not to be planned for test as he is good enough with finding bugs with Exploratory Testing for those areas. Even if the tests for that complex parts of the application are not planned also, they can be done at the time of execution if the tester is having expertise in testing and that too in Exploratory Testing, very much.
Designing the tests is also an art and it also involves creativity in itself. It is the different ways of thinking of the tester as an individual which is put into papers and termed as Test Plan. Testing is a mindset. The interpretation of the information differs from people to people. If this is the case then coverage of testing can be achieved by more than one people testing the same piece of code. Thus with the different ways of exploration, we can achieve the coverage.
Summary :
If the exploration is done on Test Application for testing that, then that is termed as Exploratory Testing. If the exploration is done on Test Application for designing the tests then that is termed as Test Planning. Whatever the terms used, Exploration in testing is very much in need.
Subscribe to:
Posts (Atom)