Test Summary Report / Test Sign-off Report

The Test Summary Report (TSR) of Test Sign-off Report provides a test execution summary for the testing phase (e.g. Sys, UAT) and a recommendation of the readiness to progress to the next phase (e.g. Production).

The purpose of the TSR is to share the testing results, outstanding defects & issues, assessment of the risks & conclusion and a recommendation based on the confidence of the testing team.

The Test Summary Report document should state a recommendation from the testing team highlighting the testing experience and reasons for the decision to progress to the next phase or to continue in the current phase. It should also specify the overview of the test conditions tested/not tested and their results, Defects closed & their severity, any outstanding Defects along with the impact, variances from the Test Plan, any Test Cases removed from the planned testing and Change Requests added to the overall testing scope.

Another important section is to mention the status of the Test Entry and Test Exit criteria and any reasons, exceptions taken during the testing phase if the criteria was not met.  

The Risk section highlights the risks identified in the Test Plan, their realisation and any impacts.

 

It should mention the Test Estimation variance in terms of actual and planned test effort.

The last sections cover the builds deployed, any downtime  for the testing team.

Test Summary sign-off responsibility lies with all the project stakeholders identified in the Test Plan. e.g. all these or some of them can be involved in the sign-off stage – Project Manager, Development Manager, Business Analyst, Test Manager, Business Manager and few more (if applicable).

So, overall Test Sign-off document provides a clear idea to the stakeholders about the Testing phase and testing team’s viewpoint which helps them to take the next action in the software life cycle.

$9.99 – Download the Test Summary/Sign-off Report Template Checkout


Added to cart

 

Do you want to learn more about Testing Processes or Test Estimation, check out our online courses.

Test Estimation – $29 only (70% Discount) 

Test Framework, Processes, Life Cycle – $19 only (80% Discount)

 

Follow and Like us:

Test Summary Report / Test Sign-off Report

CoE - Leadership Team

The CoE Leadership Team is responsible for setting the strategic goals in-line with the CoE vision. Other main functional areas include,

• Approving all the policies that govern the processes and provides guidelines for the smooth functioning of the CoE.
• Initiatives flow from the Leadership team downwards. Any new initiatives required for improving the CoE functions are discussed and understood at this level before showing them the green signal to implement them.
• Financial approvals and proper allocation of funds is being controlled at the Leadership Team level. The Operations layer has to justify the funding by delivering the expected results.
• The roadblocks preventing the smooth functioning of the CoE are escalated to the leadership team if can’t be handled by the Operations team. The Leadership team has the responsibility to clear them off.
• Maintaining Progress in the CoE operations helps in achieving the desired results and keeping in pace with the Business requirements. The Leadership team continuously monitors the progress across different domains and take required actions, if required to correct the issues.
• As Leadership team sits on top, the issues beyond the control of CoE teams are escalated to the Leadership team. These issues could be internal to CoE or external to it.
• The Leadership team governs and directs the smooth implementation of the process within the CoE like Development or Testing processes.
• The Leadership team also acts proactively to identify any gaps visible in the CoE functioning and suggests improvements to overcome those gaps.
• Overseeing of the various policies and processes lies with the Leadership team. The team make sure that there is a smooth deployment and integration of the new policies or processes with the already existing processes.

CoE | Center of Excellence Model

The CoE Model at the Technology level is explained in the diagram by taking a Software Testing example. The top layer represents the Test Specialists who have the required Testing expertise. The examples could be Automation Tester, Mobile Tester, Performance Tester or ManualTester.

 

These experts based on their role possess a skill-set covered in the Testing Knowledge layer. There is a mapping of Resources with the skill-set to have a clear picture of available resources and their expertise. The bottom later Engagement is talking about the different projects where the specialised Testing resources can be or are allocated.

