Eclectic Colors!

Typical Automation Tool Cosine Wave

2011-04-26T13:35:00.000+05:30

VBAbility

2011-02-26T13:51:00.002+05:30

VBAbility

Most usually and likely you must be using VBA macros for some excel automation. There is other side of VBA too i.e. creating small applications to be applied to automation. This article discusses some of these facets.

The Excel Gift

VBA editor

The day MS office was installed on your computer, you were gifted. You were gifted with a free editor that comes with it so that you could churn out the code with all the features and facets of any wonderful code editor.

Most of you must have used the code editor to write snippets called macros in MS terminology. The code editor window gives you something interesting i.e. a project explorer. Thus exposing the excel sheets so that you could manipulate it whichever way you want. Since it’s a Project explorer you know that you are creating a project typically like a development project. Yes! Like a development project, where you can add window forms, add business logic modules and treat the excel cells as data layer. The gift also provides you with some more powerful features like referencing an external dll (dll, tlb.ocx, wsc, .net ineterops etc) thereby providing the extensibility to excel to its existing vast set of functionalities.

You had an automation tool right in front of you all these years

If automation is defined as anything that saves human effort then excel as an automation tool was there right in front of your eyes all these years.

You need to do some file manipulation?

You need to access windows services and check the status?

You need to access the web services?

You need to access web browser?

You need to send out an email?

… And the list goes on. If above are some of the activities that you do routinely and want to automate, Excel is the right tool for you.

UI (Web) Test Automation

The other perspective of using the Excel’s VBA editor is that it can be used to drive IE. Capture the objects rendered on the screen and do actions on it. The automation level can be from simple HTML controls to advance RAD controls like component one if you know how to do it.

Learning VBA

If you are a VBScript developer or novice or a mix VBA is equally good for all. The learning curve of VBA is smooth and short and in minimal time you can master the VBA language. I was always addicted by the power that a simple excel sheet can offer. With little step by step mastering the Excel has led to building small to full blown applications.

Just with the intent that how can the excel sheets be used as an automation tool, the following examples show case as well as probably instigate you to think in this direction so that even in lack of tools like selenium, QTP, Robot, SilkTest you would be able to achieve much.

EXAMPLE 1: Excel Mock SOAPUI

The tools to create SOAP Xmls, Submit SOAP requests and get SOAP responses. In Core this is what essentially is done by industry standard tool named SOAPUI.

• You can create an Template to create XML with feature to add /delete multiple nodes on the fly with a custom menu item added via macros

• Embedded textbox controls to edit/modify xml

• Embedded web browser control to view SOAP response

To Submit a SOAP Request. Use reference MSXML2

objXMLHTTP.Open "post", <>, False

objXMLHTTP.setRequestHeader "Man", Post & " " & <> & " HTTP/1.1"

objXMLHTTP.setRequestHeader "MessageType", "CALL"

objXMLHTTP.setRequestHeader "Content-Type", "text/xml"

objXMLHTTP.setRequestHeader "SOAPAction", <>

objXMLHTTP.send Sheet4.txtPreview.Text

EXAMPLE 2: XML to XML Convertor

The tool to convert one form of XML to another using a simple XSLT transformation

To Transform XML to XML using XSLT

Set xml = New DOMDocument60

Set stylesheet = New DOMDocument60

xml.async = False

stylesheet.async = False

xml.Load <>

stylesheet.LoadXML <>' "SOA-SOAP.xsl"

EXAMPLE 3: UI Automation1 A tool to navigate web pages, access the web links and get the BSE/NSE codes. The VBA code inside the excel sheets mock user actions on the page. The tools does not make use of any third party tools and merely uses IE and MSHTML objects to achieve automation.

Access IE Dom to create IE objects and access the API Clicks the same way SIlkTest would be achieveing.

EXAMPLE 4: UI Automation2 Web UI automation achieved again for an order entry application. Typically this approach can be used to create /pump test data into the applications.

Just use Excel Application Object, Scripting Run time as reference and FileSystemObjects.

Just use MSHTML reference to achieve UI Automation.

Thank You!. Hopefully these examples are good enough for one to think in the direction of using Excel as an automation tool. IWould be glad to help anyone. Abhijeet Bhagat

The surprising truth about what motivates us

2011-02-26T12:33:00.000+05:30

The surprising truth about what motivates us

SilkTest 2010 Installation Screens

2010-10-01T08:19:00.000+05:30

SDLC Models

2010-01-31T22:04:00.002+05:30

There are various software development approaches defined and designed which are used/employed during development process of software, these approaches are also referred as "Software Development Process Models". Each process model follows a particular life cycle in order to ensure success in process of software development.

1. Waterfall Model:
Waterfall approach was first Process Model to be introduced and followed widely in Software Engineering to ensure success of the project. In "The Waterfall" approach, the whole process of software development is divided into separate process phases. The phases in Waterfall model are: Requirement Specifications phase, Software Design, Implementation and Testing & Maintenance. All these phases are cascaded to each other so that second phase is started as and when defined set of goals are achieved for first phase and it is signed off, so the name "Waterfall Model". All the methods and processes undertaken in Waterfall Model are more visible.

The stages of "The Waterfall Model" are:

Requirement Analysis & Definition: All possible requirements of the system to be developed are captured in this phase. Requirements are set of functionalities and constraints that the end-user (who will be using the system) expects from the system. The requirements are gathered from the end-user by consultation, these requirements are analyzed for their validity and the possibility of incorporating the requirements in the system to be development is also studied. Finally, a Requirement Specification document is created which serves the purpose of guideline for the next phase of the model.

System & Software Design: Before a starting for actual coding, it is highly important to understand what we are going to create and what it should look like? The requirement specifications from first phase are studied in this phase and system design is prepared. System Design helps in specifying hardware and system requirements and also helps in defining overall system architecture. The system design specifications serve as input for the next phase of the model.

Implementation & Unit Testing: On receiving system design documents, the work is divided in modules/units and actual coding is started. The system is first developed in small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality; this is referred to as Unit Testing. Unit testing mainly verifies if the modules/units meet their specifications.

Integration & System Testing: As specified above, the system is first divided in units which are developed and tested for their functionalities. These units are integrated into a complete system during Integration phase and tested to check if all modules/units coordinate between each other and the system as a whole behaves as per the specifications. After successfully testing the software, it is delivered to the customer.

Operations & Maintenance: This phase of "The Waterfall Model" is virtually never ending phase (Very long). Generally, problems with the system developed (which are not found during the development life cycle) come up after its practical use starts, so the issues related to the system are solved after deployment of the system. Not all the problems come in picture directly but they arise time to time and needs to be solved; hence this process is referred as Maintenance.

Advantages:
The advantage of waterfall development is that it allows for departmentalization and managerial control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process like a car in a carwash, and theoretically, be delivered on time. Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order, without any overlapping or iterative steps.

Disadvantages:
The disadvantage of waterfall development is that it does not allow for much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage. Alternatives to the waterfall model include joint application development (JAD), rapid application development (RAD), synch and stabilize, build and fix, and the spiral model.

In the traditional waterfall model of software development, the first phase of requirements analysis is also the most important one. This is the phase which involves gathering information about the customer's needs and defining, in the clearest possible terms, the problem that the product is expected to solve.

This analysis includes understanding the customer's business context and constraints, the functions the product must perform, the performance levels it must adhere to, and the external systems it must be compatible with. Techniques used to obtain this understanding include customer interviews, use cases, and "shopping lists" of software features. The results of the analysis are typically captured in a formal requirements specification, which serves as input to the next step.

Well, at least that's the way it's supposed to work theoretically. In reality, there are a number of problems with this theoretical model, and these can cause delays and knock-on errors in the rest of the process. This article discusses some of the more common problems that project managers experience during this phase, and suggests possible solutions.

2. Iterative Model:

An iterative lifecycle model does not attempt to start with a full specification of requirements. Instead, development begins by specifying and implementing just part of the software, which can then be reviewed in order to identify further requirements. This process is then repeated, producing a new version of the software for each cycle of the model. Consider an iterative lifecycle model which consists of repeating the following four phases in sequence:

A Requirements phase, in which the requirements for the software are gathered and analyzed. Iteration should eventually result in a requirements phase that produces a complete and final specification of requirements.

- A Design phase, in which a software solution to meet the requirements is designed. This may be a new design, or an extension of an earlier design.

- An Implementation and Test phase, when the software is coded, integrated and tested.

- A Review phase, in which the software is evaluated, the current requirements are reviewed, and changes and additions to requirements proposed.

For each cycle of the model, a decision has to be made as to whether the software produced by the cycle will be discarded, or kept as a starting point for the next cycle (sometimes referred to as incremental prototyping). Eventually a point will be reached where the requirements are complete and the software can be delivered, or it becomes impossible to enhance the software as required, and a fresh start has to be made.

