Tuesday 3 November 2015

Test Methodology Summary

No comments:

  • Smoke or Sanity
    ** Non-extensive software testing, makes sure that the most crucial functions of a program work, but not bothering with finer details.
  • Unit
    ** Verify individual hardware or software units
  • Integration (Integ)
    ** Verify inter-unit and external interfaces
  • Functional (Func)
    ** Verify small groups of units and their interface ability to perform specific system and process functions
  • System (ST)
    Verify the complete system meets Func and Non-func Objectives and Requirements
    Functional ST includes: External Interoperability of all data and control elements
    Non-functional ST includes: Useability, Reliability, Efficiency, Portability, Maintainability
  • Performance (Perf)
    Covers Load, Volume, Stress and Exception testing
  • Regression
    Ensures that changes have not adversely affected the pre-existing system(s) or application(s)
  • User/Acceptance (UAT)
    Validates the complete and integrated system against acceptance criteria and customer expectations.
  • NOTE: Acceptance criteria are arrived at by aid of the System Requirements Specification (SRS), the Request For Proposal (RFP) and/or the Integration Test Plan (ITP)
  • Pilot/Field
    Verifies the complete system co-operates with business processes and workflow, to meet stakeholder expectations in a production-like environment.
  • Production Verification (PVT)
    A repeat of the Pilot testing but under full production and business conditions

Test Phases Explained


  • Smoke/Sanity Testing: Performed by developers before releasing the build to the testing team.
    May also be performed by testers to decide whether to accept the build for further testing or not.
TestPhasesExplained.png

Tuesday 13 October 2015

Word 2013 VBA runtime error 4605 on Read-only document

No comments:
I recently converted my office PC from standalone WinXP and Office 2007 to Windows 8.1 and Office 2013 running in VirtulaBox on a Windows 7 host ... that's the content of another post in-the-writing ...
Having got everything working as I wanted, I went to run one of my VB automated Word templates but low-and-behold it threw an error on the first selection.find.execute statement it encountered.

To cut a long story short, I found web articles detailing the necessity to include the line of code which says:
ActiveWindow.View.ReadingLayout = False
This seemingly fixed the problem when I added it right at the start of my code

WRONG !
As soon  as I finished updating the code and put the document back into Read-only the error raised its ugly head again.

Again for brevity, the solution was to go into Word's File - Options and uncheck the option
"Open email attachments and other uneditable files in reading view" as per this MS article

How to get Windows Tablet Data-only Cellular (LTE) Information

No comments:
I have found several methods of obtaining information about the SIM ICCID, IMEI, provider and other details from my Windows 8.1 tablet.

Note: I had my LTE connection enabled and active at the time I carried out these actions

First option 

From Settings - Network & Internet (Wi-Fi, airplane mode, VPN) - Cellular - double-tap the desired cellular connection in the RH panel ("Telstra Mobile - Connected" in my case) - Advanced Options - scroll to Properties section to view the:
IMEI: (also known as the Device Id);
SIM ICCID: (which matches the partial number printed on the actual SIM);
and the Mobile Number: field, which unfortunately is empty on my device as this is a data-only SIM, even though the SIM is referenced/billed by my provider as an Australian mobile cell-phone number !

Second Option

Using the command line there are a number of  netsh commands which can be used to show varying views of the mobile interface information.
From a command window prompt ( e.g. c:\Users\{username}\Desktop> )
Issuing the following commands provides varying detail:
The best overview is netsh mbn sh int
From the output of this first command you have the interface (int) value (i.e. Name: ), in my case  ...
There is 1 interface on the system:
      Name              : Cellular {interface (int) name-string}
      Description    : Sierra Wireless EM7345 4G LTE
etc ...
      Physical Address      : nn:nn:nn:nn:nn:nn {16-digit hex MAC address}
etc ...
      Device ID      : nnnnnnnnnnnnnnn {15-digid IMEI number}
 etc ...

