Quality Assurance of PaaS Components Configurations : A Case Study at Sogeti

• Main Author: Totangy, Omar
• Format: Others
• Language: English
• Published: Högskolan i Gävle, Avdelningen för datavetenskap och samhällsbyggnad 2020
• Subjects: Quality Assurance; PaaS; Azure; Software development; Computer Sciences; Datavetenskap (datalogi)
• Online Access: http://urn.kb.se/resolve?urn=urn:nbn:se:hig:diva-32641

In a world where software systems are essential for our everyday life, a vast amount of software errors have led to severe consequences, almost causing a nuclear war. Ensuring the quality of software systems has increasingly come into demand due to the rising complexity of technologies used in today´s solutions such as cloud computing, internet of things (IoT). Companies strive to ensure the quality of their softwares and have different approaches to do so. Some companies follow an industry standard such as ISO 9000, others develop their own standards and implement a software to ensure conformance. Quality Assurance (QA) has traditionally been implemented in the later stages of the development process. Research suggests however that early or constant implementation of QA is more likely to provide better end results. Current studies explore the stages of implementation for QA, the effects of QA and approaches for QA. Few studies however investigate how QA is approached within private companies. This study investigates the implementation of QA within private companies, the use of QA and which stage of the development process QA should be implemented. The investigation was done through suggesting a suitable approach to achieve QA for the case company Sogeti. The challenge that Sogeti faced was to ensure the quality of their PaaS components configurations. To further understand the problem, a QA plan was developed with the use of Robert P. Elliots ten steps of developing a QA specification. The QA plan indicated that a software would be a suitable approach due to the specific demands that Sogeti provided, the software would then implemented in the later stages of the QA development process before the components reach the end customer. The final prototype of the software helped discovering the amount of improper configurations that exists (38,46% components with improper configurations). Early QA might have been a better approach, assuming that the problems were discovered early. When the problems are dicovered late, the stage of QA implementation might not matter as the approach for QA is reactive. In order to draw that conclusion however, further research is needed where multiple companies are analyzed to visualize the qualitative and quantitative effects of QA.