Logo
  • Home
  • My Page
  • Tester Community
  • Testing Question Bank
  • Blog navigation
  • Downloads
  • Testing Quiz
  • Forum
  • Groups
  • Testing Related Video
  • Photos
  • Ask
  • Answer
  • Search Answers
  • Software Testing
  • Software Testing Tools
  • Test Management
  • Quality Engineering
lost pwd lost username create account
Home My Page ayon

About Me

Basic Information

Gender
Male

Contact Information

Country
India

Education

Friends

0 friends
Show all
Share this
ayon
ayon
  • Karma
  • Member since
  • Sunday, 30 December 2007 13:01
  • Last online
  • 19 hours 39 minutes ago
  • Profile views
  • 404 views
  • Add as friend
  • Photos
  • Blog
  • Videos
  • Write Message
ayon & friends ayon
Yesterday
ayon uploaded a new avatar. 06:00 AM
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.

In this method, input parameters will be combined with one another to create all discrete possibilities that may occur during operation. Contrary to exhaustive testing, or verifying all combinations individually, this method utilizes statistical principles to find software faults and to reduce a number of test cases while maintaining satisfactory test coverage. In actual practice, this often translates to higher productivity and lower cost.

Real-life software testing always faces the dilemma of having thousands of test cases to thoroughly verify internal and external system behavior. However, meeting client needs often restricts project management in having the luxury of time during testing phase to cover all test cases. Thus, different types of all-pairs testing was formed to incorporate both past and modern statistical concepts into test case creation to find as many faults as possible out of minimal cases.

Combinatorial Testing
This testing is the simplest pair testing. In this type, all combinations should be evaluated by tedious approaches like prime-based solutions and brute-force. Such solutions where proven to be tiresome and least reliable because it relies on random probabilities and guesses from previous results. Apart from this, it imposes higher chance of error because of its heavy testing procedures and its similarity with exhaustive testing.

Pairwise Testing
In exhaustive testing, all combinations are being formulated. For example, 243 items should be formulated for a system with five distinct parameters having three possible states. Testers do not have enough resources to cover all 243 items but through the pair wise testing, only minimal test cases will be needed to cover all interactions. Finite field computation, modulo arithmetic, etc. is used to solve the least number of test cases needed. This testing started as early as 1990s and continues to become popular because of its feasibility and high quality despite its low cost.

Orthogonal Array Testing
This type was derived from industrial engineering concepts of manufacturing. It offers robust methodologies in creating efficient test cases. This pair testing is similar with the pair wise but goes further by arranging each combination orthogonal. In the orthogonal arrangement, combinations of values between parameter pairs will only occur once in all sides of the array. This arrangement makes it suitable for more sophisticated software applications because of faster and more reliable bug detection.

Through pair testing is appropriate for most systems, it will not be as efficient when applied in medical equipment, distributed computing, and shared databases. All-pairs testing common mistakes can be summarized into three:

Manual Pair Creation
Using spreadsheets to manually plot pair values is very tedious. It is also difficult to maintain and presents lots of inaccuracies. To avoid such scenarios, test engineers can opt to professional or freeware applications to automate their test case creation.

Wrong Application Usage
This is either using pair testing in wrong application, or using it in correct application but in its wrong area. Pair testing is not applicable to high-risk applications like medical systems. It should be used in collaboration with other testing procedures to ensure its reliability. This is because the high-risk systems encounter fatal errors from useless combinations being ignored by pair testing. Wrong usage also includes employing pair testing in areas where simpler methods with less effort are more applicable.

Wrong Parameter Selection
Success of pair testing depends on how well the parameter interaction is defined. Using wrong parameters in pairing will yield low success rate. Sometimes, choosing the best test parameters calls for involvement of requirements analyst, developer, and test engineers.

05:57 AM
6 months ago
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.

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 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:

 

  1. Performance testing is mainly to find software problems and hardware bottlenecks.

 

  1. At the requirement phase people should find all the performance requirements which are also called non functional requirements.

 

  1. For each performance requirements we should have one or two test cases.

 

  1. 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 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:

  • 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
8 months ago
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:

  • CSTM certification is a formal recognition of competenceof practicing professionals
  • It is the process of validation ad recognition of knowledge, skills and personal attributes among the testing professionals
  • Professionals need to demonstrate their proficiency within a specified BOK of CSTM.

The Objectives of CSTM certification are as follows:

  • Enable software professionals to acquire skills of software testing through training
  • Enable them to become eligible for CSTM certification examinations
  • Help them to acheive professional certification.
  • Enable them to implement the knowledge and skills on software testing (Verification & Validation techniques) in day to day jobs.