The iterative lifecycle model can be likened to producing software by successive approximation. Drawing an analogy with mathematical methods that use successive approximation to arrive at a final solution, the benefit of such methods depends on how rapidly they converge on a solution.

The key to successful use of an iterative software development lifecycle is rigorous validation of requirements, and verification (including testing) of each version of the software against those requirements within each cycle of the model. The first three phases of the example iterative model is in fact an abbreviated form of a sequential V or waterfall lifecycle model. Each cycle of the model produces software that requires testing at the unit level, for software integration, for system integration and for acceptance. As the software evolves through successive cycles, tests have to be repeated and extended to verify each version of the software.

3. V-Model:

The V-model is a software development model which can be presumed to be the extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing.

Requirements analysis:In this phase, the requirements of the proposed system are collected by analyzing the needs of the user(s). This phase is concerned about establishing what the ideal system has to perform. However, it does not determine how the software will be designed or built. Usually, the users are interviewed and a document called the user requirements document is generated. The user requirements document will typically describe the system’s functional, physical, interface, performance, data, security requirements etc as expected by the user. It is one which the business analysts use to communicate their understanding of the system back to the users. The users carefully review this document as this document would serve as the guideline for the system designers in the system design phase. The user acceptance tests are designed in this phase.

System Design:System engineers analyze and understand the business of the proposed system by studying the user requirements document. They figure out possibilities and techniques by which the user requirements can be implemented. If any of the requirements are not feasible, the user is informed of the issue. A resolution is found and the user requirement document is edited accordingly.

The software specification document which serves as a blueprint for the development phase is generated. This document contains the general system organization, menu structures, data structures etc. It may also hold example business scenarios, sample windows, reports for the better understanding. Other technical documentation like entity diagrams, data dictionary will also be produced in this phase. The documents for system testing is prepared in this phase.

Architecture Design:This phase can also be called as high-level design. The baseline in selecting the architecture is that it should realize all which typically consists of the list of modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology details etc. The integration testing design is carried out in this phase.

Module Design:This phase can also be called as low-level design. The designed system is broken up in to smaller units or modules and each of them is explained so that the programmer can start coding directly. The low level design document or program specifications will contain a detailed functional logic of the module, in pseudocode - database tables, with all elements, including their type and size - all interface details with complete API references- all dependency issues- error message listings- complete input and outputs for a module. The unit test design is developed in this stage.

4. The Spiral Model

The spiral model, also known as the spiral lifecycle model, is a systems development method (SDM) used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is intended for large, expensive, and complicated projects.

The steps in the spiral model can be generalized as follows:

The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.

A preliminary design is created for the new system.

A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.

A second prototype is evolved by a fourfold procedure: (1) evaluating the first prototype in terms of its strengths, weaknesses, and risks; (2) defining the requirements of the second prototype; (3) planning and designing the second prototype; (4) constructing and testing the second prototype.

At the customer's option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer's judgment, result in a less-than-satisfactory final product.

The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above.

The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.

The final system is constructed, based on the refined prototype.

The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.

Advantages:
a. Estimates (i.e. budget, schedule, etc.) become more realistic as work progresses, because important issues are discovered earlier.

b. It is more able to cope with the (nearly inevitable) changes that software development generally entails.

c. Software engineers (who can get restless with protracted design processes) can get their hands in and start working on a project earlier.

Disadvantages:
a. Highly customized limiting re-usability

b. Applied differently for each application

c. Risk of not meeting budget or schedule

d. Risk of not meeting budget or schedule

5. The Big Bang Model:
Let's review the observational evidence:

a. Distance/velocity relationship: distant galaxies are moving away from us, with speeds which increase linearly with distance

b. Chemistry: the universe is almost entirely hydrogen and helium, in a mixture of roughly 12 H atoms to 1 He atom
Cosmic Microwave Background: no matter where we look in the universe, we see radio waves which look like those radiated by a blackbody at about 2.7 degrees above absolute zero. There are tiny (one part in 10,000) variations in the brightness of this radiation on scales of a degree or so

c. Is there any way to tie all these pieces of data together? Yes! One model which can explain them all is called the Big Bang model. The name was coined by a scientist who didn't like the theory and tried to make it sound silly.

Fundamentals of the Big Bang Model:

The Big Bang is built upon three main tenets:

