How to Setup an Automated Reminder in Tick Spot

Misplaced my timesheet

Timesheet is a mandatory implementation in every organization and implementation of timesheets definitely helps in reducing the frequency of disputes between employees and supervisors/employers. It is also a very effective way to track cost, making business accounting more accurate and error free.

Incomplete timesheets slow down our business. Employees spend longer trying to recall their jobs and hours, managers spend time chasing down incomplete timesheets, and accounting gets delayed. I understand your problems, and that is why I came up with this technique for setting up the automatic reminder feature in Tick Spot to complete timesheets on time. Follow some simple steps to set it up on your PC/Laptops.In one of my projects at Zen Test Labs, I implemented the automated timesheet reminder in Tick Spot. This helped not only the individuals working on the project, but also helped business in making correct effort calculations.

Setting up an Automated Reminder in Tick Spot:  

Every evening (you can specify your EOD), your browser opens up with the Tick Spot login screen.

Step 1

  • Create “timesheet.bat”
  • Open Notepad and type the following:
    • echo off
    • start /max iexplore.exe
  • Save the file as “timesheet.bat”

Step 2

Copy the file “timesheet.bat” to your preferred location

Step 3

Open the Run window and type “Task Scheduler”

Task Scheduler

Step 4: Add Batch Action

Select the Action tab, Click on “New”

Add Batch Action

Step 5: Add Batch File

To add the batch file, click “Browse” and select “timesheet.bat” from the stored location

Add Batch File

Step 6: Setup Trigger

To add Trigger tab and follow 5, 6, 7 & 8 actions

Click “New” –> Add the “Daily” radio button –> Add time –>Check “Enable” Check Box –> Click “OK”

Setup Trigger

Your automated reminder has been setup! The great thing about this feature is that it does not require any manual intervention and causes no overhead on system resources. You can extend this technique to other reminders too.

Mukund Wangikar | Zen Test Labs

Building a Test Centre of Excellence: Experiences, Insights and Failures

As organizations mature in their Testing Processes, the perennial quest to achieve ultimate excellence has led them towards attempts to establish the “Test Centre of Excellence” better known as TCoE. Many such initiatives have been plagued with issues ranging from partial implementations to complete abandonment midway. Additionally, most TCoE initiatives find heavy resistance and inertia within teams as it is perceived as a threat to their independence and way of doing things.

At the heart of some of these issues lies poor alignment to business goals, poor ROI analysis prior to investing, poor communication and incorrect choice of models to centralize amongst many others. Drawing from their experience of consulting with organizations on TCoE initiatives and building one for their own, Krishna and Mukesh have written a whitepaper to share insights, experiences and lessons learnt from both successes and failures.

Download the whitepaper to learn how to go about creating your own TCoE while overcoming the common and not so common challenges you will face along the way. Draw on their experience to troubleshoot some of your unique problems.

Communication- A Key Skill to Excel at Testing

Enabling better communication is not a onetime activity. It requires continuous effort across the company. Good internal and external communication is extremely important to a business’s success. In order to work together effectively, there must be clear and coherent communication among all the departments.

Here are a few scenarios wherein communication gaps may arise and lead to poor quality:

1. Continuously Changing Requirements:
At times, requirement changes are implemented directly without updating the specification document. In such cases, there is a chance that the changed requirements remain untested or are tested incorrectly.
Any change in the requirements should be communicated correctly to all stake holders and it is necessary to update the specification document on a timely basis.

2. Configurations:
Lack of clarity from the stakeholders on the configurations to be tested can lead to wasted effort and extra work. Configuration testing can be expensive and time consuming. Investment in hardware and software is required to test the different permutations and combinations. There is also the cost of test execution, test reporting and managing the infrastructure.
Increasing communication between development, QA and stakeholders can help deal with these challenges.

3. Team Size:
When team sizes are large, some members of the team may miss changes in requirements or may not be communicated updates on activities in the project. This could lead to severe problems in the project or project failure.  Each team member should be abreast of the activities in the project through a log or through other means.

4. Changes in  Application Behavior not Communicated:
Continuous changes in the application behavior may lead to requirements being tested incorrectly.  All the functionality implemented in the application should be frozen while testing. If any changes are made to the functionality, they should be communicated to the testing team on a timely basis.

