My Page
ayon

|
|
|
ayon updated a blog entry LoadRunner Virtual U... LoadRunner is a tool, or more accurately a collection of tools, which facilitates in Vusers can be of four main types. |
Apr 11 |
|
|
|
ayon created a blog entry LoadRunner Virtual U... LoadRunner is a tool, or more accurately a collection of tools, which facilitates in What is "Virtual Users"? To perform a load test, a system needs many users to access the system concurrently, DB Virtual Users GUI Virtual Users |
Apr 11 |
|
|
|
ayon created a blog entry Static Testing – An ... Static Testing – An Effective Method Between Coding and Testing Phase |
Mar 20 |
|
|
|
ayon updated a blog entry A video game Testin...
Video games are also considered as software that needs sufficient testing before releasing in the market. In fact, many software developers want to become game developers. |
Mar 14 |
|
|
|
ayon created a blog entry A video game Testin... <!-- /* Font Definitions */ @font-face {font-family:Calibri; mso-font-alt:"Century Gothic"; mso-font-charset:0; mso-generic-font-family:swiss; mso-font-pitch:variable; mso-font-signature:-1610611985 1073750139 0 0 159 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-parent:""; margin-top:0in; margin-right:0in; margin-bottom:10.0pt; margin-left:0in; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:Calibri; mso-fareast-font-family:Calibri; mso-bidi-font-family:"Times New Roman";} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.Section1 {page:Section1;} --> Video games are also considered as software that needs sufficient testing before releasing in the market. In fact, many software developers want to become game developers. Game testing is the process of verifying game environment and behavior. Its occurrence in game development depends on its budget. High-budgeted projects test their products when the draft version is finished. On the other hand, low-budgeted games might only support testing of the probable final version. Other types like public betas and stress tests are also used in actual game industry, but it less systematic and scientific because testing is being done by simply playing the game from the start to finish and reporting random bugs that occur and detected accidentally. Scientific and methodological approaches in testing have the following purposes: Game Functionality This includes gaming environment, textures, and elements. Issues like stability and game messages are also included in this purpose. The exciting part about functional testing is verifying the correctness of game elements, because for example, checking if weapons like swords can really incur damage to enemies and of course, the most practical way to do it is to play the actual game. Game Compliance Most games are not stand-alone system. They need to interact with hardware devices and this is especially true for console games. Protocol compatibility and hardware pin assignments should be compatible for both software and hardware side. This is often seen as an area outside the scope of game testers because it now deals with issues beyond the gaming environment. Game Localization It is the common knowledge that most RPGs and other story-based games came from Japan. Thus, scripts may have inconsistencies when translated from one language to another. Unlike functional testers who need to play the actual game, localization testers often face a spreadsheet-like interface where all game scripts and its translation are listed. Game Soaking Soaking simply means exposing the game for an exaggerated long period of execution. This is to test if the game will exhibit unreleased segments of memory and mathematical rounding discrepancies. Rounding errors can be problematic for games because it can affect its pointing system, health value consumption, and other game parameters that involve numerical computation. Games need thorough evaluation to deliver maximum playing experience. For this reason, its testing focuses on some crucial part and breakdown to achieve realistic game behavior. Listed below are some game testing components:
Game testing tips and considerations are greatly focused in game graphics. For example, testers should verify a realistic behavior when multiple objects overlapped with each other. Collision effects between two objects should also be realistic. This is especially true for games involved in sports. In terms of considerations, testers should be aware of the so-called crack bugs and placeholder. This often appears in the development period. Crack bugs are also called false bugs because it is just the result of misjudgment by the tester, while placeholders are shapes used to cover temporarily some part of the game screen while the real image is not yet finished. |
Mar 14 |
|
|
|
ayon uploaded a new avatar. | Mar 13 |
|
|
|
ayon created a blog entry All-Pairs Testing – ... The only universal statement that will satisfy the diverse software development principles of IT professionals is that the software to be delivered to clients must have the highest accuracy and reliability as possible. Software testing was proven to be a vital part of achieving such results since the early days of IT industry up to present situation when numerous testing methodologies have already been developed. One of the most widely adopted software testing techniques is all-pairs testing. |
Mar 13 |
|
|
|
ayon updated a blog entry Web Performance Test... Stress Test: In this case we increase the load of the system to check if it can sustain such load and what is the bottleneck point. Also when system fails for such heavy load can it recover gracefully. Load Test: In the tested system we will continuously increase the pressure until the performance index reached its limit, response time exceeds a predetermined target, or a resource has already reached saturation point. Load test can find system processing limit, to provide a basis for system tuning. Large data volume test: In this case a large volume of data is used to test the system. This volume will be recorded in the requirement by the client, mainly the daily data volume transaction for the system. For example a system will process 700 transactions per day. Configuration test: Test to determine what is the optimal level of recourses needed by the system to run. Reliability Test: You can increase CPU resources to maintain a 70% -90% utilization of the pressure. Then continue pressure on the system to run 8 hours, and do the analysis of the stability of the system based on the results. Concurrency Testing: Run same transactions simultaneously to find some algorithm design problems. Performance testing using concurrent users: 1. Performance testing is mainly to find software problems and hardware bottlenecks. 2. At the requirement phase people should find all the performance requirements which are also called non functional requirements. 3. For each performance requirements we should have one or two test cases. 4. Is expected to test the performance of indicators are usually single-user oriented, if it involves concurrent users, then we need to design test cases accordingly. Network Performance Testing The main focus of this testing to determine the number of users and network bandwidth relationship. It also shows how the bandwidth, load and port change affects the user's response time. The best way is to adjust the performance of soft and hard combination. Large data volume testing Mainly aimed at the database systems have special requirements for testing, divided into three types: 1. Real-time large amounts of data: real-time simulation of a user working with large amounts of data, the main purpose was to test the user operations have a greater amount of data and the system can run stable. 2. Limit state test: The main focus is to test the system for a period of time where the system accumulate a certain amount of data and can normally run the business 3. The combination of the first two: Test the system has accumulated large amounts of data, some real-time transactions have a greater amount of data and can work steadily. |
Sep 11 |
|
|
|
ayon updated a blog entry WEB Performance Test... Stress Test: In this case we increase the load of the system to check if it can sustain such load and what is the bottleneck point. Also when system fails for such heavy load can it recover gracefully. |
Sep 11 |
|
|
|
ayon created a blog entry WEB Performance Test... <!-- /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-parent:""; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; font-family:"Times New Roman"; mso-fareast-font-family:"Times New Roman";} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.Section1 {page:Section1;} --> <!-- /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-parent:""; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; font-family:"Times New Roman"; mso-fareast-font-family:"Times New Roman";} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:1747993280; mso-list-type:hybrid; mso-list-template-ids:-289893936 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;} @list l0:level1 {mso-level-tab-stop:.5in; mso-level-number-position:left; text-indent:-.25in;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} --> WEB Performance Test Category
Stress Test: In this case we increase the load of the system to check if it can sustain such load and what is the bottleneck point. Also when system fails for such heavy load can it recover gracefully.
Load Test: In the tested system we will continuously increase the pressure until the performance index reached its limit, response time exceeds a predetermined target, or a resource has already reached saturation point. Load test can find system processing limit, to provide a basis for system tuning.
Large data volume test: In this case a large volume of data is used to test the system. This volume will be recorded in the requirement by the client, mainly the daily data volume transaction for the system. For example a system will process 700 transactions per day.
Configuration test: Test to determine what is the optimal level of recourses needed by the system to run.
Reliability Test: You can increase CPU resources to maintain a 70% -90% utilization of the pressure. Then continue pressure on the system to run 8 hours, and do the analysis of the stability of the system based on the results.
Concurrency Testing: Run same transactions simultaneously to find some algorithm design problems.
Performance testing using concurrent users:
Network Performance Testing
The main focus of this testing to determine the number of users and network bandwidth relationship. It also shows how the bandwidth, load and port change affects the user's response time. The best way is to adjust the performance of soft and hard combination.
Large data volume testing
Mainly aimed at the database systems have special requirements for testing, divided into three types:
1. Real-time large amounts of data: real-time simulation of a user working with large amounts of data, the main purpose was to test the user operations have a greater amount of data and the system can run stable.
2. Limit state test: The main focus is to test the system for a period of time where the system accumulate a certain amount of data and can normally run the business
3. The combination of the first two: Test the system has accumulated large amounts of data, some real-time transactions have a greater amount of data and can work steadily.
|
Sep 11 |
|
|
|
ayon updated a blog entry Functional Testing F... To build a functional testing framework we need to define the following software testing artifacts at the very first stage of the project. 1. Test Plan: This needs to be written in a very early stage of the project (typically at the time of project design phase). The test manager needs to sit with all the project stakeholders and client to get it done, reviews and signed off. Typically it should contain the following important things: i. The total number of the resources (tester, test lead and test manager) needed to complete the project. So a clear stuffing plan must be determined. ii. The test schedule is another important part of the test plan. Ideally it should not be a very tight. Put some buffer time in place. In many cases you will see delay in the original testing due to development delay or decision pending from client so if you do not put some buffer time those unseen risks and issues can not be handled and you end up doing lots of work to meet the schedule. iii. Test environment configuration: Clearly define the hardware and software needs, their license procurement procedure etc. If you are working in offshore and onshore model then mention the access restrictions to the onshore systems from offshore if there is any, the performance issue, do you need extra bandwidth to access the onshore servers etc. iv. Write down the items to be tested, items which are beyond the scope of the testing. v. Clearly define a knowledge transfer plan for the system you are going to test. It may need you to send some tester to onsite to learn the system and understand the requirements. vi. Identify the test exit criteria or when you can stop the testing. It varies from client to client. But in the SOW/contract document it should be clearly mentioned that when you can say the testing is done. 2. Test cases: The test case documents tell you how to do the testing for a functionality. Each requirement should have ideally 4 test cases associated with it viz two boundary values, one negative test and one happy path testing. It should have the test objective/business scenario, test steps which tells how to perform the testing, test data, expected result and actual result mentioned. 3. Defect Report guide: this is the most commonly used document for any functional testing project. Any deviation from the original requirement should be logged as a defect. A defect incident report should contain the following things in minimum: * Defect ID: Defect ID number which is unique. No duplication of defect ID’s possible * Reporter’s/Originator Name on the bug. If there are questions we need to know who originated this report. * Assigned to (This bug is assigned); who’s going to be responsible for the bug and do the work on the bug? * Defect Status State of the defect like submitted, assigned, planned, completed, re-tested, closed etc., * Defect Type Defect Type may be logical, Data, Documentation, Bad fix, Third party, Performance etc., * Date of origin Date of origin of the defect like when it was found. * Build or Version number This gives the details of the code being worked on. * Phase found The defect found in (like Requirement, design, coding, testing) phase. * Origin of defect The defect originated in (like Requirement, design, coding, testing) phase. * Severity and Priority of the defect - Severity (High, medium, low) and Priority (High, medium, low) of the bug * Brief Description of defect (what the problem is) For example, “Fatal error when printing landscape.” is a good description; short and to the point * Platform on which the bug found on * Windows, Linux, etc. Is the bug specific to one platform or does it occur on all platforms? * Feature or Specification or part of the code. * This facilitates assigning the bug to a developer assigned to that part of the product. * Test case No. Test case reference number given here like Test_case v1.0 (where the defect is found) * Details including how to reproduce the bug and any other relevant data or clues about the bug. - Start with how the computer and software is setup. - List each and every step (don’t leave any out) to produce the bug. - Attach Snapshot of the error. - Sometimes a minor detail can make all the difference in duplicating or not duplicating a bug. For example, using the keyboard versus using the mouse may product very different results when duplicating a bug. - Attach the screenshot of the error if there is any 4. Test Summary Report: This contains the report and summary of the project test results, citing the relevant test data and statistics, and record the remaining issues. It typically contains total number of defects logged in the testing phase, the severity level of those defect, defects type and how many of them are still open or deferred to the next release.Also test exit report/summary report is an official sign off from the test team. |
Sep 07 |
|
|
|
ayon created a blog entry Functional Testing F... <!-- /* Font Definitions */ @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0; mso-font-charset:2; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:0 268435456 0 0 -2147483648 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-parent:""; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; font-family:"Times New Roman"; mso-fareast-font-family:"Times New Roman";} p {mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; mso-pagination:widow-orphan; font-size:12.0pt; font-family:"Times New Roman"; mso-fareast-font-family:"Times New Roman";} span.apple-converted-space {mso-style-name:apple-converted-space;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:109592554; mso-list-type:hybrid; mso-list-template-ids:1457299780 1310989400 -886018122 -59082866 -434583240 232973728 -226603200 -898878016 1300807712 939422248;} @list l0:level1 {mso-level-number-format:bullet; mso-level-text:; mso-level-tab-stop:.5in; mso-level-number-position:left; text-indent:-.25in; font-family:Wingdings;} @list l0:level2 {mso-level-start-at:178; mso-level-number-format:bullet; mso-level-text:-; mso-level-tab-stop:1.0in; mso-level-number-position:left; text-indent:-.25in; font-family:"Times New Roman";} @list l1 {mso-list-id:647440276; mso-list-type:hybrid; mso-list-template-ids:662058904 1112860956 -1680573708 -2073791816 -2111792474 1286479260 1817996010 -290802148 -583658558 1022372298;} @list l1:level1 {mso-level-number-format:bullet; mso-level-text:; mso-level-tab-stop:.5in; mso-level-number-position:left; text-indent:-.25in; font-family:Wingdings;} @list l1:level2 {mso-level-start-at:178; mso-level-number-format:bullet; mso-level-text:-; mso-level-tab-stop:1.0in; mso-level-number-position:left; text-indent:-.25in; font-family:"Times New Roman";} @list l2 {mso-list-id:883979805; mso-list-type:hybrid; mso-list-template-ids:892864108 -1643090190 -1458635918 -607496470 -741162212 -1635090124 509744008 -1730219140 2104236370 -787186936;} @list l2:level1 {mso-level-number-format:bullet; mso-level-text:; mso-level-tab-stop:.5in; mso-level-number-position:left; text-indent:-.25in; font-family:Wingdings;} @list l3 {mso-list-id:941717932; mso-list-type:hybrid; mso-list-template-ids:782396364 -456476216 -1267981814 863554196 322087480 -652825166 316552290 272534206 -86745956 1361724468;} @list l3:level1 {mso-level-number-format:bullet; mso-level-text:; mso-level-tab-stop:.5in; mso-level-number-position:left; text-indent:-.25in; font-family:Wingdings;} @list l4 {mso-list-id:1469276748; mso-list-type:hybrid; mso-list-template-ids:-1628149048 215014748 -1634159382 -314939846 1547729894 -1345841828 -775681824 -209317054 379763420 1055534172;} @list l4:level1 {mso-level-number-format:bullet; mso-level-text:; mso-level-tab-stop:.5in; mso-level-number-position:left; text-indent:-.25in; font-family:Wingdings;} @list l5 {mso-list-id:1528175238; mso-list-type:hybrid; mso-list-template-ids:-1823419544 -370133166 -1882537810 -1916913256 220103274 -1446844612 1918824680 -1319174852 -1568005280 -1553821732;} @list l5:level1 {mso-level-number-format:bullet; mso-level-text:; mso-level-tab-stop:.5in; mso-level-number-position:left; text-indent:-.25in; font-family:Wingdings;} @list l5:level2 {mso-level-start-at:178; mso-level-number-format:bullet; mso-level-text:-; mso-level-tab-stop:1.0in; mso-level-number-position:left; text-indent:-.25in; font-family:"Times New Roman";} ol {margin-bottom:0in;} ul {margin-bottom:0in;} --> To build a functional testing framework we need to define the following software testing artifacts at the very first stage of the project. 1. Test Plan: This needs to be written in a very early stage of the project (typically at the time of project design phase). The test manager needs to sit with all the project stakeholders and client to get it done, reviews and signed off. Typically it should contain the following important things: i. The total number of the resources (tester, test lead and test manager) needed to complete the project. So a clear stuffing plan must be determined. ii. The test schedule is another important part of the test plan. Ideally it should not be a very tight. Put some buffer time in place. In many cases you will see delay in the original testing due to development delay or decision pending from client so if you do not put some buffer time those unseen risks and issues can not be handled and you end up doing lots of work to meet the schedule. iii. Test environment configuration: Clearly define the hardware and software needs, their license procurement procedure etc. If you are working in offshore and onshore model then mention the access restrictions to the onshore systems from offshore if there is any, the performance issue, do you need extra bandwidth to access the onshore servers etc. iv. Write down the items to be tested, items which are beyond the scope of the testing. v. Clearly define a knowledge transfer plan for the system you are going to test. It may need you to send some tester to onsite to learn the system and understand the requirements. vi. Identify the test exit criteria or when you can stop the testing. It varies from client to client. But in the SOW/contract document it should be clearly mentioned that when you can say the testing is done. 2. Test cases: The test case documents tell you how to do the testing for a functionality. Each requirement should have ideally 4 test cases associated with it viz two boundary values, one negative test and one happy path testing. It should have the test objective/business scenario, test steps which tells how to perform the testing, test data, expected result and actual result mentioned. 3. Defect Report guide: this is the most commonly used document for any functional testing project. Any deviation from the original requirement should be logged as a defect. A defect incident report should contain the following things in minimum:
- Start with how the computer and software is setup. - List each and every step (don’t leave any out) to produce the bug. - Attach Snapshot of the error. - Sometimes a minor detail can make all the difference in duplicating or not duplicating a bug. For example, using the keyboard versus using the mouse may product very different results when duplicating a bug. - Attach the screenshot of the error if there is any 4. Test Summary Report: This contains the report and summary of the project test results, citing the relevant test data and statistics, and record the remaining issues. It typically contains total number of defects logged in the testing phase, the severity level of those defect, defects type and how many of them are still open or deferred to the next release.Also test exit report/summary report is an official sign off from the test team. |
Sep 07 |
|
|
|
ayon created updated a blog entry Certified Software T...
Certified Software Test Manager(CSTM) certification is provided by STQC IT Service Centre, India.
About CSTM Certification:
The Objectives of CSTM certification are as follows:
People with the following job profiles will benefit from this course / certification:
The Eligibility Criteria for CSTM Certification is as follows:
Prerequisites for CSTM Certification: Must have attended the CSTM refresher course conducted at any STQC IT Service Centre. Body of knowledge:
The above information is also available in CSTM Course Material. Please refer the course material for any future updation. Course Contents: The body of knowledge for CSTM contains below essential knowledge areas of software development lifecycle. These modules are available in CSTM course book Version 5:
Participants (scoring >=60% marks) will be awarded "Certificate of Achievement". The CSTM certification will make you confident to undertake test management activities and a professional pride in belonging to the School of Certified Professionals. For further detailed information of the Certification please check the following link: |
Jul 02 |
|
|
|
ayon created a blog entry Certified Software T...
Certified Software Test Manager(CSTM) certification is provided by STQC IT Service Centre, India.
About CSTM Certification:
The Objectives of CSTM certification are as follows:
People with the following job profiles will benefit from this course / certification:
The Eligibility Criteria for CSTM Certification is as follows:
Prerequisites for CSTM Certification: Must have attended the CSTM refresher course conducted at any STQC IT Service Centre. Body of knowledge:
The above information is also available in CSTM Course Material. Please refer the course material for any future updation. Course Contents: The body of knowledge for CSTM contains below essential knowledge areas of software development lifecycle. These modules are available in CSTM course book Version 5:
Participants (scoring >=60% marks) will be awarded "Certificate of Achievement". The CSTM certification will make you confident to undertake test management activities and a professional pride in belonging to the School of Certified Professionals. For further detailed information of the Certification please check the following link: |
Jul 02 |
|
|
|
ayon added a new discussion topic for the group, Certified Software Tester (CSTE) | Jun 21 |
|
|
|
ayon updated group, Certified Software Tester (CSTE) | Jun 21 |