a. the universe used to be very hot
b. the universe used to be very dense
c. the universe is expanding (which is why it isn't so hot or dense anymore)

Note that the basic Big Bang Model does NOT say anything about the following questions:

a. will the universe collapse again, or expand forever?
b. is pace curved or flat?
c. how old is the universe?
d. what is the matter density in the universe?
e. what about dark matter?
f. is there some mysterious "repulsive" force on large scales?
g. how did galaxies form?

Some of these questions all depend upon the values of certain parameters in the model, which we may derive from observations. Others have nothing to do with the Big Bang itself.

Our understanding of the laws of nature permit us to track the physical state of the universe back to a certain point, when the density and temperature were REALLY high. Beyond that point, we don't know exactly how matter and radiation behave. Let's call that moment the starting point. It doesn't mean that the universe "began" at that time, it just means that we don't know what happened before that point.

6. RAD Model:
RAD (rapid application development) is a concept that products can be developed faster and of higher quality through:

a. Gathering requirements using workshops or focus groups
b. Prototyping and early, reiterative user testing of designs
c. The re-use of software components
d. A rigidly paced schedule that defers design improvements to the next product version
e. Less formality in reviews and other team communication

Some companies offer products that provide some or all of the tools for RAD software development. (The concept can be applied to hardware development as well.) These products include requirements gathering tools, prototyping tools, computer-aided software engineering tools, language development environments such as those for the Java platform, groupware for communication among development members, and testing tools. RAD usually embraces object-oriented programming methodology, which inherently fosters software re-use. The most popular object-oriented programming languages, C++ and Java, are offered in visual programming packages often described as providing rapid application development.

RAD model has the following phases:

Business Modeling: The information flow among business functions is defined by answering questions like what information drives the business process, what information is generated, who generates it, where does the information go, who process it and so on.

Data Modeling: The information collected from business modeling is refined into a set of data objects (entities) that are needed to support the business. The attributes (character of each entity) are identified and the relation between these data objects (entities) is defined.

Process Modeling: The data object defined in the data modeling phase are transformed to achieve the information flow necessary to implement a business function. Processing descriptions are created for adding, modifying, deleting or retrieving a data object.

Application Generation: Automated tools are used to facilitate construction of the software; even they use the 4th GL techniques.

Testing and Turn over: Many of the programming components have already been tested since RAD emphasis reuse. This reduces overall testing time. But new components must be tested and all interfaces must be fully exercised.

Advantage and Disadvantages:

RAD reduces the development time and reusability of components help to speed up development. All functions are modularized so it is easy to work with.

For large projects RAD require highly skilled engineers in the team. Both end customer and developer should be committed to complete the system in a much abbreviated time frame. If commitment is lacking RAD will fail. RAD is based on Object Oriented approach and if it is difficult to modularize the project the RAD may not work well.

7. Prototype Model:

A prototype is a working model that is functionally equivalent to a component of the product.

In many instances the client only has a general view of what is expected from the software product. In such a scenario where there is an absence of detailed information regarding the input to the system, the processing needs and the output requirements, the prototyping model may be employed. This model reflects an attempt to increase the flexibility of the development process by allowing the client to interact and experiment with a working representation of the product. The developmental process only continues once the client is satisfied with the functioning of the prototype. At that stage the developer determines the specifications of the client’s real needs.

Software prototyping has many variants. However, all the methods are in some way based on two major types of prototyping: Throwaway Prototyping and Evolutionary Prototyping.

Throwaway prototyping:

Throwaway or Rapid Prototyping refers to the creation of a model that will eventually be discarded rather than becoming part of the finally delivered software. After preliminary requirements gathering is accomplished, a simple working model of the system is constructed to visually show the users what their requirements may look like when they are implemented into a finished system.

Rapid Prototyping involved creating a working model of various parts of the system at a very early stage, after a relatively short investigation. The method used in building it is usually quite informal, the most important factor being the speed with which the model is provided. The model then becomes the starting point from which users can re-examine their expectations and clarify their requirements. When this has been achieved, the prototype model is 'thrown away', and the system is formally developed based on the identified requirements.
The most obvious reason for using Throwaway Prototyping is that it can be done quickly. If the users can get quick feedback on their requirements, they may be able to refine them early in the development of the software. Making changes early in the development lifecycle is extremely cost effective since there is nothing at that point to redo. If a project is changed after a considerable work has been done then small changes could require large efforts to implement since software systems have many dependencies. Speed is crucial in implementing a throwaway prototype, since with a limited budget of time and money little can be expended on a prototype that will be discarded.

Another strength of Throwaway Prototyping is its ability to construct interfaces that the users can test. The user interface is what the user sees as the system, and by seeing it in front of them, it is much easier to grasp how the system will work.

…it is asserted that revolutionary rapid prototyping is a more effective manner in which to deal with user requirements-related issues, and therefore a greater enhancement to software productivity overall. Requirements can be identified, simulated, and tested far more quickly and cheaply when issues of evolvability, maintainability, and software structure are ignored. This, in turn, leads to the accurate specification of requirements, and the subsequent construction of a valid and usable system from the user's perspective via conventional software development models.
Prototypes can be classified according to the fidelity with which they resemble the actual product in terms of appearance, interaction and timing. One method of creating a low fidelity Throwaway Prototype is Paper Prototyping. The prototype is implemented using paper and pencil, and thus mimics the function of the actual product, but does not look at all like it. Another method to easily build high fidelity Throwaway Prototypes is to use a GUI Builder and create a click dummy, a prototype that looks like the goal system, but does not provide any functionality.

Not exactly the same as Throwaway Prototyping, but certainly in the same family, is the usage of storyboards, animatics or drawings. These are non-functional implementations but show how the system will look.

Evolutionary Prototyping:

Evolutionary Prototyping (also known as breadboard prototyping) is quite different from Throwaway Prototyping. The main goal when using Evolutionary Prototyping is to build a very robust prototype in a structured manner and constantly refine it. "The reason for this is that the Evolutionary prototype, when built, forms the heart of the new system, and the improvements and further requirements will be built

When developing a system using Evolutionary Prototyping, the system is continually refined and rebuilt.

"…evolutionary prototyping acknowledges that we do not understand all the requirements and builds only those that are well understood."
This technique allows the development team to add features, or make changes that couldn't be conceived during the requirements and design phase.

For a system to be useful, it must evolve through use in its intended operational environment. A product is never "done;" it is always maturing as the usage environment changes…we often try to define a system using our most familiar frame of reference---where we are now. We make assumptions about the way business will be conducted and the technology base on which the business will be implemented. A plan is enacted to develop the capability, and, sooner or later, something resembling the envisioned system is delivered.
Evolutionary Prototyping have an advantage over Throwaway Prototyping in that they are functional systems. Although they may not have all the features the users have planned, they may be used on an interim basis until the final system is delivered.

"It is not unusual within a prototyping environment for the user to put an initial prototype to practical use while waiting for a more developed version…The user may decide that a 'flawed' system is better than no system at all."
In Evolutionary Prototyping, developers can focus themselves to develop parts of the system that they understand instead of working on developing a whole system.

To minimize risk, the developer does not implement poorly understood features. The partial system is sent to customer sites. As users work with the system, they detect opportunities for new features and give requests for these features to developers. Developers then take these enhancement requests along with their own and use sound configuration-management practices to change the software-requirements specification, update the design, recode and retest.

Advantages:

There are many advantages to using prototyping in software development, some tangible some abstract.

Reduced time and costs: Prototyping can improve the quality of requirements and specifications provided to developers. Because changes cost exponentially more to implement as they are detected later in development, the early determination of what the user really wants can result in faster and less expensive software.

Improved and increased user involvement: Prototyping requires user involvement and allows them to see and interact with a prototype allowing them to provide better and more complete feedback and specifications. The presence of the prototype being examined by the user prevents many misunderstandings and miscommunications that occur when each side believe the other understands what they said. Since users know the problem domain better than anyone on the development team does, increased interaction can result in final product that has greater tangible and intangible quality. The final product is more likely to satisfy the users desire for look, feel and performance.

Disadvantages:

Using, or perhaps misusing, prototyping can also have disadvantages.

Insufficient analysis: The focus on a limited prototype can distract developers from properly analyzing the complete project. This can lead to overlooking better solutions, preparation of incomplete specifications or the conversion of limited prototypes into poorly engineered final projects that are hard to maintain. Further, since a prototype is limited in functionality it may not scale well if the prototype is used as the basis of a final deliverable, which may not be noticed if developers are too focused on building a prototype as a model.

User confusion of prototype and finished system: Users can begin to think that a prototype, intended to be thrown away, is actually a final system that merely needs to be finished or polished. (They are, for example, often unaware of the effort needed to add error-checking and security features which a prototype may not have.) This can lead them to expect the prototype to accurately model the performance of the final system when this is not the intent of the developers. Users can also become attached to features that were included in a prototype for consideration and then removed from the specification for a final system. If users are able to require all proposed features be included in the final system this can lead to feature creep.

Developer attachment to prototype: Developers can also become attached to prototypes they have spent a great deal of effort producing; this can lead to problems like attempting to convert a limited prototype into a final system when it does not have an appropriate underlying architecture. (This may suggest that throwaway prototyping, rather than evolutionary prototyping, should be used.)

Excessive development time of the prototype: A key property to prototyping is the fact that it is supposed to be done quickly. If the developers lose sight of this fact, they very well may try to develop a prototype that is too complex. When the prototype is thrown away the precisely developed requirements that it provides may not yield a sufficient increase in productivity to make up for the time spent developing the prototype. Users can become stuck in debates over details of the prototype, holding up the development team and delaying the final product.

Expense of implementing prototyping: the start up costs for building a development team focused on prototyping may be high. Many companies have development methodologies in place, and changing them can mean retraining, retooling, or both. Many companies tend to just jump into the prototyping without bothering to retrain their workers as much as they should.

A common problem with adopting prototyping technology is high expectations for productivity with insufficient effort behind the learning curve. In addition to training for the use of a prototyping technique, there is an often overlooked need for developing corporate and project specific underlying structure to support the technology. When this underlying structure is omitted, lower productivity can often result.

external Links :

Understanding Theory of Constraint has Helped Me in Effective Test Management

2010-01-08T04:50:00.002+05:30

Understanding Theory of Constraint has Helped Me in Effective Test Management

The popular theory of constraints proposed by Dr. Eliyahu M. Goldratt has always helped in doing effective test management. This post discusses the TOC in a nutshell and it application to management - be it Test management.

TOC originates from the idea that output of any system is limited by very small number of constraints. Constraints being anything that prevents the system from achieveing its goal.

Example 1: lets say that the at any given time 1000 vehicle can run on a highway per hour. From origin to destination if there were no constraints then the out of the system would be 1000.Now assume that there is a small tunnel on the highway and at any given time only 50 vehicle can pass through that tunnel per hour. Now What would be the out put of the system per hour? 1000? surely not and it would be merely 50 vehicle per hour reaching the destination.

The tunnel in above example is "Constraint" on the system. if we were to improve the efficiency of the system then the first thing that we would be doing is increase the throughput through this tunnel or simply bypass it.

Example 2: If there is an assembly line which has a capacity of producing 1000 engines but in some intermediate position we have recruited an unskilled labor who is churning out his parts far below the capacity what would happen? Wouldn't the following picture be true in this case? In our day to day terminology we call this as "bottlenecks".

TOC : is essentially the management philosophy of identifying all such conatrtaints and eliminating those so that the system achieve its goal.

Toc is base on the assumption that anyssystem can be measured and controlled by following three measures :

Throughput : The money generated through sales.
Operating expenses :The money incurred on Operations.
Inventory :The money invested into ensuring services.

having understood this very basic intriduction to TOC let me illustrate how has it helped me in effective test management.

For me and my system(The Testing Team and processes) our goal is to achieve maximum coverage of the application and to test the application thoroughly enough with optimum resources and allocated budget.

What is My Throughput : The Number of test cases executed per day and the number of defects logged per day.
What are my operating expenses: the day to day billing to the client and the cost incurred on my systems /softwares /electricity /the coomutation and a whole list of things incurred on employee.
What is my invetory : the costly KT sessions, the calls to understand the client requirement and the set of documentation produced for further references.

What are my constraints?

The continuous availability of test environment, the test build deployed.
The skilled manpower availability at all times.
The continuous availability of my Test Case management / Defect management systems. and the list goes on.

Where were I actually creating bottlenecks into my system knowingly or unknowlingly?

I am the only person who will review all the test cases / scripts. - though skilled here is a bottleneck created.
Testers are testing the application without much KT (Knowledge Transfer)being given to them? bottleneck, yes it is as i am not able to achive my goal - The more number of defects.
The people are testing effecively but the status reporting is taking good amout of time.bottleneck? yes it would be cause I making people slog.

How could the small subset of problem(among my gigantic) listed above were addressed later after analysing the constraints?

Have 2-3 resources who could comfortably make a pass1 of the review so that atleast the bottleneck is prevented.
KTs are essential and I should consider it as my operating expense. KT would ensure people understands the domian and the functinality.
For effective test reporting - I then followed the best practice of tempaltizing documents /mails and all the artificats so that people now needed only to fill in the blanks.

I essentially followed on till i eliminated most of the constraints in the system. be it related to equipment, people or policy.
Not stopping at this point i ensured that i have sufficient buffers in every place so that if at all it is not possible to eliminate a constraint i would see that i feed sufficient work continuouly at the constraint point. How?

See. I had this constraint that a firmware module be tested by only the experts.in any case is not possible for a manual functional tester. This being my contstraint the possibility of creating abottleneck here would mean that the functional testers would just not be able to get their feed of work.I Applied the buffer(additional resources) in my case.One might think that buffers would add on to my operating expenses, true it does in fact it did but using the small percentage of incremnet my goal was achieved much more effectively.Once this extra resource was on the roll i was able to do better resource levelling for other manual functional resources.

The above and many more examples can be cited.TOC has helped me to look into the management with a new perspective.
In testing we normally say that its cheaper to catch the defect in a software in its early stages otherwise the cost increases logarithmically. Now is it not good to think test management from cost perspective? the preventive,appraisal and failure costs? we do we do think in that mannner extend this further and ask yourself where is my maximum cost being incurred - in prevention? in appraisal or in failures? and there you could find out that the cost being incurred more is becuase of some kind of constraint in the system.

Think of eliminating this casue. probably by reaching its root cause you'd be on your way to achieve you GOALS.

Decision Analysis and Resolution (DAR) Process explained

2009-12-27T17:03:00.000+05:30

Decision Analysis and Resolution (DAR) Process

Introduction : DAR is a Process area in CMMI to aid systematic decision process.

Purpose : DAR is a Formal method of evaluation of key decisions for proposed solutions. Avoids reactionary decisions.DAR can be applied to any / all levels of decisions made within a project. Although its true that we can apply DAR to any decision making process still in practice it is limited to key decisions identified by the event triggers. Applying DAR to each and every decision may impede the
program's progress. Completed DAR worksheets will be stored in the approved program document repository according to the Configuration Management Plan.
What are these

What are Event Triggers : Event triggers are typically the criterion which call for formal evaluation process.
examples,

This Tool Versus That Tool for Automation.
Function Library versus Dll Approach.
Make/buy/reuse decisions
Significant architectural changes
Selection of third party solution providers
Selection of organizational tools
Modification of organizational processes

Roles: There are three roles involved in DAR

Decision Owner : One who is to ensure that the final decision is reached.
Decision Participant : One Who is involved in the DAR Process having necessary background and education on how DAR is conducted.
Decision Stakeholders : One who is likely to be affected by the decision.

The Process - Step 1

Solution Identification : One needs to identify a minimal set of solutions for a given problem. If the number of solutions is typically more that 4-5 then we need to apply appropriate elimination techniques and identify the best 4-5 solution.
The Solutions can be identified by various methods :

Brainstorming..
Quizzes.
Market Research.
Customer Feedback reports.
Expertise analysis and white papers.
Historical data if any.

example lets say we have identified Solutions A,B,C for this study.

The Process - Step 2

Evaluation Criteria : The Specific points against which the solutions will be weighed.For each criteria we shall assign a weight also called as coefficient. Coefficient will help us decide the importance of this criteria. Larger the coefficient more the criteria is important.

example

Evaluation Criteria	Coefficient
X	5
Y	3
Z	1

The Process - Step 3

Solution Evaluation :Evaluate each of the solutions for the established criterion and assign individual rank to the solutions. example
Solution A --> Criteria X --> rank 4
Solution A --> Criteria Y -->rank 3 and so on...
Note :- Higher the score the better is the solution for this specific criteria.

The Process - Step 4

Computation :
Once the solutions are ranked for each evaluation criteria, the total score for each solution is computed. The total score shall be the weighted summation of the evaluation criteria. A higher
score represents a better solution choice.The method used to compute the total score shall be:
Total Score = sum (rank x coefficient) for each evaluation criteria.
The following Table provides an example of evaluating 3 potential solutions A,B,C
suppliers using the coefficients from Table above

Evaluation Criteria	Coefficient	Solution A	Solution B	Solution C
X	5	4	3	2
Y	3	3	2	3
Z	1	2	2	1
Total		31	23	20

The Process - Step 5

Solution Selection :The solution with the highest total score shall be selected. In the
event of a tie between multiple solutions, the solution with thebest (highest) ranking for the most important evaluation criteria shall be selected.
In the example shown in table above, Solution A would be selected since it has the best (highest) Total Score.

What are the most common mistakes that new managers make when interacting with the team?

2009-12-20T16:35:00.001+05:30

Have you ever experienced that some managers are most popular among the team whereas others need to be forceful on the human resources?. I want to know expert opinions so that all the new managers can be benefited.
A Repost of Answers by Famous on Linked In

Steve Wickens, CMC, PMP, FCAM, BSAC, CSSGB, CCP, CICP, CB

Project & Risk Management | Systems & Process Analysis | Strategic Planning | Operational Management & Leadership

Says,
Some of the most common mistakes include:

- Failure to earn the confidence, respect and trust of your staff.
- Failure to manage and focus in on your objectives and workload.
- Failure to manage your relationships with subordinates, peers, and superiors.

Just because you have a new title and authority does not grant you automatic confidence, respect and trust. These things have to be earned. This means getting to know your staff, who they are, their strengths and weaknesses, and what motivates them. You must show them respect if you want respect. Treat people how you would expect to be treated if you were in there position. Take a few minutes everyday to say good morning and good night to your staff, and engage with them randomly. Don't be the guy perpetually working behind closed doors. Your staff need to feel that you are approachable to discuss issues. When they do, encourage them to show initiative and solve simple problems on their own, or to at least suggest possible solutions. The two most important words in your vocabulary as a new manager should be "Thank you".

In order to focus in on your objectives and workload, you need to build a strong team, and manage your time effectively. The moment you catch yourself saying or thinking that the most effective way to get work done is for you to do it yourself, close your door, and beat yourself across the head with a ruler. To succeed, you must learn to delegate. You cannot do it all yourself... there are not enough hours in the day. If your staff are that incompetent that they cannot be relied upon to handle simple tasks, then you have a much bigger problem. To be effective at delegation, you must assign specific tasks, to specific individuals, with specific deliverables, on specific dates. You must log these requests and follow-up. You must ensure the person being assigned the tasks clearly understands what is expected of them, and when the task is due. You must hold people accountable for their delivery of those delegated tasks, and keep records.

Communication must be clear and concise. But you must also periodically gauge whether there is understanding. Try to avoid office politics where possible until you understand how politics work, and how to control them. As a leader, you must be an example. How you treat others and relate to others will be noticed, and your staff will act accordingly. Above all, you must be very careful not to maintain personal friendships with subordinates. I'm told that in small companies this is not an issue, but in corporations it is a career killer. You must be seen as being objective, which is nearly impossible if you are known to be friends with one or more of your subordinates. You will always be under the microscope and open to accusations of favouritism if you do not keep a distance between your and your staff.

Never address performance issues with staff in public, and especially in front of their peers. Always do this behind closed doors, and keep notes of such discussions and events.

Remember that you are the most highly paid, and likely the most highly qualified individual in the department. Learn to plan your day (to the degree that this is possible), and how to manage your time effectively. (Take a time management course if you are unsure of what this means.)

These are the most common issues that trip up new managers, but with some careful planning, and attention, you'll quickly make the grade, and build that trusting and respectful relationship with your staff.

Best regards,

Steve

Kathy Klotz

Customer Experience Project Manager

Says,
The biggest mistake new managers make is not acknowledging that without the skillset of their team--they would not be able to be successful. The best managers have insight into the workings of their team and an understanding of the need for managerial support. Support means getting your team the tools, means or training needed to do the job at hand. A new manager should not be the one sitting back waiting for reports from the team; but rather be in the trenches with the team doing what it takes to motivate and drive the team forward. The most successful managers will make it clear to the team that they (the manager) is part of the team--not just a governing body.

Steven Wolff

Consultant: Team Development/Effectiveness, Leadership, Org. Change, Researcher, Statistician/Analyst, Survey Design

Says,

Linda Hill wrote a book called "Becoming a Manager" that studies this exact issue.

In my experience the biggest mistake is what I call "managing the Xerox machine." The new manager feels compelled to find all efficiencies and does things like create restrictions on people using the copy machine. In essence, the new manager is typically in the position because they are a good performer and have been successful at getting things done. They now have to realize they need to get things done through people and that there is a balance that needs to be struck between optimizing the task system and optimizing the social system. Managing the Xerox machine is an attempt to optimize the task system without concern for the social system.

Stephen Harvard Davis

Talent Integration and Team Productivity Expert

Says,

Research that we have undertaken shows that between 40 & 50% of ALL executives leave early, are dismissed or receive a poor performance review within eighteen months. Considering the cost of recruitment and potential lost opportunities any business experiencing a "new hire" falling into this statistic must be considered a failure.

Such failure is often despite a track record of success. Indeed, the appointment to a new job in management is always attributable to previous success.

There seems to be three common mistakes that organisations make when instructing a new hire. The first is failing to communicate the exact results that are required. Job descriptions provide an indication of the required results but success in a new job more often depends upon a boss’s assessment. New hires therefore, need to be told what constitutes a success in the boss’ eyes and how such success will be measured.

Giving a clear understanding of what success looks like can be achieved by holding a series of meetings with the new hire. These meetings need to be structured in order to provide the greatest amount of useful information. As such they are best undertaken as formal discussions as opposed to short conversations over the coffee machine. A mistake that a new hire will make is not to arrange for these meetings with a new boss.

The type of information that need to be given to a new hire includes:

· How has the current situation reached this point?
· What problems have been identified if the situation is not improved?
· What actions are expected from the new hire in the short and medium term?
· What would constitute success in the boss’ eyes?
· How and when will performance be measured?

The second mistake is failing to understand the boss’s management style. The new hire needs to ask the boss on the best way to communicate with the boss. Is this by email, report or verbally, and how often? What decisions the boss likes to make personally and what decisions are clearly delegated?

Other information that contributes to success for the new hire is what help the boss is prepared to give.
These include:

· Identifying the people with the most influence in the organisation?
· When and how these influence makers should be contacted?
· What support to plans and actions the boss will give?

A big mistake a new hire can make is to introduce systems and processes that have worked for them in the past without considering the new culture or the people affected. All change will have an affect on other people, particularly in other areas in the organisation, so prior to making changes it’s important to consider the consequences both upstream and downstream.

It’s also worth remembering that new hires are unlikely to positively affect the bottom line within their first few months. Yet in the new hire’s mind there is the need to prove oneself. This often gives the new hire a false sense of urgency that encourages the introduction of “quick wins”. However, the wrong “quick win” can permanently harm a new hire and point the individual towards the “Exit door”.

Quick wins need to focus on creating a reputation for problem solving that satisfies the boss, the team and other parts of the organisation. The boss should discourage changes that look good on the surface but which contribute nothing to profits or productivity. The “quick wins” to encourage are those that remove blockages or simplify a process.

Finally, in order to succeed a new hire needs information about the company, the people and the culture. Such information provides warnings of early mistakes that could create a negative opinion of a new hire in the minds of others. All this can be communicated by the new hire’s boss.

A boss can help a new hire avoid the three main errors, understand the new culture, network with colleagues early and thus significantly reduce the 40% risk of failure.

Linda Hardenstein, MPA, PCC

America’s Overwhelm Coach │Systems │Increased Performance │Successful Transitions Linda@HardensteinConsulting

Says,

I think the most common mistake is to believe that everyone operates the same way the manager does. I have found the best way to form a team, earn trust, avoid conflicts and enhance team communication is to do an assessment of the team that reveals everyone's communication and work styles. When I provide this type of assessment for the teams I have managed it enables team members to identify their strengths and the strenghts of others. As a manager of teams my main goals has been to enable team members to work to their strengths and it has always worked well.

Amit Gupta

Research Manager at Pipal Research,

Says,

Unless the new manager has been promoted from among the team, a new manager is well advised to understand either each or important persons, team dynamics and subtle underflows. Every effort in that direction allows the new managers to gauge competencies, establish equations and work towards developing trust. While managers will forever continue to be observed / scrutinized by his/her subordinates, this is particularly true for the initial period. Like it or not, first impressions matter and persist much longer that we’d like them to. And sometimes, there are no second chances. And this brings into play all of the management wisdom – from do unto others as you want done to you to living by example.

My 2 ¢. Hope this helps. Best, Amit.

Shailesh Wagh

Module Lead at Persistent Systems,

Says,

1.Taking team members granted for all decisions which managers take
2.Ego problems due to power & glamor of the position in the organisation
3.Managers thought that as they are managers so why to make their hands dirty by work when team actually needs solution from them
4.Carrying lot of assumptions about team members in mind
5.Some times too bossy....not understanding exact difference between delegation & dumping
6.Not involve deeply in project budgeting & less interaction with sales people

Mujahidin Zulkiffli

Contact Center Professional

Says,

Implementing radical change without proper change management process in-placed.

Azmil Abdul Aziz

Service Manager at Standard Chartered Bank

Says,

My mentor once told me "People are different, so treat them differently". I have kept this in mind till now. And this quote is very relevant to my answer. Put aside politics - Some people are manager because they would have (at one point of time in their career) proven themselves to be worthy of a promotion. In other words, they are good in what they do!

Sadly, some managers only knows or acknowledges ONE way of being good - THEIR WAY. Therefore, although with good intention, these managers tend to 'force' their way / believes / preferences / even 'brain waves' onto their people. To them - "I have walked this pathway before. All you have to do is follow my footprint & you will be successful too". So, the minute they see their subordinates do something different then what they did, they will be thinking that this person needs help and that a good 'spanking' would teach them a lesson or two to get them back onto the 'footprint'.

However, they forget that each individuals are very different. They are different right down to their genes and upbringing. They have very different dreams, different way of thinking, different way of doing things, different ambition, different preferences, different role models & different reason for living. AND THERE ARE multiple stairways to success, which allows us, as managers, to streamline these differences. But before we could streamline, we must first acknowledge these differences. Just because our way works for us and we became successful, that does not mean that if we force our way onto others, they would be successful too.

So, my advise to new managers - Start by understanding what is the objective you want to achieve and ensure that you and your team understands this clearly. It is alright to be strict by the book. Wrong is wrong, right is right!

But remember to work on those grey areas in managing a team. Learn to know when to let loose a bit & see where the flow goes - you'll be surprise that it may lead you & your team to miracles!!

James Bupp

Electrical Engineer at UTC Power,

Says,

Failure to listen to the team members; failure to ask the finial of the team.failure to ask the opinion of the team.
Many times a problem has been seen before, a solution is in place. A manager who fails to check for such things loses credibility very quickly.

Mike McRitchie

Director of Operations at RealCom Associates, LLC - Optimist, Synthesizer, Business Builder...

Says,

The biggest mistake is thinking they have to know it all.
This keeps them from opening up and getting ideas from their team.
The end result is the team underperforms because it is limited by the expertise of the lead manager.

Hector Erazo

California Retail Investigator,

Says,

I believe it is important to admit when you do not know the answer and rely on your team's experience. By levereging on other's strengths, the entire team has the opportunity to grow and develop rapport.

You Can always Checkback these answers at

http://www.linkedin.com/answers/management/labor-relations/MGM_LBR/602406-16632837

I Personally thank to all the people who took out precious time to post and answer.

Value averaging Investment Plan

2009-12-13T14:12:00.004+05:30

V.I.P in Investment

Value averaging Investment Plan
(Indian Context)

Most of the investors in the share market are aware of S.I.P(Systematic Investment Plan). They also know the merits of the SIP. Disciplined investment, good returns and very easy to invest. Recently the cancellation of entry load charges has almost nullified the investment charges in SIP.

Although the fact that SIP is giving good returns but there is ample of scope for improvement in the SIP's process of investment as per the experts. Actually speaking owing to the fact that investor invests a fixed amount in SIP per month it lacks flexibility. Whether the market is going up or down a fixed amount is always invested. In a nutshell we cannot match our timing with the share market to take advantage of share markets ups and downs. Probably that is the reason why some people also call SIP as lazyman's farming.

When the Market is up and the NAV(Nett Asset Value) of the mutual fund is dearer then the monthly investment in SIP should reduce and when the NAV is cheaper the the investment should be more so that you purchase more units.If this happens then you get more value for your investment in the market.

Exactly the same principle explained above is applied to the improved SIP called "Value Averaging Investment(VIP)". VIP as a concept was proposed by Proff. Michael Edelson from Harvard university and developed further. According to Edelson to improve investor's portfolio only continuity in investment does not suffice rather with continuity the timing of the market should also be matched. With VIP one should get all the advantages of SIP but he should also be matching the timing in the market. VIP is very popular in other countries but now its also available in India.

Some Salient points of VIP.

Fixed monthly investment same like SIP.
Investment on a fixed date of month.
Whenever NAV goes up then the monthly investment will lower and vice-versa.
It is quite likely that when the NAV is quite high then zero investment is made.
The Investor has to decide the 'maximum debit' which he can invest in a particular month. e.g. if the investor opts for a monthly investment of Rs. 5000 /month and his maximum debit is Rs. 10000/- then in a given month the investment can range from 0-10000.

The following table depicts the advantages of investment in VIP.

Month	Fund NAV	VIP		SIP
Month	Fund NAV	Investment	No. Of Units	Investment	No. Of Units
Jan	10	2000	200	2000	200
Feb	15	1500	100	2000	133.33
Mar	20	0	0	2000	100
Apr	15	1500	100	2000	133.33
May	6	6000	1000	2000	333.33
June	3	6000	2000	2000	666.67
Total		17000	3400	12000	1566.66

Though the above table shows that both the investments looks good calculating the average cost of Unit we find:
investment in VIP : Average cost per unit=Rs.5 i.e. 17000 /3400 and
investment in SIP : Average cost per unit=7.66 i.e.12000/1566.66

VIP is new in India and benchmark company has launched its 'S & P CNX 500 Fund' www.benchmarkfunds.com

Suggested Reading Further :Value averaging

Zillions Of Thanks To All Who Recommended Me

2009-12-10T01:15:00.009+05:30

Zillions of thanks to all who have recommended me

Recommendations Written for me.

=======================================================================

QA Manager

Persistent Systems Ltd.

“It’s my pleasure working with Abhijeet; he is one of best manager I ever seen in my career. He encourages individuals as well as team from all professional aspects. He is very effective and always has full support of his team. Abhijeet has through understanding of automation as well as manual testing, engineering processes and methodologies coupled with his effective communications skills. He is very good as a person and I always wish to work with him.” November 18, 2009
Kamlesh Jaware, Senior Software Engineer, Persistent Systems

reported to Abhijeet at Persistent Systems Ltd.

“Abhijeet is a great leader and honest person. His knowledge in software industry is mind blowing and he’s pro in automation testing (be it any tool or language). He leads by example. He encourages for individual development from all professional aspects. He taught me many skills and tactics in software testing. He is very helpful as well as critical whenever appropriate; this helped me a lot while executing project together and delivering quality products on time. He is a very good person and great motivator.” November 17, 2009
Avinash Kalambe, Module Lead, Persistent Systems

reported to Abhijeet at Persistent Systems Ltd.

“Abhijeet possesses strong UI/QA Automation skills and .NET skills. He has good working experience and he is working in one of the Best Project (iDeal) at Persistent. He is hard working and quite famous in his Team. People love to get advice from him. All the best Abhijeet.” August 23, 2009
Nasir Khan, Sr. Team Lead, Persistent System, Pune

worked with Abhijeet at Persistent Systems Ltd.

“I know Abhijit since three years or more. He is very good at leading a team and handling team members. He has in-depth knowledge in testing and possesses great testing skills. Product quality has been of paramount importance for him. I have seen him always persuing knowledge about all technologies that are directly/indirectly related to his skills and he always looks at improving himself. I found Abhijit very hard working and follower of quality goals and processes of the company. I wish Abhijit all the best in his future endeavours.” August 11, 2009
Mahesh Deshpande, Module Lead, Persistent Systems Ltd.

worked directly with Abhijeet at Persistent Systems Ltd.

“Like all the fellow employees at Persistent Abhijeet took keep interest in his work and continuous learning. He has been a great indivisual to be a friend. I felt I could safely depend on his capacities and cooperation.” August 10, 2009

Kaustubh Bhadbhade, Manager - Human Resources, Persistent Systems Ltd

worked with Abhijeet at Persistent Systems Ltd.

“Abhijeet leads the team by setting up right examples. He does the things by his virtue and believes in creating leaders instead of creating team members.” August 9, 2009

Girish Hasabnis, Information Developer, Persistent Systems Ltd.

worked directly with Abhijeet at Persistent Systems Ltd.

“Abhijeet is a hard working diligent individual who added great value to our project while he lead our QA Automation effort for IPREO. Abhijeet is a dedicated resource with only one goal in mind to provide the best service and quality of testing for our products.” July 20, 2009

Top qualities: Great Results, Expert, High Integrity
David Sener

hired Abhijeet as a IT Consultant in 2005

Module Lead

Persistent Systems Ltd.

“I consider Abhijeet to be a highly successful person, who is competent in nature. He is very driven and has a very analytical mind which makes him excellent at understanding the problem before finding a fast, effective resolution. Abhijeet was extremely professional and responsive, and dealt with issues in a structured and controlled manner. I would very happily recommend Abhijeet, who demonstrates high personal standards, and inspires the confidence of his clients. He is a fantastically motivated person that always has a positive outlook and intelligently approaches and solves problems. Working with him was an extremely enjoyable and enlightening experience. I can safely recommend Abhijeet to anyone in the business/Software community.” June 22, 2009
Mahesh Vanamala, Software Engineer QE, Persistent Systems Limited

reported to Abhijeet at Persistent Systems Ltd.

“Abhijit is an excellant Automation Lead/Tester. He has goood anlaytical skills, communication skills and is very enthusiastic and emotional about his work. He is a an excellant asset to have if you want to manage automation testing for your project” June 2, 2008

Vikram Puranik, Senior Project Manager, Persistent Systems Ltd

managed Abhijeet at Persistent Systems Ltd.

“Abhijeet is a very hard worker, who is able to grasp difficult concepts quickly. He has excellent management skills and comminucates well with his team and other managers. Consistently met his deliverables and ensured his efforts were in line with the company's objectives. Lastly I want to say "he is technically vertical in software test automation development".” April 18, 2008

Vijay Motagi, PSL Pune India, Persistent System Limited

reported to Abhijeet at Persistent Systems Ltd.

Quality Assuarance Engineer

Geometric Software

“Abhijeet is one of the most harworking person I worked with. He has amzing brains to find solutions to the complex problems with the easiet and simplest ways possible.” September 19, 2008
Joseph Cutler, Software Engineer, Geometric Software Solutions Co. Ltd.

worked with Abhijeet at Geometric Software

“Abhijeet is a very innovative person. He's a man of ideas and envisioned a very handy tool to enhance productivity of the test team. His understanding of the end-User's requirements and the test team's requirements was crystal clear. Abhijeet has carried enormous goodwill from the QA team, as he gelled well with the Development team to get the solution implemented. It was a pleasure working with Abhijeet.” April 21, 2008

Sudipto Pa ul, QA Lead, Geometric

managed Abhijeet indirectly at Geometric Software

Software Test Engineer

Expert NetCAD Solutions

“Worked for a small duration with Abhijeet, but in that span of time he reflected many colours of his inteligence and dedication towards work. A very focused person to say, where his consistancy and hardwork, always sights him apart from other.” May 6, 2008
Amol Chaphekar, Sr. Executive - Global Business Development, Expert NetCAD Solutions

worked directly with Abhijeet at Expert NetCAD Solutions

Software Test Engineer

Veritek Solutions

“Working with Abhijeet was a great experience technically as well as personally. His sound technical knowledge helped many of our projects to acheive 100% ecpected metrics. Appreciate his approach towards the work especially doing etiology and finding root cause of the of every problem.” June 14, 2008
Amol Peshwe, Consultant, Tech Mahindra Ameraicas Inc

worked directly with Abhijeet at Veritek Solutions

Additional Information

Websites

Interests

Net Surf Learning New Test Tools

Groups and Associations

TestPartner Users, QA Automation Architecht

Honors and Awards

1. Spot Award in Persistent Systems for Utilizing Automation tool for Load testing. 2. Recognition in Geometric solutions for building a Tool to create flow in TestDirector TM 8.0 3. Percentile score of 100% in Subjective QE Automation Assessment exam in Persistent Systems

WinRunner vs QTP and BackGUI

2009-12-09T02:50:00.002+05:30

WR vs. QTP and BackGUI Perspective

I think the difference is in the philosophy of make of tools While Its easy to say WR doesn’t support This whereas QTP Supports that or vice versa Lets add a Simple Keyword there.. "The Tool Has inbuilt support"

Coz I am yet to see Why WR cannot do anything that's possible with QTP all is the matter of knowing Windows API, Its implementation and if you also know the MSAA (Microsoft Accessibility Framework) then even with WR you can archive same things that QTP can do.

However here are the key highlighters

WR: The Script is Proprietary called TSL

QTP: The Script is VBS

WR: Complete Procedural Code

QTP: Procedural Code but ability to define Classes with no INHERITANCE that's basic of VBS

WR: No Direct support for XML but can be implemented using MSXML API

QTP : Some elemetantary XML Chekpoints can be added to the script.

WR : Very Good Support for Win32 API

QTP : Win32 API support as supported by vbs

WR : Features good when u have a flavor for C

QTP : Feature good when u have a falvor for VBScript

WR: Learning curve is big

QTP : Learning curve is shorter

WR : External Libraries needs to be referenced through codes like "LoadLibrary"

QTP: Relies on Latebinding throug vbs e.g. CreateObject

Both are equally ok in file Handling

WR : Inbuilt File handling Routine

QTP relies on FIleSystem Object

WR : Well Defined Datatypes

QTP : Everything is a Variant even object is variant

WR : Images can be compared only with Check Points

QTP : though has Image aCheckpoints we can still compare bitmaps pixel by pixel through ReadFile

One Thing To say Both The tools lack design time object browsers like one we have in Visual Studios.

Probably that's the reason IMHO that people are moving away from these so called powerful tools to more .Net Framewrok based tools like Ranorex, TestPartner where u have more design time control and do not have to rely on the inbuilt libraries only.

People I am taking about controls Like Exceed Grids, Component One Controls, Flex, Ajax, Oracle Forms.

Do understand that Tools can never Cope up with the pace of development of technology. so What is good?

Keep Following tools versions after versions or move to tools that are build on the technology that was used for development?

Point is left to you!!!!

But to Stress again

Did you know that Microsoft is pushing the new Accessbility Objects to Limits.

Did you Know that With .net Framework 33.0 onwards Microsoft has started providing UIAutomation name space?

Did you know that people have started using VSTS and VS 2008 to automate already? be it web based or Desktop application.

This is the era of tools called "BackGUI" where you hold your objects from Backend and take action on front end. I know its not true GUI testing but whats the objective? TO TEST and TO TEST THE FUNCTIONALITY BackGUI Approach is finding more defects.

Please Leave Your Comments: While My Research is always on to help You I would like to hear from you.

Introduction To Scrum

2009-11-29T19:46:00.001+05:30

An Introduction to Scrum

Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time.
It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month).
The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features.
Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint.

