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

Selenium WebDriver: полное руководство
онлайн, начало 19 октября
Логи как инструмент тестировщика
онлайн, начало 22 октября
Первый Онлайн ИНститут Тестировщиков
онлайн, начало 15 октября
Тестирование REST API
онлайн, начало 22 октября
Фотография

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


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

#1 July Kuzmicheva

July Kuzmicheva

    Опытный участник

  • Members
  • PipPipPipPip
  • 480 сообщений

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

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

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

 

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

 

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


  • 0

#2 SALar

SALar

    Гуру

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


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

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

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

 

 

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

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

 

> 3

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

 

> 4

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

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

 

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

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

 

> 6

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

 

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

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

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

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

 

> 8

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

 

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

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

 

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

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

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

 

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


  • 1

-- 

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

Блог 255 ступеней

 


#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


Инструменты тестировщика: Командная строка
онлайн, начало 3 октября
Практикум по тест-дизайну 2.0
онлайн, начало 12 октября
Программирование на Phyton для тестировщиков
онлайн, начало 26 октября
Тестирование производительности (JMeter)
онлайн, начало 28 сентября



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

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

Яндекс.Метрика
Реклама на портале