{"id":11003,"date":"2019-02-14T02:05:02","date_gmt":"2019-02-14T02:05:02","guid":{"rendered":"http:\/\/abstracta.us\/blog\/?p=11003"},"modified":"2025-05-05T21:23:28","modified_gmt":"2025-05-05T21:23:28","slug":"software-quality-assurance-company","status":"publish","type":"post","link":"https:\/\/abstracta.us\/blog\/software-testing\/software-quality-assurance-company\/","title":{"rendered":"Why We Are Not a Software Quality Assurance Company"},"content":{"rendered":"

It’s a matter of responsibility for quality<\/span><\/h1>\n

Often times, testers get blamed when a bug makes it to production. <\/span><\/p>\n

\u201cWho tested this? Who left this untested? How could this happen? Where was the QA?\u201d<\/span><\/p>\n

I\u2019ve seen several cases in which a tester ends up being questioned if they tested something or not. Then, to defend him or herself, he or she\u00a0generates a document with screenshots filled with evidence of when he or she tested, with what data, in what environment, etc. just to be able to say, \u201cWhen I tested it, it worked. If it doesn\u2019t work in production, then it\u2019s on somebody else.\u201d This turns into an expensive and futile endeavor that doesn\u2019t add any value to the business or the user. When people within an organization have to spend time and energy defending themselves from internal threats, they will have less time and energy to focus on the user\u2019s needs and important business opportunities. \u00a0<\/span><\/p>\n

Quality is the team’s responsibility, this is part of the Agile philosophy. <\/span><\/p>\n

The questions above aren\u2019t aligned with the values nor with the principles of Agile. If we continue with the traditional software development mindset, which generates conflicts of interest between devs and testers (devs build and testers destroy what was built), we will not be able to take advantage of the real benefits of agile methodologies, which occur when a team acts as one and works in unison.<\/span><\/p>\n

In a talk I gave last year with Gabriel Montero<\/span><\/a> from Peregrinus, a partner of Abstracta, at the <\/span>Argentesting<\/span><\/a> conference, we discussed this topic and shared this picture below. Someone had told me it reminded them of a manager they once had who wore a similar expression, accusing them of not testing enough when a bug made it to the users.<\/span><\/p>\n

\"unamused<\/p>\n

<\/span>What Does Software QA Mean?<\/span><\/strong><\/span><\/h2>\n

So what does QA mean? As you know, it stands for quality assurance.<\/span><\/p>\n

If we present ourselves as \u201cthe team\u2019s QA,” we\u2019re demonstrating that we believe we\u2019re the ones that assure\/ensure quality and we are going to own those mistakes. <\/span><\/p>\n

One of the things that testers have to change in our area, to be aligned with an agile mentality, is to stop thinking of ourselves as \u201cQA.\u201d<\/span><\/p>\n

We are not the ones to determine if the quality is satisfactory before moving forward with a release.<\/p>\n

In a recent TechWell Interview, <\/span>Michael Bolton<\/span><\/a>, principal at DevelopSense and the co-creator of Rapid Software Testing, <\/span>expresses his view<\/span><\/a> on the matter as well, which is in line with our sentiment: <\/span><\/p>\n

\u201cIt\u2019s very strange, very strange that a tester, <\/span>a tester, <\/span><\/i>should sign off on the quality of a product. <\/span>It\u2019s like an investigative reporter signing off on the decision of the electoral college.<\/b> That\u2019s not how the distribution of responsibility should be in a business.\u201d <\/span><\/p>\n

[tweet_box design=”default” float=”none”]Software testers do not assure anything. There’s no way for us to do so.[\/tweet_box]<\/span><\/p>\n

 <\/p>\n

We are testers. As testers, we do testing. <\/span><\/p>\n

<\/span>What is Software Testing?<\/span><\/strong><\/span><\/h2>\n

Software testing is a process in which we provide information about the quality of a product, for someone who is interested and who is going to do something with that information<\/span>\u2014<\/span>someone who is going to make a decision. <\/span><\/p>\n

For example, we can provide the information to a manager, or to the CEO of the company who has to decide whether to put the latest version into production or not. Or, they may decide to postpone the launch to do more testing, or to take some time to fix the known bugs. <\/span><\/p>\n

What does that person need to make a good decision? They need to know:<\/span><\/p>\n