Upgrade vs Migration


We often encounter these terms being used interchangeably and it is useful to point out a few differences. Here are some thoughts -

Upgrade is the process of moving an existing system from one version to a higher version. Normally, the term upgrade is used to refer to upgrading on the same hardware. This is also known as in-place upgrade. Upgrade allows you to retain your existing system, configuration/ device/ security/etc. settings. An argument against frequent in place upgrades is the possibility of reduced performance over time when compared to new installation and migration. Of course, doing an upgrade of your existing system carries the risk of rendering your existing system unusable in case the upgrade does not go as planned. To mitigate this risk, a full back up prior to upgrade is recommended.

Migration is the process of switching over or upgrading from one set of hardware to another. It normally involves installing newer software on a clean system and transferring data across. Migration can occur across versions of the same software product or even across software from different vendors such as migrating from SQL Server to Oracle DB for instance!

One of the uses of migration is in production deployments wherein you could continue to have your existing systems up and running while you perform a migration to another set of hardware. If the upgrade succeeds and your tests have passed, you can switch to the upgraded system. Else, you have the option of falling back to the existing system.

As testers, both these processes need to be tested. However, for organizations, which of these processes do they choose? The answer depends on multiple factors including - the feasibility of either of these approaches - can an in-place upgrade be performed/is it supported? Some systems may not permit further upgrades or your existing infrastructure may be inadequate to support an upgrade; next comes the need for an upgrade - do you need to upgrade? Assuming that upgrade is doable, it still does not mean that upgrade is what you must do. Is it really a must to maintain your existing infrastructure and do an upgrade or would it make sense to move to a new installation and migrate data across? Depending on the nature of the software you intend to move to, there may be many other considerations (apart from just the data) when choosing between an upgrade and migration.

The distinction between upgrade and migration isn't restricted to the above. Some organizations consider all of the above as different types of migration i.e. an upgrade is seen as an in-place migration whereas the migration listed above would be a non in-place migration. Yet other organizations view migration to a large degree as a type of upgrade (migration type upgrade) and distinct from migration itself with few differences. However, for simplicity's sake I have segregated upgrade (in-place) and migration as mentioned above.

Are Testers below Developers in your company?


During a recent campus hiring visit to a reputed engineering college, a student whom we had shortlisted after multiple rounds of interviewing for an entry level QA engineer position seemed to have some doubt lingering in his mind regarding the role on offer.

In the final HR round, the student decided to speak up and popped the question - whether QA engineers were "below" Developers in the organization? The HR representative promptly called me to clarify. As is my wont, the expectation was for me to (over) sell the QA role. However, on calmly listening to the student's question and his source of (mis) information, I decided to play it even. I did accept that there were/are organizations where QA engineers are perceived as lesser cousins to their development counterparts. However, the QA engineers and their management need to share a part of the blame for this state of affairs.

If your QA team is seen as a non-technical entity, who cannot converse and actively engage with Development and other functional groups in their language then you deserve to be at a level below the rest. While black box manual testing is good and important, testers must constantly acquire and renew their technical skills to stay relevant. Else, the tester stands out like a sore thumb who needs a fair or more amount of spoon feeding and hand holding. Wouldn't it be wonderful if Developers and Testers worked side by side, treating each other as equals and challenging one another in the pursuit of better quality software deliverables? To do so, the QA team needs to raise the bar of technical competencies expected from testers to a level wherein they can clearly understand the architecture, design, requirements and the code to a large extent. Rather than divide testers into the specialist black box (and thereby perceived as technically challenged) and specialist white box groups, testers must evolve to take the best of both worlds while ramping up on technical competencies.

Testers need to earn credibility and I have seen quite a few such testers who are experts in their product/area/technology/domain to the extent that other functional groups ping-ed these testers when they had queries that need answering! Were these testers seen as second level citizens? Of course, not ! they were considered as respected peers and key members who had to be involved in decisions impacting the product/project.

Every organization needs to see the value of testing and testers. Yes, all (ok most) organizations tend to think that testing is a necessary function and testers are necessary parts of the production process. However, the degree of importance accorded to testers is directly proportional to the perceived value of testing. What can testers do to impact this value perception? Think about it !

Getting back to the student, I did explain that in the context of the organization he was being interviewed for (namely the organization I represented), we do not discriminate or think QA engineers as being less important than Developers. Of course, the student needed to do his part once he's on board in terms of earning his credentials and respect. He had to demonstrate his ability to quickly grasp the area he would be asked to work upon, ask intelligent questions, make efforts to expand his knowledge of the area and domain both breadth and depth-wise, have an insatiable thirst and commitment to excellence. Both Development and Testing are key to producing quality software with well defined and challenging career options in both areas.

Note: In the above post, I have used the term QA liberally to refer to testing. I am very well aware of the QA function and how QA literally isn't testing. However, I have come across various organizations and groups where Test engineers are referred to as QA engineers and the usage was in this context. As the bard would say, a rose by any name would smell just as sweet!