So now a series of show (sh) commands can be issued against the particular interface (int)
Connection Information netsh mbn sh connection int="Cellular"
Ready Information netsh mbn sh readyinfo int="Cellular"
SMS Configuration Information netsh mbn sh smsconfig int="Cellular"
Visible Provider Information netsh mbn sh visibleproviders int="Cellular"
Radio State Information netsh mbn sh radio int="Cellular"

Available show (sh) commands for the mbn context are:
show capability - Shows the interface capability information for the given interface.
show connection - Shows the current connection information for the given interface.
show homeprovider - Shows the home provider information for the given interface.
show interfaces - Shows a list of Mobile Broadband interfaces on the system.
show pin       - Shows the pin information for the given interface.
show pinlist   - Shows the pin list information for the given interface.
show preferredproviders - Shows the preferred providers list for the given interface.
show profiles  - Shows a list of profiles configured on the system.
show provisionedcontexts - Shows the provisioned contexts information for the given interface.
show radio     - Shows the radio state information for the given interface.
show readyinfo - Shows the ready information for the given interface.
show signal    - Shows the signal information for the given interface.
show smsconfig - Shows the SMS configuration information for the given interface.
show tracing   - Shows whether Mobile Broadband tracing is enabled or disabled.
show visibleproviders - Shows the visible providers list for the given interface.

Unfortunately neither of these methods was able to return me the "Mobile Number" associated with the data-only SIM
If anyone knows how to do this, please leave a comment

Creating an I.T. Service Definition (as opposed to a Service Catalogue entry)

No comments:

Creating an I.T. Service Definition




I recently had a go at creating my first attempt at a full-detail  Service Definition (as opposed to a Service Catalog entry) to cover enterprise BPI work requests.

So far I have come up with the broad Service Description headings and sub-headings  and used a real-life BPI request to provide examples of how those headers may be filled.

This is an incomplete work based upon resources shown in the bibliography.

I have attempted to cover most key elements identified for a Service Descriptor artifact even though some of those elements may not require completion through bespoke work deliverables.

I would appreciate any critical feedback on whether I am on the right track for designing a Service Definition and what things I may have overlooked.

Service Description Elements

There appear to be at-least ten Service Description Elements:
1.       Service Description
2.       Business Benefits
3.       Risk Identification
  Business risk
  I.T. risk
4.       Service Price
  Model
  Unit cost
5.       Service Design
  Functional
  Resilience and DR
  Monitoring
  Alerting
  Reporting
6.       Service Provision Resourcing
7.       Service Capacity
8.       Service Warranty
  Parameters
  Prioritisation
9.       Service Commitments
  SLA – CFS
  OLA – RFS & inter/intra-department
10.   Authorisation
11.   Usage
  General Operation
  Required Software
  Web Interface
  Support
12.   Change and Upgrades


Partially-worked Example

1.       Service description
                Title                      
 e.g. Bespoke Integration, Reporting and Business Process Improvement for monthly board-reporting of Divisional Management metrics 
Summary            
e.g. Integration automation to increase speed of monthly regional report production through reduced manual processing and remediation of inherent human error
Features             
e.g. Created as transportable WinAutomation™ executable (or Visual Basic macro), will permit its application to standardised regional report spreadsheets for all enterprise regions
Functions           
e.g. Reads all data from each  regions’ individual projects Report workbooks as they are delivered. Compiles regional summary report.
Parent or Partners Service(s) (from defined Business Services) 
e.g. XXX State Report Visual Basic macro and monthly Project Report Visual basic macro
Availability Times & Maintenance Window(s) – a schedule          
e.g. 24x7 local-system access for those to whom this service is deployed

