Комментарии

Все зависит от продуктового стека и того, чем автоматизируется тестирование. В DST Global лично у меня:

Linux/macos
VScode
Pytest
DST CRM
Jenkins
Bitbucket

И еще вопрос — какими инструментами пользуются тестировщики: окружение, редакторы и IDE, библиотеки и фреймворки?

Это очень сильно зависит от подхода к тестированию в конкретной компании. Часто бывают случаи, что тестировщику вообще не приходится заглядывать в код. Особенно это может касаться различных embedded решений или прошивок устройств. Но знать, как разрабатывается продукт, как он работает, и почему сделано именно так, тестировщик должен.

Интересно, чтобы проверять написанные программистами приложения, тестировщик должен разбираться в коде лучше программистов. Этот тезис верный или нет?

С финансовой — к позиции программиста. Вот только смотри пункт про образ мышления. Есть мнение, что тот, кто рожден быть хорошим тестировщиком, будет паршивым программистом. И наоборот.

И опять особняком автоматизаторы: часто их зарплаты сопоставимы с программистами. Именно потому, что они, по факту, занимаются разработкой, и им платят, чтобы они действительно не ушли в разработку.

Спасибо за развернутый ответ. А тогда с финансовой точки зрения к чему выгоднее стремиться: к позиции тестировщика или программиста?

1. Проще сказать, чем они похожи: оба специалиста работают над тем, чтобы на выходе получился качественный продукт, отвечающий требованиям заказчика. В остальном это совершенно разные направления работы.

Конечно, есть отдельные специализации, такие, как специалист по автоматизации тестирования (test automation engineer) или разработчик в тестировании (software development engineer in tests), чья работа почти идентична работе программиста. Она предполагает написание кода автоматических тестов и тестовых фреймворков.

Но в целом задачи тестировщика слабо перекликаются с задачами программиста. Анализ требований, составление тестового плана с учетом покрытия требований, выполнение ручного тестирование и запуск автотестов, подготовка отчетов — вот работа тестировщика. Если не рассматривать уровень простого мануального тестирования, я бы сказал, что такая работа имеет значительно большую аналитическую составляющую, чем техническую.

Валидация продукта требует от тестировщика достаточно большого кругозора, так как приходится смотреть на продукт глазами пользователя, понимать его потребности. Надо уметь «быть пользователем» и знать его потребности, что непросто, если речь идет о специализированных решениях. Надо знать отраслевые стандарты, которым должно соответствовать решение, и уметь это соответствие проверить. Надо уметь находить способы тестирования совместимости с конкурентными решениями.

Кроме того, от тестировщика требуется другое мышление. Способ думать разработчика должен привести его к одному правильному и оптимальному сценарию решения проблемы. Способ думать тестировщика ведёт его ко всему многообразию сценариев, которых, по определению, больше.

Еще раз повторюсь: мы не рассматриваем автоматизаторов и разработчиков в тестировании, потому что они, на мой взгляд, всё же разработчики, а не тестировщики.

2. По поводу вопроса — кем проще стать: разработчиком или тестировщиком?

Тестировщиком. Но не потому, что им быть проще. Просто порог входа ниже. Карьера разработчика начинается с позиции junior software developer, которая требует наличия минимальных знаний: язык программирования, основные алгоритмов и структур данных, знакомство с фреймворками и так далее. Чтобы стать джуном, ты уже должен быть разработчиком.

Карьера тестировщика начинается с уровня специалиста по ручному тестированию (manual testing): есть описание тестов, делай руками, вноси результаты в отчет. Очевидно, что начинать во втором случае проще.

Спасибо за ответы Марат. У меня есть еще два вопроса.

1. Чем работа тестировщика отличается от работы программиста? И что есть общего в работе тестировщика и программиста?

2. Кем проще стать: разработчиком или тестировщиком?

Я бы сказал, что для программистов первично знание программирования. Языки и платформы — это уже вторично. Фундаментальные знания позволяют легко освоить новый язык. По моим данным, это справедливо и для QA.