5. Unclear Requirements:
Complex requirements that contain insufficient data may be difficult to understand and therefore, may lead to improper testing. The functional/technical specification documents should be clear and easy to understand; they should contain a glossary, screenshots and examples wherever necessary.

The path to project success is through ensuring that small communication problems are eliminated completely before they build up, so that the message is delivered correctly and completely. Instead of discovering problems, we should figure out how to stop them from appearing in the first place.

Poonam Rathi | Test Consultant | Zen Test Labs

Developer + Tester = 1?

Recently I attended a software testing conference where the main focus of discussion revolved around future of testing and how innovation can be ingrained more in testing!

The speakers included Randy Rice, Michael Bolton and Lee Copeland. When asked about the future of testing, and each one said that it was a too dangerous to predict. They realized that when they were asked this question ten years back, their predictions failed thoroughly J  Quoting Neils Bohr “Prediction is very difficult, especially if it’s about the future”.
A common point said by each was that it would be more complex and besides functional testing, security testing would be a major game.

One of the intriguing points I found was in order to enhance creativity,asking the developer to also play tester. I think it is a recipe for disaster to expect a developer to test his baby.

The reasons why the developer and the tester should be different are:

–          The developer works  on building a particular module but the tester has to think of the integrating that part as well, thus varying  the scope and efficiency expected from the tester and the developer

–          The creative process of a developer works on a structured constructing process, where as a tester proves his creativity by breaking the barriers and rules

–          A developer is entitled only to the code and does not work with the mindset of looking for failures, where as a tester whether access to code or no code works towards digging failures

–          However, when a new Functional Specification Document or a Business Specification Document is acquired, the tester and the developer can start working simultaneously, by adopting Agile more productivity and efficiency is attained over a limited period of time.

If I must combine the role of a tester and a developer, then

A developer can enhance his productivity by unit testing, if there is an error in the code it is easier found by the developer rather than a separate tester who might or might not have the knowledge of that technology/language.He can also build by thinking of end to end business flows.

A tester can wear the developer’s shoes by building automated scripts and applying Oops concepts in his test cases.

I believe this would also add in enhancing the innovation in testing! These are my views acquired over dedicating a period of time in testing, Would be great to know yours?

Poonam Rathi |Test Consultant | ZenTest Labs

Automation lessons learnt: Funding automation projects & the role of change management

One of the many reasons test automation is often compromised is in situations where business funds technology projects on a per project basis. Key reason being business benefits of automation, primarily time to market, are realized only during the subsequent releases of the application, never in the release where automation is undertaken. Even when business agrees to fund an automation project, the order of magnitude of benefits is small due to the potentially low levels of automation feasible within the project scope. The benefits accumulate only over a period of time from increasing automation levels and therefore the return on investment is realized over a longer duration. In order to reap benefits from automation business needs to continually invest in it and maintain a long term orientation to ROI. These are typical characteristics of any change initiatives. Test automation initiatives funded by individual business units can therefore learn from the vast expanse of knowledge pertaining to other organizational change initiatives and do not need to reinvent the wheel.

I have captured my experience of change initiatives as applied to automation in the visual below. It shows key components required to not only succeed at a pilot project but also create a cascading positive spiral where the benefits accumulate over time.


Like any other change initiative the key components form a chain, where the initiative is just as strong as its weakest link. Successful pilot accompanied by the right communication can act as a feeder to the next project and as long as all key components act in unison incremental benefits from each project can lead to significant cumulative benefits. The problem is that the first cycle tends to be demanding and it needs continuity of the champions until such time that the framework is institutionalized. A failure at early stages can have devastating effects with a stigma associated with it presenting greater roadblocks during subsequent attempts at automation. This is where senior management support from business and IT is crucial. A champion driving each automation cycle to success is central for the overall success of automation!

What do you think of the role of change management in automation projects? Have you had difficulty funding automation projects? Please feel free to share your experiences.

Aparna Katre | Director Strategy | Zen Test Labs

Automating data migration testing

I had the opportunity to be a part of data migration project recently. I was involved in automated data migration testing, which I found it to be a very exciting and challenging form of testing.  I wanted to share my learning’s in this post.

