For the past eight years, I have moved from one company to another, finding the right company for me to work and gain experience. One of the characteristics that I looked for was the testing culture that the company practiced. Here are a few testing cultures that I experienced working with.
Company A
Company A was the first company that I worked with related to software quality. I learned the proper process and procedures on how to verify and validate software products. Since it is an independent software testing service provider, it has a heavy process and following standards such as ISO(International Organization for Standardization), TMMi(Test Maturity Model integration), and IEEE(Institute of Electrical and Electronics Engineers). For example, one test cycle is only for one specific version and build. Retesting or confirmation testing is to be conducted in another test cycle.
The documentation for testing is very comprehensive and consists of the test plan, test design, test cases, test log, test incident, and test summary report.
My thought about quality when I worked here was that the software must meet all the expectations, else it is bad quality software. As a junior software tester, I was always worried if I could not find any bug. I had the perception that if no bug was found, it meant I am not a good tester.
Company B
Company B is a project-based company that receives projects from clients. When I worked here, they have just started to set up a QA team. I was reporting to a manager who was quite new to software quality. The manager trusted us, the subordinates, to do testing using our style.
The challenge that I faced there was not how to satisfy the manager, but the perception of the product engineering team. To them, QA’s only responsibility is to execute tests. They had no idea that test execution is only one of the testing activities.
There was no proper process being communicated across the team. They only had a basic idea of the development life cycle which includes requirement gathering – coding – testing – maintenance. The Application Under Test (AUT) was not ready to enter the testing phase. Besides that, the test environment was also unstable as many deployments happened during test execution.
The documentations that they referred to were product flow chart, tickets in the ticket management system, and User Acceptance Test (UAT) test cases.
My perception of quality when I worked here was, “delivering just enough software quality is alright”.
Company C
Company C is a product-based company that builds its products and markets them internationally. They had a small QA team that helped with testing before the product went live. In my opinion, their agile practices were quite structured as they had a consistent bi-weekly sprint cycle.
The product engineering team had a similar perception as Company B, thinking that testing is an easy activity. If there was any delay from the development phase, the timeline was fixed and remained unchanged. Indirectly, the QA timeline was crunched to meet the expected timeline. The estimation was rigid as they were not considering other project risks such as people was on leave or other events like public holidays.
The documentation that they used were excel sheets and tickets in the ticket management system.
My thought about quality when I worked here was, “try to meet the best quality by designing and executing test cases, and report as many bugs as possible within the time given”. This was because if there was any bug that managed to slip into production, QA was at fault.
Company D
Company D is a product-based company related to the e-commerce industry. Like Company B, they have just started to establish a QA team. I reported to an experienced leader in software quality. His direction for the team was interesting where he wanted the team to move into test automation without neglecting manual testing. He also mentioned that quality is the whole team’s responsibility.
In the early years, we had no documented nor official QA process. The product engineering team had a basic process of plan-design-code-test-release. They incorporated agile methodology into the development life cycle. There were daily stand-ups, bi-weekly sprint planning, retrospective meetings, and many more. We were also moving to a mindset where quality is a team effort.
We started to give awareness about software quality, the concept of early testing, and the test pyramid across the product engineering team. It was not an easy journey, but I can see that the team started to believe that that quality is everybody’s responsibility. Any decision will always be a team decision.
What was interesting about Company D was the people in the product engineering team. They welcomed any new idea from anyone regardless of whether they were a junior engineer or an engineering manager.
My thought about quality while working there was “we strive for the best quality product, at the same time keep on learning new things and improving our workflow to work better”.
The table below sums up my ratings on the testing practice that I experienced based on four criteria.
(Scale 1 = not satisfied, 5 = very satisfied)
| Criteria | Company A | Company B | Company C | Company D |
| Release smoothness | 4.0 | 3.0 | 3.5 | 4.0 |
| Product quality | 4.5 | 3.0 | 4.0 | 4.0 |
| Documentation | 4.0 | 2.0 | 3.0 | 3.5 |
| Manager testing experience | 3.0 | 1.0 | 1.0 | 4.0 |
Based on these experiences, I can summarize that
- The test process ensures consistency and stability. We can predict the outcome and lower the product risks.
- Documentation can give an impact on the product quality as it gives us clear information such as the test goal, test scope, and test coverage.
- Hiring an experienced test leader is crucial to ensure accountability and to align the organizational test strategy with the company’s needs.
- Every company has its testing approach. Testing culture depends on the organization, what is best for one company may not be the best for another. For example, Company A has the most comprehensive process but might not be suitable for other organizations because too process-heavy and hard to follow. We need to fine-tune with the team demographics and working experience.
- Your perspective about quality will change based on which testing culture you are in.
- An organization’s working culture will affect the organization’s testing culture. Being in an organization that always welcomes new ideas allows us to learn and improve a testing culture that leads to developing a new practice of software quality.
- A mature test process can contribute to good software product quality with fewer defects. This can be achieved by learning and improving. We can start by defining a high-level organizational test strategy and discussing it with the management.
Referring to the title, which would be the best testing culture? From my point of view, I believe that Company D has the best testing culture, due to the organization’s working culture that produced good values. It embraces change to be better every day, always inventing, improving, and innovating. Indirectly, it influences the evolution of a good testing culture in the company.
Know our Super Writer:
Sarah Mohammed
Sarah Mohammed is a QA Engineer and working in Fave for the past 3.5 years. Her passion for software quality started after she took her first software testing course, 8 years ago. Since then she realized that there are so many areas that she can explore in the software quality world. She is now interested in learning more about test process improvement.
