Comments 13
Если подумать, то у нас вся компания – тестировщики.
Похоже, вы реально не понимаете, для чего нужны специальные люди QA-инженеры и как продуктивно с ними работать. При правильном применении это сэкономит массу времени и денег.
+1
Скорее всего и вы не совсем понимаете тк. не знаете всех деталей. Судя по описанию, у них венегрет разных стеков и чтобы что то протестировать нужнод много особых знаний которыми должен обладать тестировщик. И мне кажется что таких очень сложно найти или подготовить.
Хотя с другой стороны, если люди уходили и не хотели обучаться… то похоже что в процессах действительно что то не так.
Сама статья сухая… все ждал интересных тех подробностей, но нет… Причину написания поста не совсем понял…
Хотя с другой стороны, если люди уходили и не хотели обучаться… то похоже что в процессах действительно что то не так.
Сама статья сухая… все ждал интересных тех подробностей, но нет… Причину написания поста не совсем понял…
0
Не нужно быть семи пядей во лбу, чтобы предположить их потребности, так как это вполне себе обычный проект с SPA-сайтом и мобильными приложениями. В таком проекте QA отдел просто необходим, выгода от него очевидна. Впрочем, я встречал небольшие проекты, где тестировали топ-менеджеры. Забавно смотрелось.
-1
Ну вот мы и предположили ) Более того, с большой вероятностью, большинство разработчиков с вами согласны, даже те, кто работает у них самих но…
Вот ключевой момент, как мне кажется, согласитесь, это далеко не типично. И ключевая проблема как мне кажется именно в этом. Нет смысла гадать, но скорее всего на беке обязали покрывать все тестами, а для фронта, коме тестов, привлекли тех же самых специалистов и для тестирования.
И возможно теперь вы согласитесь, это экономически более выгодно. А просто содержать целые отделы ради «правильности» подхода не целесообразно.
Итого на текущий момент у нас в бэкэнде Python, Kotlin/Java, Go, Ruby. На фронтэнде доминант у нас React. (+ что то на ангуляре)
Вот ключевой момент, как мне кажется, согласитесь, это далеко не типично. И ключевая проблема как мне кажется именно в этом. Нет смысла гадать, но скорее всего на беке обязали покрывать все тестами, а для фронта, коме тестов, привлекли тех же самых специалистов и для тестирования.
И возможно теперь вы согласитесь, это экономически более выгодно. А просто содержать целые отделы ради «правильности» подхода не целесообразно.
0
Без ручных тестировщиков разработчик начинает трепетнее относится к работоспособности своего компонента (будь то бэкэнд или фронтэнд), так как в случае возникновения ошибок обвинить кого-то кроме как себя не остается. Такая организация естественным способом заставляет разработчика больше думать о тестировании, точнее об автотестировании — разработчик начинает больше покрывать свой компонент тестами.
Я соглашусь, что QA специалист может быть весьма полезен в тестировании комплексно всей системы, например, для проверки корректности бизнес-процессов, которые начинают протекать в системе, составленной из множества компонент.
Я соглашусь, что QA специалист может быть весьма полезен в тестировании комплексно всей системы, например, для проверки корректности бизнес-процессов, которые начинают протекать в системе, составленной из множества компонент.
+2
К сожалению, Ваши познания о QA весьма примитивны. QA ведь не для того, чтобы приставить manual tester для каждого разработчика, чтобы разгрузить его от тестирования.
Задач у QA-отдела по сути несколько:
1) Не пропустить в релиз сырой продукт. Хороший QA стоит дешевле разработчика, а тестирует продукт в разы лучше.
2) Проверять и расписывать кейсы, поступающие от пользователей в процессе работы с продуктом.
3) Готовить сопровождение по продукту — тулзы для тестов, различные окружения, документацию, что весьма ценно для разработчиков, так как экономит их время.
Задач у QA-отдела по сути несколько:
1) Не пропустить в релиз сырой продукт. Хороший QA стоит дешевле разработчика, а тестирует продукт в разы лучше.
2) Проверять и расписывать кейсы, поступающие от пользователей в процессе работы с продуктом.
3) Готовить сопровождение по продукту — тулзы для тестов, различные окружения, документацию, что весьма ценно для разработчиков, так как экономит их время.
0
А какие приложения перевели на PWA и почему (у вас на сайте не нашел)? Что вообще думаете по поводу перспективы PWA-приложений?
0
PWA — некорректное название в статье. Речь идет скорее про гибриды, т.к. Apple не дают полную поддержку pwa, все равно приходится делать обертки из, допустим, cordova. Есть 1 полноценное гибридное приложение (бизнес — логика на вебе и сервис воркерах). Дистрибуцируется через внутренний магазин, 10 000 пользователей. Полет более чем нормальный. Лично я верю в PWA и прочие технологии, т.к. писать один и тот же код 3 раза (Веб, IOS, Android)- архитектурный антипаттерн.
0
Интересненько
+1
Сейчас во всем ДомКлике более 700 людей.
Сколько из них разработчиков?
0
0
Sign up to leave a comment.
Путь от молодого стартапа до технологической компании, которая делает высоконагруженные проекты в сфере недвижимости