To explain it in a generic way, consider there is a centralised pool of resources having different skill-set. There could be a number of resources sharing the same expertise as sometimes multiple resources are required for the same knowledge. Whenever, there is a Project requirement, they are allocated to that project based on the project requirements by matching their skill-set. Those resources are now a part of the project and no other project can take them unless they are not being utilized 100%. Once, the project is completed or there is no work for the respective resource, he or she returns to the main resource pool and becomes available again for allocation. It helps in the better management of the resources and there is no pressure on the project to consume them even without any work as most of the time happens. Another advantage of CoE – It brings maturity to the processes and improve the project efficiency.

Follow and Like us:

CoE | Center of Excellence Model

Testing Reviews - Static Testing

A Review is a structured approach to examine a document by one or more people with the aim of identifying and removing defects. The primary advantage of the Review process in the Software Development Life Cycle is to identify gaps/defects as early as possible, thereby reducing the cost of fixing them if found later in the life cycle. It’s too expensive to fix the defects when the software has been built.

The Reviews are helpful in finding the various types of defects like Deviations from the standards, Requirements defects, Incorrect specifications, Design defects and few more.

Review Process can be very formal or just a casual/informal process. It depends upon the need for the Review process like legal requirements, audit or maturity of the software development  process. The Basic Review process includes the first step of document to be studied by the reviewers. Then identifying and communicating the defects found, to the Author. Later, the Author fixes the defects and updates the document.

The moral formal review can follow a complete cycle, starting from Planning, Allocating Roles, defining the Entry & Exit criteria, Preparation, Review meeting, Fixing Defects and Follow-up.

Follow and Like us:

Testing Reviews - Static Testing

Formal Reviews – Roles and Responsibilities

In the Static testing, formal reviews help in identifying the defects by following a structured and detailed approach. There are various roles being played to carry out the entire process.

Manager

The Manager takes care of the management part and normally doesn’t get involved in the actual review activity unless he/she has a technical knowledge. The manager decides what is to be reviewed, the time required for the review activities and to make sure or find out if the objectives have been met.

Moderator

The Moderator carries out the activities related to planning, organising & running the meeting and follow-ups. The success of the Review process very much lies with the Moderator and it is the moderator who puts the stamp on the release of the final document.

Author

The Author writes the original document to be reviewed and carries out the related activities of developing that document and fixing of defects.

Reviewers

Reviewers have the required knowledge to review the document and come up with the identified defects. They represent different business and technical areas to contribute effectively to the review process.

Scribe

The Scribe notes down all the happenings along with the identified defects in the Review meeting.

Follow and Like us:

Formal Reviews – Roles and Responsibilities

How much Documentation to do in Agile?

In the Agile world, there is always a doubt about the amount of Test Documentation required. I’ve seen in various projects that it totally depends upon the Agile team, their understanding of Agile methodologies and project timelines. Sometimes, teams are doing too much of documentation and sometimes not at all. The best solution is to find the mid-way where the timelines are followed and the documentation is kept to a minimum level for a better understanding. For example, if one doesn’t have a Test Plan and just working on the Test Cases then like waterfall nobody knows what is the testing approach. It may not be a heavy document as normally in the Waterfall project but enough to cover the important testing areas.

Follow and Like us:

How much Documentation to do in Agile?

Maintenance or Enhancement Testing

Maintenance/Enhancement Testing falls under the BAU (Business As Usual) scope. As software goes live and deployed into the Production environment, sometimes it’s necessary to change it. There are number of reasons like,

• Migration to the new infrastructure


• More features required


• Bugs/Defects identified in the Production environment


• Planned upgrade.

Once it’s identified that a change is required in the system, the relevant change could fall under Maintenance or Enhancement ticket (if a minor change, otherwise it becomes a Project). Maintenance Testing involves testing that change to make sure the system is working correctly after the required change. Regression testing is the primary type of testing being done under Maintenance change. If there are time constraints, a call can be taken to prioritise the Testing based on the primary impacted areas.

Follow and Like us:

Maintenance or Enhancement Testing

