What DevOps changes for testers


 What DevOps changes for testers 



Actually writing a longer article about what DevOps means for software testers, but as i was inspired on a danish meetup to write something in english here is some summary about that topic.



There are a lot of definition of what “DevOps” means, most come out that DevOps is a combination of culture, practices and tools enabling to enclose the collaboration developing and operating Software.
At the moment “DevOps” is one of the most hyped buzzwords of cause it includes the roles developers and operators but what does it mean for testers? In my opinion for testers or let´s say for everyone who does quality assurance because this does not necessarily have to be testers, there are a lot of benefits of the DevOps transformation.
The practice infrastructure as code enables to set up test environments easily at almost no cost, even it enables that all requirements of the software are described in a prober way the configuration.  As there is no more need to configure target systems manually, they could just be generated on demand for any type of test. Tools for these could be Docker for containerized environments, Ansible and Vagrant if you walk on the virtual machines path. Practices like continuous integration or continuous deployment even belong to the DevOps stack and enhance the flow of software development lifecycle.

The DevOps culture enables Teams to manage infrastructure needed by themselves, which of cause could even include the Team-members with role QA or the test Teams. This might not be completely new as some testers already managed their systems in the past, but if it comes to collaboration it might keep system configuration of development less stressfull, test and production systems more automated and closer together.

Kommentare

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

SoCraTes Day Franken 2019

Bild
Am 28.09.2019 hatte die Software Craftmanship Community in den Datev IT Campus Nürnberg eingeladen, eine Veranstaltung die viel Coding und Innovation versprach und eine gute Gelegenheit alte bekannte aus der Datev SCC wieder zu treffen. Die gesamte un-Konferenz fand im Open Space Format mit 45 min Slots statt, die Location umfasste sowohl die große Kantine als auch diverse Meeting räume auf dem Campus. Das Session Angebot war großartig und breit gefächert. Neben eher auf Austausch ausgelegten Sessions gab es auch viel zum Hands On und mitmachen. Interessant war das MeetingCreatures spiel von Udo , hier beschriebt er verschieden Charaktere in einem Kartenspiel ( hier verfügbar ). Eine gute Methodik für Scrum Master oder Agile Coaches welche man z.B. in Retros einsetzen könnte um die Meeting Kultur zu verbessern. Ich habe mich mit einer Git Kata Session beteiligt, Johan hatte mir quasi auf dem gang der DevOpsDays zugerufen das seine Git Katas frei verfügbar sind und ich nut...
Mehr anzeigen

Which core competency ot the Lean Enterprise helps drive Bullt-in Quality practices?

A)  Team and Technical Agility B) DevOps and Release on Demand C) Business Solutions and Lean Systems Engineering D) Lean Portfolio Management ----  A is the correct answer,  could be found at https://www.scaledagileframework.com/built-in-quality/ "The Built-in Quality dimension of Team and Technical Agility also contains quality guidance that is generally applicable to all teams – pairing, collective ownership, standards, automation, and definition of done." © Scaled Agile, Inc. Include this copyright notice with the copied content.
Mehr anzeigen

During the final plan review, Program risks are addressed using ROAM. What do the letters in ROAM represent?

During the final plan review, Program risks are addressed using ROAM. What do the letters in ROAM represent? A) Owned, Mitigated, Active,Resolved B)  Owned, Mitigated, Resolved,Accepted C) Resolved, Assigned,Migrated, Owned D) Resolved. Owned. Approved, Mitigated --- This is a tricky questions,  The correct Answer is B as  Wrong Answer D is the only one having the words in right order.  ROAM is described in the PI Planning Section Resolved – The teams agree that the risk is no longer a concern. Owned – Someone on the train takes ownership of the risk since it cannot be resolved during PI planning. Accepted – Some risks are just facts or potential problems that must be understood and accepted. Mitigated – Teams identify a plan to reduce the impact of the risk. © Scaled Agile, Inc. Include this copyright notice with the copied content.
Mehr anzeigen