KinderTrack 4 is currently also being configured to serve the California space, where many agencies are still running our client/server version of KinderTrack 3.

What is that???

That is a result of the system that is printing the timesheet missing a font that is used to generate a barcode representing the paymentID.  This barcode can then be scanned for quick reference to the timesheet/payment.  The font needed for the timesheet is installed on the KinderTrack server at deployment, but if you print from your local workstation, it may not have been installed.  However, there is an easy fix…

What you need to do is download and install 2 fonts called “Wasp” fonts.  These are used to generate the barcodes.  To get a copy of the ZIP file of these fonts, please contact Customer Support. Once you have the ZIP file, unzip and then move the files to your Fonts directory (accessible via the Control Panel link in your start menu).

NOTE: Based on your agency’s policies and procedures, you may not have permissions to install this font to your machine.  Please check with your IT department to complete this task.

Once again, the release notes for this patch are published here and I will try (really this time) to add some posts regarding the bugs and/or features in this and the last patch.

By the way, the new family fee module is really taking hold and agencies that have been using it are enjoying its power and realizing the time savings.  If you haven’t yet seen the module, let me know and I’ll be happy to schedule a demo for you.

Release Notes:

3_14_7 patch 12_11

3_14_7 patch 1_25

There release notes are attached here for reference… I will break out each of these items in a separate blog over the next week or so.  As always, if you have questions on any of these, drop me an e-mail or phone call and I’ll get answers for you!

3_14_7 patch 10_28

At Controltec, we have taken great steps to improve this QA process.  We put the code, calculator and database on a completely “neutral” server – one that doesn’t have any development environment or tools installed.  We take a “clean” database – one that can’t be updated or modified by developers and we run through the upgrade process as if we were upgrading a client.  This process tests the upgrade scripts to ensure that they will run on client machines without issue and the prepares the QA site for testing.

Once the site is updated, QA can begin testing by running through test scripts and general “smoke tests”.  Depending on the version of the build, regression testing is also performed.  For instance, if the release is a patch that fixes 2 procedures, then a small bit of regression testing is done – add a new family, create a payment, etc.  However, if the release is a full release, such as 3.14.8, then a full realm of regression testing is done throughout the entire system.  We attempt to “touch” every page and every scenario.  As we continue to strengthen our QA department and testing, these regression tests are being automated and new tests are continually added to enhance the test suite.

Of course, if anything fails QA, then we push the release back down to development where the process starts over with the build, goes to unit testing and then back to QA again.  We continue this cycle until everything passes and we have a valid release candidate.

So, that’s QA… in a nutshell.  It’s no easy task, let me assure you!  As you can see, there is a lot involved in this process, which is why a lot of these releases take time to get out the door.  As we speak, 3.14.8 is 2 SPRs away from going to QA… so it’s getting closer!  Meanwhile… see the next post… where the next 3.14.7 patch has been released and is being installed.

For every feature that passes their unit test, there are a couple that don’t pass.  The features that don’t pass are investigated and resolved in preparation for another build candidate.    The cycle continues until all of the units have passed unit testing.  Also, during this process, test procedures are confirmed and updated in preparation for the candidates move to the next phase… Quality Assurance.

This phase is also the last chance to fix any of those other pesky bugs or issues that have come up while the development cycle was occurring.  For instance, if the state announces an 801a change we will often push a release back into unit testing to capture all of these changes for the end result.  These push-backs are the main cause of release delays because this often means that not only is this release delayed, but the current version has to be updated, tested and released with the changes prior to this release continuing.

Check back soon for details on this next phase as we get closer to the release.

 This check is to verify the validity of the schedule period based on child enrollment and blackouts. By clicking the ‘Go->’ button to the right of the dropdown list, the system performs the following checks:

Child Blackouts:  The system checks if any blackout days exist within the schedule period of care. Blackouts are entered via the Special Period button on the Schedule page. If a child/schedule blackout exists, the system will display an error with the corresponding blackout period.

Family Blackouts: The system checks if any family blackouts exist within the scheduled period of care. Family blackouts are entered into the system by setting the family status to Term Pending. If a blackout exists, the system will display an error with the corresponding blackout period.

Child Enrollment Status: The system checks the child history to ensure the child is enrolled throughout the entire scheduled period. If the child is not enrolled for the scheduled period, the system will display an error with the date of the first un-enrolled day.