Top-Down Integration Testing

Top-Down Integration Testing is an important type of Integration Testing. It comes into the picture when Top level components are built first in the software or those who call other components. Tester will evaluate component interfaces starting with the top level component. To represent it diagrammatically,

Top-Down Testing

Component ‘A’ is the top most component and can call other components ‘B’, ‘C’ and ‘D’. It’s components will be tested first before testing the low-level components. Similarly, ‘D’ can call ‘G’ and ‘H’ components; ‘B’ can call ‘E’ and ‘C’ can call ‘F’.

The interactions of all the components must be tested and there may be a situation where the low-level components have not been created. In that case, a skeletal implementation of the lower component is created, called a stub. A stub is nothing but a dummy created to receive input and giving an output based on the input without performing any operation. It’s very important in the Top-Down Integration testing as all the components are not ready at once.

Follow and Like us:

Top-Down Integration Testing

Software Debugging and Testing

Software Debugging and Testing goes hand-in-hand. Both are required to validate the software quality of the system. Debugging process is the responsibility of the Developers and they debug their code to check for the errors and then fix them. They may not be bothered about the other impacted areas. On the other hand, Testing is the process to check the software for errors or Requirements gaps and then logging the defects for the developers to fix. Testing is the responsibility of the tester and it does involve validating the other impacted areas of the software because of the defect.

Debugging is an important activity to understand the quality level of the software components before beginning with the testing. Testing gives a confidence at the entire software level before releasing it to the Production environment. So both play their role at different levels and are important part of the software development life cycle.

Follow and Like us:

Software Debugging and Testing

Software Test Estimation

What is Software Test Estimation?

Before understanding the definition of Test Estimation, let’s understand Estimation and how familiar you are with it. Everyone does estimations in his/her real life e.g. You will try to figure out – At what time you need to wake up in the morning so that you can reach office at 7 am or 8 am or 9 am OR to attend an early morning meeting. Other example can be…How long will it take you to reach someone’s house? What should be your monthly expenses, what should be the weekly or monthly loan repayment amount without putting undue pressure on your life style?

So there are various instances where you are always trying to figure out the estimation factor in different terms.

Let’s go to the Test Estimation. As discussed in the examples…In a layman’s term – “How long will it take”. Moving on to the formal definition – It is the process of finding an approximate value in Hrs or Days or sometimes in months to complete the testing activities in a software development life cycle. It could be a high level or detailed, which we are going to discuss later in the course.

It is required to communicate the testing effort (Time or Cost) to the Project stakeholders. Therefore, before commencing testing activities, it is critical to have testing estimates to formulate a testing plan and further communication to the Project Manager to fit into the overall Project Plan.

Several industry studies have reported that fewer than half of software projects finish within their allotted schedules and budgets. It tells us that mostly people struggle with the Estimations and it’s an important area to address. Let’s discuss the various benefits of doing Test Estimations.

Benefits of Test Estimation:

• Identifying the number of resources required to meet the project timelines: It’s always a critical area to identify the number of testing resources to be allocated to the project. This would help in further identification of shortfall in the resources availability, in case there are not too many resources available.


• Helps in identifying/executing the Testing priorities, in case project has shorter time frames: This is relevant to the Risk based technique, which we are going to discuss later in detail. Let’s assume that your project has less time to market and you cannot complete your testing within the project timelines. So, you can target to complete the prioritised testing areas to meet the timelines and justifying the testing effort. I’ve observed this scenario in number of projects, as senior management board or Project stakeholders are always in a hurry to get the Project to market.


• More accurate scheduling: You can plan your testing schedule in a better accurate way if you know your timelines, work effort and expected start and end dates.


• Better planning, execution and monitoring of tasks: Once you have Testing estimates, you can monitor the overall tasks (like Test Preparation, Test Execution) and can track their progress. Moreover, you can take the corrective action in vase there are any deviations.