Characteristics :

Self-organizing teams
Product progresses in a series of month-long “sprints”
Requirements are captured as items in a list of “product backlog”
No specific engineering practices prescribed
Uses generative rules to create an agile environment for delivering projects
One of the “agile processes”

Sprints :

Scrum projects make progress in a series of “sprints”
Analogous to Extreme Programming iterations
Typical duration is 2–4 weeks or a calendar month at most
A constant duration leads to a better rhythm
Product is designed, coded, and tested during the sprint

The Scrum Framework :

Roles

Product owner
ScrumMaster
Team

Ceremonies

Sprint planning
Sprint review
Sprint retrospective
Daily scrum meeting

Artifacts

Product backlog
Sprint backlog
Burndown charts

Let's Discuss the Three Roles :

Product Owner :

Define the features of the product
Decide on release date and content
Be responsible for the profitability of the product (ROI)
Prioritize features according to market value
Adjust features and priority every iteration, as needed
Accept or reject work results

The Scrum Master :

Represents management to the project
Responsible for enacting Scrum values and practices
Removes impediments
Ensure that the team is fully functional and productive
Enable close cooperation across all roles and functions
Shield the team from external interferences

The Team :

Typically 5-9 people
Cross-functional:
Programmers, testers, user experience designers, etc.
Members should be full-time
May be exceptions (e.g., database administrator)
Teams are self-organizing
Ideally, no titles but rarely a possibility
Membership should change only between sprints