Большое спасибо, мне понравилось. Но на один вопрос пока не нашёл ответа в рунете — если программисты почти строго делятся по языкам/платформе, то как обстоят дела у тестировщиков? Заранее спасибо

спасибо за статью. Скажите, знания, полученные для тестировщика, могут в дальнейшем пригодиться для освоение NLP-developer или это вообще совершенно разные знания и ничего из тетсировщика для nlp не почерпнешь?

Хорошая статья и комментарии, полезные советы, но я бы добавил.

1. Формы должны быть короткими

Когда пользователь посещает ваш сайт, естественно, как он-лайн маркетолог, вы хотите собрать с него как можно больше данных. Однако, когда дело доходит до создания хорошей целевой страницы, чем меньше, тем лучше. Чрезвычайно важно, чтобы пользователь заполнял как можно меньше полей формы. Чем больше полей вы просите ввести посетителя, тем меньше у вас шансов получить заполненную форму и выполнить желаемую конверсию. Если вам необходимо заполнить форму, спросите только самое необходимое. Помните, что вы всегда можете запросить дополнительную информацию на странице благодарности.

При наличии таких ограничений, какие поля в форме вы должны сделать обязательными? Большинство пользователей не возражают назвать свое имя и адрес электронной почты, но запрос телефонных номеров или даты рождения может привести к тому, что ваш показатель падения возрастет до 50%. Остерегайтесь этих полей формы!

2. Адаптируйте свои целевые страницы для отдельных аудиторий

Если у вас есть отличное предложение, и вы его хорошо продвигаете, вы, скорее всего, будете получать трафик из разных источников. Если это вообще возможно, вы хотите настроить целевые страницы для разных аудиторий. Пользователь, который попадает на вашу целевую страницу с поста в Facebook или Twitter, совершенно отличается от пользователя, который попадает на вашу целевую страницу с объявления PPC или по ссылке из вашего ежемесячного информационного бюллетеня.

3. Сопоставьте копию целевой страницы с рекламой PPC

Для получения эффективной целевой страницы не забудьте сопоставить слова, используемые на странице, с ключевыми словами и текстом, используемыми в объявлениях и платной рекламе в Google. Повторение того же языка и ключевых фраз демонстрирует последовательность и убеждает посетителей в том, что они находятся на правильном пути. Также важно доставлять пользователей непосредственно к контенту, который они ищут. Если пользователь нажимает на рекламу PPC о спальных мешках, не оставляйте их в разделе кемпинга — вы хотите доставить их в нужное место назначения. Соответствуйте потребностям пользователя как можно ближе — вот где происходит конверсия кликов в покупку!

4. Тест!

Последний признак хорошей целевой страницы — тестирование. Эффективная целевая страница просто не может быть создана без тщательного тестирования. Результаты тестирования и отслеживания важны для того, чтобы увидеть, что ваша целевая страница делает правильно, а что нет. Тестируйте, тестируйте и тестируйте еще!

Я не поняла на счет «черного и белого». На счет догм было же уже написано в начале моего коммента.

Про начальников — что я имела ввиду — разработчик не может самостоятельно определять цели и средства потому как он находится внутри разработки. Поэтому есть специальные люди, специально в стороне от разработчиков у которых должен быть бОльший опыт(специальный опыт) и они «не в команде»(не в банде). А то что все люди и все ошибаются — ну да, но если есть нормальный подход к построению команд разработчиков то человеческий фактор снижается.
На счет лишь разница в ЗП, уровне ответственности — да верно. Но это же не главное!!! Начальник в стороне со своими задачами и он видит когда его подчиненные полезным делом занимаются, а когда начинают изобретать велосипед или их потянуло не туда.

Алгоритм Mobile First влияет на поисковую выдачу не только во время мобильного серфинга, но и при использовании десктопных устройств. Основная и мобильная версии сайта ранжируются по одному индексу, поэтому если ресурс не адаптивен к мобильным устройствам, позиции сайта могут просесть. Если пользователь переходит на сайт, не находит полезную информацию и возвращается к поисковой выдаче, Google воспринимает это как отрицательный сигнал и снижает позиции сайта при ранжировании.