• Realising results more confidently: It’s like seeing into the future and making sure to meet those timelines. Meeting the planned estimates will give you a more confidence. The more you do, more you learn and will become more confident in producing the Test estimates and achieving the related test targets.


• Forming the foundation of good management credibility: Once you start producing and meeting your timelines with less variance, you will start showing your expertise in this process and will earn the confidence of your senior management.

For more understanding, enroll to our most valued Test Estimation Course. More than 100 students have already enrolled and benefited from the course.

http://veansys.com/testing-training/#Test Estimation

Follow and Like us:

Software Test Estimation

Software Testing Life Cycle

The video explains the complete Software Testing Life Cycle and various test documents required in each phase.  

Software Testing is a process rather than a single activity. The fundamental Testing life cycle consists of the following 5 steps:

• Test Planning and Control


• Analysis and Design


• Implementation and Execution


• Evaluating Exit criteria and Reporting


• Test Closure activities

The Test team produces the Test Deliverables in accordance with the corresponding software testing life cycle stage/step.

Test Planning and Control

Test Planning determines the scope, objectives of testing and test approach. The availability of requirements is crucial at this stage.

Test Control is an ongoing activity of comparing actual progress against the plan and reporting the status (including deviations from the plan). It involves taking actions necessary to meet the mission and objectives of the project.

Test Plan & Test Estimates are the two important test documents produced in this phase.

Analysis and Design

In this phase, the software requirements are analysed to identify their testability and the expected behaviour of different features/functionalities of the software.

In addition to the above activities, test environment infrastructure and the support required to perform the testing are also identified.  

Test Scenarios / Cases and Traceability Matrix are the required documents. The Traceability Matrix maps the test cases with the corresponding requirements IDs. It helps in identifying the potential test cases to be updated, in case requirements changes. The matrix can also be used to find whether 100% requirements coverage is achieved.

Implementation and Execution

During Test Implementation,

• Test cases are further refined,


• Test data is created,


• Test suites are created for efficient test execution and


• Test environment is implemented and verified.

Test execution has the following major tasks,

• Evaluating the entry criteria,


• Executing the test cases,


• Logging defects for the discrepancies/failed test cases and


• Preparing Test Execution results.

Test Case Pass/Fail Criteria

The Test cases are executed and the status is documented against the expected result. The following results are applicable:

• Passed


• Failed


• Blocked


• Not Completed


• Not Applicable (NA)

Status Reports are shared regularly with the stakeholders.

Evaluating Exit Criteria and Reporting

Evaluating Exit Criteria and Reporting is an activity during which test execution is assessed against the defined objectives. This should be performed at each test level.

Test Entry and Exit Criteria

The Entry criteria are required for the commencement of the next phase of testing in the testing life cycle. Similarly, the Exit criteria are required to exit the testing phase. 

The test results are checked against the exit criteria specified in the Test Plan document. Based on the assessment, a decision is to be made, whether to stop the testing or if more tests are to be executed. 

Test Summary Report

The Test Summary Report is to be produced, at the end of the testing phase. It specifies the overall test status about how the testing was done, test execution, defects status, confidence level of the Test Analyst and variances from the Test Plan.

Test Closure activities

The Post testing activities are meant to consolidate experience, test ware, facts and numbers.

Follow and Like us:

Software Testing Life Cycle

Selenium IDE User Interface, Features

Selenium IDE (Integrated Development Environment) is a web based Plugin tool that can be used to automate your test scripts for web testing. It is installed through the Firefox browser and once installed, it can be opened from the Tools menu (Tools -> Selenium IDE) or use shortcut ‘Ctrl+Alt+S’.

The below Selenium IDE UI screen is used to record or write testing steps.

Selenium IDE User Interface

I would say it’s a very powerful tool to quickly showcase the automation value additions in your company.  Selenium Automation is perfect for the beginners who want to get into the Automation and then gradually developing their skills with other full-fledged tools like Selenium WebDriver, HP QTP, Selenium Test Complete. Initially, It was designed for the Firefox browser only but now its test scripts can be executed in other browsers also which is a very important addition to this tool. 

