Home

Автор: Ирина Иванова, старший инженер по тестированию в образовательной платформе Учи.ру.
Оригинальная публикация

Привет! Меня зовут Ирина Иванова, я работаю QA-инженером в команде разработки внутренних проектов в Учи.ру. Мы занимаемся такими сервисами, как виджет поддержки, личный кабинет сотрудников пользовательской поддержки, карьерный сайт и так далее. 

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

Автор: Эльвира Скачко

Я работаю тестировщиком больше 10 лет. Успела поработать в НПО, где только знакомились с тестированием. В крупном рабовладельце аутсорсе, отчитывающемся перед заказчиком за каждую чашку кофе. В продуктовой компании с более чем 100 тестировщиками и выстроенными (нууу, как-то) процессами. Каждая компания уникальна, как снежинка, но есть нюанс. Есть работа, которой тестировщики пренебрегают независимо от зрелости компании и её ценностей. Недавно я участвовала в опросе 85 команд разработки, начиная от свеженьких стартапов, заканчивая лютыми энтерпрайзами. И была крайне удивлена, сколько же общего у этих ребят. Вот что они не делают.

Автор: Майкл Болтон
Оригинал статьи
Перевод: Ольга Алифанова

Как-то раз я написал статью про покрытие. На самом деле их было несколько, но речь об этой. Недавно на LinkedIn возник вопрос, который помог мне понять, что я упустил нечто важное.

Статья компании SimbirSoft

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

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

Всем привет! Меня зовут Василий, я руковожу командой QA в Сравни. Сегодня хочу поделиться своим опытом найма и онбординга тестировщиков. По мере роста штата компании эти процессы видоизменялись, пандемия тоже внесла свои коррективы. Надеюсь, статья будет полезна всем, кто так или иначе участвует в найме сотрудников технических специальностей. Но обо всём по порядку.  

Статья компании SimbirSoft

Привет! Меня зовут Валерий, я руковожу группой QA Fullstack компании SimbirSoft. В сфере тестирования чаще всего выделяют группы QA-специалистов и SDET. Но сейчас многие компании задумываются об оптимизации расходов, особенно это актуально для проектов с длительным периодом эксплуатации, вроде небольших монолитов или внушительных размеров систем с множеством интеграций и микросервисов. Рано или поздно наступает момент, когда требуется подключать специалистов, которые не только хорошо разбираются в продукте и могут тщательно его протестировать, но и тех, кто могут писать автотесты. Убить двух зайцев сразу помогут QA фулстеки.

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

Статья компании SimbirSoft

Управление релизами охватывает все этапы продукта — от разработки и тестирования до продакшена. Это самая ответственная роль, которую может взять на себя IT-специалист. Вместе с коллегами из направления QA SimbirSoft рассказали, на что стоит обратить внимание IT-специалисту, стартующему в роли релиз-менеджера или решившему проанализировать процесс релизов на проекте.

Компетенции релиз-менеджера можно разделить на две части с точки зрения инструментов: техническую и работу с документами.

Автор: Алия Токарева, ICL Services
Оригинальная публикация

Предисловия, или Размышления о том, как много тестировщиков в IT

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

Если в компании не применяются мероприятия по аттестации сотрудника и/или сотрудник не применяет полученные знания в работе, то память тестировщика может очень сильно подвести. И более того, это может сказаться также и на качестве тестирования («и далее, как снежный ком…»). При этом проблема может возникнуть не только в отрицательную сторону, где тестер забыл весь пройденный курс обучения, но и в положительную – специалист повысил свои навыки и знания в тестировании, а руководители недооценили своего подчиненного (И как долго недооцененный сотрудник продержится в компании? А ведь это давит морально на эмплоера).

Часть 1. Найм и развитие

Всем привет. Меня зовут Александр Наумов, я Team Lead QA в Утконос Онлайн. В этой статье я поделюсь личным опытом, который будет полезен тимлидам и руководителям: как мы за 5 месяцев набрали 28 начинающих специалистов, обучили и через 3 месяца получили миддлов. 

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

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Меня часто спрашивают об идеальном соотношении разработчиков и тестировщиков. Я всегда отвечаю, что это зависит от контекста. Хорошее соотношение тестировщиков и разработчиков определяется рядом факторов. Тут надо подумать о том, работаете ли вы с последней технологией или с давно существующим продуктом, о таланте и опыте членов команды, и об ожидаемом ритме релизов. На самом деле сработать могут самые разнообразные соотношения, но у каждого есть достоинства и недостатки. Разберем несколько примеров.