software quality assurance

Sharing knowledge: difficulties in software quality assurance

Why is it that sharing knowledge can become a problem in SQA (software quality assurance)? It's not news that the employment market is undergoing significant changes on a global scale. New trends are cropping up that have transformed employment relationships and the very concept workers have of the way they can contribute to organisations. 

The employee who spends their whole life in the same company no longer exists, or is at least very rare. In the same way that companies that work with the same supplier for a lifetime are also a thing of the past. All this is also favoured by the bidding model, which incentivises companies to change supplier in order to reduce costs. 

And this is where "sharing knowledge" becomes a problem or at least, an obstacle.  Companies have specialists with knowledge, but often the service is provided by a third party with rotation of employees and, therefore, sharing knowledge with all of those who are just passing through becomes a challenge.  

Employee rotation: a serious problem for SQA teams 

It's worth noting that the rotation we're talking about and the difficulty in sharing knowledge is not a problem that only affects SQA teams, but is indeed one that is becoming a problem for these software quality assurance teams. 

As DevOps practice continues to pick up the speed of innovation, its participants are obliged to constantly change direction in accordance with this new change that is spreading through the IT industry.

And those who move around take a good part of the knowledge that makes an efficient team with them. And this is where many companies don't manage to optimise their time, as they have to train the new recruits to the position, and in the process, in addition to the time lost as we've said, knowledge is also destroyed. 

In the specific case of Software Quality Assurance (SQA) teams, there are at least two causes of rotation: individual and collective. The first refer to people looking for a change in career, for example. And collective rotation relates to companies changing their SQA services provider. Naturally the latter has a huge impact on the company, which they try to mitigate with transition periods from one team to another. 

From tacit to explicit knowledge 

There is a type of knowledge -tacit, personal, undocumented knowledge- in relation to skills that is difficult to explain or transfer to others through language, which sets us apart and makes us special. It is difficult to copy by competitors and thus offers a competitive advantage. But it's difficult to share. Explicit knowledge, on the other hand, is that which is documented or coded and is transferable. 

One of the most effective ways for companies to protect themselves from the rotation of staff within the company is by converting tacit knowledge into explicit knowledge, so that the person who has just come on board in the team quickly reaches the desired level of efficiency in their work. 

icaria TDM facilitates the sharing of knowledge

So what can icaria TDM do to avoid the loss of knowledge caused by staff rotation in QA teams? As we have explained, the solution to the problem we've been taking about in this article is none other than the conversion, as explained, of tacit knowledge into explicit knowledge. 

There are different features that facilitate the transfer of this knowledge and we're going to explain two of these below: data archetypes and functional data domains, as both of these meet our design principals: to record, conserve and share the knowledge. 

1.  Data archetypes (also known as data profiles) 

One of the inexhaustible sources of confusion and errors in QA is the lack of a shared definition of the different data profiles used in the test cases. At the highest level, everyone understands what a "Potential resident client for bid X" is. The problems start when you have to write queries to find one or create one manually to perform testing.   

In icaria TDM you can create a catalogue of conditions in relation to your business data architecture, simply, without writing queries. Next, you can select the archetype you need by selecting the conditions that define this. 

The archetype itself will take care of finding examples of this archetype in the databases you indicate: production and non-productive environments. 

2. Functional data domains 

Knowing how the information is represented in an organisation's multiple data models is no mean feat and it is frequently fragmented knowledge, which prevents you from efficiently exploiting the available data, whether for use in software testing or in processes. 

icaria TDM's subsetting trees describe the functional data domains and the relationships between them (even when they belong to different applications or different technologies) so well that icaria STUDIO becomes a centralised point of knowledge of the organisation's business data model. 

To find out more, please don't hesitate to contact us. At icaria Technology we will be happy to hear from you.