Tag Archives: QA

Testing Hardware – QA and the Nest Thermostat 

I have had a Nest thermostat now for 3 years. For the first year it was great. Then, something shorted out in our furnace or something and it went haywire. 

Problem was, the furnace blower would try to start when the A/C was on. Not good.

A bug fix was to just disconnect the heat wire during the summer. But I am getting sick of that. 

  
And how can I prove that it isn’t a botched wire job or a screwed up Nest?

Most HVAC companies still don’t know much about Nest and that’s a shame, but their first line of defense would be to blame the Nest anyways.

Tonight I ran and picked up a $25 programmable thermostat and wired it up. All wires. To try to replicate the problem 

Well I hook it up and no problems. My guess is the Nest is borked. Now on to try to prove that.

In any event here is my test harness :)

  
So now the question is. Try to get it fixed/replaced or just buy a new one. After I get it sorted I will update this post.

VB6 to .NET Migration: Preparation and Migration

In my previous post on this topic, VB6 to .NET Migration: Decision and Analysis, I talked about the decision to migrate instead of rewrite, and also the analysis portion of the project.

Once you are ready to go, what happens? You need to prepare for the migration process. What ArtInSoft needs in Test Cases and Test Scripts so they can run through your application on their end in QA (the VB6 version) and then once they migrate it, run through the same scripts again (once migrated to .NET).

My guess is shops have some kind of test scripts, but nothing too extensive. This is where we were scrambling, we had things all over the place and not very complete test scripts/cases. This ended up biting us in the end as a lot of the app wasn’t covered by test cases so it was hard for ArtInSoft to test and migrate it without tons of exploratory testing.

Since the migration, we have shored up our test scripts and test cases by using a QA firm, Beta Breakers, but that is for another post.

After ArtInSoft gets your test scripts, they run through them and ask any questions, and in the mean time, their dev team is migrating your code and looking for areas they can automated in the migration, that aren’t in the main migration scope of the their migration tool.

ArtInSoft sets up a SharePoint portal for your project so you can share documents and other things, as well as a discussion forum for “technical queries” – or things they want to know on a technical level what they should do during the migration.

As you can guess, many things in .NET aren’t the same as VB6, the way some controls react, etc. They want to know what to do in those cases. Also, you might have some crazy things going on in VB6 that have no direct translation to .NET, so they need to know what to do there, overall though it shouldn’t’ be too bad

Along the migration, you can get the migrated code as they are doing it every once in a while and look at it and get into source control on your end if you’d like. Also, up to to a certain point you can send minor changes to ArtInSoft, so you don’t have a to have a code freeze for the entire migration. Obviously at a given point, you can’t be sending changes, if you have them, you can do a “change control” request, but it is going to cost you, which is expected.

As they work on the migration, you can work on other things on your end, whatever you’d like. Towards the end of the migration (development), you will send 1-2 people down to Costa Rica to help finish the migration and deep dive into testing and development.

The final phase of the of the migration comes when your team becomes the “testing team” and you do User Acceptance Testing (UAT). You have a specified amount of time to test on your end and send bugs back to ArtInSoft. This is a good back and forth for 1-2 months possibly depending on the size of your application. Once you are OK with the code and app, you sign off and the code in your hands. Next up.. your own “fixing” period.