Let’s go through the different components and their functionality. 

Base URL: It tells you about the website or web page you are going to test. It can be set to an absolute path and then add relative paths in your test scripts.

Toolbar gives various options to run test scripts. The Execution speed, Running entire test suite, Running current test case, Pause/Resume the execution, Step through a test case (one command at a time) for debugging, Rollup to group multiple repetitive test steps into one step.

Test Case Pane is used to view the test steps in the test script. Whether you are recording or writing your test steps in the ‘Command’, ‘Target’, or ‘Value’ fields, they will be displayed here in a sequential order.

Log presents the execution log along with the reasons for the failure of a test case.

Reference explains the different commands and their usage.

Runs and Failures give the count of successful and failed test scripts.

For more details, please enrol to our Selenium IDE course (online available), to understand the tool with a Project example along with smart Tips & Tricks.

Follow and Like us:

Selenium IDE User Interface, Features

Regression Testing, Importance and Scope Identification

People often talk about the Regression Testing and its importance. Even then I’ve seen testers, especially beginners unable to identify the scope of Regression testing. The primary focus is to make sure the existing unchanged features of the software are working after adding/changing one or multiple features. The most important thing is to identify the scope. As Functional/System testing will take care of the changed functionality but how to identify the regression scope?

Most of the companies execute the available Regression Test Suite after the functional testing but it doesn’t always solve the purpose considering time and effort required.

To target the specific areas, one needs to understand the software, requirements and can talk to the Business Analyst, Developer and other project team members. This helps to understand the areas which might get impacted by the change. Those are the primary focus areas for the Regression testing. Based on the time availability and complexity of the change, try to identify other non-related areas also based on your conversations, software knowledge and gut feeling. This exercise would give you enough scope to work on your Regression Testing planning.

Follow and Like us:

Regression Testing, Importance and Scope Identification

Independence Level in Software Testing

Software Testing is most effective when it’s done at the highest level of independence. There are 4 levels to achieve Test Independence.

• Testing done by the person (Development team) who has written the code.


• Testing done by another development team member.


• Tests designed by the Test Analyst or Test Specialist in the Testing team within the same company.


• The highest level of independence is achieved when Testing is carried out by the Testing team from different company.

There are various benefits associated with the levels of independence as an independent tester can found more defects and can think out of the box to create more test cases. The tester would not hesitate to communicate the bugs in the software, without any bias.

Software Testing Types

The video explains the different software testing types being widely used in the software industry.

There are various types of testing being done under various Test Levels. Let’s go through them one by one.

Static Reviews: A Testing type where the test documents are manually reviewed to checked the sanity of the document, to make sure templates and testing processes are being followed correctly. The actual software is not tested in this phase.  This type of review also involves reviewing software requirements for their testability and making sure they are unambiguous.

Smoke testing: It performs a broad and shallow validation of the software. Say, you are getting a new build from the Development team and want to make sure that the features are working fine to the acceptable level to carry out further testing.

Functional Testing is required to test the features of the software. The majority of the testing effort falls under it. It’s a black box type and based on the functional specifications of the software. The application is tested by providing input and then the results are examined that need to conform to the functionality it was intended for. Functional testing of software is conducted on a complete, integrated system to evaluate the system’s compliance with its specified requirements. There are five steps that are involved while testing an application for functionality.

Integration Testing: In Integration testing, the interaction between the software components/modules is tested. Integration testing makes sure that interfaces between the components and the integration of those components are working as per the software specifications.

Regression testing: The purpose of Regression testing is to verify the unintended side effects that may have been introduced into the system, as a result of the defect fixes, new or changed functionality, environment or hardware change.

