Poll: The best Functional Test Automation IDE for YOU is

10 Objects to be Hand On!

This post is just short manual or reminder on generic system-available objects in Windows environments.
10 So let's go and begin for instantination. In order to unify and isolate external objects management, I prefer either Singleton or Factory simple patterns (http://at4qa.blogspot.com/2010/01/20-essential-design-patterns-for.html). They will take care about objects lifecycle management:
- object creation if not exist in current context or reference returning if an instance lives (singleton)
- new instance creation (if factory)
- dynamic object update when needed
- object life finalization destroy and freeding memory as it actual for languages w/o garbage collection or with with weak one
- protected/private use
- logging and exception handling

In VBScript new instance of object can be created as:
Set Obj= CreateObject(ObjStrSemantic),
e.g Set Obj= CreateObject("MSXML.DOMDocument")
I will address objects by mean of string variable ObjStrSemantic down the road:

1. "Scripting.FileSystemObject" - all operations over files and folders
2. "Shell.Application" - Standard shell Win object for running basic system operations
3. "WScript.Shell" - This is more prefearable object then listed above
4. "VBScript.RegExp" - Regular expressions object
5. "Scripting.Dictionary" - Dictionary object type. Basically, this structure is used in VBS or to create arguments of this type for subsequent calls
6. "WScript.Network" - Implements basic interfaces for networking
7. "InternetExplorer.Application" - can be used to manipulate on IE and can be candidate to replace testing tool functionality, clicking and so on
8. "ADODB.Connection" and "ADODB.Recordset" - basic object for obtaining connection with source through ADODB connector and object of Recordset type serving to store retrieved data from ADODB in memory
9. "MSXML.DOMDocument"("MSXML2.DOMDocument.3.0") - essential object to process XML through standard DOM methods, XPath. Why you may need it? You can develop Web testing code omitting testing vendors tools which make the same but giving own custom interfaces. Desing data (DDT) or keyword-driven(KDT) testing framework leveraging power of XML. Check out my post about XML possible use (http://at4qa.blogspot.com/2010/01/tools-xml-orm-for-efficient.html)
10. "WbemScripting.SWbemLocator" - Windows Management Instrumentation (WMI) is really powerful tool to manipulate over various system operations (hardware and software). I think WMI covers all system capabilities including all related to administration, providing remote connection and querying using SQL-like language WQL and unified API for administration automation. The link http://www.microsoft.com/downloads/details.aspx?FamilyID=2cc30a64-ea15-4661-8da4-55bbc145c30e&displaylang=en leads on download page of WMI code editor tool from MS - indeed, this tool is simple and handy.
    

Simple WMI usage for local querying:
Set oWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & HostName & "\root\cimv2")
Set colOperatingSystems = oWMIService.ExecQuery ("Select * from Win32_OperatingSystem") 'Querying OS info

Simple WMI usage for remoting:
Set objSWbemLocator = CreateObject("WbemScripting.SWbemLocator")
Set objWMIService = objSWbemLocator.ConnectServer(Host, "root\CIMV2", UID, Pwd, "MS_409")
Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_LogicalDisk",,48)


Working on test automation or infrastracture framework, it's better to design wrappers over methods, properties and events of appropriate objects and put these wrappers into appropriate custom Registry classes which will represent appropriate object interfaces. What you will get from that? At least:

1. Unified and safe access to objects, methods and properties (Registry class is better to implement using Singleton)
   
2. Your IDE/TDE will see instructions and Intellisense will work!
3. You will follow proper coding standards, you will avoid duplications and improper use. As result, you get back quality and code consistency
4. More long-term advantages...
   

Let's perfect scripting skills, MSDN will help in that - don't forget to utilize Scripting Technet space where you can enjoy examples and practices, follow at http://technet.microsoft.com/en-us/library/cc498722.aspx

Model-Based test automation with randomization

There is a pure work articulating on Model-based testing and it looks like the page http://www.goldpractices.com/practices/mbt/index.php widely covers all about that. Though it's theoretical at most, this is good start point to acquire knowledge and apply on practice. Also I liked the case studies showing effectiveness of model-based testing.

