Peer Reviews
Welcome friends , new week has just started. Monday blue’s are on full swing. Let’s start this week’s blogging with a less talked topic “PEER REVIWES”
What is it ? In simple language this term is used to describe a review process of the artifacts /documents by the peers in the team wherein the author of the document presents it to peer members in the team with the purpose of getting feedback in order to improve the document before making its final version.
Process of peer review is not very tedious where the document author presents the document to the group of reviewers who are members of same team and explains the purpose of the document as to what is the document, objective and details about the document and ask for the feedback on the document. From the author’s point of view it’s good to have a checklist ready at his end before submitting the document just to reduce the reviewing time and avoid small mistakes.
Purpose behind this activity is can be –
- Validate the correctness of the document.
- Validate the coverage of document with respect to purpose for ex. Peer review of a test plan/strategy document should verify that the test plan/strategy is in accordance with the project/product for which we are doing testing and it is covering each and every aspect of testing which can be done/carried on.
- Validate the conformance of the document with respect to the process followed in organization, standards of the organization and client needs if any.
With respect to software testing , there are many documents for which we can conduct peer review such as test plan, test strategy , test cases and scripts and other such documents. Benefits of the PEER REVIEW process can be achieved only when the review comments are documented and in turn implemented properly. Also as a suggestion it should be done be senior members of the team who have good command over the product/system and have good domain knowledge
Monday, May 31, 2010
Friday, May 28, 2010
Ad-hoc testing and Exploratory testing
Today’s post is just a MICRO blog about Ad-hoc testing and Exploratory testing
These two terms are often used interchangeably by the development guys. I wonder senior dev guys in my team don’t even know difference between black box & white box testing. Anyways coming back to our main topic both ad-hoc and exploratory testing
- are system testing techniques where in we test the whole software system.
- are undocumented form of testing in the sense that the test we perform are no formally documented. That is the scenarios in this testing are apart from the documented test cases.
- are informal testing techniques performed at small scale generally after the completion of formal testing OR when we have less time.
The only difference between these two is that in order to perform Ad-hoc testing a tester should have domain /product knowledge while no such knowledge is required for exploratory testing, success of ad-hoc testing totally depends on the knowledge and experience level of the tester. We can understand exploratory testing going be name , it means to explore the system with the intent of learning and also to find bugs. Main aim of tester performing exploratory testing is to get knowledge about the system and report bugs after getting them validated from a person having sound knowledge of the product. While the sole purpose of ad-hoc testing is to find bugs in the system as the tester already have the necessary knowledge about the system/product under testing. One important implementation of ADHOC TESTING is when we want to test the application beyond the documented OR obvious tests and also we may want to focus on most critical areas of application in case we have less time for testing and therefore can’t prepare test cases. For exploratory testing one such implication is when we do not have enough documentation available and want to know more about the application so that we can prepare some formal document regarding the functionality of the application.
These two terms are often used interchangeably by the development guys. I wonder senior dev guys in my team don’t even know difference between black box & white box testing. Anyways coming back to our main topic both ad-hoc and exploratory testing
- are system testing techniques where in we test the whole software system.
- are undocumented form of testing in the sense that the test we perform are no formally documented. That is the scenarios in this testing are apart from the documented test cases.
- are informal testing techniques performed at small scale generally after the completion of formal testing OR when we have less time.
The only difference between these two is that in order to perform Ad-hoc testing a tester should have domain /product knowledge while no such knowledge is required for exploratory testing, success of ad-hoc testing totally depends on the knowledge and experience level of the tester. We can understand exploratory testing going be name , it means to explore the system with the intent of learning and also to find bugs. Main aim of tester performing exploratory testing is to get knowledge about the system and report bugs after getting them validated from a person having sound knowledge of the product. While the sole purpose of ad-hoc testing is to find bugs in the system as the tester already have the necessary knowledge about the system/product under testing. One important implementation of ADHOC TESTING is when we want to test the application beyond the documented OR obvious tests and also we may want to focus on most critical areas of application in case we have less time for testing and therefore can’t prepare test cases. For exploratory testing one such implication is when we do not have enough documentation available and want to know more about the application so that we can prepare some formal document regarding the functionality of the application.
Thursday, May 27, 2010
Positive, Negative testing and test execution
Ideal flow of test execution , some days before a friend of mine (a fresher is testing field) asked me about positive, negative testing and the flow of test execution and his understanding inspired me for this post. As per my understanding, positive testing is ‘Test to pass’ that is testing done to confirm that the system meets the specified requirements. In these types of tests we usually do not input invalid conditions and main concentration should be on finding out the defects/bugs by executing the system as per the normal functionality. Under this we concentrate on the written requirements and normal flows and validate the system against it. In other words we validate that the system is working as per the documented requirements.
Coming on to negative testing, it is ‘Test to break’. Now that we are done with the normal testing we try to break the system by trying negative scenarios on it such as invalid inputs, unusual load and other negative scenarios so as to know the behavior of the system with such conditions. Suppose that a website is expected to have load of 1000 hits at a time then in negative testing we may try to overload along with the abnormal communication conditions.
Coming on to the test execution part, I follow a thumb rule that as a tester my job is to first validate that the system is working as per the written requirements (TEST TO PASS) and then after this I should try the negative scenarios (TEST TO BREAK). Remember, our first job is to execute the documented test cases since this is what we have agreed to deliver to the client and these are the test for which client is expecting the test report. So the order of execution should be first the positive tests and then the negative tests that is after positive testing we can try our hands on some undocumented testing (Ad-hoc and exploratory testing)
Coming on to negative testing, it is ‘Test to break’. Now that we are done with the normal testing we try to break the system by trying negative scenarios on it such as invalid inputs, unusual load and other negative scenarios so as to know the behavior of the system with such conditions. Suppose that a website is expected to have load of 1000 hits at a time then in negative testing we may try to overload along with the abnormal communication conditions.
Coming on to the test execution part, I follow a thumb rule that as a tester my job is to first validate that the system is working as per the written requirements (TEST TO PASS) and then after this I should try the negative scenarios (TEST TO BREAK). Remember, our first job is to execute the documented test cases since this is what we have agreed to deliver to the client and these are the test for which client is expecting the test report. So the order of execution should be first the positive tests and then the negative tests that is after positive testing we can try our hands on some undocumented testing (Ad-hoc and exploratory testing)
Requirement traceability matrix (RTM)
Requirement traceability matrix (RTM) in simple words is a document containing the requirements mapped with the test cases/scripts covering that particular requirement. it is one of the most important document created during a project life cycle and is very important in software testing activities. Going further RTM can contain more details like name and brief detail about the requirement, details of test case/script document which contains the test case(s)/script(s) handling the requirement, priority & severity of the requirement and also the verification status of the requirement (whether the test cases have been executed OR not) along with the status of requirement (Pass/Fail – requirement is catered in the software system and in fully functional without any bug). These details are not mandatory but definitely adds value to the RTM document as it provides complete picture about a particular requirement.
Creating RTM – there are 100’s and 1000’s of template available on the internet. Just pick one of them OR create your own. In a very simple way , you just need to create a table containing requirement ID (As mentioned in the SRS/FRS/Requirement Specification document) and test case ID of the test case in which this requirement is being tested. In addition to this we can provide other fields as mentioned above. Also we can create a single RTM document for both unit and functional/system test cases
Benefits – RTM is very beneficial in software testing as it –
- Track all requirements and whether or not they are being met by the test.
- Help ensure that all system requirements have been met during the Verification process.
- Above all it’s a very good tool from management and testers perspective as well. For testers , it serves the benefit of knowing how many requirements are covered and from management’s perspective it’s a tool from which they can gather all the required information pertaining to a particular requirement.
Creating RTM – there are 100’s and 1000’s of template available on the internet. Just pick one of them OR create your own. In a very simple way , you just need to create a table containing requirement ID (As mentioned in the SRS/FRS/Requirement Specification document) and test case ID of the test case in which this requirement is being tested. In addition to this we can provide other fields as mentioned above. Also we can create a single RTM document for both unit and functional/system test cases
Benefits – RTM is very beneficial in software testing as it –
- Track all requirements and whether or not they are being met by the test.
- Help ensure that all system requirements have been met during the Verification process.
- Above all it’s a very good tool from management and testers perspective as well. For testers , it serves the benefit of knowing how many requirements are covered and from management’s perspective it’s a tool from which they can gather all the required information pertaining to a particular requirement.
Wednesday, May 26, 2010
Mobile Application Certifications
There days mobile applications are on real boom specially after the entry of mobile platforms like Iphone/Blackberry/Android. As far as testing of mobile applications is concerned , a mobile app has to be tested on functionality aspects and on other aspects as well. You might have gone through my previous post mentioning major points of consideration while testing a mobile application. In this post, I am concentrating on testing the mobile application on other aspects. One such aspect is vendor certification testing which is done in order to get your application available on different app stores so that end users can download and use it further. Due to the boom and increasing number of mobile applications everyday different mobile technology/platform vendors have provided centralized places from where user can download the available applications such as Apple app store for apple, Windows Marketplace for windows, Blackberry App World for windows, Mobile Shop for BREW. These technology vendors have provided generalized tests, In order to place/release their application to users software vendors has to get them passed through these tests.
So far, following vendors have defined their test process and provided the test cases
- BREW – The process is known as ‘True BREW Certification’ and a set of test cases provide for this is known as ‘‘True BREW Test’ OR TBT in popular.
- Windows marketplace submission criteria for placing the application on Windows market place.
- Java verified program for J2ME applications.
- Symbian signed criteria for getting the application signed by symbian
All these above concentrates on general behavior, stability and functionality of the application. These are not at all related to testing of specific functionality but concentrates on general attributes which every application should posses.
So far, following vendors have defined their test process and provided the test cases
- BREW – The process is known as ‘True BREW Certification’ and a set of test cases provide for this is known as ‘‘True BREW Test’ OR TBT in popular.
- Windows marketplace submission criteria for placing the application on Windows market place.
- Java verified program for J2ME applications.
- Symbian signed criteria for getting the application signed by symbian
All these above concentrates on general behavior, stability and functionality of the application. These are not at all related to testing of specific functionality but concentrates on general attributes which every application should posses.
Subscribe to:
Posts (Atom)