Whenever a change in a software application is made, it is quite possible that other areas within the application have been affected by this change. Regression testing is performed to verify that a fixed bug hasn’t resulted in another functionality or business rule violation. The intent of regression testing is to ensure that a change, such as a bug fix should not result in another fault being uncovered in the application.

Regression testing is important because of the following reasons:

• Minimize the gaps in testing when an application with changes made has to be tested.


• Testing the new changes to verify that the changes made did not affect any other area of the application.


• Mitigates risks when regression testing is performed on the application.


• Test coverage is increased without compromising timelines.


• Increase speed to market the product.

Automation Testing: It automates the manual testing steps to control the execution of tests and the comparison of actual & expected results, by using specialised software Automation executes pre-scripted tests developed in a coding language (e.g. Java, VB, C#) on a software application. Smoke testing, Regression testing are the best candidates for Automation or wherever repetitive effort is required.

UAT Testing: The final testing level is conducted to determine if the software is ready for release. The actual Users test the software to find if it meets their business needs. Test Analysts provide support in co-ordination for Acceptance testing, if required. 

Non Functional: In Non-functional testing, the quality attributes of software are tested. Non-functional testing includes – Security, Usability and Performance.

Security Testing: It is a non-functional testing type and intends to identify the flaws in the security mechanisms of the software. Software security vulnerabilities are big business for potential attackers.  Identifying them early and knowing what common pitfalls to avoid can make a big difference to the resilience of the applications.

Penetration Testing: A penetration test is a proactive and authorized attempt to evaluate the security of an IT infrastructure by safely attempting to exploit system vulnerabilities, including OS, service and application flaws, improper configurations, and even risky end-user behaviour. Such assessments are also useful in validating the efficacy of defensive mechanisms, as well as end-users’ adherence to security policies. 

Testing in Production: It is carried out in the Production environment after the go-live phase. This helps in quickly verifying that application is working as expected and there are no surprises. It can be done by the Test Analyst, Application Support staff or application user.

Lucky Leader

There is no definition of a Lucky leader. Studies have shown that behaviours and thinking of the leaders influence things around them to a great extent. We can create luck by just keeping a positive outlook towards life. We all know how the Positive Attitude promotes Team Productivity.

Lucky Leaders can pass on their positive thoughts to the team members which could play wonders. In terms of Lucky Leader attributes, the following approaches play a big role.

• Listening to the Lucky hunches

Lucky People make effective decisions based on their intuition and gut feeling.

• Maximise chance opportunities

Create, notice and act upon chance opportunities. They are always open to new experiences, adopt a relaxed attitude towards the life and build, grow a strong network.

• Expecting good, bright future

This outlook helps them to interact with people positively and to survive in the stage of failure.

• Turn bad Luck into Good

Take control of the situation than to dwell on the ill-fortune. They imagine how things could have been worse.

Team Management is getting complex day-by-day but implementing basic positive thoughts within the team goes a long way in creating a successful team.

Follow and Like us:

Lucky Leader

Managerial Courage

Managerial Courage involves showing strong belief in your ideas, thoughts. It also means that you are thoughtful about others and their ideas. You say things in the right, expected way.

It is an important part of the overall management and there are various ways to display it.

• Whenever making any decision, always keep everybody in your mind.


• Make a clear plan about the impacts, thoughts of your decision and communication channel.


• A good leader or manager always understand other viewpoints, takes the buy-in before trying to implement his/her idea.


• A courage to positively implement the ideas is another important asset.


• Keeps all the communication channels open (360 degree approach)


• Always ready to discuss, act upon the hard team topics like non-performing resource.

Follow and Like us:

Managerial Courage

Agile Scrum - Sprint Planning – Facts

• In the initial phase of Sprint Planning, team asks questions and get their doubts clarified from the Product owner.


• The Development team decides which tasks to be taken from the Product Backlog for the Sprint.


• Product Backlog Items are features and not tasks.


• The Development team acquires confidence by breaking the Product Backlog items into small chunks (second half).


• In the second half of Sprint Planning, team may ask the left over questions to the Product Owner for complete understanding as they dig deeper.


• It’s a good idea to size Sprint tasks in hours.


• Backlog Refinement (pre-planning) part way through the Sprint.

Follow and Like us:

Agile Scrum - Sprint Planning – Facts

Agile - Scrum - Time Boxing Approach

Time-Boxing in Scrum Methodology

Time is the most important factor in everybody’s life and the same applies to the Projects. The problem is that we don’t use it efficiently, in fact worst possible way.

In the Scrum methodology, time is the prime factor driving all the project activities. Once decided on the time required within Scrum, timelines are fixed and is an alternative option to Scope-boxing. It helps in creating a focussed environment within the team where every team member understand the sense of urgency. Time-boxed approach facilitates the team interaction and implementing control points. The Sprint meetings should be time-boxed and should be followed unfailingly to reap the benefits.

Choosing an appropriate Sprint length is the crucial factor in the success or failure of a Sprint. One needs to consider the various factors to decide the Sprint length.

• The Product Owner’s confidence in the Development team and work effort required from them.


• When does a Product Owner (PO) want to see the finished Sprint product for making decisions.


• The number of Sprints required to make things right before the release.


• How much time will be taken to create something of significance.

There are various benefits of following time-boxed approach in the Scrum methodology,

• More focus


• Predictability increases


• Automatic evolution of the team, no command


• Prioritising and self-organising teams


• Establishes rhythm


• Imparts the confidence and factor of possible.

Follow and Like us:

Agile - Scrum - Time Boxing Approach

Software Testing Metrics

Test Metrics are important to quantify the quality of software testing. Let’s discuss some of the common Test Metrics.

Defect Density (%)

It’s the number of defects per thousand lines of code and shows the quality of the application code. Defect Density should be very minimal. Higher the %age of Defect Density, lower the confidence in the software quality. It can also be calculated in terms of – Module(s) or Requirement(s).

Defect Density = (# of Defects / KLoC) * 100



Defect leakage (%)

It is measured to identify the number of defects missed in the software testing phase.

Defect Leakage =  (Defects found in the ‘N+1’ testing phase / Defects found in the ‘N’ testing phase) * 100



Test Cases – Passed %age

The number of test cases passed in the execution phase divided by the total number of test cases.

Passed %age = (# of test cases passed/total # of test cases executed) * 100



Test Cases – Failed %age

The number of test cases failed in the execution phase divided by the total number of test cases.

Failed %age = (# of test cases failed/total # of test cases executed) * 100



Test Cases – Blocked %age

The number of test cases blocked in the execution phase divided by the total number of test cases.

Blocked %age = (# of test cases blocked/total # of test cases executed) * 100



Test Cases – Execution %age

The number of test cases executed in the phase divided by the total number of test cases written or available for test execution in the corresponding phase.

Test Execution %age = (# of test cases executed/total # of test cases available) * 100



Test Case Writing Productivity

The Productivity factor is often talked about and measured by considering total number of test cases written in a particular timeframe.

Daily Productivity (Test Case Writing) =  Total # of Test Cases written / # of hours in a day



Test Case Execution Productivity

The Test Case Execution Productivity is measured by considering total number of test cases executed in a particular timeframe.

Daily Productivity (Test Case Execution) =  Total # of Test Cases executed / # of hours in a day



Defects – High Severity %age

This metric gives a quick idea about the high severity defects out of total identified.

High Severity %age = (# of high severity defects / total # of defects) * 100



Defects – Med Severity %age

This metric gives a quick idea about the med severity defects out of total identified.

Med Severity %age = (# of medium severity defects / total # of defects) * 100



Defects – Low Severity %age

This metric gives a quick idea about the low severity defects out of total identified.

Low Severity %age = (# of low severity defects / total # of defects) * 100



Defects – High Priority %age

This metric gives a quick idea about the high Priority defects out of total identified.

High Priority %age = (# of high Priority defects / total # of defects) * 100



Defects – Med Priority %age

This metric gives a quick idea about the med Priority defects out of total identified.

Med Priority  %age = (# of medium Priority defects / total # of defects) * 100



Defects – Low Priority %age

This metric gives a quick idea about the low Priority defects out of total identified.

Low Priority %age = (# of low Priority defects / total # of defects) * 100

Follow and Like us:

Software Testing Metrics

Project Managers Compromising Testing Processes

I’ve come across an interesting situation few days back which reminded me few other instances also.

‘Sometimes, why do PMs start compromising testing processes to accomplish project targets or to sort out other issues. Is this approach beneficial for the project?’

I’ve encountered this approach many times and most of the time the reason is to meet the timelines or covering the delay happening on other project processes. Only Test Manager or Test Analyst can understand the existing Testing stage and should take a strong stand against it.

For example, there was a scenario where PM was requesting to go into the Production without Test Sign-off to cover the time being spent on other processes. This is totally unacceptable and away from the basics. If we are going live without Test Sign-off then that’s a big gap in the software life cycle process. Absence of Test sign-off means no input from the Testing team on the software quality, which signifies no value put on the Software Testing. We should not compromise Testing processes to sort out other project issues.

Under no circumstances the IT testing should be compromised, it is the core for the measurement of the project’s deliverables.

Follow and Like us:

Project Managers Compromising Testing Processes

Agile Scrum – Sprint Review Facts

• A feature should not be demonstrated in the Sprint Review if it doesn’t meet the Definition of Done (DoD).


• Always explain the context around the features to be demonstrated to have everyone on the same page.


• The Product Owner accepts only those features which were agreed at the start of a Sprint and met the Acceptance criteria.


• The Product Owner decides whether the features demonstrated in the Sprint Review are ready for release or need more work on it to bring it to the release-ready standard.


• The preparation time for the Sprint Review must not be long. Team can have a quick planning session and identify what to demonstrate.


• Sprint Review is a primary platform to collaborate and understand the progress of the software. The constructive feedback is always welcome.


• Stakeholders can provide a valuable feedback in the Sprint review sessions.


• The Sprint Review session involves demonstration of the features, discussing acceptance criteria, to elicit feedback and what could be the implications on the future Product Backlog Items (PBIs).


• The features should be presented as a Team achievement rather than an individual. Encourage Team Work.

Follow and Like us:

Agile Scrum – Sprint Review Facts

PRINCE2 – Controlling a Stage (CS) | Delivery Stages

The First Delivery Stage or Controlling a Stage is where the team gets involved and the Project Manager (PM) does most of the work.

• PM assigns Work Packages to the Team Managers and keeps track of the progress till completion.


• Shares regular reports to the Project Board about the progress.


• Compares the current status with the Stage Plan.


• Manages issues and risks.

Managing a Stage Boundary (SB)

The Stage Boundary process comes into the picture at the end of CS stage and involves preparing documents about the work done in the stage.

• Business Case and Project Plan are updated with actual information.


• End Stage Report talks about the comparison to the actual plan.


• Next Stage Plan presents an overview about the next stage to the Project Board for approval.


• Benefits Review Plan summarising if benefits have or have not been realised.

Project Board reviews all the information presented and compares the progress along with the benefits with the actual plan and decides if it’s still viable to go ahead with the project. The Next Delivery Stage is started only once the Project Board give its approval.

The timelines for this stage vary from project to project but can be around 8-10 weeks.

Multiple Delivery Stages

The Project can have 2 or more stages and all preceded by the Project Board decision. All the above activities in the 1st Delivery Stage are duplicated in the next stages except the Work Packages. Other difference could be the change in timeline as per the project situation but approved by the Project Board.

Follow and Like us:

PRINCE2 – Controlling a Stage (CS) | Delivery Stages