From test automation standpoint, this is really powerful thing which is not replacement of traditional static test design for BVT, extended tests. The automatic test suite modeling allow to run regression and exploratory tests which can cover much more s/w paths. It's true that covering all possible combinations is not efficient way even for automation as everything has limits. To run your test optimally, suggested use is applying:
- limitations
- preconditions
- coverage control points (if previous test has visited that destination, why we should repeat that over?)
- some randomization for both control flow operations (steps composition) and test data feeding on

To build models, I'd suggest to use XML technologies as flexible approaches for relational data storage, querying and transformation. Look at some tips here http://at4qa.blogspot.com/2010/01/tools-xml-orm-for-efficient.html

Importance of Basing on Testability in Automation

Greetings!

I'm back after very hard work on Kaspersky Antivirus new Release. We successfully passed technical Release. Our automated testing is proven and valuable weapon for daily build testing on a lot of test stands simulataneously. The automation is really indispensable on this project since it provides significant coverage and feel of confidence about each build quality.

The official Beta release of Kaspersky Internet Security/Antivirus 2011 is available of Company's forum here:
http://forum.kaspersky.com/index.php?s=22c83ab5a899d1bdafd4afc822a3ead6&showforum=16

The first thing i'd like to share with you is my thoughts about testability. This term can have relation to any software artifact: code, documentation, architecture, design, interface, structure, product and so on. In fact, the testability metric can be applied to any level of software, downside to code piece for unit testing. Let say if code piece is completely for protected usage, you can't pull interfaces of that class, so that testability is difficult and you need to invite workarounds like fake objects having rights to treat that class.

For routine functional automated testing, product testability plays key role for defining whether s/w suitable for automation or not. Formally I suggest to come up and register the requirements to product testability within Project book and Testing Strategy documents. Believe me or not but this is a ground and shield for you in developed project especially in strongly formalized projects. If you provide external test automation services these requirements are must as early as possible on a project. In essence, testability requirements is a basis of constructive proposals, negotiations and argumentations during project progress.

What kind of information should be listed out as requirements? Not sure I'm able to cover all things together but some general fitting to most projects are:

• Changes in software external GUI interfaces to be addressed as part of appropriate change management procedures

• Changes in software external non GUI interfaces to be addressed as part of appropriate change management procedures
• Changes in software internal tested interfaces to be addressed as part of appropriate change management procedures
• All changes to be planned, discussed and notified when it takes place
• All interfaces with which testing automated, should be frozen when the code freeze will take place
• Changes in software interfaces should not reduce capabilities of approved testing tools or significantly affect test automation codebase.
• All GUI objects should be recognizable by the use of approved testing tool
• All GUI objects should be uniquely identifiable by the use of approved testing tool
• All standard GUI objects' methods and properties to be accessible by the use of approved testing tool
• All intermediate and low-level software interface used for automated testing should be stable
• On All planned changes, appropriate persons should be notified prior the date of changes
• The data structures processed by test automation should provide access to each granular element using conventional methods. For instance, DB querying, object deserialization, XPath, Registry, CSV, INI parsing and so on.
• Access to GUI objects should be unified for identical object types. All custom objects should have minimal and similar access methods
• Custom controls not supported by approved test automation tools should be either enriched by typical access methods or special tool should be provided capable to recognize those objects
  
• Preferably, all typical interfaces should be identical between related projects, i.e. development should try to come up with cross-project solution of interfaces design
• Preferably, changes should be shown to automated testers before new deployment in order to adapt testing code in advance of deployment or releasing
  

Some projects may have individual requirements, some - not. You are free to adopt the list above and propose on review and approve requirements. Anyway, I hope my list from past experience could help one day for someone.

PS subscribe to dev codebase changelist to be prepared for changes in unstable project.

My Presentation is Featured of the Day on SlideShare.net

Nice to be informed by SlideShare about my presentation "Effective QA as driver towards innovations..." was chosen as featured of the day. I'm really surprised as I did not expect whatever and did not prepare - just wrote down some thoughts and put some illustrations.

11000+ views, shares and favorites. Looks like huge traffic!
Link on the uploading:
http://www.slideshare.net/PeterBiz/automated-testing-for-qa-httpat4qablogspotcom