For many of us here at Controltec, this is the fun part.  This is where we actually get to make the parts work.  The developer takes the design and test procedures and digs into the code to build the feature into the application.  In some cases, database tables or fields need to be added to the database, in some cases changes to an “rpt” file occurs and in some cases changes in the application occur.  In many cases, all three have to happen.

As an aside, an “rpt” is a report file.  RPT being the extension to a crystal report file which is the tool we use to create reports in KinderTrack.  For this reason, many developers will refer to every piece of paper that comes from KinderTrack as a “report”.  Every NOA, letter, listing, communication or item that is printed to the printer is done in a crystal report file coded into the application.

When all of the changes for a feature have been coded, the developer completes development testing on the changes made.  This is a very, very basic level of testing that occurs at the developer’s workstation with the developer’s environment.  This testing is meant to test that the feature has been coded and does not indicate that the feature is ready for release.  However, it does indicate that the developer believes it is ready and they can move onto other features in the release.

Once all of the features targeted for the release are updated and ready to build, the test candidate is built.  The actual build process consists of 2 different actions.  The first is “scripting” where a database script is completed to capture all of the database changes made since the last version.  The second action is the building of the application, including the calculators and the latest report files.

When the test candidate is ready to go, we move into the next phase… unit testing.  Check back soon for this next phase in the release process!

Once we have determined that we need to do a release, the first step is to define what items are going into the release, organize and/or create the SPRs and then complete the definition of what needs to be done.  The items to include come from a number of different sources:

1)      A new client needs something in order to be deployed.  For example, we currently have a client waiting for the new billing cycles in 3.14.8 – they can’t start using the system until we get this feature implemented and released to them.

2)      Items that didn’t make it into the last release.  New items are found or requested daily and often in order to get a release out we have to say “no more”.  When this happens, we take the leftovers and move them to the next release.

3)      Wish list items.  With every release, the product manager (yours truly) reviews the wish list to see if there are any items that should make it into the next release.  The wish list is a list of items that have been requested over the years as we have visited or talked to clients.  In reviewing the wish list, we have to identify items that will have a positive impact for the majority of our clients.  As a side note, did you know that there are currently approximately 500 items on the wish list for KinderTrack?

Once the items for the release are established, the product manager and project managers must go through the list and define what needs to be done for each item.  In some cases, this is as simple as updating the item with a few more sentences, but often it means creating an entire document defining the scenarios, mockups of the screens, etc.  Additionally, test procedures are written to describe the desired output of the item.  Once everything is designed, the items are assigned to the developers and the next step in the process begins… the development or build phase.

Today, let’s discuss the version numbers…

KinderTrack currently has 3 different released versions of the system.  There is an East Coast version labeled 3.13.12, some lingering CA agencies on 3.13.5 and the bulk of CA on 3.14.x.  I say, “.x” because we have some clients on .5, some on .6 and some on .7.  This last digit is often called the “dot” release as we refer to it as “dot 5”, “dot 6” or “dot 7”.  “Dot” releases are intended to introduce minor enhancements or new modules that do not affect the rest of the system’s integrity.  Major enhancements, or things that affect the entire system, are designated for a Major release (i.e. from 3.13 to 3.14).  For instance, 3.14 introduced the templates and new rates pages.  Tweaks and changes were made to these enhancements until they were stabilized in “dot 5”.  “Dot 6” then introduced the Reports DLL – a way to release reports without a full upgrade – and then “dot 7” introduced the new Family Fee module that allows agencies that deduct family fees to also invoice and track the fees collected from the family.

The upcoming “dot 8” release introduces a new billing cycle ability as well as some other minor enhancements that I think you will like (or that you may have been patiently waiting for).

The 3 in KinderTrack 3 is what we call the “Generation” number.  These come along when there are major shifts in platforms or system cores that require a ground-up rebuild of the system.  KinderTrack is currently in its third generation (hence the KT3 designation) and has been in place since the mid nineties.  KinderTrack 4, built on the .NET platform and designed as a web application, builds on the third generation knowledge and know-how and offers an exciting new interface and approach.  The first release of this new generation has successfully been installed in the state of Iowa.

There is another group of “hidden” numbers that you might often see or hear us refer to.  The last digit (or actually digits) in the application is the “build” number.  Builds are used for internal testing and when a hotfix or patch needs to be released to fix the latest release.  Controltec has build numbers on the database, the exe and the calculator so that these patches can be installed without a major overhaul and effort.  Because great effort is made to keep enhancements out of the builds, Controltec can install a patch build quickly and easily at the agency without fear of breaking other parts of the system.