Let's Discuss the Ceremonies :

Sprint Planning :

Team selects items from the product backlog they can commit to completing
Sprint backlog is created
Tasks are identified and each is estimated (1-16 hours)
Collaboratively, not done alone by the ScrumMaster
High-level design is considered

The Daily Scrum :

Held Daily
15-minutes
Stand-up
Not for problem solving

Whole world is invited
Only team members, ScrumMaster, product owner, can talk

Helps avoid other unnecessary meetings

Each Team Member answers 3 Questions :

What did you do yesterday?
What will you do today?
Is anything in your way?

The Sprint Review :

Team presents what it accomplished during the sprint
Typically takes the form of a demo of new features or underlying architecture
Informal
2-hour prep time rule
No slides
Whole team participates
Invite the world

Sprint retrospective :

Periodically take a look at what is and is not working
Typically 15–30 minutes
Done after every sprint
Whole team participates
ScrumMaster
Product owner
Team
Possibly customers and others

Let's Discuss the Artifacts:

The Product Backlog:

The requirements
A list of all desired work on the project
Ideally expressed such that each item has value to the users or customers of the product
Prioritized by the product owner
Reprioritized at the start of each sprint

Managing the sprint backlog

Sprint Goal : A short statement of what the work will be focused on during the sprintIndividuals sign up for work of their own choosing

