Back in 2012, we were a small team - one developer and one QA engineer, organized and managed by a technical lead.
We were working on only one project with huge potential to grow and scale. Building a good and stable foundation was a key factor in the long-term success of the project and assuring quality was considered as a material for a separate role and organizational unit based on three key drivers:
- The software held health-related data, which is considered highly sensitive and private information. So the role of the quality engineer was heavily related to ensuring procedures of creating built-in quality to be incorporated into the methodology and making sure that every information is served in the right place and in the right way.
- There was a legacy solution that we needed to understand and improve. A huge amount of work was dedicated to business process modeling and striving to depict and visualize the information flow and architectural design in order to create optimized and improved solutions.
- The solution was used on a daily basis by a big team that was used to work heavily with manual processes, (not automated and not digitized). Every release was causing disruption and there was a need for training and understanding of the new features meant to improve and optimize the heavy workload.
Since then, we have always considered QA as a key concept with a huge level of impact, responsibility and importance as a crucial part of the methodology and operations. We were always focused on building expertise in this segment of the Software Development Life Cycle.
Also, we always considered the importance of the high overview of the system (both from a business and architectural perspective) to be crucial for scalability and growth of the software solution, and historically analyzed, the QA position always held the knowledge of how workflows are orchestrated and organized and what was the story behind every business process. This knowledge kept in a different form, flowcharts, documentation, and specification was built and used by QA as guidance in the iterative development and as a guardian of the customer value and business justification.
Specification and advanced forms of collaboration and communication with the business stakeholders are initiatives that came from this period as a way of bridging the gap between the business and technical implementation. When we started our first project, we understood the importance of clear goals and project vision in this period, and most of these activities were related to the role of the QA at IBORN since then the customer-centric approach was mostly realized with the role of the QA, in the form of different activities to keep close with the vision of the business and to make sure that we are translating business requirements into a workable software solution.
It’s true that the process was rigid and not collaborative. The software development team was doing the specification, and implementation part and the things were left to QA engineers after the implementation phase. They were doing “checks” if the requirements meet the given acceptance criteria. They were responsible for release schedules and deployments. This was happening in the earliest stages of our company, bringing us a lot of problems. So first evolution in the company started here by encouraging the “shift left” testing movement, which means putting QA at the earliest stage in the life cycle making them advocates of project vision, responsible for bridging the gap between business stakeholders and technical people and guardians of specification and requirement gathering process. To make the picture complete, the software developers have their fair share by respecting the testing strategy and plan for the project and actively participating in its execution. The developers are paired with the QA specialists by keeping close the high overview of the project scope and vision and building the specification which they follow along the way.
So, you might be asking, has it changed so far? Yes and no. The vision of the company about the need for a department and culture which will take care of establishing, maintaining, and improving processes for this segment of the SDLC has not changed from day one. But, the team is constantly growing, our expertise is changed and improved, our portfolio of specific software quality assurance services is expanded, we managed to build and execute different QA strategies based on the needs and we expanded the team, which grew into a self-organizing team that advocates for built-in quality and continuous improvement.
In our world quality is a shared responsibility so that's why we have a QA culture instead of a sector or department and testers are Quality Assurance Engineers or Developers with expertise in assuring the quality of software.
Regarding the QA tools and assets today we have a modern tech stack - as end-to-end testing frameworks, we use Cypress, Protractor, and Specflow. For the API testing Postman, Cypress and JMeter. For performance and load testing, we use JMeter with Influx DB and Grafana for the visualization. As a test management tool, we use TestRail which helps us manage test cases, suites, and test runs. And with the model-based testing, we go through every possible scenario so for that purpose we’re using Xstate and TestModeller.
For the last couple of years, we were focusing on establishing the QA culture, a concept that has a crucial impact and meaning in our organization. The idea behind this concept is to create a centralized center of excellence, a core unit consisting of committed, high-performing individuals who are working on standardizing testing processes, metrics, tools, and mechanisms. The culture is aligning the QA approach to different project goals and providing standards and QA strategy designs to the whole organization.
We tend to perceive quality as something built into the process and incorporated into the company's values and culture. We strongly believe in the need and importance of QA specialists included in the SDLC and we struggle to reshape the position of the QA by emphasizing its importance and emphasizing the right activities associated with it.