[Тестирование веб-сервисов] Хрустальный шар опытного тестировщика (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Этот блог посвящен размышлениям о прошлом, настоящем и будущем в тестировании. Как бы я ни хотел видеть все ясно, мой хрустальный шар довольно тусклый. Однако, учиться необходимо, и вот мой инструмент для этого. Разница между тест-идеей и тест-кейсом?Год за годом, меняя организацию одну за другой, я прихожу на новое предприятие в предвкушении того, что мне не придется видеть тест-кейсы, кроме тех, которые автоматизированы, и посредством непрерывного выполнения поддерживают постоянное обновление. И все же год за годом, переходя из одной организации в другую, я узнаю, что люди по-прежнему пишут тест-кейсы. Это те тест-кейсы, которые содержат название и шаги для выполнения. Те, которые определяют последовательность действий в приложении, которые необходимо проверять, и шаги, которые вы можете и не выполнить, потому что вы не робот. С моей точки зрения, идеи не представляют ценности, и нас мало волнует, насколько хорошо они задокументированы. Идеи, записанные на листочках, мне часто трудно расшифровать через месяц, но это критически важные заметки и они мне очень нужны, когда я возвращаюсь к заранее структурированной информации, которую ранее документировал. Тест-кейсы — это то, что мы, возможно, захотим оставить на потом, это больше, чем идеи. У них есть структура, которая поддерживает их выполнение, даже если они похожи на чеклист. Они часто включают шаги и идеи о порядке выполнения. Тест-кейсы лучше рассматривать как результат тестирования (причем автоматизированного!), а не исходными данными для тестирования.Дело в том, что некоторые из наших неудачных опытов никогда не будут опубликованы, потому что мы не можем говорить о них, пока мы ещё находимся в процессе работы. Вдохновленный сегодняшними разговорами, я возвращаюсь к опыту, о котором я не мог рассказать, когда он произошел, но могу сегодня, с примерами.Я работал в продуктовой/консалтинговой компании, и консалтинговая сторона, которую я представлял, работала довольно хорошо — настолько хорошо, что было трудно выделить место для любого из наших экспертов по тестированию, чтобы провести тестирование нашего собственного продукта. Консалтинг оплачивался гораздо лучше. Руководство вытаскивало одного из нас, консультантов, для тестирования релиза 1, другого — для тестирования релиза 2 и так далее. В конце концов, я оказался следующим в очереди. Вспоминая об этом 20 лет спустя, забавно осознавать, что я уже представлялся как эксперт по тестированию. Тестируя продукт, я намеревался сделать это хорошо — как и все мы. Я спросил, что делали те, кто был до меня, и мне указали на инструмент управления тестированием, гордые коллеги, которые позаботились о том, чтобы задокументировать свое тестирование. Вот реальные примеры того, что я получил.
Они считались тест-кейсами. Они намного хуже некоторых лучших тестовых-кейсов, которые я видел на протяжении многих лет, но даже лучшие из них имеют всеобщее клеймо бесполезности для хорошего тестирования. Эти тест-кейсы были ужасны. Они и сейчас ужасны. Время не сделало их лучше, только хуже. Они представляли собой пошаговые инструкции, в которых много усилий было направлено на имитацию тестирования путем тщательного описания одних и тех же шагов только для того, чтобы тестировщик, применяющий их, знал, что он, например, сделал box-тестирование сверху-вниз, справа-налево. В них были определены некие магические значения, которые полностью упускают смысл того, почему эти значения были выбраны, но я могу только догадываться, что выбор данных в них отражал названия в соответствии с концепцией, а не названия для вероятности нахождения проблем или даже указания на идеи, где могут быть проблемы. Во время моей работы, первое, что я сделал, это отказался от всех работ. Это были работы моих уважаемых коллег, и они сделали лучшее, что могли придумать в той ситуации. Я мог только надеяться, что они отразили тест-кейсы, а не проведенное тестирование. Я перевел тестирование на исследовательский уровень. Больше никаких тест-кейсов. Максимум, что мы могли получить, — это контрольный список функций и идей после того, как все это было изучено и структурировано в ходе многочисленных раундов репетиций через реальное тестирование. Хотя то, с чем я сталкиваюсь в организациях в наши дни, обычно не так плохо, но и не намного лучше. Я снова и снова доказывал, что отказ от тест-кейсов улучшает тестирование. Контролируемый эксперимент в течение четырех недель, в котором мы использовали заранее разработанные кейсы в двух случаях, обнаружив ноль проблем, и использовали свободное исследовательское тестирование с подготовленными тестовыми данными в двух других случаях, обнаружив все проблемы был сделан для того, чтобы сообщить о результатах того пользовательского тестирования. Это по сути было удаление 39 страниц с 46 "тест-кейсами", где 3 части информации я даже не знал, присоединившись к новой компании на первой неделе. В остальных случаях, когда я не делал публичных презентаций, я могу спустя годы найти цифры, которыми я делился. Я бы хотел, чтобы мир был готов к качественному тестированию, но это все еще не так. Автоматизация и работа над идеями лучшего и качественного тестирования кажутся нашей главной надеждой. И я рад, что автоматизация тестирования — это всего лишь разумный способ документирования тестирования.
Перевод статьи подготовлен в рамках курса "QA Engineer".
Присоединяйтесь к вебинару «Методологии разработки», где мы рассмотрим методологии разработки scrum, kanban, waterfallи изучим роль тестирования в процессе разработки.
===========
Источник:
habr.com
===========
===========
Автор оригинала: Maaret Pyhäjärvi
===========Похожие новости:
- [Тестирование IT-систем, Python, Программирование, Машинное обучение] PyTest для машинного обучения — простой учебник на основе примеров (перевод)
- [Тестирование IT-систем, API, Тестирование веб-сервисов, Тестирование мобильных приложений] Что такое JSON
- [Тестирование IT-систем, Программирование, Проектирование и рефакторинг, Тестирование веб-сервисов] Аспекты хороших юнит-тестов
- [Программирование, Java] Okta: безопасный доступ к приложениям на Angular + Spring Boot (перевод)
- [Python, Программирование] Режим мачете: теги для фреймов (перевод)
- [Высокая производительность, Тестирование веб-сервисов, Конференции, DevOps] Приглашаем на Semrush IT meetup: Производительность веб-сервисов
- [Управление разработкой, Управление продуктом] 3 самых больших факапа разработчика (перевод)
- [Высокая производительность, Тестирование IT-систем] 30 тысяч пользователей одновременно: как мы тестировали корпоративный портал «1С-Битрикс24: Enterprise»
- [Программирование, Kotlin] Руководство по работе с фреймворком Kotlin Exposed (перевод)
- [Тестирование IT-систем, Анализ и проектирование систем, ERP-системы, Agile] Масштабный проект по внедрению SAP S/4HANA в удаленном режиме: уроки, которые мы усвоили
Теги для поиска: #_testirovanie_vebservisov (Тестирование веб-сервисов), #_testirovanie (тестирование), #_testkejs (тест-кейс), #_avtomatizatsija_testirovanija (автоматизация тестирования), #_metodologii_razrabotki (методологии разработки), #_blog_kompanii_otus (
Блог компании OTUS
), #_testirovanie_vebservisov (
Тестирование веб-сервисов
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 12:24
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Этот блог посвящен размышлениям о прошлом, настоящем и будущем в тестировании. Как бы я ни хотел видеть все ясно, мой хрустальный шар довольно тусклый. Однако, учиться необходимо, и вот мой инструмент для этого. Разница между тест-идеей и тест-кейсом?Год за годом, меняя организацию одну за другой, я прихожу на новое предприятие в предвкушении того, что мне не придется видеть тест-кейсы, кроме тех, которые автоматизированы, и посредством непрерывного выполнения поддерживают постоянное обновление. И все же год за годом, переходя из одной организации в другую, я узнаю, что люди по-прежнему пишут тест-кейсы. Это те тест-кейсы, которые содержат название и шаги для выполнения. Те, которые определяют последовательность действий в приложении, которые необходимо проверять, и шаги, которые вы можете и не выполнить, потому что вы не робот. С моей точки зрения, идеи не представляют ценности, и нас мало волнует, насколько хорошо они задокументированы. Идеи, записанные на листочках, мне часто трудно расшифровать через месяц, но это критически важные заметки и они мне очень нужны, когда я возвращаюсь к заранее структурированной информации, которую ранее документировал. Тест-кейсы — это то, что мы, возможно, захотим оставить на потом, это больше, чем идеи. У них есть структура, которая поддерживает их выполнение, даже если они похожи на чеклист. Они часто включают шаги и идеи о порядке выполнения. Тест-кейсы лучше рассматривать как результат тестирования (причем автоматизированного!), а не исходными данными для тестирования.Дело в том, что некоторые из наших неудачных опытов никогда не будут опубликованы, потому что мы не можем говорить о них, пока мы ещё находимся в процессе работы. Вдохновленный сегодняшними разговорами, я возвращаюсь к опыту, о котором я не мог рассказать, когда он произошел, но могу сегодня, с примерами.Я работал в продуктовой/консалтинговой компании, и консалтинговая сторона, которую я представлял, работала довольно хорошо — настолько хорошо, что было трудно выделить место для любого из наших экспертов по тестированию, чтобы провести тестирование нашего собственного продукта. Консалтинг оплачивался гораздо лучше. Руководство вытаскивало одного из нас, консультантов, для тестирования релиза 1, другого — для тестирования релиза 2 и так далее. В конце концов, я оказался следующим в очереди. Вспоминая об этом 20 лет спустя, забавно осознавать, что я уже представлялся как эксперт по тестированию. Тестируя продукт, я намеревался сделать это хорошо — как и все мы. Я спросил, что делали те, кто был до меня, и мне указали на инструмент управления тестированием, гордые коллеги, которые позаботились о том, чтобы задокументировать свое тестирование. Вот реальные примеры того, что я получил.    Они считались тест-кейсами. Они намного хуже некоторых лучших тестовых-кейсов, которые я видел на протяжении многих лет, но даже лучшие из них имеют всеобщее клеймо бесполезности для хорошего тестирования. Эти тест-кейсы были ужасны. Они и сейчас ужасны. Время не сделало их лучше, только хуже. Они представляли собой пошаговые инструкции, в которых много усилий было направлено на имитацию тестирования путем тщательного описания одних и тех же шагов только для того, чтобы тестировщик, применяющий их, знал, что он, например, сделал box-тестирование сверху-вниз, справа-налево. В них были определены некие магические значения, которые полностью упускают смысл того, почему эти значения были выбраны, но я могу только догадываться, что выбор данных в них отражал названия в соответствии с концепцией, а не названия для вероятности нахождения проблем или даже указания на идеи, где могут быть проблемы. Во время моей работы, первое, что я сделал, это отказался от всех работ. Это были работы моих уважаемых коллег, и они сделали лучшее, что могли придумать в той ситуации. Я мог только надеяться, что они отразили тест-кейсы, а не проведенное тестирование. Я перевел тестирование на исследовательский уровень. Больше никаких тест-кейсов. Максимум, что мы могли получить, — это контрольный список функций и идей после того, как все это было изучено и структурировано в ходе многочисленных раундов репетиций через реальное тестирование. Хотя то, с чем я сталкиваюсь в организациях в наши дни, обычно не так плохо, но и не намного лучше. Я снова и снова доказывал, что отказ от тест-кейсов улучшает тестирование. Контролируемый эксперимент в течение четырех недель, в котором мы использовали заранее разработанные кейсы в двух случаях, обнаружив ноль проблем, и использовали свободное исследовательское тестирование с подготовленными тестовыми данными в двух других случаях, обнаружив все проблемы был сделан для того, чтобы сообщить о результатах того пользовательского тестирования. Это по сути было удаление 39 страниц с 46 "тест-кейсами", где 3 части информации я даже не знал, присоединившись к новой компании на первой неделе. В остальных случаях, когда я не делал публичных презентаций, я могу спустя годы найти цифры, которыми я делился. Я бы хотел, чтобы мир был готов к качественному тестированию, но это все еще не так. Автоматизация и работа над идеями лучшего и качественного тестирования кажутся нашей главной надеждой. И я рад, что автоматизация тестирования — это всего лишь разумный способ документирования тестирования. Перевод статьи подготовлен в рамках курса "QA Engineer".
Присоединяйтесь к вебинару «Методологии разработки», где мы рассмотрим методологии разработки scrum, kanban, waterfallи изучим роль тестирования в процессе разработки. =========== Источник: habr.com =========== =========== Автор оригинала: Maaret Pyhäjärvi ===========Похожие новости:
Блог компании OTUS ), #_testirovanie_vebservisov ( Тестирование веб-сервисов ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 12:24
Часовой пояс: UTC + 5