Перейти к содержимому

Фотография

Что делать когда нет времени на тестирование: лайф-хаки и практики


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 3

#1 July Kuzmicheva

July Kuzmicheva

    Специалист

  • Members
  • PipPipPipPipPip
  • 518 сообщений

Отправлено 14 февраля 2018 - 06:31

Автор: Юлия Бурматова, тест-менеджер компании "Лаборатория качества"
 

Оригинальная публикация: http://quality-lab.r...me-for-testing/

 

Наверняка многие тестировщики хотя бы раз сталкивались с ситуацией, когда времени на тестирование совершенно нет. Даже если им чуточку повезло, и хоть какое-то время осталось, то его все равно не хватит на проверку всего продукта. И не столь важно, почему так получилось (неправильно спланирована работа, заказчик захотел «прикрутить вон ту фичу» в самый последний момент, тестировщиков поздно подключили к проекту), – главное в том, что выходить из положения как-то нужно.

 

Читать публикацию полностью


  • 0

#2 SALar

SALar

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 14 февраля 2018 - 13:31

Хорошая статья. Впечатлило. Без шуток. Это очень хорошая статья человека, который в теме. Очень приличного уровня специалиста. Если по нашему рынку, то эксперт. Если по моей шкале - маг 3-4 уровня. И, да, это очень высокая оценка.   Но раз было приглашение обсуждать, то: --------------------------------------------------------------------------------------------------------- > 1. Приоритизация

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

 

 

>2 ... для смоук-тестов всегда выбираются наиболее важные бизнес-сценарии. 

Да сдчаз. Часто (не всегда) выбираются те, где более вероятна ошибка. И есть еще куча вариантов. Наиболее же востребованный для хорошей карьеры: "То, что может обнаружить HiPPO". Эту стратегию я еще на SQADays-18 рассказывал.

 

> 3

"Регрессионное тестирование" - это плохо. Смотри статью "Идеальный тестовый набор".

 

> 4

Для некоторых видов тестов документирование тестовых сценариев недопустимо. Например для "коридорного тестирования" (поименованный вид тестирования от Джоела Спольски). Ответ на вопрос: "Сможет ли покупатель в интернет магазине сделать покупку без тестовых сценариев?" - иногда ключевой.

Но есть обратная сторона. Часто именно записанные сценарии единственный способ сократить время тестирования.

 

> 5. Каждая функциональность – привыкшему к ней тестировщику

А вот это ОЧЕНЬ плохо. Это вариации. О которых Деминг писал, что их надо всячески избегать. Ну, или если хотите бытовую аналогию: "Замыленный взгляд".

 

> 6

Отошлю к блогу Влада Балина. Статьи про неуловимого Джо.

 

> 7 Только позитивные тесты

И через час после продакшена ваша компания разорилась. Реальные истории знаю.

В целом: иногда да, иногда нет. Зависит от проекта. Правильнее будет: "В зависимости от проекта выбираем позитивные или негативные". Может вы вообще только фазинг тестировать будете. Это крайне рекомендуется для финансовых проектов. А то сольют с вашей базы четырнадцать миллионов номеров банковских карт с экперейшен дейт и CVV2/CVC2 и вы после этого даже в антарктиде не спрячетесь. Даже если шкуру пингвина оденете. И, да реальные примеры я тоже знаю.

И да, я разговаривал с пенсионером, у которого баланс по коммуналке на 4 копейки не сошелся. Крайне неприятно было.

 

> 8

Промолчу. Тут не на комментарий, не на статью, а на книгу. Или цикл книг.

 

Отсутствие времени на тестирование – это всегда неприятно, ведь тестировщикам так хочется как можно качественнее проверить продукт, выполнить как можно больше проверок и в итоге порадовать конечных пользователей прекрасным результатом. 

Не-а. Есть такая штука, как "равновесие по Парето" и "гуд инаф". И многие компании для выживания специально урезают время на тестирование. Потому что от этого выигрывают все. В том числе и пользователи.

 

===================================================

