New 3.14.7 patch available

Well, I never got to discuss some of the last patch features, did I?  Even worse, I didn’t announce the previous patch released in December.  Well, this was all because I was busy at work with the latest patch… which is now available.  This patch fixes a couple of pesky bugs that I was finally able to get my arms around, including one that shows duplicate alerts on the Family Alerts page.  It also includes a ‘revert’ button on the attendance page to quickly revert back to the scheduled hours, if necessary.

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

New 3.14.7 patch now available!

The latest patch for 3.14.7 is now available and being installed at client sites.  This patch fixes some known issues and bugs in 3.14.7, including a calculator bug affecting pro-rating of payments for contracted providers where the schedule and payment both start mid-week.  There is also a change to the sibling reduction logic in this release.

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

KT Release Process – QA

So, we’ve talked about the versioning, design, build and unit test phases of the release process… what’s left?  Well, only the most important step in the process… Quality Assurance… or QA.  The QA process is a step where we give the application to someone other than a developer to review and… in all honesty… try to break.  While QA will follow the test steps defined during design and implementation, they will also push those buttons that should never get pushed.  QAs job is to try to find all the bugs before the release goes out the door.  Now, let me assure you that this is almost an impossible task.  Look at Microsoft, for example… how many times do they release a new operating system and then a service pack follows almost immediately?  That’s because, inevitably, as soon as QA gives it the stamp of approval and you put it on the first client’s machine, someone finds something that everyone missed.

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.

KT Release Process

In this next installment of the Release Process blog, we are going to talk about unit testing.  Unit testing is where we take each individual feature or “unit” and test it in a build candidate.  This phase is important because it gets the code off of the developer’s local workstation and into a full build of the application.  All of the parts are pulled from source control to get the very latest of everything and a candidate is built.  The candidate is placed on a “neutral” machine (i.e. not a developer’s machine) so that it can be tested in something close to a real world scenario.  We expect to find a lot of bugs in the stage of the process as the build comes together.  However, at this point, it is still the developer who coded the feature who is responsible for testing their unit.

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.

Schedule Verification capability

The schedule verification process is launched from the Family activity Schedule page. In the lower left hand corner exists a dropdown with a ‘Verify Schedule’ list item (shown below).

 

 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.

The Release Process – Part 3

In this installment of the release process blog, we are going to talk about the build process. 

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!

The Release Process… part 2

So, we talked a bit about version numbers in our last blog about the release process.  Today, let’s talk about the first step in the process… the definition and organization of the release.

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.

The Release Process… part 1

Today we will start a series on the release process of the KinderTrack product.  As the next “dot” release of KinderTrack goes into Unit Testing, we will explain the entire process that goes into the release so you can get a feel for where we are and why it’s taking so long.  Controltec has made great efforts to improve the quality of the product over the past couple of years and what will follow the next couple of days is an explanation of what we’ve done to do that.

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.

Contributors wanted!

Now that we’ve had the blogs online for a while and have officially announced its existence, it’s time to get everyone involved.  If you have something that you would like to contribute to this blog, you can participate in a number of ways.

1) E-mail me and ask to be a contributor.  Contributors can then login to the site and post their own blog.  Controltec will review and publish it to the site for all to read and comment.

2) Comment on an existing blog.  You can start a discussion with other viewers on the site by clicking on the Comment link under each topic.  Make a comment or add a contribution/take to the discussion for everyone to review and respond – you can even add relevant questions to your comments.

3) E-mail a topic, question or request that you would like discussed in the blog.  I will review the topics received and create a new blog topic if appropriate.

Also, note the “Agencies” box to the right of the blog text.  We can add a link to your agency’s web site in this area so that other users can review and communicate with your agency through your agency web sites.

Help me make YOUR blog better… let me know what you want to talk about!

801a Modifications pending

As you are all probably aware, the state has released information regarding changes to the 801a report effective for the July submission.  Controltec is currently reviewing these changes and will be providing an analysis of the necessary modifications to the report as soon as possible.  We will update everyone within the next week on the progress and approach for the July report.

If you have any specific questions regarding these changes, feel free to post them as a follow-up here so we can address them to the group instead of each individual client.  Meanwhile, we are working on a solution and will update you as soon as we can.

Link to the state’s site regarding these changes: http://www.cde.ca.gov/sp/cd/ci/update12.asp