Hawaiian? Pepperoni? There are lots of flavors out there for pizza and getting analogy from these flavors. These flavors can represent different things - an organization, a family, a process, etc.
And for this article, all those flavors may refer to the types of software application your team is involved with and whatever it is – one thing that matters to everybody, is the Software Quality, and that quality can be measured by different metrics/factors - has it been released within the schedule with targeted users or marketing campaign?, is it matching the user requirements and related technical docs?, does it handle error/negative scenarios well?, does it has lesser and minor bugs? (take note, I didn’t mentioned zero defects as in real situation, it is seldom that an application gets on production with zero defect thus we can discuss this – entirely separate article J ), etc.
But regardless how we measure/rate the Software Quality is. One thing is sure, Software Quality is not just for Software/QA tester/professionals alone, but everybody on the team can contribute to the overall quality.
THE BLAME GAME
As I agree the bulk of work could be on us, QA professionals, but it doesn’t mean that the other members of the team can’t contribute a thing or two to overall Software Quality.
With more-than-a-decade of solid experience in Software Quality and Assurance Testing, I’ve seen enough from higher ups to within the core team, and I’ve seen how others (not QAs) seem to deviate themselves from quality assurance as the mentality in their head, it is solely in QA plate.
As I would agree that everybody has their specific roles (developers to develop/code, business analysts to gather requirements and translate them to organized docs, etc.) to focus on and that’s understandable, but adding an extra effort to make your work better will be very beneficial.
WORK BETTER – DO THAT EXTRA MILE
Let me give two examples.
One is if you’re a Business Analysts(BA), and as you gathered those requirements and began translating them to technical docs and while doing your write-ups, flowcharts, illustrations, etc., if you saw some loophole or some scenarios that leads nowhere and you are not as well quite sure what will happen next (if user click on that, do that) For that moment, you can immediately ask the client/customer what they would be expecting in that particular scenario and you have captured that scenario right from the very start and it could have save lots of efforts and money doing coding/testing.
Imagine, if that would have been left out, and QAs find it later and found out its impact is very important to the customer. Then, it happens to be not doable or will do major change to the current development, it will take a lot of effort or everyone’s back to zero as it will need redesign. Or worst one, the client backs-off and feel dissatisfied how the team handled the software development. By the way, this type of testing is called Review (the first part of Static testing) where one try to find and eliminate errors or inconsistencies in the technical documents (reference: https://www.tutorialspoint.com/software_testing_dictionary/static_testing.htm)
Second example is when you’re a developer and does same thing. During coding of one of the features of the application or while trying to fix one of the errors, you noticed that the changes you are going to make will have an impact to other functions, but neglected it as you believe you don’t have enough time, that is not important, etc. But when QA found it during testing process, it was caught, communicated and of course, given back to dev for fixing. Then when the dev tried to fix it, the changes has now a bigger impact since the code is now integrated with other functions. Resulting to take a lot of effort and communications again why it is not been found during development, etc. Again, it will have the same impact as above. Thus, it will really be beneficial if everyone in the team would take that extra mile, contributing to software overall quality, directly and/or indirectly.
LET BYGONES BE BYGONES
Gone are the days of ‘Devs’ vs ‘QAs’. That when ‘QAs’ are being called to as ‘Anti-Devs’. There is no faction in here, we all just doing our roles.
And for this article, all those flavors may refer to the types of software application your team is involved with and whatever it is – one thing that matters to everybody, is the Software Quality, and that quality can be measured by different metrics/factors - has it been released within the schedule with targeted users or marketing campaign?, is it matching the user requirements and related technical docs?, does it handle error/negative scenarios well?, does it has lesser and minor bugs? (take note, I didn’t mentioned zero defects as in real situation, it is seldom that an application gets on production with zero defect thus we can discuss this – entirely separate article J ), etc.
But regardless how we measure/rate the Software Quality is. One thing is sure, Software Quality is not just for Software/QA tester/professionals alone, but everybody on the team can contribute to the overall quality.
THE BLAME GAME
As I agree the bulk of work could be on us, QA professionals, but it doesn’t mean that the other members of the team can’t contribute a thing or two to overall Software Quality.
With more-than-a-decade of solid experience in Software Quality and Assurance Testing, I’ve seen enough from higher ups to within the core team, and I’ve seen how others (not QAs) seem to deviate themselves from quality assurance as the mentality in their head, it is solely in QA plate.
As I would agree that everybody has their specific roles (developers to develop/code, business analysts to gather requirements and translate them to organized docs, etc.) to focus on and that’s understandable, but adding an extra effort to make your work better will be very beneficial.
WORK BETTER – DO THAT EXTRA MILE
Let me give two examples.
One is if you’re a Business Analysts(BA), and as you gathered those requirements and began translating them to technical docs and while doing your write-ups, flowcharts, illustrations, etc., if you saw some loophole or some scenarios that leads nowhere and you are not as well quite sure what will happen next (if user click on that, do that) For that moment, you can immediately ask the client/customer what they would be expecting in that particular scenario and you have captured that scenario right from the very start and it could have save lots of efforts and money doing coding/testing.
Imagine, if that would have been left out, and QAs find it later and found out its impact is very important to the customer. Then, it happens to be not doable or will do major change to the current development, it will take a lot of effort or everyone’s back to zero as it will need redesign. Or worst one, the client backs-off and feel dissatisfied how the team handled the software development. By the way, this type of testing is called Review (the first part of Static testing) where one try to find and eliminate errors or inconsistencies in the technical documents (reference: https://www.tutorialspoint.com/software_testing_dictionary/static_testing.htm)
Second example is when you’re a developer and does same thing. During coding of one of the features of the application or while trying to fix one of the errors, you noticed that the changes you are going to make will have an impact to other functions, but neglected it as you believe you don’t have enough time, that is not important, etc. But when QA found it during testing process, it was caught, communicated and of course, given back to dev for fixing. Then when the dev tried to fix it, the changes has now a bigger impact since the code is now integrated with other functions. Resulting to take a lot of effort and communications again why it is not been found during development, etc. Again, it will have the same impact as above. Thus, it will really be beneficial if everyone in the team would take that extra mile, contributing to software overall quality, directly and/or indirectly.
LET BYGONES BE BYGONES
Gone are the days of ‘Devs’ vs ‘QAs’. That when ‘QAs’ are being called to as ‘Anti-Devs’. There is no faction in here, we all just doing our roles.
For devs, example, instead of remembering the past that a specific QA make your life harder by finding that unexpected defect in your code that you’re so proud of. Step back and inhale. Take it as a challenge and positively, that it’s a good thing that it was found during testing by QA in development environment, rather not by customer or stakeholders in production site.
Same goes for QA’s, don’t take it personal. If a specific developer make your life harder by doing lousy development and you still need to create defect even for obvious issues (submit button is not working, redirection not ok, etc.). Take it easy and communicate it properly and professionally, just do your work, after all that is your role and expertise. Do not take it against the person but to his work.
EVERYBODY WINS
As everyone takes out their personal grudges/feelings, stop pointing fingers (blame game) and do the extra mile to their respective roles, the benefits will be massive and surely, everybody wins.
With Software Quality being shared to everyone’s role from the start till the end in any software development life cycle, a better software quality can be deployed in shorter time, reducing costs and efforts and avoiding reschedules or delays. This will surely earn the satisfactions of the clients/stakeholders/users of the software product.
This is surely not easy, but once your team/organization apply this, it will certainly be worth it.
Same goes for QA’s, don’t take it personal. If a specific developer make your life harder by doing lousy development and you still need to create defect even for obvious issues (submit button is not working, redirection not ok, etc.). Take it easy and communicate it properly and professionally, just do your work, after all that is your role and expertise. Do not take it against the person but to his work.
EVERYBODY WINS
As everyone takes out their personal grudges/feelings, stop pointing fingers (blame game) and do the extra mile to their respective roles, the benefits will be massive and surely, everybody wins.
With Software Quality being shared to everyone’s role from the start till the end in any software development life cycle, a better software quality can be deployed in shorter time, reducing costs and efforts and avoiding reschedules or delays. This will surely earn the satisfactions of the clients/stakeholders/users of the software product.
This is surely not easy, but once your team/organization apply this, it will certainly be worth it.
Comments
Post a Comment