The testing team was right. They needed more time to test the system.
The first problem found regards product integration and interface testing.
It looks that the data migrated by us is using a key that differs from a satellite system. We checked the data migrated and it complies with the specification, the mapping rules defined and the transformation rules implemented. This was also confirmed various times over the last 4 months by the tests performed on the migrated data.
The other system is sending a different key from the one we're sending.
This is an obvious integration error which would easily be found and corrected if integration tests had been performed.
With less than 3 month from the real data migration, this is not a good sign. Specially because we've already alerted several times to the need of consistent and automatic tests, something that no one here seems to care for except the testing team which, by the way, does not have the power to enforce it.
Monday, March 29, 2010
Day 360 - First Product Go Live
Things didn't went exactly as planned.
Just minutes before the loading of the migrated data someone just noticed that there was something wrong with the configuration and a critical action took place.
This meant a delay of over 4 hours regarding the original plan but eventually everything went well and the first product in GIS is ready for the go live next Monday.
Just minutes before the loading of the migrated data someone just noticed that there was something wrong with the configuration and a critical action took place.
This meant a delay of over 4 hours regarding the original plan but eventually everything went well and the first product in GIS is ready for the go live next Monday.
Friday, March 26, 2010
Day 359 - Pre-Production Stress
People are getting pre-production stress.
Things should go smooth, but since people do know that the tests should have been better, they get stressed.
Today, one of the people responsible for the data migrated for the system go live tomorrow has just came to ask me why the data has only 379 records. That is the same person that defined the data source scope, the transformation rules and has been validating the this data for the last 6 months...
In the end, it was all correct, it was just a pre-production stress attack.
I think this shows how uncomfortable people really are with the data migration quality assurance procedure.
Things should go smooth, but since people do know that the tests should have been better, they get stressed.
Today, one of the people responsible for the data migrated for the system go live tomorrow has just came to ask me why the data has only 379 records. That is the same person that defined the data source scope, the transformation rules and has been validating the this data for the last 6 months...
In the end, it was all correct, it was just a pre-production stress attack.
I think this shows how uncomfortable people really are with the data migration quality assurance procedure.
Thursday, March 25, 2010
Day 358 - Go Live Files Ready
We have received the source files and have loaded them into our staging area.
We have executed the data migration for the entities and created the GIS loading files required for the go live.
The files have been loaded in the quality acceptance environment without a single problem. Tomorrow the testing team will check if everything is in order and, if so, the data will be loaded on the day after.
We have executed the data migration for the entities and created the GIS loading files required for the go live.
The files have been loaded in the quality acceptance environment without a single problem. Tomorrow the testing team will check if everything is in order and, if so, the data will be loaded on the day after.
Day 352 - Data Migration Plan For Go Live
We have just received the plan for the data migration part that is required for the new system kick-off.
We will receive the source data, loaded it in our staging area, execute the transformation rules for the entities and create the GIS loading files for the acceptance and production environments.
Since a postpone has not been granted for the new system go live date, the testing team seems to be working a bit harder and things seem to be a lot better.
We will receive the source data, loaded it in our staging area, execute the transformation rules for the entities and create the GIS loading files for the acceptance and production environments.
Since a postpone has not been granted for the new system go live date, the testing team seems to be working a bit harder and things seem to be a lot better.
Day 345 - New System Go Live
The new system will go live with a new product.
Since this is a new product, only a tiny part of the data included in the migration scope will be loaded at that time.
This will happen on 29th March.
There has been problems with the tests, which can resumed to the fact that the tests are not yelling the expected results and are seen as insufficient by many people involved in the process.
Management did tried to postpone the go live for two weeks. But the project sponsor has denied this request, so, the system will go live as planed.
Since this is a new product, only a tiny part of the data included in the migration scope will be loaded at that time.
This will happen on 29th March.
There has been problems with the tests, which can resumed to the fact that the tests are not yelling the expected results and are seen as insufficient by many people involved in the process.
Management did tried to postpone the go live for two weeks. But the project sponsor has denied this request, so, the system will go live as planed.
Wednesday, March 17, 2010
Day 335 - Reprioritization
The project sponsor is not very comfortable with the current dead line compliance, so management has reprioritized the migration of the business areas.
This happened because management believes that there is need for a greater focus on some business areas where it comes to the data migration.
In practice, this means that credit insurance has been defined as non-priority data to be migrated.
I'm actively involved in this business area and my opinion is that this is actually a mistake.
Credit insurance is equivalent with all other business areas when it comes to mapping and errors, and the other business areas are not "on hold" because of the migration.
The reason the project sponsor is afraid is because the mapping team cannot solve the problems faster or there are dependencies from other players and the testing team is no longer working daily.
There are several management mistakes here. Testing should be a priority now, but the tests have been reduced and the testing team, which was performing ad-hoc tests 4 hours per day, is only doing up to 16 hours of testing per week. Some tests should have been automated by now, but there is not even a plan to do so, so testing will continue to be ad-hoc.
Management should focus on forcing third party players to comply with their tasks and dates instead of reducing the scope of data being migrated. As an example, we are waiting for some data files for at least 6 weeks, but the third party responsible for it doesn't actually care. They've sent a couple of files last week, to shut us up, and they came all wrong...
This happened because management believes that there is need for a greater focus on some business areas where it comes to the data migration.
In practice, this means that credit insurance has been defined as non-priority data to be migrated.
I'm actively involved in this business area and my opinion is that this is actually a mistake.
Credit insurance is equivalent with all other business areas when it comes to mapping and errors, and the other business areas are not "on hold" because of the migration.
The reason the project sponsor is afraid is because the mapping team cannot solve the problems faster or there are dependencies from other players and the testing team is no longer working daily.
There are several management mistakes here. Testing should be a priority now, but the tests have been reduced and the testing team, which was performing ad-hoc tests 4 hours per day, is only doing up to 16 hours of testing per week. Some tests should have been automated by now, but there is not even a plan to do so, so testing will continue to be ad-hoc.
Management should focus on forcing third party players to comply with their tasks and dates instead of reducing the scope of data being migrated. As an example, we are waiting for some data files for at least 6 weeks, but the third party responsible for it doesn't actually care. They've sent a couple of files last week, to shut us up, and they came all wrong...
Day 332 - Yet, Another Team Reshape
There has been yet another team reshape.
In practice this means that there is currently only two business people responsible for the mappings, one which aims to more practical actions and another that aims for business rules validation.
In practice this means that there is currently only two business people responsible for the mappings, one which aims to more practical actions and another that aims for business rules validation.
Subscribe to:
Posts (Atom)
Posts
