Send Email through vbs using CDO object

set  objemail=createobject("cdo. message")
objemail. from=strmailfrom
objemail. to=strmailto
objemail. subject=strmailsubject
objemail. textbody=strmailbody
strmailattachment="c:\test. btml"
objemail. addattachment strmailattachment
objemail. configuration. fields. item("http://schemas.microsoft.com/cdo/configuration/sendusing")=2
objemail. configuration. fields. item("http://schemas.microsoft.com/cdo/configuration/smtpserver") ="mailhost. ldn... com"
objemail. configuration. fields. item("http://schemas.microsoft.com/cdo/configuration/smtpserverport") =25
objemail. configuration. fields. update
objemail. send

Send email through vbs using Outlook Application utility object

set objoutlookmail=createobject("outlook. application")
Set mymail=objoutlookmail. createitem(0)
mymail.display
set mymailproperty=objoutlookmail. activeinsepector
if mymailproperty. iswordmail="trur" then
    set mydoc=mymailproperty. wordeditor
    mydoc. range chr(13)+"Hi All," +chr(13) & " Please see execution status for.... application." +chr(13)
     mydoc.range.insertafter chr(13)+"Regards,"+chr(13) & "support team" +chr(13)
     strmailattachment="c:\test. html"
      mymail. Attachments. add strmailattachment
       mymail. from="abc@gmail.com"
       mymail. to="xyz@gmail.com;pyz@gmail.com"
      mymail. subject="Application Automation Execution Reports"
       mymail. send
end if
Set mymail.=Nothing
Set mydoc=Nothing
Set objoutlookmail=Nothing

Test Metrics

Hi,

Couple of Test Matrics formulas.

Formulae :

Test Coverage (%) = (No. of Test Cases Executed / No. of Test Cases Planned) * 100

Test Case Effectiveness (%) = (1 - (No. of Inadeqaute Test Cases Detected / Actual No. of Test Cases)) * 100

Quality of Testing (%) = (No. of Defects Accepted / No. of Defects Reported) * 100

Automation Suite Test Coverage (%) = (No. of Test Cases Automated / Total No. of Test Cases) * 100

Environmental Availability (%) = (1 - (Total Down Time / Total Cycle Time)) * 100 Regards, Trupti

Test Summary Report

Test Summary Report

A test summary report is a testing work product that formally summarizes the results of all testing on an endeavor.

Why Required?

• Summarize all of the testing that was performed since the previous test summary report.
• Enable project management and the customer to know the status of project testing.

Benefits

Project Management and end customer can:

• Able to get project testing status
• Able to get application quality status
• Able to take corrective actions, if required

Guidelines

1.       A Test summary report should generated on regular basis

2.       It should be in metrics, charts and table forms, if possible

3.       Copy of each summary report should maintain until the build release. It can be kept on central location, for future reference

4.       To write  a test summary report, required pre requisites are- test plan should be complete, test execution should occur and respective test reports should be available.

Content of Test Summary Report 

Introduction

•  Definition
•  Objective
• Reference document
• Target Audience
• Test Summary
• Unit Testing Summary
• Integration Testing Summary
• System Testing Summary
• Launch Testing Summary
• List of Severity One Failures
• Testing Issues Requiring Resolution
•  Appendices:
• TBDs
• Assumptions

For each kind of testing summarized, a test summary report will include the following information (previous report, current report, and percentage change):

• Test Suite Information:
• o   Number of test suites planned.
• o   Number and percentage of test suites implemented.
• o   Number and percentage of test suites executed.
•  Test Case Information:
•  Number of test cases planned.
•  Number and percentage of test cases implemented.
•  Number and percentage of test cases executed.
•  Number and percentage of test cases passed.
•  Number and percentage of test cases failed (total and by severity).

All about Bug or Issues

All about Bug, Error and Defects

Error: Mistake in code is error. Error is an undesirable deviation from requirement

Bug: if defect accepted by the development team it is called bug. Bug is an error found before the application goes into production

Defect: Defect is a variance from desired product attributes or normal flow. When defect reaches to end customer is termed as failure. Defect is an error found after the application goes into production.

Defects can be from product specification

Defects can be from customer or user expectation.

Attributes of Defect

1. Defect Naming – requirement defect, design defect, documentation defect

2. Severity of Defect

• Critical (high) –show stopper
• Major (high) incorrect output derived
• Minor (Low) spelling mistake

3. Type of Defect

• Wrong- requirements implemented incorrectly
• Missing – requirement given by end customer but it were not implemented at all
• Extra – requirement implemented correctly but were not requested by end customer

About Severity and Priority

Severity: Seriousness of defect with respect to functionality

Priority: importance of defects with respect to customer

• · High: without resolving defect we are unable to continue testing
• · Medium: compulsory to solve but able to continue
• · Low: may or may not be resolved

Examples:

• User interface bug- low severity
• Calculation bug- high severity and high priority bug
• Improper alignment – low priority and low severity bug
• Spell mistake – high priority and low severity bug
• Final output wrong – low priority
• Dependent output wrong – high priority
• Annual report print functionality not working – High severity and low priority issue

Components of Bug

• Title of bug
• Severity of bug
• Priority of bug
• Bug type
• Module name
• Assigned to
• Project manager
• Steps to reproduce
• Actual output
• Expected output
• Attachment of log and screen shot
• Comments
• Test environment – browser, OS information etc
• Build date and platform

Guidelines to write bug

• Be precise
• Be clear – explain it so other can reproduce the bug
• Mention exact steps to reproduce with details
• Provide sufficient test environment details
• Mention build date and number with details
• When you close your bug mention on which build and date you verify it, so in future if require to reopen it we can have track on which build it works last

Defect Density

defect density is the count of total defects identified against a particular software entity it is calculated as... no of defects/ size of software where size is typically counted in lines of code this is used to compare the relative number of defects in various software components, to find out the defect prone areas of the application

Defect density = Total number of defects/LOC (lines of code)

Defect density = Total number of defects/Size of the project Size of Project can be Function points, feature points, use cases, KLOC etc