SD & QA processes and brief analysis of QA process in ITSM app project based on Salesforce platform

Project

ITSM app is built on the Salesforce platform and delivers out-of-the-box ITIL (Information Technology Infrastructure Library) processes designed to inform any service delivery function, from internal help desks to customer-facing service operations.  In conjunction with the Salesforce Service cloud and Experience Cloud platforms, Service Management ensures ITIL compliance, mitigates risk, and provides top-tier support to all customers and employee engagements.

Point of growth

One of the challenging moments for our team was that the product entered a new stage, significantly expanding the functionality of existing modules, as well as integrating the product with third-party services from various software providers. 

One of the suggestions for solving this task on our part was a proposal to expand the development team working on the project and update SD & QA processes.

Here we uncover the question of how an effective quality assurance process is built and the work of the quality control team is organized to achieve the best performance and effectiveness on the above-mentioned project of our customer.

SD & QA Processes

Description of the implemented processes

The main difficulty of the project lies in its huge size, complexity and intricacy. Therefore, we have slightly extended the quality control process. We have provided triple quality control, separately in the isolated environment, then comprehensive control in the test environment, and after that alpha testing in the Release environment.

Test Environments

Implemented stages of SD & QA processes:

• Tasks are created by the Product owner as JIRA tickets, but quite often product improvement tasks are also created by other team members, mostly by quality assurance engineers. 
• Tickets generally contain requirements for their implementation.If the task is already ready for implementation, it is transferred to the Ready for Development status and a sprint label is assigned. After that, the developers start working on it.
• In turn, a member of quality control engineers sees tasks on the board that are in the status Ready for Development or in the status In progress. With this information, regardless of whether the developer is working on any task or not, he starts working on the test documentation. 
• The requirements are covered by tests, if necessary, QA clarify the requirements with the product owner or other team members who can clarify this information.
• After completion of the development, the task is transferred to the Ready for QA status and any free quality assurance engineer takes the task into testing.
• The task that is being worked on is first tested on an isolated scratch org, after which, if there are no issues, the code is merged with the code on QA org, and the task is retested on this org. This approach slightly lengthens the testing process, but this is related to the technical features of the project. 
• If issues are not detected, the task is transferred to the Ready for UAT status, and they are re-checked on the main test environment by the product owner, after which they are transferred to the Ready for Release status.
• By the time the sprint ends, there is a fairly large set of tasks ready for release. A package from these tasks are assembled. It is installed in the Release environment, where, depending on the size of the release and the complexity of the tasks included in it, QA team conducts either smoke or regression testing.

In the process of working on the project, ad-hoc and exploratory testing are periodically conducted.

Exploratory testing is carried out in order to update the test documentation, because the functionality of the product elements changes quite quickly. And without up-to-date test documentation, it will be impossible to take into account the details of the functionality in the future.

Ad-hoc testing is also vital, since strictly formalized testing based on test cases, with such a large amount of functionality integrated into each other, does not allow identifying all defects, testing looking around, relying on the experience of the tester, from our point of view, is necessary to ensure quality.

At the moment the project has entered a new stage and the team has been strengthened, just over 1 000 tickets (only various types of tasks are counted, tickets with quality control documentation are excluded) have been registered in the backlog of the project, both finished and not yet completed.

Among them, 426 tickets were created only by the quality assurance members of the team. Which accounts for about 42% of the backlog, and indicates the extremely positive impact of quality assurance staff on the development of the project. 
 

Conclusion

There are issues in any product and at any stage and quality control is vital in any project to achieve success. 

The customer's decision to strengthen the team with additional qualified quality control engineers was right. This definitely contributed to the satisfaction of end users, the successful implementation of the project and the customer's business goals.

The main advantages of JET BI's software development and quality control efforts for the considered project are:

• Cost Efficiency and Operational Excellence
• Responsible partnership
• Security
• Highly qualified team with expertise in the sphere
• Accelerated development time
• Flexibility
• Resource management and scalability
• Independence from circumstances
• Improving the quality of services