Work is never assigned
Estimated work remaining is updated daily
Any team member can add, delete or change the sprint backlog
Work for the sprint emerges
If work is unclear, define a sprint backlog item with a larger amount of time and break it down later
Update work remaining as more becomes known

Srum is used by :

Microsoft
Yahoo
Google
Electronic Arts
Lockheed Martin
Philips
Siemens
Nokia
IBM
Capital One
BBC
Intuit
Nielsen Media
First American Real Estate
BMC Software
Ipswitch
John Deere
Lexis Nexis
Sabre
Salesforce.com
Time Warner
Turner Broadcasting
Oce

Lines Of Code - KLOC - Issues in Estimation

2009-11-26T19:29:00.002+05:30

Lines Of Code - KLOC - Issues in Estimation

We have seen that KLOC being used as a measure to generate good number of Metrics Like Defect Density.

Since the measure is such a popular measure hence I wanted to understand if everyone in the industry has a common definition of LOC or does the definition change with the frame of reference. Astonishingly i found that different people or different organistaions have different meaning / interpretation fo Lines of Code and this necessarily means - Different perspectives, Different Judgements, and less computation.

Less Computation means Lot of gut feel and gut feel means you are introducing errors into the estimate calculations and what a disaster would it be if the tolerence of the error is as good as +-30%.

