Пост на волне ажиотажа вокруг IT. Автор не в курсе теории тестирования и зачем оно нужно. Тестировщик вполне себе отдельная профессия, а не ступенька на пути в разрабы. Есть много примеров тестеров с зп больше, чем у разработчиков.
Такие статьи вызывают грусть, что профессия как-то обесценивается.
И к слову, QA это обеспечение качества. Это самое обеспечение может в себя включать и ручное, и автоматизированное тестирование, и код ревью разработчиков. Все зависит от рисков и потребностей проекта.
Вы сейчас описали именно обеспечение качества (QA) :)
Вы увидели риск для качества в описании спецификации - идем пинаем нужных людей или сами правим. Тестировать требования, разобраться в коде, если разработчики не рассказывают, автоматизировать - это все должен делать инженер по обеспечению качества, если там есть риски. Или не должен, если там проблем нет.
Сейчас какая-то подмена понятий идет... Во всех вакансиях и резюме гордо красуются буковки QA, но по факту там просто инженер по тестированию.
Все круто, но как-то получается, что вокруг автотестов (которые должны помогать) у вас слишком много проблем :) Такими темпами скоро появятся вакансии «Тестировщик фреймворков автотестирования».
Может подумать над корневой причиной — зачем вам часто менять базовый код в фреймворке и почему при изменениях есть риск, что автотесты сломаются?
И еще было бы круто, если бы был инструмент, который анализирует какие регрессионные тесты нужно запустить исходя из изменений в коде продукта!
Я думаю там процент конверсии значительно меньше, чем на hh. На Linkedin, в основном, сидят внештатные рекрутеры, они всех пачками гребут, шанс успешного трудоустройства гораздо меньше, чем при работе со штатными рекрутерами компаний, которые в основном на hh.ru.
Так что ответ на вопрос — они хуже (не по условиям, а по релевантности), но их больше и они сыпятся в пассивном режиме
Смотря какая цель. Если фаза активного поиска в короткие сроки, то да. Если неспешный пассивный поиск, то вполне. Мне пару раз в неделю пишут разные рекрутеры, с 10% я могу начать диалог и даже сходить потом на собес. И это я даже не ставил статус, что ищу работу
ML для фикса локаторов это спорная тема. Может приложение реально с багом, а тест сам себя пофиксит так, чтобы успешно завершиться. Будет ложно-положительный результат.
Но, безусловно, интересно развитие таких инструментов. В будущем, думаю, будет возможно некоторые типы тестов полностью отдать машинам, без участия человека
Это визуальные тесты. ML там скриншоты сравнивает, чтобы оценить «поехала» верстка или нет. Генерации тестов, сбора локаторов с участием ML там нет, на сколько понял
В целом, я про еще один слой абстракции, который позволяет писать тесты на псевдоязыке. Это сейчас уже синонимом BDD стало (по правде то — нет).
Ну, т.е. мне кажется проще немного подучить тестеров, чтобы они писали тесты кодом, сделать для них API удобный. Чем поддерживать этот псевдоязычный API.
Так что в итоге то с автотестерами стало? :)
Всех разогнали и автотесты разработчики пишут? А тест кейсы для конкретной фичи кто формирует?
И еще вопрос: зачем вам Specflow? Без сарказма, реально интересно. Просто во всех случаях, которые встречал, эти ваши кукумберы использовали только потому, что модно.
… нежели поддерживать его синхронизацию с assert-сообщениями (и это только вопрос времени, когда синхронизация будет нарушена)
А что значит синхронизация нарушена? Типа поменял тест, а сообщение не поменял?
Зачем вообще менять тест? Если он логики, которую он тестирует, больше нет, то тест просто выкидывается… не?
Все видели такие схемы и собирали по ним. Посыл автора в другом. По вашей схеме нужно заучить кучу формул, чтобы собирать без нее. А автор предлагает схему, в которой не нужно зубрить последовательности, а лишь запомнить общий принцип и все получится.
Почитал на других ресурсах про Y-Move, оказывается нужно было вертеть весь кубик, а не только поворачивать верхнюю грань :)
Из вашей статьи это не очень понятно было, думал, что его нужно держать всегда в одном положении.
А так, да, у меня получилось, что все средние кубики на местах, но два из них перевернуты, после переворотов всего кубика, получилось собрать центральные
Неплохо написано, но это, как бы, прописные истины :)
Да, этому мало кто следует, лишний раз можно перечитать, но хотелось бы реальных кейсов посмотреть. Что вы конкретно сделали, как это восприняла остальная команда, какие были сложности и противостояния?
У меня тоже был опыт построения более тесных взаимоотношений с разработчиками. И их лид не очень желал идти на встречу. Много усилий было приложено, чтобы коммиты моих ребят начали попадать в мастер.
Любая утилита, помогающая тестировщику, это, конечно, хорошо. Но с конкретно этим решением, мне кажется, вы выбрали тупиковую ветвь развития. Тут очень много ограничений, в которые вы упретесь со временем. И, либо бросите развивать дальше, либо придется начинать все с начала.
Если следовать вашей мотивации, то решение, вроде как, и подходит. Но мне кажется, вы немного неправильно поставили изначальный вопрос. Он бы «неудобно работать с тестовыми данными в json, как сделать удобно?». Ок, excel удобный, поехали. А если бы вы задали вопрос типа: «мне неудобно работать с данными, как сделать так, чтобы с ними вообще не работать?». Тогда бы вы пришли к построению классической системы автотестирования, которая сама подготавливает для себя тестовые данные.
В целом, у вас получилась неплохая приблуда в помощь при ручном тестировании. Но это не автотесты (хотя вы, вроде, и не претендовали). За статью, таки, минус. В карму плюс. Удачи!
Сказано, что час опытного специалиста, у него все пункты автоматом будут соблюдены. Джун, конечно, может и больше потратить, но на то он и джун. Если место достойное, то можно и неделю потратить. Конкуренция на рынке начинающих программистов не в пользу последних.
Ну это, наверно, весьма запущенный случай, если большую часть времени нужно ковырять xpath-ы… У меня был опыт, когда есть доступ к коду фронта — просто расставлял свои классы на нужных элементах. И мои селекторы были вида «input.qa_login».
Пост на волне ажиотажа вокруг IT. Автор не в курсе теории тестирования и зачем оно нужно. Тестировщик вполне себе отдельная профессия, а не ступенька на пути в разрабы. Есть много примеров тестеров с зп больше, чем у разработчиков.
Такие статьи вызывают грусть, что профессия как-то обесценивается.
И к слову, QA это обеспечение качества. Это самое обеспечение может в себя включать и ручное, и автоматизированное тестирование, и код ревью разработчиков. Все зависит от рисков и потребностей проекта.
Вы сейчас описали именно обеспечение качества (QA) :)
Вы увидели риск для качества в описании спецификации - идем пинаем нужных людей или сами правим. Тестировать требования, разобраться в коде, если разработчики не рассказывают, автоматизировать - это все должен делать инженер по обеспечению качества, если там есть риски. Или не должен, если там проблем нет.
Сейчас какая-то подмена понятий идет... Во всех вакансиях и резюме гордо красуются буковки QA, но по факту там просто инженер по тестированию.
Может подумать над корневой причиной — зачем вам часто менять базовый код в фреймворке и почему при изменениях есть риск, что автотесты сломаются?
И еще было бы круто, если бы был инструмент, который анализирует какие регрессионные тесты нужно запустить исходя из изменений в коде продукта!
Так что ответ на вопрос — они хуже (не по условиям, а по релевантности), но их больше и они сыпятся в пассивном режиме
Но, безусловно, интересно развитие таких инструментов. В будущем, думаю, будет возможно некоторые типы тестов полностью отдать машинам, без участия человека
Ну, т.е. мне кажется проще немного подучить тестеров, чтобы они писали тесты кодом, сделать для них API удобный. Чем поддерживать этот псевдоязычный API.
Всех разогнали и автотесты разработчики пишут? А тест кейсы для конкретной фичи кто формирует?
И еще вопрос: зачем вам Specflow? Без сарказма, реально интересно. Просто во всех случаях, которые встречал, эти ваши кукумберы использовали только потому, что модно.
А что значит синхронизация нарушена? Типа поменял тест, а сообщение не поменял?
Зачем вообще менять тест? Если он логики, которую он тестирует, больше нет, то тест просто выкидывается… не?
Вы уж определитесь как хотите их называть. ИМХО, «SRE-инженер» звучит как-то тавтологически.
Из вашей статьи это не очень понятно было, думал, что его нужно держать всегда в одном положении.
А так, да, у меня получилось, что все средние кубики на местах, но два из них перевернуты, после переворотов всего кубика, получилось собрать центральные
А как быть, когда на свои местах, но перевернутые? Ведь они переворачиваются, только при перемещении.
Да, этому мало кто следует, лишний раз можно перечитать, но хотелось бы реальных кейсов посмотреть. Что вы конкретно сделали, как это восприняла остальная команда, какие были сложности и противостояния?
У меня тоже был опыт построения более тесных взаимоотношений с разработчиками. И их лид не очень желал идти на встречу. Много усилий было приложено, чтобы коммиты моих ребят начали попадать в мастер.
Если следовать вашей мотивации, то решение, вроде как, и подходит. Но мне кажется, вы немного неправильно поставили изначальный вопрос. Он бы «неудобно работать с тестовыми данными в json, как сделать удобно?». Ок, excel удобный, поехали. А если бы вы задали вопрос типа: «мне неудобно работать с данными, как сделать так, чтобы с ними вообще не работать?». Тогда бы вы пришли к построению классической системы автотестирования, которая сама подготавливает для себя тестовые данные.
В целом, у вас получилась неплохая приблуда в помощь при ручном тестировании. Но это не автотесты (хотя вы, вроде, и не претендовали). За статью, таки, минус. В карму плюс. Удачи!
Сказано, что час опытного специалиста, у него все пункты автоматом будут соблюдены. Джун, конечно, может и больше потратить, но на то он и джун. Если место достойное, то можно и неделю потратить. Конкуренция на рынке начинающих программистов не в пользу последних.
Вот только бы еще отвечали на подобный вопросы. А то в лучше случае отпишутся шаблонным «На данный момент не готовы сделать вам предложение»