2.       Business benefits
Speed / delivery timeliness,       
e.g. will reduce current 1-man-week per month labour expenditure for reports production
Cost savings,                     
e.g. labor savings in terms of regained productivity for the regional and national managers
Staffing reduction/load-sharing,              
e.g. automated data compilation of the monthly reports can now be performed by staff other than the regional managers
Staff skilling/hiring,        
e.g. Less highly skilled operators required for report compilation
Hours of attendance,    
Repeatability,                   
e.g. consistent output through reduced tedium in the monthly compilation of the 26-plus project reports
Error reduction,               
e.g. less likelihood of missed or mal-transposed data from project to regional summary reports
Risk reduction,                 
e.g. single-person dependency reduced by making it possible for other-than the regional managers to produce the monthly summary reports

3.       Risk Identification
                Business
                                Operational impact – consult with business to identify impact
                                Legal Impact– consult with business to identify impact
                Information Systems
                                Operational Impact        
e.g. Staff with the required (WinAutomation or Visual Basic) automation skills must be retained
                                RFS Systems Impact       
e.g. No internal I.S. services interface with this service offering

4.       Service Price
Model  - the way in which this service will be charged to the customer on a one-time or recurring basis, and any additional charges which may be apparent.
Initial, Refinement/Enhancement, Warranty and post-warranty should all be considered                             
e.g.
This service will be internally chargeable to the requesting department at an agreed  one-time value based on estimated/quoted labor
The total service estimate shall  not exceed 160 hours labor - 40 hours design,  120 hours develop and deliver.
The estimated value will derive from the initial analysis and proposed design;  to prototype, debug, refine, document, and deploy this service.
Prototype refinement costs will be chargeable as defined in the following per-deliverable Unit Cost section
Warranty labor costs are covered in the development labor estimate based on the initial analysis of this service’s design
Post-warranty support will be covered under each departments standard I.S. charge-back contribution

per deliverable Unit Cost – charges for first and subsequent deployments of this service 
e.g.
Initial analysis suggests approximately 40 hours will be required to design, develop and deliver this service.
A further labour charge of up to 16 hours is estimated to refine the delivered prototype to meet User Acceptance.
For each additional state into which this service is deployed and additional 8 hours labour charge will apply

5.       Service Design
               Analysis – description pending
                Design and Prototyping - description pending
                Build - description pending
                Testing - description pending
                Debugging - description pending
    Documentation - description pending
    User Training - description pending
    Deployment - description pending
    Warranty - description pending
    Support - description pending

6.       Service Provision Resourcingestimated persons and duration's required
                Analysis / Requirements definition – I.S.                                    
e.g. I person for 3~4 hrs
                Design – I.S. or external               
e.g. 1 person 8 hrs
                Prototyping – I.S. or external     
e.g. 1 person 16 hrs
Build – I.S. or external                   
e.g. 1 person 16 hrs
UAT – Business and Build resources       
e.g. 1 person 2~4 hrs
Debugging – Build resource                        
e.g. 1 person 16 hrs
Documentation – Design and Build resources    
e.g. 2 persons 16 hrs combined
Deployment – I.S.                           
e.g. 1 person 30 mins per deploy
Training – Design and/or Build and/or I.S. resources       
e.g. 1 person 4 hrs per deployment
Warranty – Build and/or I.S. resources                                  
e.g. 2 persons 4 hrs combined
First contact Support – I.S. Service Desk               
< 1% Service Desk resource overhead

7.       Service Capacity
                Baseline - description pending
                Growth Projection - description pending

8.       Service Warranty
                Parameters
                                Period  
e.g. 30 days elapsed starting from User Acceptance
                                Coverage
                                                Bug fixes – all non-functional or erroneous-actions performed by the service will be addressed as “bugs”
                                                Design refinement – as defined in per deliverable Unit Cost section
Resourcing / Prioritisation
                Bug Fixing
                Design refinement – matching requirements
                Enhancement requests – extended requirements

9.       Service Commitments:
Service Level Agreement (SLA) – CFS – between I.S. and Customer
                What will occur?
                                First Response (TTR)
                                System Recovery (TTF or RTO)
                                Full Data Access Recovery (RPO)
                By when?
                                Response Time Objectives (TTR)
                                                Service viability assessmentTime of assessment delivery from time of business request                
