Home

Статья компании 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)
Оригинал статьи
Перевод: Ольга Алифанова

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

Автор: Майк Харрис (Mike Harris)

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

Я много раз слышал вопрос "Почему тестировщик упустил этот баг", но это неверный вопрос. Философия У. Эдвардса Деминга гласит, что если что-то пошло не так, то надо разбираться с процессом, а не винить конкретного человека. Тестировщик может работать в системе, которую не способен изменить, и в результате получается ПО, содержащее баги. Если там есть баги, надо разобраться с породившей их системой.

Автор: Марина Кудрявцева, iSpring, Инженер по качеству

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

Расскажу, с какими сложностями сталкиваются стажёры, и как мы помогаем эти сложности преодолеть и погрузиться в сложный проект.

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

Уверена, что мой опыт пригодится наставникам и тимлидам, которые также вводят новых QA. Делитесь в комментариях и своим опытом.

Автор: Алия Токарева, ICL Services

Меня зовут Алия, я – инженер-тестировщик с 5-летним стажем, в повседневном рабочем процессе занимающийся тестированием банковского приложения. И в местную «Вселенную» хочу войти с историей о том, как мне однажды удалось преодолеть трудную ситуацию, связанную с уходом из команды опытного сотрудника и приходом неопытного, предложить свое решение – и преуспеть.

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

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

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

• Он, возможно, не сможет автоматизировать тесты вообще – все тестирование будет вручную, и это сильно замедлит релиз.
• Он будет плохо автоматизировать тесты, и вы получите нестабильные тесты, которым нельзя доверять, нуждающиеся в постоянной поддержке.
• Он будет плохо понимать технические концепции – другим членам команды придется тратить время, чтобы снова и снова объяснять их коллеге.
• Он не сумеет создать тест-стратегию – в итоге тестироваться будет не то, что нужно, а то, что нужно, не будет проверяться вообще.

Перевод: Алексей Иванов

Автор оригинала: Yuliia Kuprii