How to Perform Image Comparison

‘Function Name : BinaryImageCompare()
‘Arguments : 1. Source File with path, 2. Destination File to be compared with path
‘Description : The function compares the source and destination files in the binary mode. This
can be used for any type of files.
‘Return Type : If the files are identical then function return true else false
‘*************************************************************************************************************

Function BinaryImageCompare(fileA,fileB)
Dim sFileA, sFileB
Dim bMatched
Dim nSize
Dim bufA, bufB
Dim lengthA, lengthB
Const adTypeBinary = 1
Set fso = CreateObject(”Scripting.FileSystemObject”)
Set streamA = CreateObject(”ADODB.Stream”)
Set streamB = CreateObject(”ADODB.Stream”)
FileCompare = null
if vartype(fileA) vbString then
on error resume next
sFileA = fileA.path
if err then exit function
on error goto 0
else
if not fso.fileexists(fileA) then
exit function
else
sFileA = fileA
end if
end if
if vartype(FileB) vbString then
on error resume next
sFileB = FileB.path
if err then exit function
on error goto 0
else
if not fso.fileexists(FileB) then
exit function
else
sFileB = FileB
end if
end if

streamA.type = adTypeBinary
streamB.type = adTypeBinary
streamA.open
streamB.open
on error resume next
streamA.loadfromfile sFileA
if err then exit function
streamB.loadfromfile sFileB
if err then exit function
on error goto 0
bMatched = true
nSize = 2^15 ‘32K
do until streamA.eos or streamB.eos
bufA = streamA.read(nSize)
bufb = streamB.read(nSize)
lengthA = lenB(bufA)
lengthB = lenB(bufB)
if lengthA lengthB then
bMatched = false
exit do
elseif MidB(bufA,1,lengthA) MidB(bufB,1,lengthB) then
bMatched = false
exit do
end if
loop
if not (streamA.eos and streamB.eos) then
bMatched = false
end if
streamA.close
streamB.close
BinaryFileCompare = bMatched
End Function

How to Find Possible Number of Test Cases

It absolutely depends on your approach you take(test case generation strategy), but you should use Pair Wise (Orthogonal Array) to reduce the number of TCs. Personally I don’t think there is a method to know the exact number of test cases before writing that. It depends on the approach which you use. Some folks write functional level and some write unit level test cases. According to me test coverage matters rather than no. of test cases.

Also, traceability matrix should be maintained and checked regularly, in order to ensure your test coverage.

The estimation can be done using the following data/method

Historical data
===============
If you have a similar application, then you can get the historical data, and find out how much your current project varies from that. Accordingly, give a rough guess.

Function points
===============
Estimate the number of function points that could be generated for your requirements.

This is done by the development team also. So, you may borrow the data from them.

Types of testing
================
Functional, security, Performance/stress, Interoperability etc…

Testing techniques
==================
BVA, EP, Decision Tables, State Transition etc.

The methods could be something like below:
1. Identify the types of testing to be done.
2. Identify which testing type is applied on whICH function point(FP).
3. Determine which testing technique is applied to test which FP (while doing this, remember what kind of testing you wanted to do on the FP)

4. For each testing technique, give a rough estimate on the number of test cases that can be generated, example:
FP1 – BVA – 8 test cases
FP2 – DT – 15 test cases

5. Compare this final data with the Historical data.

What Are LoadRunner Components

Load Runner Components are as follows -
➤ The Virtual User Generator captures end-user business processes and creates an automated
performance testing script, also known as a virtual user script.

➤ The Controller organizes, drives, manages, and monitors the load test.

➤ The Load Generators create the load by running virtual users.

➤ The Analysis helps you view, dissect, and compare the performance results.

➤ The Launcher provides a single point of access for all of the LoadRunner
components.

What is Software Testing Auditing Process

Introduction: To ensure transparency and reliability of the IT systems it may be necessary to audit the Software Development Processes including the most important aspect – Software Testing Process. it ensure that the Testing processes are followed as defined.

Types of Testing Process Audits
The Audits are performed to achieve certain following goals :

Audit to verify compliance: To judge if the process complies with a standards. In this, the actual testing conducted is compared with the documented process.

Audit for process improvement/problem solving: To audit and trace the various steps in the process and try to weed out process problems. For instance it is observed that too many software defects escaped detection even though the testing process was apparently followed. So the audit is done as a preliminary step to collect facts and analyze them.

Audit for Root Cause Analysis : To audit the testing process is to find a Root Cause of a specific problem. For example the customers discovered a high severity defect in software. So we retrace our testing steps to find out what went wrong in this specific case.

Internal Audits – The internal audits are initiated from within the organizations

External Audits – External Audits are done by and initiated by external agencies

Need of Software Testing Process Audit –
It is a management activity & helps the management understand if the process is being followed as specified.

Testing audit may be peforemd for one or more of the following factors:
• To ensure continued reliability and integrity of the process
• To verify compliance of standards (ISO, CMM, etc)
• To solve process related problems
• To find the root cause of a specific problem
• To detect or prevent Fraud
• To improve the Testing process

Auditing of the Testing process may also be done if the Software Product is a mission critical one such as used for Medical Life Support Systems. This is done to prevent any loop holes or bugs in the system.

How to Audit
Typically the Audit of the Testing Process will include the following steps:

• reviewing the Testing process as documented in the Quality Manual. This helps the auditor
understand the process as defined.
• Reviewing the deliverable documents at each step
• Document reviewed include
– Test Strategy
– Test Plans
– Test Cases
– Test Logs
– Defects Tracked
– Test Coverage Matrix
– any other relevant records

Each of the above document provides a certain level of traceability that the process was followed and the necessary steps were taken

• Interviewing the Project Team at various levels – PM, Coordinator, Tester.

Interviewing the Project Team members gives an understanding of the thought process prevalent in those conducting the Testing Process. This can provide valuable insights over an above what was actually documented

Whether test cases created covered all requirements/use cases
This analysis reveals if the test coverage was sufficient. It indicates that whether the testing team did the best to provide adequate amount of testing

Whether all Defects were fixed – The Status of all the Defects logged is checked to verify if all were fixed and verified

Whether there are any known bugs in the software released – Sometimes all the defects may not be fixed, the software may be released with known problems. Test Logs would indicate the actual results and evidence of any bugs being present.

Whether the levels of testing was effective enough – If Defects pass thru the various levels of testing undetected, it may reflect poorly on the effectiveness of the testing process
• What were the number of defects (Defect Leaks) that went by undetected in each phase
• Number of iterations of testing in each level
• Time taken to test each module/component
• This data may be used for process improvement
• Versions of source code actually tested

The Test Logs and Defect Logs indicates (if the information was captured) the actual versions of code/components tested. This information is valuable in root cause analysis.

What is Philosophies Behind HTML5

There are three main stated design principles to HTML5:
– Specifying current browser behaviors that are interoperable
– Defining error handling for the first time
– Evolving the language for easier authoring of web applications