What is DevOps, You Ask?
First, a quick primer on our subject matter.
Ask ten software professionals what
DevOps is and you’re likely to get ten different answers, and this is where the problem starts.
At its simplest definition, using a
DevOps method means that previously isolated teams such as development, QA, Business, and Operations communicate more frequently, more in depth, and work together in a collaborative manner and share responsibility for the end product.
This isn’t unlike other methodologies out there, such as Agile.
And like similar methodologies,
DevOps aims to help teams put software and services into production faster and with higher quality.
With a stress on communication, integration, automation, and collaboration, teams use tools and policies to facilitate faster delivery with increased quality.
Many teams aim for continuous improvement via extremely fast release cycles with smaller, incremental changes that pose less risk due to affecting such small parts of the system.
There’s certainly nothing wrong with that at all, isn’t that what we all want?
Misuse #1 – The Jack-of-all-trades approach. Some teams misconstrue
DevOps to mean that each member of the team plays multiple roles.
The developer is also the DBA and the build manager, for instance; the BA is also the QA person, so on and so forth.
This kind of ‘jack-of-all-trades’ approach is necessary for small startups who don’t have the capital to hire larger teams.
But it means that corners are cut, individuals are stressed to the max, and each different task that a person branches out to perform is done with decreasing quality.
People specialize for a reason – one person cannot know and do everything well for an indefinite period of time. Continuing this kind of process as the company grows and the demand increases will only rapidly burn out team members. Not to mention that continual task switching actually slows people down and costs both time and money.
Choose the right person for a specific job. It’s to any team member’s advantage to have multiple skill sets – it makes them more employable as an individual and more indispensable as a team member.
It’s also great for the team and business to have team members who can perform multiple roles when the need arises, but it should not be the preferred state.
Misuse #2 – The release-too-fast approach. Some teams release multiple times a day and such a rapid release schedule inevitably means cutting corners.
As those of us who have been in QA for a while know, QA is often a big target for such cuts.
It seems as though we’ve only just gotten to the point of full acceptance of how valuable effective QA is for a team, and now those managers who never really bought into it are using DevOps as an excuse to cut QA again.
It’s not overt since they do claim that they desire quality, but they just don’t allow for the time to actually achieve it.
This speed at the cost of testing and quality assurance does not result in a quality end product.
And, releasing poor quality software – no matter how quickly – is not beneficial for any business.
While
DevOps methods can aid in speeding up releases, it needs to be tempered with equally efficient quality assurance.
Misuse #3 – The automate-everything-approach The major push now is to automate, automate, automate.
Unit tests, functional tests, even delivery.
Again, in theory there’s nothing wrong with automation, but in practice every single aspect of development and QA cannot be automated.
Doing so leads to removal of the human element of actually using and exploring a system the way a human is apt to do.
Removing that aspect can lead to glaring defects that end users will ultimately find.
Automated tools can merely check code, they can’t actually test.
They can’t problem solve, they can’t explore and find different paths, and neither can they determine aesthetics or usability. While testing should always be supported by tools, it still requires a human element.
Testers need tools and should know how to use them and use them well, but these tools can never replace the tester despite how badly a manager may want them to.
Meaningful exploratory, human testing will always be necessary.
But there will continue to be managers who misconstrue
DevOps to mean replacing the testers with an automated tool that simply checks code.
Final Notes
The deeply collaborative, quicker released, and higher quality products that DevOps aims for simply cannot be done without adequate testing.
Without a doubt automation is necessary and testers need to adapt their skills to a faster paced world.
While all testers really should have some level of coding skills, we can’t and shouldn’t assume that the future of all quality assurances lies in testers becoming programmers.
Developers aren’t the only one expected to multi-task, testers need to as well.
It would help to learn some architecture, some coding skills, and the business aspect.
The more that a QA professional can do, the more beneficial they are to any team, but they’re still needed as testers, not developers.
QA professionals should always keep their skills up to date and keep an eye to future needs in this ever-changing world of technology.
But should they be worried their jobs disappearing? No.
They should learn to automate, keep their skills fresh, maintain the ability to adapt, and understand that a human tester will always be needed. At least until SkyNet is created.
Best Regards · Mit freundlichem Gruß · Cordialmente ·
André VondranThink Green! Please don’t print if it’s not necessary.
"""""
![6
IM
TEDEVOPS
A
: —
(L102), [1]
NTE](https://contents.bebee.com/users/id/12146962/article/what-is-devops-you-ask/_b13c180b-950.webp)
Comentarios