Do you get me where i am coming from? We have experienced this in our practical life as a testers and quality engineers. If we cannot estimate Size how can the relative metrics be relied upon? that too at a range of +-30% tolerance?

Well then, What could give me a correct measure of size of my module, component, software!!! haan?
I researched and researched till i came across IFPUG{International Function Point Users Group} FAQs

Let me quote IFPUG verbatim as below :
"

Why shouldn’t I use lines of code?
Lines of code tend to reward profligate design and penalize concise design.
There is no industry standards (ISO or otherwise) for lines of code.
Lines of code cannot be used for normalizing across platform, language or by organization.
Some 4GL don’t even use lines of code.
Lines of code can be positively misleading – refer to Capers Jones Productivity Paradox.
What about backfiring?
Backfiring is based on lines of code, so you run into the same difficulties as using lines of code.
It can be used cautiously on legacy systems without much prospect of further work.
Backfiring could be useful if accuracy is not an issue. "

Owing to the ambiguity of the definition we need a definite and computational model to measure the size and not the judgemental measure. I found the answer to be FPs or Function Points.

Function Points and Use Case points are the most effective means to measure the size of something intangible like a piece of software.

Since FPA[Function Point Analysis] relies on fundamentals like breaking the software to its elementary processes and elementary data transactions and then start counting /computing above its more COMPUTATIONAL in nature.

Discussing the entire FPA is beyond the scope of this article though i would like to leave some Start points to the people for whom the above paragraph did not made anysense.

Pointers :

To measure something we need more computation and not judgement.
Judgement is error prone.
FPA breaks any software into very elementary process and Data Transactions.

For any software there are only five of the following happening...

Input
Output
Query( Different From Output - i.e here the data is not altered you may call this as a simple SQL Query just to understand )
Internal Data Files modification
External Data Files modification

If we know that any software is mere a compbination of above 5 processes then break down each peice of software in above manner and calculate the FPs
Please note that FP is just like any other unit for e.g. Hours
Hence we can talk of SIZE of software in terms of number of function points
Apart for the Extra bias added to the Numeber of Function Points Function Points is the best measue to calculate the size.

Nonetheless FPA is very detailed procedure and should be applied only to projects of large size and not to small POC kinds of projects of duration of 1 week to 15 Days.

FPA being very detailed in nature demands time and resources for estimation so for quick estimations our good'ol KLOC seems to be okay.

What to use when is left to users's need or accuracy!.

All You Ever Wanted To Know About Defect Density

2009-11-26T03:28:00.000+05:30

All You Ever Wanted To Know About Defect Density

Defect Density Defined :

The ratio of the number of defects to program length.
defect density is the count of total defects identified against a particular software entity.
Defect density is a measure of the total known defects divided by the size of the software entity being measured.

