Отличная книга по тестированию от Гугл для начинающих, продолжающих и освоившихся! Ручное и много автоматизированного тестирования. История и факты про процессы, инструменты, людей, команды и топов в тестировании.
Ставит мозги, утверждает и структурирует собственные догадки и находки. Опровергает ошибочные ожидания.
Много практических советов. Часть советов по инструментам уже успешно попробовал на практике.
Книга про софт, но также важные взаимозависимости и требования к тестированию на различном железе.
Книга уже классика и давно не новая, но все равно сильно рекомендую и для своей команды и организации, всем кто интересуется разработкой программных продуктов, качеством.
Также советую всем новичкам в тестировании как одно из первых пособий по тестированию и вхождению в ИТ.
На русском языке бесплатная электронная версия любезно предоставляется издательством Питер, ссылка в статье на Хабре, https://habr.com/ru/company/piter/blo…
Finally finished one of the best old classic book on software development practices.
Java code examples. Agile and test driven development quality practices. Many code examples. Step-by-step instructions. Good and interesting reasoning and motivation examples about lean, agile and tdd development. Addresses code and software architecture principles. Code readability and maintainability. Meaningful code.
Definitely strongly recommend for all colleagues, mates, friends and broad society who involved and responsible for coding, programming, software architecture. To benefit from code maintainability, reusability. Sustainable code also.
Not least – fun and entertaining, all from old good fun and serious Bob Martin!
Disclaimer: Clean Code as a concept itself of course only one of many reliable and viable methodologies which may or may not match your team and project. In case your team see benefits from Clean Code practices – strongly recommend book as a pragmatic everyday manual or almost reference document for your group coding work.
There is SAFe, which looks grow in popularity. There is LeSS which has it’s fans as well. There is common acknowledge and understanding of needs for bridging and adopting agile practices to non-traditional for agile organisations, departments and products. There are even those who are traditionally digitally intensive organisations or departments who are challenged by modern next generation of digital transformation and even they strive to adopt, implement and practice scaled agile practices the right way. There are new roles and processes which required by new agile frameworks and old ones which became obsolete and often there is no obvious and clear one-to-one transformation path exists.
Some organisations see the necessity to coordinate multiple agile teams and try intuitively borrowing some concepts from scaled frameworks run own adoption which are some variants of scrum-of-scrums.
SAFe and LESS being both targeted to support scaling agile have slightly different approaches. SAFe is more declarative framework with defined methods, structures and roles ready to execute which expects that the whole organisation is being transformed almost at once. LeSS tries to help support applying agile methodology to a group of scrum teams working on the same product being the same scrum as on team level.
Helping organisation in adoption requires to be pedagogical, careful. It requires respect and understanding for existing processes and hybrid processes under transformation and transition. Those processes works often as bridges to fill the gaps between parts of organisation with established and well-functioning agile practices and those other parts of organisations where agile practices are not intuitive to understand and adopt directly.
I’ve recently got a question about how should or should not, how and when a desktop app development team’s separate developers move to next version of a framework. The question was merely about patch version change. The case is part of developers happened step forward and some developers got error due to patched version was not installed on their computers.
This particular case was about move from .NET 4.7.1 to .NET 4.7.2. This is of course for the case where particular Windows version doesn’t come with required framework version pre-installed.
So apart from decision for the team to baseline solution framework dependency to .NET 4.7.2 and proceed and install manually .NET 4.7.2 where it’s missing on developer computers, I got an idea about the problem would be better solved to find and adapt a solution where development environment both specified, distributed and potentially automatically executed the same way as in containerized environment, like docker. Or other good example local virtual development environment management like in python frameworks and tools – for example anaconda. Important part of the idea is that environment requirements and dependencies are managed the same way as most package management solutions do and reside of course under code source control.
Spontaneously I couldn’t come with anything better than Chocolatey or Nuget with plain Powershell scripting. Could there be better established and more complete tools and solutions? The idea is to have something which is not yet completely virtualized machine as virtualbox with vagrant. But more like automated isolated package environment with slightly broader platform and stack independence so it could be for example both .NET framework, packages but also let say python and javascript environments. So what I could start thinking is something more like ansible and similar tools. The problem is that they have quite big learning and implementation curve. Still could be not natural for part of developer roles to use as a local developer environment automation.
So I have no good answer as for now but will investigate and test appropriate tools. See if it is possible to find good solution for the case. I will give a try and test to make Chocolatey environment specification or simply powershell script.
Thanks for reading and would be interesting to know if you have similar challenges and how you approach them. Maybe there are some good solutions out there or some of you succeeded to do something good! You are welcome to share your experience if you will! It would be really interesting!
Software Architecture and Development Career 