Home

Автор: Алексей Анисимов

В вашей команде есть Middle QA, который хочет развиваться дальше. Что должен делать лид команды, чтобы вырастить из него синьора? Ниже вы найдете советы, основанные на моем опыте. Если вы инженер, тоже читайте дальше - рекомендации помогут понять, как расти и что просить от своего лида.

Будущему сеньору нужен ментор

Если рост от Junior до Middle в основном обеспечивается развитием hard-скиллов, то рост от Middle и выше больше связан с софт-скиллами, хотя техническое развитие тоже не должно отставать.

Вырасти из миддла в синьора довольно сложно и одного желания может быть недостаточно. Наставник поможет пройти этот путь: стать им может как опытный senior или principle, так и лид тестирования. 

Автор: Александр Шленский

Вступление

Я работаю на позиции QA Automation Engineer более 7 лет. За это время команда автоматизаторов выросла с 7 до 70 человек, и мы продолжаем расширяться. В нашей компании группы ручного и автоматического тестирования находятся в отдельных командах. 

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

У нас хорошо развито автотестирование: на момент написания статьи у нас  более 100 тысяч уникальных тестов. На нашем основном продукте около 45 тысяч приемочных end-to-end-тестов. Это экономит более 400 часов ручного тестирования. При условии, что один прогон длится 1,5 часа. Чтобы все это работало, мы используем и разрабатываем свои внутренние инструменты.

Автор: Егорова Лидия, телеграм - @LiEgorova

В тестировании я работаю около 5 лет. За это время сменила несколько компаний и выросла с джуна до QA-Lead'a. Все годы работы я наблюдала за психологическим состоянием коллег, а потом и членов команды, которую набирала под себя.

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

Придя в «Иннотех», я продолжала собственные исследования влияние стресса на тестировщиков. И готова поделиться результатами, а также советами, как сделать работу менее нервной и напряжённой.

Провел опрос и подготовил результаты Касимов Василий.

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

В опросе по России приняло участие почти 2000 человек, спасибо телеграмм-чатам и особенно QA - Finance. К сожалению, по Беларуси и Украине охвата не хватает, по каждой из них немногим больше 100 ответов.

Предыдущий опрос за 2019 год можно найти здесь.

Ниже можно найти данные по городам и стране в целом по различным срезам. По горизонтали шкала зарплат, по вертикали количество проголосовавших, получающих зарплату в этом диапазоне. Цветом выделен опыт работы (расшифровка справа на картинке). Данные идут за текущий опрос и за предыдущий. Еще более старые данные можно найти в предыдущем опросе. Обращаю внимание, что за в этом опросе я расширил диапазон зарплат. Данные немного странные, не видно общего пика, как было в предыдущие годы.

На связи Кирилл Шувалов, Senior QA Test Engineer аутстаффинговой компании Smart IT. В этой статье я расскажу вам о пути в тестирование и как добиться успеха в этой области. Будет круто, если в этих строчках начинающие IT-специалисты почерпнут для себя полезную информацию, а опытные спецы поделятся своими наставлениями в комментариях. Ну, что ж, погнали!:)

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

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

На практике, примерно у каждого третьего IT-шника в крупной компании нет профильного IT-образования, но есть техническое.

Оригинальная публикация

Бытует мнение, что простейший путь к IT лежит через тестирование. Мол, знать ничего не нужно, уметь и подавно, достаточно желания и готовности не сильно щуриться от боли и слёз, когда тебе прилетает очередной набор тест-кейсов для регрессионного тестирования.

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

Возросшие требования к тестировщикам, их знаниям и квалификации, так как всё чаще решаются задачи чуть сложнее, чем «клик-клик — и в продакшен». Работа тестировщиков становится всё более «инженерной», требует технической подкованности, специфических знаний, навыков и компетенций. Тестировщики всё чаще становится QA-инженерами (кто в теме, тот понимает разницу).

Возросшее предложение на рынке, когда толпы вчерашних «гражданских» ринулись в пучину IT, подогреваемые обилием информации: от конференций и книг до статей и курсов по тестированию ПО. Ваш покорный слуга в своё время также приложил руку к созданию пары общедоступных курсов по причине желания тиражировать базовые вещи из своей профессиональной области (посмотреть можно, например, здесь)

Автор: Кейт Полк (Kate Paulk)
Оригинал статьи
Перевод: Ольга Алифанова

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

Ниже – десять распространенных и наиболее ошибочных причин не нанимать тестировщиков.

Автор: Елена Поплоухина, руководитель группы тестирования в Usetech (https://career.usetech.ru/)

Оригинальная публикация

Добрый день! Я – Елена Поплоухина, руководитель группы тестирования в компании Usetech. В предыдущей статье я рассказывала про опыт построения обучения в группе тестирования на основе практики квартальных целей. 3,5 года мы пользовались этим подходом, но в итоге решили всё переделать. Почему так получилось? Для этого было несколько причин, и о них я расскажу в этой статье.

Это следующие причины:

• Рост группы тестирования. Появилась необходимость в установке целей в любой момент года, а не только 1 раз в начале каждого квартала.

• Не всегда было очевидно, какие пробелы в знаниях и опыте есть у сотрудника.

• Периодически не устраивал период выполнения цели в 3 месяца. На квартал могли выпадать и новогодние праздники, и отпуск сотрудника. В таком случае времени на выполнение цели не хватало. Требовалось варьировать период выполнения целей с учётом как их сложности, так и других факторов.

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

Базовая версия профиля тестировщика была получена нами на одном из курсов по тест-менеджменту и переработана на 50% под нашу компанию. Давайте рассмотрим, как выглядит профиль.

В конце ноября состоялся первый релиз нашей платформы для подготовки к собеседованиям IT Resume. И знаете с чего он начался? Правильно — нас сразу купил Гугл на нас сошла лавина баг-репортов. Если точно — почти несколько сотен за неполных 2 дня! Но это было лучшее, что с нами произошло за долгое время! :)

Однако обо всем по порядку.

Пролог

Для начала накидаем немного контекста, чтобы вы могли лучше прочувствовать наше положение и понять наши мотивации. 

1. Мы начали пилить платформу для подготовки к собеседованиям в апреле. В ноябре состоялся релиз. За это время были разработаны дизайны, написан фронт, развернуто полноценное API и создан обработчик кода со всеми наворотами типа лексических анализаторов. 

Уточнение: Фронт был сначала написан, а потом еще раз переписан на другом фреймворке. Классика.

2. Все это делалось силами нескольких программистов. Команда была небольшая: бекендер на фултайм + фронтендер и дизайнер на парт-тайм. 

3. 200+ задач и тестов разрабатывались силой все той же команды. Для каждой задачи нужно было прописать формулировку, подсказки, решения и оформить юнит-тесты. 

Лирическое отступление: сначала казалось, что работы по созданию задач будет немного. Оказалось много. 

4. Мы решили не тратиться на рекламу. Собирались привлекать пользователей на платформу из своих социальных сетей (кстати, будем рады вас видеть: ВКонтакте Телеграм Инстаграм).

Итак, хватит контекста. Перейдем к сути дела.