В этой докладе я буду говорить только о Lean проектах:

• Понятна бизнес-цель, но не понятны пути достижения. Есть гипотезы, которые можно проверить только на практике.

• Требования часто меняются. Фича, сделанная на прошлой неделе, может быть убрана на этой.

• Чем чаще релизы — тем лучше.

Что меняется для тестировщика в таком проекте? Почему частые релизы - это тоже фича? Почему не обойтись без автотестов команде из 1 тестировщика и 4 разработчиков?

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

За 5 лет мы сделали 8 стажировок тестировщиков. Мы пробовали разные форматы и собирали грабли. В докладе я расскажу, к какому оптимальному соотношению затраченного времени и качества полученных стажеров мы пришли.

Часто говорят о том, что в IT вообще и в тестировании в частности нужно постоянно развиваться, изучать новые технологии, методологии и инструменты. Мне хочется поговорить о том, как это можно делать:

• что нужно, чтобы постоянный рост как специалиста стал частью повседневной жизни;
• чему можно научиться у разработчиков, менеджеров и devops;
• что полезно знать о своем мозге, чтобы перестать говорить "да, это классно, но у меня сейчас нет на это времени".

Метрик не будет.

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