Back then, our main purpose as software testers was to be an end-user advocate. Business analysts developed features and blueprint the project, developers constructed the project, and QA Engineers would put themselves in the mindset of the person using the web-based software the project produced. Our main focus as QA Engineers was to represent the human element of the equation. Almost twenty years after I first entered the field, it still is. And not much has changed in how a customer interacts with a web app: websites have become more dynamic, interactive, faster, and with better quality video, more of a multimedia feel to them, but they still interact with the web app with a click of a mouse, or the typing of a keyboard. The customer doesn't really care what lastest JavaScript library is operating under the covers, whether Angular, Node, or React. The customer only cares about a web app being easy-to-use, intuitive, and being able to do the job in which the website is designed for, whether it is buying groceries, books, or doing research online. Mobile apps didn't shift the paradigm that much, with a finger replacing a mouse, and touch screen keyboards replacing the physical keyboard, but not has much changed in that regard.
What has changed is the speed of a software project: As software projects became smaller, from enterprise products stored on twenty CDs to having releases to your production website just-in-time, the software development process could get faster. Even though QA Engineers were now -- with the Agile Software Development Process -- brought into the fold and working on the same team, not a separate department, the relationship between them and development hasn't changed.
In an ideal world, the relationship between the developer and the QA Engineer shouldn't be the relationship between an artist and an art critic. Rather, it should be the relationship of a writer and a copyeditor. The software developer is too close to their creation to properly evaluate it, and how their possibly non-technical audience may use it. You need someone to see the web product for as it is, not how it was supposed to be, or how it is going to be just two more releases from now.
Unfortunately, Agile has been a double-edged sword for the QA Engineer. It has been great for them being integrated into the rest of the team, having a voice in the release planning, and a say in what features should and should not go into the web product in the next two weeks, planning out the day-to-day testing of the new functionality being developed. The problem is that the speed of the development has been so quick that regression testing -- checking that as the new features being built don't break the old functionality -- moved out of their hands and into the hands of automation engineers.
Between you and me, I think regression testing is the worst of the tasks of a QA Engineer. When I was acting as a QA Lead doing mobile testing, it meant me leading a team for two weeks to stare at the exact same screen and click the exact same button and type the exact same command in the exact same order in five or six different mobile devices. If there is some task that is boring, repetitive, but has to be done with precision, that task is the perfect candidate for an automated test. The only problem is that every now and then in the software industry someone floats the idea that software testing would be so much quicker if you just get rid of the QA Engineers. Doesn't a developer's unit tests cover everything? If you can replace some of the tasks a QA Engineer does, why not replace all of them?
Luckily, my current job does not have that philosophy. Manual QA is embedded with the team of developers, working side-by-side with them as the new features and functionality are being developed. The automation department I am part of comes in soon after, learning from the manual QA Engineers how they tested a feature and why, and works with them planning what should be the minimum level of content to put in the sanity tests, and how extensive to make the regression suite. Before this job, though, I found manual testing positions uncomfortably rare. Through reading job posting after job posting, everyone was looking for at least a good one year experience as an automated tester for software testing position.
Unfortunately, there is a good reason why every company is looking for manual QA Engineer's to have a bare minimum of a year of on-the-job programming experience, and it's not because of Selenium WebDriver. WebDriver is actually a very simple library to learn. The problem is the rest of the code that implements the Selenium WebDriver, whether Java, Python, Ruby, or something else. You start getting into object-oriented programming. About basic software design principles such as keeping your code DRY ("Don't Repeat Yourself"). About much more advanced software design principles such as keeping the code SOLID. About starting to learn software design patterns.
It's been six months at my current job. I am starting to pick up those programming concepts by example. Let's hope I last another six! :)
-T.J. Maher
Sr. QA Engineer, Fitbit
// Manual tester, 15 years
// Automated tester for [ 6 ] months and counting
Please note: 'Adventures in Automation' is a personal blog about automated testing. It is not an official blog of Fitbit.com.
2 comments:
testing toolsonline courses
seleniumonline courses
pythononline course
Great Blog I Have Read Your Blog It Is Very Useful For Me Thank you for posting and sharing such great information.can you help me in finding out more detail on Become a Software Tester.
Post a Comment