[max 10 business days elapsed]
                                                Service Designtime to deliver a design from delivery of “viable” assessment                                   
[max 40 expended hours]
                                                Service Deliverytime to deliver a working prototype for UAT, from time of design completion
 [T.B.D based on design complexity but guideline max 120 expended hours else “too big” to offer as a service, needs to become a Project]
                                                Warranty bug-fixtime to first contact upon warranty bug notification                                [tbd]
                                                Warranty design refinement - time to first contact upon receipt of refinement request                [tbd]
                                                Post-warranty support - time to first contact upon incident notification                                 
[Standard Service Desk TTR SLA unless otherwise negotiated]
                                Recovery Time Objectives (TTF)
                                                System Functionality restored   [tbd]
                                                All data accessible                            [tbd]
                To what degree?
                                Recovery Point Objective (RPO) – anticipated worst-case data loss - example pending
                Whom is responsible for delivery? - example pending
                Escalation thresholds     [tbd]
                Escalation Methods & Procedures - description pending - example pending
                Breach penalties              [tbd]

Supporting Operational Level Agreements (OLA’s) – RFS – Internal to I.S. or between I.S. and any third-party Service Providers
                                Supporting systems dependencies? - example pending
                                Supporting system SLA’s              [tbd]
                                Whom is responsible for OLA deliveries? - example pending
                                OLA escalation thresholds            [tbd]
                                OLA escalation methods & procedures - description pending - example pending

                Dependent Operational Level Agreements - OLA’s or Inter/Intra-departmental business agreements
                                Dependent systems or services? - example pending
                                Whom is responsible for ensuring service delivery to third-parties - example pending
                                OLA escalation thresholds            [tbd]
                                OLA escalation methods & procedures - description pending - example pending

10.   Authorisation - who is authorising time and expenditure for this service - example pending
11.   Usage - Text or links describing how to access or use functions of the service. Self-service resource links. Configuration information. - example pending
Software - Links to standard software used to access the service. - example pending
Web interface details - URLs etc - example pending
Getting Help - Standard Service Desk links and any additional contacts for clients to receive service support. Links to relevant FAQs and self-service information. - example pending
12.   Change and Upgrades - description pending - example pending





Glossary




CFS

Customer Facing Service

defines the characteristics and behaviour of a particular service as seen by the customer
OLA

Operational Level Agreement

an agreement between an IT service provider and another part of the same organization
RFS


Resource Facing Service


supports CFSs but are not seen or purchased directly by the customer.
(e.g., “DHCP” [RFS] is required for “Email” [CFS])
RPO




Recovery Point Objective




RPO (Recovery Point Objective) refers to the amount of data at risk. It's determined by the amount of time between data protection events and reflects the amount of data that potentially could be lost during a disaster recovery. The metric is an indication of the amount of data at risk of being lost.
RTO




Recovery Time Objective




RTO (Recovery Time Objective) is related to downtime. The metric refers to the amount of time it takes to recover from a data loss event and how long it takes to return to service. RTO refers then to the amount of time the system's data is unavailable or inaccessible preventing normal service.
SLA



Service Level Agreement



A formal, negotiated document that defines (or attempts to define) in quantitative (and perhaps qualitative) terms the service being offered between an IT service provider and a customer.
TTF


Time To Fix
NOTE: Sometimes referred to as:
Time To Resolve or Time To Recover
TTR


Time To Respond
NOTE: can be confused with:
Time To Resolve or Time To Recover
the point at which someone takes ownership of the issue


URL


Universal Resource Locator


one type of Uniform Resource Identifier (URI); the generic term for all types of names and addresses that refer to objects on the World Wide Web.
WSLA


Web Service Level Agreement (Language)


The Web Service Level Agreement (WSLA)
framework is targeted at defining and monitoring SLAs for Web Services

Bibliography

Business-focused IT and Service Excellence – David Miller