People with the following job profiles will benefit from this course / certification:

  • Software Testing Professionals
  • Test Leads/Managers
  • Members of Software Quality Assurance Group (SQA)
  • Members of Software Engineering Process Group (SEPG)

The Eligibility Criteria for CSTM Certification is as follows:

  • Bachelors degree in engineering or Master degree in Science / Computer Science with at least 2 years of relevant work experience
  •  OR Diploma in Engineering or Bachelors degree with at least 3 years of relevant work experience
  • The work experience should be relevant to the title and should be in the field of software
    development, inspection, reviews, testing and/or QA.

Prerequisites for CSTM Certification:

Must have attended the CSTM refresher course conducted at any STQC IT Service Centre.

Body of knowledge:

  1. CSTM - An Introduction                    [General Information; no Questions]
  2. Software Testing Introduction
  3. Testing Standards & best practices    [25 Marks] i.e. 25 one mark questions
  4. Static Testing                                 [15 Marks] i.e. 15 one mark questions
  5. Dynamic Testing                             [30(5+25) Marks] i.e. 5 one mark questions and 5 descriptive type questions
  6. Testing throughout the life cycle       [30 Marks] i.e. 30 one mark questions
  7. Test Management                           [50(25+25) Marks] i.e. 25 one mark questions and 5 descriptive type questions

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:

  • CSTM Introduction
  • Principles of Testing
  • Testing Standards ad best practices
  • Static Testing
  • Dynamic Testing
  • Testing throughout the life cycle
  • Test Management 

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:
http://www.stqc.nic.in/searchdetail.asp?lid=660&skey=cstm

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:

  • CSTM certification is a formal recognition of competenceof practicing professionals
  • It is the process of validation ad recognition of knowledge, skills and personal attributes among the testing professionals
  • Professionals need to demonstrate their proficiency within a specified BOK of CSTM.

The Objectives of CSTM certification are as follows:

  • Enable software professionals to acquire skills of software testing through training
  • Enable them to become eligible for CSTM certification examinations
  • Help them to acheive professional certification.
  • Enable them to implement the knowledge and skills on software testing (Verification & Validation techniques) in day to day jobs.

People with the following job profiles will benefit from this course / certification:

  • Software Testing Professionals
  • Test Leads/Managers
  • Members of Software Quality Assurance Group (SQA)
  • Members of Software Engineering Process Group (SEPG)

The Eligibility Criteria for CSTM Certification is as follows:

  • Bachelors degree in engineering or Master degree in Science / Computer Science with at least 2 years of relevant work experience
  •  OR Diploma in Engineering or Bachelors degree with at least 3 years of relevant work experience
  • The work experience should be relevant to the title and should be in the field of software
    development, inspection, reviews, testing and/or QA.

Prerequisites for CSTM Certification:

Must have attended the CSTM refresher course conducted at any STQC IT Service Centre.

Body of knowledge:

  1. CSTM - An Introduction                    [General Information; no Questions]
  2. Software Testing Introduction
  3. Testing Standards & best practices    [25 Marks] i.e. 25 one mark questions
  4. Static Testing                                 [15 Marks] i.e. 15 one mark questions
  5. Dynamic Testing                             [30(5+25) Marks] i.e. 5 one mark questions and 5 descriptive type questions
  6. Testing throughout the life cycle       [30 Marks] i.e. 30 one mark questions
  7. Test Management                           [50(25+25) Marks] i.e. 25 one mark questions and 5 descriptive type questions

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:

  • CSTM Introduction
  • Principles of Testing
  • Testing Standards ad best practices
  • Static Testing
  • Dynamic Testing
  • Testing throughout the life cycle
  • Test Management 

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:
http://www.stqc.nic.in/searchdetail.asp?lid=660&skey=cstm

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
ayon updated group, CSTE Jun 21
ayon created a new group, CSTE ( Certified Software Test Engineer) Jun 21
ayon created updated a blog entry Effective Methods Fo...

Effective Methods For Software Testing

 

The need for some of the most effective methods for software testing is certainly far more now than ever before. There are certain principles that need to be followed which would keep most of us in good stead apart of any conditions. We need to have a very clear understanding of we are doing. So getting your self acquainted is certainly the main objective that is behind all of the training and skill building. We simply need to find some of the best and more efficient ways to test software. There certainly are a number of misconceptions in most of the software industries today and most of the people believe that software testing is in fact an easy task and anyone can simply do it.

 

The main factor is that there certainly are a number of skills that you have to develop and sharpen before you think of being a good tester. So you simply need to develop your mindset and you certainly need to have enough of the patience. Training is very much important as it certainly helps one to develop. One needs a constant practice along with repetition of all techniques. It certainly is a long way to make the training more effective.

 