The Formula : Number of Known Defects / Size
Where - The Number of Known Defects is the count of total defects identified against a particular
software entity, during a particular time period.
Examples - Defects Found In Software Module Till Date + Defects Found During Tesing + Defects Found During Alpha and Beta Testing+ Defects Found at Customer Site(Production)

Size of the Software entity is typically measured in 1000 Lines of Code(Also Called KLOC) or Number of Function Points.

What is the use of this metric? : The Sofware Defect Density serves as a Comparator between different modules so that the testing task force can be alligned or optimized to foucs on critical few modules therby resulting in better utilization of time and money -- They Call it as ROI(Return on Investment).
Also the metric can be used to perform a release /iteration /sprint wise comparision of quality efforts only to see if the quality norms are being implemented.

There is a lot of debate in the area of what should be considered as appropriate size? Function Points of KLOCs.
There is another school of thought on use of KLOC that is usualy it is found that only few lines in the code are changed and other lines are untouched owing to the fact that being legacy code.
In this perspective changed Defect density would be another useful metric where current changes are being introduced.So that we can come to know if the changes are impacting the Densities.

Changed Defect Density can also be calculated as Number of Defects per Code churns. Remember Code churns are the changes in the code from one version to another.

Recommended References :

Relative Defect Density Mesaures : http://research.microsoft.com/pubs/69126/icse05churn.pdf
Estimating Defect Density : http://www.cs.colostate.edu/TechReports/Reports/1998/tr98-104.pdf

The FarmVille Challenge

2009-11-24T02:17:00.004+05:30

Much have been written about FarmVille and Millions of Blogs have been written about FarmVille.
Now take this challenge and Show'em that you are a Pro FarmViller.

Quizzes by Quibblo.com

Short Selling and Stop Loss Orders

2009-11-21T19:56:00.088+05:30

Short Selling and Stop Loss Orders

Let's understand...

Short Selling and Stop Loss Stock Orders

Recently there has been an exponential growth in the stock market awareness. There are certain words that are constantly bothering new investors 'Short Selling' and 'Stop Loss' or 'Stop Loss Orders' being among them. Since I saw many queries being posted on various blogs, portals etc. This article is an attempt to explain these terms in an easy to understand manner with animated presentation.

If you are...

New to 'Stock Market'
Have a feeling that stock market is a gamble.

Then... this article is not for you.

Before proceeding further I highly recommend that you grasp the Basics of Stock Market.

References :

Further... What is Short Selling

Still with me? Okay let's proceed then.The 2 terms Stop Loss Orders and Short Selling being related to each other in some way hence I have chosen to write on these two terms.

Short Selling :

Short selling is a concept where in you sell stocks that you do not own. I SELL STOCKS THAT I DO NOT OWN? yes you read that right. This is very much possible with the account with your broker where the broker lends you some stocks for a limited period of time.Such accounts are called Margin accounts.

Why would a person do Short Selling? Well to earn from falling market, EARN FROM FALLING MARKET? yes you read that right again..See the presentation.

Stop Loss Orders are executed in following 2 situations:

BUY and SELL
SELL and BUY

BUY and SELL situation :

You anticipate market may go up
X Co. is trading at 100
You place a Limit order of 105
if everything works okay your order may execute at 105 and you earn a profit of 5%
Your order was executed and everything looked okay
BUT...
if market starts falling .... what do you do?
You issue a Stop Loss order of 103 with a Trigger price of 104
The moment Trigger Price of 104 is reached your order becomes a normal Limit order and is likely to sale at 103

So you have limited your losses in above case.
SELL and BUY situation :

You anticipate market may go down
You short on X Co Shares which is say trading at 100 now
i.e. You sell the shares at 100
You are supposed to return back the shares to broker since you have short sold the Shares
since you anticipated that market may go down you'd buy the shares at 95 and gain 5%
Instead!!! market started climbing up... now what????
You issue a stop loss order with Limit of 101 and trigger of 101.1
The moment 101.1 price is reached the order become a normal Limit order and you'd buy the shares at 101
hence you again limit your losses.

Software Testing And Certifications

2009-11-18T20:38:00.002+05:30

With the rising number of people appearing for software certifications and while the certifications may give a definite advantage it has become a business of few.

Assess your certification needs and have a clear path in mind or else all you'll end up into is losing hard earned money and precious time.

Type "Software Testing Certification" in google and you are bound to get 2.5 million searches all pointing to Software Testing certifications. Before taking any certification lets try and understand why get Certified?

Why get Certified at all?

Certification can lead to better visibility, opportunities, and jobs. In today's increasingly complex and highly-specialized economy, credentials are everything. Sure, you know you've got the skills to do the job, but how do you convince potential customers and employers? For many career-minded professionals, certification is often the answer.

For some entomologists, it is recognized as a valuable way to prove professional credentials to non-entomologists and the general public. For others, the topic can generate a puzzled response. Why become certified? Isn't a college degree and/or years of practical hands-on experience enough to establish one's credentials? Either response of yes or no is correct, depending on your clientele and colleagues.

Consider the doctor, plumber, architect, lawyer, or building inspector ... These are all professionals just like you. They have been educated in their craft. They have spent years working in the field, and in some cases, earning their degrees, but credentialing is an important and recognized part of their career.

When to think of certification

When you are working in a highly competitive industry.
You need to stand out of crowd when applying for jobs.
When your employer demands.
Your field demands keeping up the license that you get after doing certification.

Does Software Testing or Software Test Automation fit in any of the above criteria?

Well, Surely it does!!!. Software Testing and Software test automation is a challenging field and people often need to prove their competence by doing certification and also often the employer or Client demand the proof of competence.

This calls for going ahead with the certification for sure. and this is many peoples start point of confusion or cul-de-sac for not going for certifications.

Think Before You Apply!!!!

Analyze your Certification Needs: The general thumb rule here is decide what you want to become 5 years down the line.Not Decided? Well its time that you start planning your carrer then.Let me give you an example of Analyzing Need. Lets say Mary joined the Testing industry as a fresher. She lives with room mates who are apprearing for CCNA certification. Mary thinks that this is a good opportunity and joins the classes. Eventually Mary finds that the certification has got nothing to offer her from long term career perspective and nor she is interested in networking. So what i would suggest is that if you are not sure take your time. I would suggest a Generice Certification or foundation level certification in case you are still not sure.
Choose Right Certification: Choose a certification that is going to offer value both in terms of your current duties and long term. Most often once the decision is made that people need to remain of manual testing jobs then they'll go for a more higher certification like CSTE,CSQA,ISTQB-Advanced ect. These certification will not be able to help you 100% at your floor but you gain a sense of confidence like "i kow my industry"

How About Automation?: Well in my view rather than doing a product(Tool) Certification i would suggest do a generic language certification something like VBA,VBScript, Perl etc.
The tools grow in versions and you may not be able to keep up with the pace and eventually you give up.
Note: - The above 2 points assume that you do not intend to become a tool specialist. Incase you do wish then the above 2 points are not valid for you.

Is there any Certification path that i Should follow?

Many people have asked me this question and my answer is definitely yes to it.

Generic Testing Certification
Database Certification
One Product Tool Certification at maximum
Domain Certification(s)
Specialization Certifications

Let me explain the above mentioned path to you.

Do a generic testing certification even if you wish to pursue Automation /Security /Database Testing Career. It is very well recommended because afterall you'll still be belonging to a fraternity called Software TESTING.
A Database is integral part of Software Testers Life and looking at the growing need of techno functional testers in the industry understanding and grasping DB is must.Go for Oracle Certified Associate or SQL Server Database Certification.
If you wish go for one Tool certification that you wish to be expert in.
Eventually as you grow towards senior management then the need for understanding domain increases and thats precisely the point where you should start thinking of domain certifications viz. Banking, Insurance, Finance, Capital Markets, SCM etc.
If you are a techno savvy and want to pursue a sepcialized Testing career namely security Testing, network testing, Database testing then plan well in advance for certificates like CCNA,A+,Advance DB Certifications Like Oracle Certified Professional. ect.

Some Recommendations[Dos /Donts]

Once you are certified as a Testers there is little point in re-appearing for the same certification once it expires.
Get yourself certified on one Database.
Do Not keep upgrading your Tools /product Certifications unless you intend to become specialist in that tool.

Getting certified should be a journey of joy and learning.

Getting Right Certification on Right Time is the key to your successfull professional growth.

Enjoy your certification. Apply in practice.

Marathi Graffiti

2009-11-18T04:47:00.009+05:30

मराठी ग्राफ्फितिंचा संग्रह.

खुबीने तयार केलेल्या ग्राफ्फितिन्ना संग्रहित करण्याचा व त्या कलाकारांना(ग्राफ्फितिकारान्ना) दाद देण्याचा हां माझा प्रामाणिक प्रयत्न.

Enjoy Marathi Graffiti