Хороший мануальщик должен уметь программировать, чтобы понимать, что вообще реализовано в задаче. Есть достаточно много хороших программистов, умеющих создавать код, но мало хороших программистов, умеющих его тестировать (читай, иметь нужный для этого склад ума).
Соответственно, осваивать надо языки программирования и технологии, используемые в компании, в которой работаешь.
Они ничего не получают сверху. По нашим ожиданиям они должны быть рады интересным задачам и возможностям
Это не совсем так.
1. Лиды учитывают вклад ручных тестировщиков в автоматизацию при проведении ревью (подробнее можно почитать тут: habrahabr.ru/company/badoo/blog/331570). Т.е. наличие автоматизации влияет на размер премии.
2. Кроме того, суммарный вклад в автоматизацию влияет на внутренний уровень сотрудника департамента QA (чем больше вклад, тем больше вероятность подняться на следующий уровень; чем выше уровень, тем выше з/п).
3. Ну и на самом деле даже в ручное тестирование мы стараемся набирать высококлассных специалистов, что позволяет нам в рамках одного уровня делать з/п одинаковой и ручным тестировщикам, и автоматизаторам (уверяю вас, задачи на ручное тестирование у нас ничуть не менее интересные/сложные/трудоемкие, чем задачи на автоматизацию).
Лучше разработчика, написавшего какой-то код, этот код может знать только разработчик, который его поддерживает :) Поэтому и юнит-тесты к проекту писались силами самих разработчиков. Конечно, проект поделен на условные «подпроекты» (или области ответственности), каждый файл в проекте закреплен за одним или несколькими maintainer'ами, а также за определенной командой.
Статистика по coverage'у, помимо прочего, показывает код какой команды в какой степени покрыт юнит-тестами. Ну а так как задача на покрытие проекта тестами ставилась непосредственно руководителям различных команд разработчиков (и прогресс в достижении цели оценивался каджый квартал), то в их интересах было сделать так, чтобы у разработчиков было и время, и желание эти тесты писать. Поэтому 1) coverage поднимали плавно, не ломая сильно основного процесса разработки, но и не останавливая покрытие; 2) отдельной команды автоматизаторов не было.
Из полезных рецептов: сначала завели практику покрывать юнит-тестами все новые фичи (без этого задача не проходит code review). Если задача срочнаая, то, как и в случае с селениум-тестами, код выезжает на прод, но параллельно в баг-трекере создается задача на написание юнит-тестов к новому коду (которая также имеет высший приоритет). Потом потихонечку ставились отдельные задачи на покрытие тестами (и местами попутный рефакторинг для возможности покрытия тестами) старого кода.
Метрики используем, стараемся держать покрытие всего проекта не ниже 50%. Какие-то части кода (например, биллинг или критичные части платформы) покрыты тестами практически полностью, какие-то — (старые скрипты, страницы, всякие геттеры/сеттеры) могут быть не покрыты вообще. Цель «повысить coverage до заветных 50%» ставилась перед руководителями команд разработки, coverage повышался постепенно. Добились такого результата примерно за год-полтора.
Это сразу пяток хороших, больших вопросов :) Попробую ответить.
1. Приемочный и функциональные тесты у нас есть, мы их используем и автоматизировали, насколько это возможно. Приемочные тесты у нас — это селениум для веба и мобильного веба + свои автотесты для мобильных клиентов. Как это работает.
— Если на тестирование приходит новая фича: проверяем ее руками (возможно, выкладываем на прод с несколькими а/б тестами) -> фича дорабатывается, устаканивается описание, выбирается лучший дизайн/набор функций/текст из а/б тестов -> создаем задачу на написание к ней селениум-тестов -> собственно, пишем тесты
— Если на тестирование приходит улучшение старого функционала/изменение существующей страницы (дизайн, расположение элементов, whatever): проверяем задачу руками, параллельно в этой же git-ветке правятся/дорабатываются селениум-тесты. Либо, если задача срочная, то проверяем только руками, а параллельно ставим задачу на правку/доработку селениум-тестов; такая задача также получает максимальный приоритет.
2. Функциональными тестами у нас являются и юнит-тесты, и интеграционные тесты. В интеграционных проверяем взаимодействие кода с БД и различными внутренними сервисами (демонами) на C/C++/Go. Там же — проверяем взаимодействие серверной части кода с клиентами (клиенты при этом тоже мокаются).
3. SoftMocks используются только для юнит-тестов, да. В других местах они могут быть вредны.
4. С таким количеством юнит-тестов по структуре можно порекомендовать только одно: пишите тестируемый код :) Тогда и огромное количество тестов будет пробегать за считанные минуты. У нас ситуация чуть сложнее — юнит-тесты стали массово писать, когда кодовая база уже успела сильно разрастись. Приходится ухищряться :)
Например, в некоторых не совсем юнит-тестах у нас есть запросы к БД. Но! В тестах реализована заглушка: если из теста идет запрос к реальной БД, то вместо настоящей запрашиваемой таблички создается временная с такой же структурой, которая наполняется тестовыми данными и по окончании теста удаляется. Таблицы такие создаются в tmpfs, поэтому на скорость выполнения тестов влияют меньше, чем могли бы (хотя это тоже сильно сказывается на времени их прохождения).
Еще тесты у нас разбиваются на микросьюты и запускаются в облаке (подробнее, почему так, можно почитать тут: Переход на PHP 5.5 и юнит-тесты).
5. Про тестирование баз не совсем понял. Если имеется ввиду проверка взаимодействия кода с базой, то у нас есть и фикстуры, и обращения к «реальным» (на самом деле тоже замоканым временным) базам. Например, фикстуру для самого популярного объекта User мы генерим автоматически на основе текущей эталонной структуры БД, складываем ее в файл на всех серваках, где гоняются тесты, и подключаем инклюдом.
Если вопрос понял не правильно, то предлагаю продолжить дискуссию ниже :)
Требования задает регулятор. Их можно попробовать не исполнять, но любое обращение граждан страны в суд приведет к необходимости оплатить штраф + к различным санкциям вплоть до запрета проведения электронных платежей через определенную платежную систему в этой стране. Это в случае если регулятор не обратит внимания на невыполнение этих требований самостоятельно: тогда у вас будет время на исправление. Иначе — снова штраф и санкции.
А вообще выяснение этих требований каждый раз происходит в момент согласования с платежными системами их включения в той или иной стране специальным отделом юристов.
1. Воркспейс очистить можно, да, но некоторые демоны могут писать временные файлы не в директории воркспейса (захардкожены в демоне). Про эти пути известно в тестах конкретного демона.
2. Это не совсем тот демон, да (но очень похож). Если фаталов нет, то примерно так и происходит — демон останавливается по sigterm (для некоторых команда остановки отличается).
Есть и интеграционные, и системные тесты — это селениум-тесты сайта на девеле + отдельная ветка автотестов, ты должен помнить :) Правда, там тесты не на все демона, а лишь на некоторые, но тесты периодически дополняются.
Соответственно, осваивать надо языки программирования и технологии, используемые в компании, в которой работаешь.
Это не совсем так.
1. Лиды учитывают вклад ручных тестировщиков в автоматизацию при проведении ревью (подробнее можно почитать тут: habrahabr.ru/company/badoo/blog/331570). Т.е. наличие автоматизации влияет на размер премии.
2. Кроме того, суммарный вклад в автоматизацию влияет на внутренний уровень сотрудника департамента QA (чем больше вклад, тем больше вероятность подняться на следующий уровень; чем выше уровень, тем выше з/п).
3. Ну и на самом деле даже в ручное тестирование мы стараемся набирать высококлассных специалистов, что позволяет нам в рамках одного уровня делать з/п одинаковой и ручным тестировщикам, и автоматизаторам (уверяю вас, задачи на ручное тестирование у нас ничуть не менее интересные/сложные/трудоемкие, чем задачи на автоматизацию).
Статистика по coverage'у, помимо прочего, показывает код какой команды в какой степени покрыт юнит-тестами. Ну а так как задача на покрытие проекта тестами ставилась непосредственно руководителям различных команд разработчиков (и прогресс в достижении цели оценивался каджый квартал), то в их интересах было сделать так, чтобы у разработчиков было и время, и желание эти тесты писать. Поэтому 1) coverage поднимали плавно, не ломая сильно основного процесса разработки, но и не останавливая покрытие; 2) отдельной команды автоматизаторов не было.
Из полезных рецептов: сначала завели практику покрывать юнит-тестами все новые фичи (без этого задача не проходит code review). Если задача срочнаая, то, как и в случае с селениум-тестами, код выезжает на прод, но параллельно в баг-трекере создается задача на написание юнит-тестов к новому коду (которая также имеет высший приоритет). Потом потихонечку ставились отдельные задачи на покрытие тестами (и местами попутный рефакторинг для возможности покрытия тестами) старого кода.
1. Приемочный и функциональные тесты у нас есть, мы их используем и автоматизировали, насколько это возможно. Приемочные тесты у нас — это селениум для веба и мобильного веба + свои автотесты для мобильных клиентов. Как это работает.
— Если на тестирование приходит новая фича: проверяем ее руками (возможно, выкладываем на прод с несколькими а/б тестами) -> фича дорабатывается, устаканивается описание, выбирается лучший дизайн/набор функций/текст из а/б тестов -> создаем задачу на написание к ней селениум-тестов -> собственно, пишем тесты
— Если на тестирование приходит улучшение старого функционала/изменение существующей страницы (дизайн, расположение элементов, whatever): проверяем задачу руками, параллельно в этой же git-ветке правятся/дорабатываются селениум-тесты. Либо, если задача срочная, то проверяем только руками, а параллельно ставим задачу на правку/доработку селениум-тестов; такая задача также получает максимальный приоритет.
2. Функциональными тестами у нас являются и юнит-тесты, и интеграционные тесты. В интеграционных проверяем взаимодействие кода с БД и различными внутренними сервисами (демонами) на C/C++/Go. Там же — проверяем взаимодействие серверной части кода с клиентами (клиенты при этом тоже мокаются).
3. SoftMocks используются только для юнит-тестов, да. В других местах они могут быть вредны.
4. С таким количеством юнит-тестов по структуре можно порекомендовать только одно: пишите тестируемый код :) Тогда и огромное количество тестов будет пробегать за считанные минуты. У нас ситуация чуть сложнее — юнит-тесты стали массово писать, когда кодовая база уже успела сильно разрастись. Приходится ухищряться :)
Например, в некоторых не совсем юнит-тестах у нас есть запросы к БД. Но! В тестах реализована заглушка: если из теста идет запрос к реальной БД, то вместо настоящей запрашиваемой таблички создается временная с такой же структурой, которая наполняется тестовыми данными и по окончании теста удаляется. Таблицы такие создаются в tmpfs, поэтому на скорость выполнения тестов влияют меньше, чем могли бы (хотя это тоже сильно сказывается на времени их прохождения).
Еще тесты у нас разбиваются на микросьюты и запускаются в облаке (подробнее, почему так, можно почитать тут: Переход на PHP 5.5 и юнит-тесты).
5. Про тестирование баз не совсем понял. Если имеется ввиду проверка взаимодействия кода с базой, то у нас есть и фикстуры, и обращения к «реальным» (на самом деле тоже замоканым временным) базам. Например, фикстуру для самого популярного объекта User мы генерим автоматически на основе текущей эталонной структуры БД, складываем ее в файл на всех серваках, где гоняются тесты, и подключаем инклюдом.
Если вопрос понял не правильно, то предлагаю продолжить дискуссию ниже :)
А вообще выяснение этих требований каждый раз происходит в момент согласования с платежными системами их включения в той или иной стране специальным отделом юристов.
2. Это не совсем тот демон, да (но очень похож). Если фаталов нет, то примерно так и происходит — демон останавливается по sigterm (для некоторых команда остановки отличается).
Есть и интеграционные, и системные тесты — это селениум-тесты сайта на девеле + отдельная ветка автотестов, ты должен помнить :) Правда, там тесты не на все демона, а лишь на некоторые, но тесты периодически дополняются.