Проходил собеседование и мне задали интересный вопрос : как после автоматизации тестов и их постоянной прогонки, через время вы убеждаетесь что тесты валидны и проверяют что должны? Формулировка именно такая, прошу поделиться своими идеями
А кто-то вообще проверяет что через некоторое время тесты все еще валидны?
0 участников
ну вообще-то автотесты пишутся для фиксации работы приложения, и если они зеленые, то значит целевое приложение работает также, как и при создании тестов
а вот если тесты падают, значит что-то поменялось (если обычно тесты проходят стабильно без проблем)
На этот вопрос я бы еще задал дополнительные вопросы, нельзя просто взять и ответить сразу. Например: Какие это тесты?
В API все более атомарно и проверка актуальности либо не выполняется вовсе после пуша теста в мастер, либо выполняется после изменения функционала. В UI тестах больше проверок ибо на каждый кейс открывать браузер - идиотизм. Поэтому убеждаться в актуальности тестов UI придется гораздо чаще в силу того, что функционала, затрагивающего один тест, может быть много. Если отвечать на их вопрос “как”, то я бы ответил - периодическим ревью. Даже интересно как ответили на этот вопрос сами собеседующие.
Вопрос - Как проверить что Ваши тесты действительно что-то тестируют, а не просто сообщают что все хорошо (всегда показывают зеленые прогоны).
Ответ - мутационное тестирование.
Это может быть сюрпризом 
если Вы вдруг осознаете что 50-60 % тестов ничего посути не тестируют и всегда зеленые, особенно часто это проявляется у тех кто злоупотре■■■ет “моками”.
есть практический пример подхода для АПИ/УИ ?
я так понимаю это должна быть кодогенерация - для разных классов в приложении без нарушения компиляции/интрепретации
Добрый день!
Несмотря на то, что вопрос задан касательно автотестов, мне думается, что в первую очередь тут стоит рассматривать валидность не тестов, а требований. Ведь для чего нужны автотесты? Это просто инструмент, который позволяет убедиться, удовлетворяются ли бизнес-требования или нет. Другими словами, валидность тестов – это не их passed/failed состояние, а то насколько они соответствуют бизнес-логике. Тут выше уже упоминали мутационное тетирование, но я бы прежде всего добавил тестирование требований. А для этого нужно понимать, как требования составляются и – что более важно – как документируются. Например, может помочь BDD подход, когда каждая фича становится user story, а ее требования описываются в виде пользовательских сценариев. Тесты же пишутся так, чтобы скрупулезно покрывать каждый given-when-then. В таком случае, при необходимости изменить что-то в функционале, прежде всего нужно переписать и связанные сценарии (обычно в спешке на это забивают, хотя строгое следование процессу – уже само по себе половина решения). Если после изменения сценариев создать тикет на правку автотестов – вопрос и вовсе становится неактуальным, поскольку требования обновлены, а тесты – в соответствии с внутренними гайдами – пишутся исключительно по требованиям и во всем им соответствуют. До тех пор пока тесты не исправлены – они будут падать, поскольку не соответствуют требованиям. Что в свою очередь является маркером их невалидности.
Ох, и вопросик! Сам помню на собеседовании примерно такого же плана вопросы задавал 
Помню разок, я описал некий функционал и спросил как бы человек его проверил, какие бы он ставил вопросы и т.д. по сути этим я проверил его на умение провести тест-аналитику.
Если по теме, то тут очень всё зыбко. Это как в теме про BDD, когда нет знаний, то все начинают высказывать мнения. В смысле реальные расчеты и графики мало кто приводит, только делятся общими впечатлениями: либо круто, либо отстой. Ещё иногда приводят сомнительные или древние статьи и исследования, и причём не оригиналы, а жвачку, типа кто-то где-то когда-то что-то там проверил на кроликах… а научный подход - это сложно, скучно и не продать.
Возвращаясь к теме: Можно рассмотреть более общую проблематику, а можно сократить до конкретной формулировки, которую привел @S_Romankov в первом сообщении.
Если смотреть в более общем случае, т.е. в примерно такой формулировке “как вы понимаете, что делается именно, то что нужно и не делается ничего ненужного?”, то начинают возникать другие вопросы “вы уверены, что в требованиях написано, то что хотел заказчик?” или “вы уверены, что заказчик хотел именно то, что сказал, а не что-то другое о чем он не упомянул или не знал и если бы ему подсказали нужный вариант, то он бы выбрал его?” или “вы уверены, что то что мы сделаем будет нужно и востребовано нашими клиентами?” (например, вспоминаем историю с кнопкой пуск в Win8). Вторая часть - это там где спрашивается, что не делается то, что не нужно. Тут вообще непонятно, что и как считать. Кто-то может решить, что и пить кофе на работе не нужно, а то расслабились, понимаешь. 
Или вот, программист “захардкодил” переменную, которая по странному стечению обстоятельств очень была похожа на номер его банковской карты (для отладки конечно же 
) и этот код попал в промышленную среду где благополучно начинал делать всякое, но не постоянно, а иногда и очень-очень аккуратно. Ну или менее трешовые случаи (без злого умысла), когда система делает ненужные/лишние записи не в ту базу, не в ту таблицу, не в те поля или наоборот что-то нужное удаляет сверх необходимого, или делает поиск не по тем ключам/полям и т.д. и т.п. Конечно же часть этих проблем можно и нужно минимизировать и компании в целом с этим успешно справляются. В частности вводят код-ревью, парное программирование, демо, юнит-тесты, интеграционные, e2e и другие виды тестов как ручные, так и автоматические, нагрузочные, безопасности, А/Б тестирование, UI-тестирование, приёмочное, альфа/бета тестирование и т.д. А также системы мониторинга, профилирования, разделения ответственности с дублированием и т.д.
Кстати, пока писал всё это, то вспомнил один отличный доклад: Руслан Черемин — Тестирование конфигурации для Java-разработчиков: практический опыт
В нем описана тоже нетривиальная вещь, но мало кто вообще этой проблемой занимается. Потому что все придерживаются главного правила инженеров: работает - не трогай!
А проблемы решаются по мере поступления в порядке приоритета.
Если же смотреть менее широко, как это было озвучено в оригинальном вопросе:
Тут все равно будет вопрос: а тесты точно были рабочими и проверяли, то что нужно когда либо вообще? Допустим пришел ты такой на проект с 15 тысячами тестов и легаси проектом в 25 лет и миллионом строк кода и тебе говорят: “У нас тут тесты все зеленые, но какой-то там начальник просил до обеда и желательно вчера сделать отчет в экселе (куда уж без него) про нашу автоматизацию. Ты можешь проверить, что они проверяют, то что нам нужно?
И заодно расставить лейблов над каждым какие что проверяют и до кучи их же выгрузить в нашу <имя_нашей_тестменеджмент_системы>.” 
По факту же автотесты это тоже программный продукт. Поэтому все практики по разработке применимы и желательны к ним не в меньшей, а зачастую в большей степени, т.к. код хотя бы проверяется тестами, а вот на тесты уже мало кто пишет другие тесты. Поэтому рецепты простые: ревью кода, детальное логирование, приемка, тесты опять-таки, мутационные воздействия, слоеная архитектура тестов с частичной перепроверкой на разных слоях: юнит → интеграционные → API* → UI* → E2E. Плюс хороший мониторинг, голова на плечах и ручной контроль. Автоматика - хорошо, но и голову включать нужно.
Вдогонку ешё одна ссылка на отличный доклад по интересному подходу к тестам: Максим Казанцев — Fuzzing-тестирование: ищем баги в JIT-компиляторе и не только
В данном подходе каждый тест сам по себе ничего не стоит, но вот сам подход и совокупность всех тестов на некотором количестве перерастает в новое качество и даёт весьма интересные результаты, впрочем, они так хорошо легли, только потому что полностью использовали специфику проекта.
Вообще, я заметил, что мало кто заморачивается со стратегией тестирования, по крайней мере тут таких слов почти не слышал. В основном лабают код в селениуме. А надо оно / или не надо, и может можно как-то по другому сделать - то это как-то мало людей интересует.
Ещё с другой конференции или митапа был хороший доклад про тестирование то ли в IBM, то ли в Intel (не помню уже), но я его сходу не нашел и видимо уже не найду.
testomat.io управление авто тестами