Но это все так, мелочи. 

Куда важнее вопрос: "Хватает ли у вас времени на исправление ошибок? Даже если они будут выданы все и сразу?" Вот это вопрос так вопрос. И часто оказывается необходимо применить стратегию: "Грибные места". Найдите любые ошибки но только прямо сейчас. Вне зависимости от качества, релиз все равно завтра.

 

====================================================


  • 1

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#3 Ujilia

Ujilia

    Новый участник

  • Members
  • Pip
  • 16 сообщений
  • ФИО:Бурматова Юлия


Отправлено 24 февраля 2018 - 10:45

Хорошая статья. Впечатлило. Без шуток. Это очень хорошая статья человека, который в теме. Очень приличного уровня специалиста. Если по нашему рынку, то эксперт. Если по моей шкале - маг 3-4 уровня. И, да, это очень высокая оценка.

Спасибо за комментарий и такой «живой» интерес. :)

 

Если по моей шкале - маг 3-4 уровня.

 

А сколько на вашей шкале уровней, если не секрет?)

 

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

Я с этим абсолютно согласна. :) В моих тестах всегда стоят приоритеты, я по-другому их просто не составляю. Но я очень часто встречаю обратную ситуацию, к сожалению.

 

Да сдчаз. Часто (не всегда) выбираются те, где более вероятна ошибка. И есть еще куча вариантов. Наиболее же востребованный для хорошей карьеры: "То, что может обнаружить HiPPO". Эту стратегию я еще на SQADays-18 рассказывал.

 

Тут очень зависит от ситуации. На многих проектах, где мне приходилось работать, было важно, чтобы самые ключевые сценарии работали корректно. Поэтому набор смоук-тестов обязательно покрывал такие сценарии, а дальше уже отбирались те тесты, которые могли привести к ошибкам (например, какие-то слабые места продукта) на усмотрение тестировщика.


  • 0

#4 Ujilia

Ujilia

    Новый участник

  • Members
  • Pip
  • 16 сообщений
  • ФИО:Бурматова Юлия


Отправлено 24 февраля 2018 - 10:45

"Регрессионное тестирование" - это плохо. Смотри статью "Идеальный тестовый набор".

 

Не все так однозначно. :) Смотрите комментарий выше.

 

А вот это ОЧЕНЬ плохо. Это вариации. О которых Деминг писал, что их надо всячески избегать. Ну, или если хотите бытовую аналогию: "Замыленный взгляд".

Если сборка готова во второй половине дня и к вечеру надо понять, есть ли блокеры, то тестировщик, который не знаком с фичей/продуктом, вряд ли принесет много пользы.

 

Должны либо быть очень подробные тест-кейсы, либо очень опытный специалист, который находит проблемы налету. Иначе будет куча вопросов, как и что должно работать, что важно проверять. Если времени очень мало, то нормально протестировать сможет, скорее всего, только хорошо знакомый с фичей/продуктом тестировщик, потому что он знает, как все устроено и где есть слабые места, где часто все «отваливается». Эксперименты хороши, когда есть время, а не когда «Надо срочно релизить, проверьте все».

 

Отошлю к блогу Влада Балина. Статьи про неуловимого Джо.

 

И ссылка бы тут не помешала.

 

И через час после продакшена ваша компания разорилась. Реальные истории знаю.

В целом: иногда да, иногда нет. Зависит от проекта. Правильнее будет: "В зависимости от проекта выбираем позитивные или негативные".

 

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

 

Промолчу. Тут не на комментарий, не на статью, а на книгу. Или цикл книг.

 

Книги в студию. :)

 

И многие компании для выживания специально урезают время на тестирование. Потому что от этого выигрывают все. В том числе и пользователи.

 

Я думаю, если в команде специалисты не очень опытные и не находят баги одним взглядом на продукт или требования, то в спешке однозначно будет что-то критичное упущено. Чудес не бывает.

 

Вне зависимости от качества, релиз все равно завтра.

 

Увы, да, так часто бывает. 


  • 0


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных