What's in a title?: Difference between revisions

Jump to navigation Jump to search
m
mNo edit summary
Line 42: Line 42:


== I am a Software Quality Engineer ==
== I am a Software Quality Engineer ==
Although, I do feel a little conflicted because '''quality''' is really an attribute ''of'' something, not some we can engineer by itself. However, the title seems to have gained traction over the recent years as meaning a broader engineering role focussed on software quality, which I can certainly sign up to. We build and engineer tools, systems, and processes to help us efficiently analyse and monitor the quality of software solutions. Testing is a wide and varied endeavour, but there is real value in being able to quickly get basic quality information about a code change through automation. The objective being to automate the boring and free up the tester to explore more and deeper. Automation of course, covers so much more than simply automating the product itself, but also in preparing the product to be ready for testing, the local development environment, the version control and branching strategy, the CI/CD pipelines, the creation of test environments and infrastructure, the preparation of test data in an environment, the capture and aggregation of (test) environment logging and monitoring data, and much more. All of these tasks may lend themselves to degrees of automation, and can each take a serious chunk of (boring) time to do without the automation. Creating the whole interconnected ecosystem necessary to efficiently determine the quality of a software solution I believe is a genuine engineering activity.  
Although, I do feel a little conflicted because quality is really an attribute of something, not some we can engineer by itself. However, the title seems to have gained traction over the recent years as meaning a broader engineering role focussed on software quality, which I can certainly sign up to. We build and engineer tools, systems, and processes to help us efficiently analyse and monitor the quality of software solutions. Testing is a wide and varied endeavour, but there is real value in being able to quickly get basic quality information about a code change through automation. The objective being to automate the boring and free up the tester to explore more and deeper. Automation of course, covers so much more than simply automating the product itself, but also in preparing the product to be ready for testing, the local development environment, the version control and branching strategy, the CI/CD pipelines, the creation of test environments and infrastructure, the preparation of test data in an environment, the capture and aggregation of (test) environment logging and monitoring data, and much more. All of these tasks may lend themselves to degrees of automation, and can each take a serious chunk of (boring) time to do without the automation. Creating the whole interconnected ecosystem necessary to efficiently determine the quality of a software solution I believe is a genuine engineering activity.


== My old (pre 2024) intro ... ==
== My old (pre 2024) intro ... ==

Navigation menu