Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 11
Мне кажется, вы описали то, что сейчас называт «Software Developer In Test». А что нужно (и в какой роли) в проекте сильно зависит от поставленных процессов
Планирование тестов/написание тестов
180 полноценных функциональных тестов за почти 2 года работы
Тесты совершают больше 1 действия?
Проверяют больше 1 условия?
С идеей согласен, но объем функциональности продукта кажется небольшим. Или нет?
В первую очередь надо выбрать язык программирования
И ни слова о том, что лучший выбор — тот язык, на котором написан проект?
Вы работаете на проектной, не продуктовой разработке?
Да Тесты совершают намного больше одного действия. Они заточены под сценарии поведения пользователей системы — включают в себя ненормальное поведение пользователей и «троллей». Объём функциональности продукта, на самом деле, большой… Не гигантский, но большой.
Да. Ни слова… Потому что язык, как мне кажется, надо выбирать не под проект, а под спектр потенциальных задач. Потому что проект как начался, так и закончится, а специалист должен остаться специалистом, не заточенным под вот эту вот конкретную функциональность.
Над продуктовой разработкой в проекте :)
Да. Ни слова… Потому что язык, как мне кажется, надо выбирать не под проект, а под спектр потенциальных задач. Потому что проект как начался, так и закончится, а специалист должен остаться специалистом, не заточенным под вот эту вот конкретную функциональность.
Над продуктовой разработкой в проекте :)
«Тесты совершают намного больше одного действия»
На мой взгляд — это антипаттерн. Тесты должны быть простыми — подготовка данных, действие и проверка. Благодаря такому подходу — тесты станет гораздо проще поддерживать, да и поиск ошибок упростится — представьте — если падает тест, то можно сразу предположить в каком именно методе и при каких условиях возникает ошибка, а не разгребать тонну логов и стек трейсов.
Тесты иммитурующии работу троллей разбивайте на маленькие:)
И еще очень полезны практики код ревью тестах (как между тестировщиками, так и перекрестные ревью разработчик — тестировщик).
На мой взгляд — это антипаттерн. Тесты должны быть простыми — подготовка данных, действие и проверка. Благодаря такому подходу — тесты станет гораздо проще поддерживать, да и поиск ошибок упростится — представьте — если падает тест, то можно сразу предположить в каком именно методе и при каких условиях возникает ошибка, а не разгребать тонну логов и стек трейсов.
Тесты иммитурующии работу троллей разбивайте на маленькие:)
И еще очень полезны практики код ревью тестах (как между тестировщиками, так и перекрестные ревью разработчик — тестировщик).
На мой взгляд, это паттерн. Тесты не должны быть простыми… Потому что пользователи ведут себя крайне непросто. Не существует действия «оплатить покупки в интернет-магазине» без действия «добавить товары в корзину»… Этот примитивный пример масштабируется на любую систему. И ограничивается лишь функциональными возможностями пользователя.
Это примерно то же самое, что говорить «тех-задание» — это паттерн. А user-story — антипаттерн. Сайты, программы, даже API постепенно переходят из набора функциональностей в набор сценариев для пользователя по реализации этих функциональностей. Уже почти нет форм с кучей кнопок на них… Есть call-to-action-ы, есть вероятности тех или иных сценариев… Это можно анализировать, изучать пользователей, выделять приоритетные сценарии, а не приоритетные функции, покрывать эти сценарии тестами. Теория тестирования, BDD идеи и т.д. подтягиваются к реальности, но, к сожалению, и в них пока есть то, что вызывает грусть.
— По-вашему проще поддерживать 2000 маленьких тестов, а не 100 сценарийных? :) Мой опыт говорит об обратном. Сценарии можно разбивать по тематикам, включать в разные сэты тестов — после падения видеть сразу, что вот в этой «сфере» у нас беда. Это очень удобно. С маленькими проверками такой прозрачности не добиться…
— По поводу предположений, в каком-методе. В стэк-трейсе всегда видна цепочка вызовов — видно в каком методе началось и где мы упали. Если всё правильно обработано, то ясное сообщение в Exception. Если и этого недостаточно, логи, если и этого — ну можно отдельно этот тест запустить и посмотреть глазами :) Ну или пройти по сценарию, если Software Developer in Test позаботился о том, чтобы тесты были читабельные и понятные. В конце концов Debug )))
-Тролли априори не троллят маленькими операциями :)
— Код-ревью — замечательная штука. Тут спорить не о чем
Это примерно то же самое, что говорить «тех-задание» — это паттерн. А user-story — антипаттерн. Сайты, программы, даже API постепенно переходят из набора функциональностей в набор сценариев для пользователя по реализации этих функциональностей. Уже почти нет форм с кучей кнопок на них… Есть call-to-action-ы, есть вероятности тех или иных сценариев… Это можно анализировать, изучать пользователей, выделять приоритетные сценарии, а не приоритетные функции, покрывать эти сценарии тестами. Теория тестирования, BDD идеи и т.д. подтягиваются к реальности, но, к сожалению, и в них пока есть то, что вызывает грусть.
— По-вашему проще поддерживать 2000 маленьких тестов, а не 100 сценарийных? :) Мой опыт говорит об обратном. Сценарии можно разбивать по тематикам, включать в разные сэты тестов — после падения видеть сразу, что вот в этой «сфере» у нас беда. Это очень удобно. С маленькими проверками такой прозрачности не добиться…
— По поводу предположений, в каком-методе. В стэк-трейсе всегда видна цепочка вызовов — видно в каком методе началось и где мы упали. Если всё правильно обработано, то ясное сообщение в Exception. Если и этого недостаточно, логи, если и этого — ну можно отдельно этот тест запустить и посмотреть глазами :) Ну или пройти по сценарию, если Software Developer in Test позаботился о том, чтобы тесты были читабельные и понятные. В конце концов Debug )))
-Тролли априори не троллят маленькими операциями :)
— Код-ревью — замечательная штука. Тут спорить не о чем
Ой… тут в голову пример пришёл.
Вот вопрос — сколько надо сделать заборов крови, что провести анализ? :)
У меня в последний раз делали 3 забора:
1. Всякие стандартные элитроциты, лейкоциты, тромбоциты и т.д. штук 25
2. Всякие нехорошие — ВИЧ, гепатит и т.д.
3. Сахар…
4*… Ещё делали время свёртываемости крови из пальца…
Окей… я вижу 4 сценария…
Ну или как предлагается Вами за 30 даже — если на секунду забыть о том, что человек умрёт от такого большого количества заборов. Кстати — если перевести на язык тестирования, то сценарии экономят время на инициализации. Потому что она проводится реже. 4 против 30 небольшая экономия. Но 100 против 2000 — огого… Особенно, если инициализация тяжёлая…
Окей. Вернёмся к нашей крови… Давайте поанализируем результаты. Я на терапевта не учился… Но рискну предположить, что часто «картиной» является не отдельный анализ, а некоторая совокупность. То есть терапевт, увидев, повышенные тромбоциты заостряет своё внимание на каких-то определённых показателях из общего списка анализов, отвергая в голове версии, или подтверждая их. Получив некоторую наибольшую вероятность, он/она принимает решение о том, к кому направить…
Согласитесь, добавив в мои 4 сецнария немного макс-правдоподобия и гипотетическую таблицу направлений в зависимости от того, на что похожа «картина», я получу неплохой движок, отвечающий с точки зрения тестирования(анализа) крови на бОльшее количество вопросов, чем изолированные проверки каждого из показателей.
Вот вопрос — сколько надо сделать заборов крови, что провести анализ? :)
У меня в последний раз делали 3 забора:
1. Всякие стандартные элитроциты, лейкоциты, тромбоциты и т.д. штук 25
2. Всякие нехорошие — ВИЧ, гепатит и т.д.
3. Сахар…
4*… Ещё делали время свёртываемости крови из пальца…
Окей… я вижу 4 сценария…
Ну или как предлагается Вами за 30 даже — если на секунду забыть о том, что человек умрёт от такого большого количества заборов. Кстати — если перевести на язык тестирования, то сценарии экономят время на инициализации. Потому что она проводится реже. 4 против 30 небольшая экономия. Но 100 против 2000 — огого… Особенно, если инициализация тяжёлая…
Окей. Вернёмся к нашей крови… Давайте поанализируем результаты. Я на терапевта не учился… Но рискну предположить, что часто «картиной» является не отдельный анализ, а некоторая совокупность. То есть терапевт, увидев, повышенные тромбоциты заостряет своё внимание на каких-то определённых показателях из общего списка анализов, отвергая в голове версии, или подтверждая их. Получив некоторую наибольшую вероятность, он/она принимает решение о том, к кому направить…
Согласитесь, добавив в мои 4 сецнария немного макс-правдоподобия и гипотетическую таблицу направлений в зависимости от того, на что похожа «картина», я получу неплохой движок, отвечающий с точки зрения тестирования(анализа) крови на бОльшее количество вопросов, чем изолированные проверки каждого из показателей.
*эритроциты))) очепятка
Рискну предположить, что Вы и Ins4n3 говорите о разном. Он говорит про модульное тестирование, а Вы про функциональное. Первое — оно про качество кода. И нужно чтобы быть уверенным что хотя бы по отдельности все модули работают так, как ожидает программист. Второе же — про качество продукта. Оно нужно уже чтобы убедиться что все модули правильно друг с другом соединены.
По идее, модульные тесты можно выкинуть, и оставить только функциональные, однако, как показывает опыт, работать с функциональными тестами значительно проще, если каждый отдельный модуль работает корректно. В таком случае хотя бы видно что «конкретно в этом месте идет запрос аккаунта с плохим id и падает один тест», а не «сама реализация поиска аккаунта по id с ошибкой и падают все тесты».
Соответственно, функциональные тесты, как Вы правильно сказали, куда полезнее делать именно сценарийными. Но вот модульные действительно должны быть простыми.
По идее, модульные тесты можно выкинуть, и оставить только функциональные, однако, как показывает опыт, работать с функциональными тестами значительно проще, если каждый отдельный модуль работает корректно. В таком случае хотя бы видно что «конкретно в этом месте идет запрос аккаунта с плохим id и падает один тест», а не «сама реализация поиска аккаунта по id с ошибкой и падают все тесты».
Соответственно, функциональные тесты, как Вы правильно сказали, куда полезнее делать именно сценарийными. Но вот модульные действительно должны быть простыми.
Полностью согласен с автором. Технологии меняются и пора меняться тестировщикам. Такие тестировщики, т.е. Software Developer In Tests наиболее полезны в продуктовых командах, т.е. работая вместе с разработчиками. В данном случае стоит использовать, тот язык, на котором построен основной код продукта
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как стать автоматизатором тестирования?