Есть и еще один совет. Обязательно оставляйте на странице «воздух». Должна быть очевидная, естественная навигация без отвлекающих факторов (таких как всплывающие окна). Хорошая целевая страница содержит всю необходимую информацию, необходимую для поощрения посетителей, но ничего лишнего. Слишком много информации может ошеломить посетителей, поэтому будьте проще и предоставьте только необходимую информацию, которая будет направлять посетителей вниз по воронке. Информация, которую вы помещаете спереди и по центру, должна легко просматриваться – желательно использовать маркеры, чтобы объяснить детали, когда это необходимо.

Хорошо обдумайте, какую ключевую информацию нужно показывать на первом экране сайта, в пределах прямой видимости посетителей, а что можно поместить под прокруткой. Большинство посетителей, естественно, знают, что могут прокрутить вниз для получения дополнительной информации, поэтому не бойтесь добавлять более подробные описания там, где они будут незаметно скрыты. Хороший дизайн целевой страницы обеспечивает чистое и привлекательное визуальное впечатление, в то же время, позволяя посетителям получать информацию, которую они могут пожелать, не навязчивым способом. Используйте преимущества в расположении информации ниже по странице. Еще один способ добавить больше информации, не перегружая посетителей текстом, — это целевые страницы с видео. Подумайте о выделении ключевых моментов вашего предложения с помощью текста и используйте необязательное кликабельное видео для объяснения деталей.

Мир не черный и не белый, всё сложнее)
Никто не виноват, что состояние распределённой системы оказывается размазанным, неопределённым, труднопостижимым чаще, чем у цельного клубка из спутавшихся нитей.
Начальники — они хоть и специальные, но тоже люди, со всеми теми же ограничениями, что и у «я лишь разработчиков», разница лишь в зарплате, уровне ответственности и количестве переваренного опыта.

Хорошая статья! Стоит не забывать что пользователю проще покинуть ресурс, чем разбираться и «попадать» пальцем на маленькие кнопки «купить». Важно не только сделать сайт адаптивным, но и продумать путь пользователя. Интерфейс сайта должен плавно вести пользователя от главного экрана сайта до достижения цели. Если все элементы сайта расположены на своих местах, конверсия сайта вырастет.

Тут все просто: Эффективная целевая страница (landing page) является краеугольным камнем успешного интернет-маркетинга. Ваше предложение может быть звездным, а ваши объявления PPC — оптимизированными, но без хорошей целевой страницы ваш бизнес неизбежно пострадает. Макет вашей целевой страницы должен быть безупречным.

Хорошая статья. Но суть одна и та же — думай головой и не занимайся догматизмом.
Всегда можно сделать что-то хорошее из куска хлама и при этом можно сделать ужас-ужас прекрасными инструментами.
Ну и главное — только цель оправдывает средства. А с целеполаганием к разработчику вообще не нужно подходить — для этого есть специальные люди — начальники, которых для этих моментов и ставят чуть выше(в стороне) от основного коллектива, чтобы трезво оценивал цели и средства.

Стало быть виноваты не девопсы-любители, а нужно было сказать, что виноват был их начальник. А автор похоже не захотел так выражаться по какой-то причине.

В общем чета осадочек остался от статьи. Извините.

Один из признаков энтерпрайз-стиля — разделение приложения на слабосвязанные слои. Дефолтная для Laravel ORM предлагает свою реализацию паттерна ActiveRecord, который по определению сильно связывает уровень бизнес-логики с уровнем хранения данных. Возможно, при должной дисциплине и(или) абстракциями поверх ORM можно отделить бизнес-логику от уровня хранения данных, вроде бы относительно легко прикрутить Doctrine для замены дефолтной, но в документации, постах и т. п. я не встречал такого подхода, а ровно наоборот подается как преимущество тесная свзяанность. Типа всего нужно написать $order = new Order(); $order.save(); и новая запись сохранена. В Doctrine это займёт минимум на строку больше.