During conversion or migration projects, data from the legacy or source systems is extracted, transformed and loaded into the target system. This is called as the ETL process. The data needs to be transformed as the data model of any two systems is different. As a standard practice the data transformations are managed in the data mapping document, which forms the basis for development as well as testing.

Testing the migrated data is usually a critical and challenging aspect. Testing the migrated data manually is a very time consuming process and so automated data validation is a good way to go ahead.

In my latest project, data from two source systems was migrated to target system. The data from the source systems’ UI was compared with the data from target system’s UI, since we did not have access to the database. Data migration was performed based on incremental loading approach to ensure cent per cent verification. The approach was to load small subsets of data every week for verification. This type of a process was a perfect solution to client’s challenges as in the event of any mismatch only that specific subset of data could be reversed.

I am also listing some of the key challenges we overcame during the course of the project

  1. We had to create scripts that could read source values and the use field level mapping rules to calculate the expected results at the destination. This had to be done because the mappings between the fields of the source system and the target system were different; i.e., both systems had their own structure
  2. We had to verify values at the target system as some extra fields were present in it leading to a mismatch with the source system
  3. We had to read the data on the target system to verify as some amount of data in the source system was in a CSV format with header changes for each customer column
  4. We also created a strong log generation mechanism that generated a result for every iteration. It also went onto ensure that when any mismatch occurs not only field name mismatches are captured but also values get captured
  5. The results also included the time taken to execute each record
  6. To counter the fact that most of the data migration was done in files of XML tab separated formats, we had to generate the input file for automation in excel format

We also went onto to create a customized data migration automation testing framework (illustrated below) to overcome these challenges which lead to a successful project.

Have any of you worked on such projects? Would love to hear some of your experiences.

Anand Gharge | Test Manager | Zen Test Labs

Agile testing uncovered…

I have been a part of agile testing for quite some time now and have experienced its edge over the traditional style of testing. Over the years I have seen that most companies shy away from this form of testing for one or a combination of these reasons; i.e., implementation issues, lack of awareness, risk involved or simply just a resistance and hesitance to change. Through my post below I am attempting at assuring readers that agile testing is not only simple and extremely effective but also goes a long way in achieving delight in your testing strategy.

What is Agile testing?

Agile testing likes its development counterpart refers to a concept of breaking down the entire process into small pieces in a bid to achieve results as quickly as possible. Thus, agile testing is nothing but validating requirements in the shortest time possible. Product Owner’s, Scrum Master’s, Agile BA’s, Agile Tester’s, Agile Developer’s, Agile Architect’s, and Agile Resource Managers can all implement this methodology of testing.

Some advantages of Agile Testing

• Ensures time and budget optimization as all phases of SDLC need to be completed quickly.
• Ensures all change requests or enhancements are implemented without budget constraints with minimum impact on time to market
• Ensures good coordination due to daily nature of activities thus determining issues & gaps in requirements in advance with countermeasures deployed rapidly
• Ensures comprehensive testing in situations where business requirements documentation is hard to quantify.
• Ensures that the product delivered is in line with business needs and timeframes.

Some learning’s

• When Agile testing is weaved into a project early in the product development cycle, it ensures that time/ work estimates are accurate thus ensuring that deadlines are met. This is primarily due to the fact that testers are exceptionally good at clarifying requirements and identifying alternative scenarios.
• Deploying Agile testing right at the beginning of projects also ensures that developers write their code to pass tests as the test approach is known well in advance.
• Early stage Agile testing also is an opportunity to bring in automated acceptance testing into the process. This is especially relevant when the development is also in the Agile mode.
• Testers are always one step ahead as they design the cases for upcoming release also, thus enabling developers to pick up at the start of the iteration.

Things to watch out for

• Project quality management is hard to implement and quantify unless the test team are able to conduct regression testing after each release.
• Attrition as always in the development cycle can have an adverse effect on project development.
• In the case that Agile Scrum is being used, it can be the leading cause of scope creep, when not managed properly.

All in all when managed properly, Agile Testing can give most projects the edge in ensuring that ROI on products can be seen much earlier than expected while keeping costs down to a minimum. I would love to write more about my experiences with agile testing but before I do, I would like to hear the views of readers in order to make this a more interactive exchange. How do you view Agile Testing?

Vikram Deshmukh |Senior Manager | Zen Test Labs