But one should always remember the fact that training may certainly not be available all the time and it certainly may be very much expensive. But there certainly are some options available for effective methods for software testing. A lot of it can be achieved by self study which you can do on the internet and also by reading some of the good books. You can certainly follow the method of team study and try discussing most of it among your team and friends. You can learn new concepts. You can also try to develop and design a sort of roadmap for all of your training. Webinars, E-learning and teleconferences can certainly be very much helpful to you to make some of the methods most effective for software testing.

 

You can certainly try reusability as it is one of the most effective methods for software testing. It will also help you to increase your team’s efficiency. Try test planning documents and strategies for completing some of the projects successfully. Try detailed test designing and automation. But you need to keep in mind that it can only affect if all of the items are managed properly. Try giving more importance to test optimization. Try looking towards all of the new test cases and then add certain amount of value to it. Try improving quality of the software. You need to remember that this extra test case certainly has to be maintained and at the same time has to perform better.

 

You need to identify all the areas that need to be automated. Once you are very much comfortable with automation then your certainly can use more expensive tools. This certainly is one of the most effective methods for software testing. If you want to be a good tester you need to analyze all the defects. You have to try to make the system more effective and efficient. List all of the top defects and try to rectify them. Always try to manage a checklist. It certainly will add consistency and also uniformity to you testing, and never compromise on the quality.

Jun 20
ayon created a blog entry Effective Methods Fo...

Effective Methods For Software Testing

 

The need for some of the most effective methods for software testing is certainly far more now than ever before. There are certain principles that need to be followed which would keep most of us in good stead apart of any conditions. We need to have a very clear understanding of we are doing. So getting your self acquainted is certainly the main objective that is behind all of the training and skill building. We simply need to find some of the best and more efficient ways to test software. There certainly are a number of misconceptions in most of the software industries today and most of the people believe that software testing is in fact an easy task and anyone can simply do it.

 

The main factor is that there certainly are a number of skills that you have to develop and sharpen before you think of being a good tester. So you simply need to develop your mindset and you certainly need to have enough of the patience. Training is very much important as it certainly helps one to develop. One needs a constant practice along with repetition of all techniques. It certainly is a long way to make the training more effective.

 

But one should always remember the fact that training may certainly not be available all the time and it certainly may be very much expensive. But there certainly are some options available for effective methods for software testing. A lot of it can be achieved by self study which you can do on the internet and also by reading some of the good books. You can certainly follow the method of team study and try discussing most of it among your team and friends. You can learn new concepts. You can also try to develop and design a sort of roadmap for all of your training. Webinars, E-learning and teleconferences can certainly be very much helpful to you to make some of the methods most effective for software testing.

 

You can certainly try reusability as it is one of the most effective methods for software testing. It will also help you to increase your team’s efficiency. Try test planning documents and strategies for completing some of the projects successfully. Try detailed test designing and automation. But you need to keep in mind that it can only affect if all of the items are managed properly. Try giving more importance to test optimization. Try looking towards all of the new test cases and then add certain amount of value to it. Try improving quality of the software. You need to remember that this extra test case certainly has to be maintained and at the same time has to perform better.

 

You need to identify all the areas that need to be automated. Once you are very much comfortable with automation then your certainly can use more expensive tools. This certainly is one of the most effective methods for software testing. If you want to be a good tester you need to analyze all the defects. You have to try to make the system more effective and efficient. List all of the top defects and try to rectify them. Always try to manage a checklist. It certainly will add consistency and also uniformity to you testing, and never compromise on the quality.

Jun 20

JomComment

Expand
No comment made yet.

hwdVideoShare

Expand
Show All |
Previous Button
Next Button

Google

Software Testing

  • Introduction to Software Testing
  • Automated Software Testing
  • Different Types Of Software Testing
  • Software Testing Levels
  • Software Testing Tools
  • Software Performance Testing
  • Web Testing Techniques
  • Software Security Assurance
  • Software Testing Certification
  • Testing Check Lists
  • Software QA Testing Career
  • SOA and Web Services Testing

Test Management

  • Test Plan Template
  • Test Estimation Techniques
  • Defect Tracking System
  • Configuration Management Process

Quality Assurance

  • Software QA Plan
  • Software QA Roles And Responsibilities
  • Software Quality Assurance Life Cycle
  • Software Quality Assurance Tutorial
  • Software Quality Assurance Certification
  • Software QA Engineer Resume
  • Software Quality Assurance Interview Questions
logo footer
  • Privacy Policy
  • Contact Us
  • Antivirus Software Reviews