Как наладить/оптимизировать процесс тестирования

управление
,
#1

Попросили оптимизировать процесс тестирования, нужен взгляд со стороны.
Один QA, два дева, менеджер и посредник между клиентом и командой. Менеджер хочет, что бы QA описывала план тестирования фичи до того как девы начнут делать, но время особо не выделяют спецом для этого, QA говорит, что вообще нету времени писать документация(чек листы).Да и баги они не трекают, в одном кабинете находятся и сразу QA передает что нужно фиксить девам. Как разруливать такие ситуации, когда времени мало, а документацию просят, красивые баг репорты просят… может что посоветуете в какую сторону смотреть, как оптимизировать процесс этот(тестирования)? Благодарю

question

1 лайк
#2

А девы сами что-то делают для поддержания качества? Или как в той картинке:
Tatu
Открою вам секрет - если разработчики не занимаются качеством кода, то даже будь там три тестировщика и QA Lead у вас бы не хватало времени на проведение полноценного тестирования и баги всё равно просачивались бы в прод. 1 тестер на 2 разработчика это довольно тепличные условия. Тут у многих бывает и по 3 и 5 разработчика на одного тестировщика и как-то люди выживают при этом.

4 лайка
#3

Самое лучшее самой сесть рядом и показать пример того что нужно
в те сроки - которые нужны.
Вариант 2 - нанять человека которые всё сделает за вас.

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

1 лайк
#4

Почитайте про методологию Rapid software testing, как раз для таких ситуаций была создана. Посмотрите выступление Майкла Болтона с последнего Гейзенбага на ютубе.

#5

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

Ну наверняка qa их коротко записывает себе в блокнот или чат с разработчиком, иначе я не представляю как он не забывает все перепроверить после фикса. Можно вот эти заметки вести в багтрекере комментариями к задаче по тестируемой фиче, А это уже можно считать чеклистом по регрессии ))

2 лайка
#6

Для решения таких проблем был придуман BDD подход. Рекомендую выбрать одну фичу и применить его. Не распространять на весь процесс, пока не поймете, что нет недопонимания, между всеми членами команды.
И самое важное, если девы не станут частью процесса тестирования(юнит, интегрейшн и прочие тесты), то вам все равно будет сложно добиться стабильного качества продукта.
Почитайте как устроен процесс тестирования в крупных компаниях, типа Google

2 лайка
#7
#8

Я прошел тренинг Rapid Software Testing с Болтоном. Одна из позиций Rapid (быстрого) как раз в том что меньше формализма и “вот этих красивостей”.

Кто хочет красивостей, пусть выделяет на них время время.

1 лайк
#9

Как наладить (коротко)

  • Чеклисты окей. Их можно писать быстро.
  • План можно разрабатывать / редактировать как mindmap ( XMind , Freeplane / Freemind). Оттуда можно копипастить в другие системы документов (Confluence)
  • Трекать можно и нужно: Google Docs , табличка с типичными “ID - Summary - Data - Steps - AR - ER” или что больше подойдет.
  • Дополнительным “ускорителем” для меня работает то что я давно изучил “слепую печать” и быстро печатаю.

“Нет времени – нет красивостей”.

1 лайк
#10

По основам “процессов” Rapid SoftwareTesting смотреть лучше не видео с Гейзенбага, а вот эти два:

2 лайка
#11

BDD подход НЕ ускоряет разработку и имеет массу своих проблем (уже писал об этом на форуме : Каковы преимущества и недостатки BDD подхода написания тестов? - #9 от пользователя rpwheeler )

3 лайка
#12

Я работаю на большом проекте, где BDD подход прекрасно прижился. В данный момент мануальные тестеры пишут большинство тестовых сценариев. Но, самое важное, заказчик начал использовать его тоже. Но это “философия”
Возращаясь к вопросу(прикольно, что автор никак не комментирует), где вы увидели хоть слово про автоматизацию?

Использование BDD решает этот вопрос:

  1. Девы имеют документ для разработки(описанную фичу)
  2. Мануальный тестировщик знает как должна работать фича и как ее тестировать
  3. В случае обнаружения бага - готовые степы для репродюса

И, повторюсь, все это ерунда, если девелоперы не вовлечены в процесс поддержания качества продукта с момента, когда они еще не написали ни одной строчки кода))

#13

Я только читал что оно прижилось “где-то”, но ни на одном проекте где я работал оно не прижилось, и от людей которых я знаю лично тоже “как оно прижилось” вот что-то не слышал. Только неудачи и выбрасывание BDD.

Где-то может и решает. По ссылке выше я привел три случая где BDD ничего не решило. В последнем из них из ~75 человек никто не говорит “давайте вернем BDD”.

1 лайк
#14

:grin:

немного не в тему, но все же
В конце пример отчета, формируемого Specflow(немного допиленного)

#15

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

Ну и вообще здесь вопрос можно перевести в плоскость - а зачем тестировать? пусть разработчики пишут хороший код, нам и тестировать не надо будет, и пусть горит эта bdd синим пламенем.

2 лайка
#16

Я не знаю, плакать или смеяться. Я написал телегу -=человеческим языком=-. Это не приблизило Вас к пониманию моего отношения к BDDSM.

Там в теме дана ссылка на статью в которой это заработало после вложения массы ресурсов. У меня три примера как это не заработало. Кто не хочет вкладывать в это массы ресурсов – можно даже не начинать. Вы хотите? Ваши ресурсы, конечно, Вы решаете как их тратить на свой страх и бюджет.

Не вижу никаких оснований с этим соглашаться. Тестирование это гораздо больше чем может описать BDD вообще даже в принципе. Геркин совершенно убог, даже в области функционального тестирования (которым все не исчерпывается). Геркин это алгоритмическое описание с ограниченными возможностями для людей с особыми потребностями. Формальность изолированных фич, возведенная в садомазохизм “мы свяжем всех этим Геркином, и они должны получать от этого удовольствие”.

Можно. Где-то. Как-то. Вместе с созданием и поддержкой для этого особого языка и кучи кода (как я написал в “телеге”). Это траты времени и труда, это совершенно не обязательно будет нормально работать, не обязательно даже принесет существенную пользу.

Отсюда и отношение: в основном и на массе проектов это не нужно, это ничего не ускоряет и не оптимизирует.

#17

мир не исчерпывается тиньковым, где бдд выстрелил, и 3 проектами из вашего опыта, где бдд не выстрелил.

я понял, что вам bdd не нравится, ну что поделать, копайте в другую сторону, а этот срач по методологии предлагаю окончить, а то так и эджайл можно вспомнить, и ооп вс фп, и так далее

#18

Я опять не знаю плакать или смеяться.

Тестирование это большая тема.
Функциональное тестирование это только часть его.
Любое функциональное описание — лишь часть того что должно происходить.

Текущая фича включает три новых графичеких маркера которые выглядят определенным образом, могут менять положение и размер. Это легко подергать, но как, и зачем фиксировать в геркине вид маркера?

Фича должна получить определенную автоматизацию, и проверку перформанса системы после того как она задействована. Перфоманс нужен, но прекрасно чувствует себя без геркина.

Одна из прошлых фич которые я буду включать в будущую презентацию состояла в переключении двух экранов, а получила 13 связанных с ней багов, бОльшей частью потому что я решил попробовать фичу в контексте связанных с ней путей пользователя. Например 1) отказ от повторного прохождения тем же клиентом на следующем за одним из двух фичевых экранов приводил ко крэшу 2) пропуск одной строчки при мерже предыдущей фичи приводил к попытке загружать умопомрачительное количество данных вместо только тех что нужны 3) программист забыл подмержить новую иконку от дизайна …

По классику Гленфорду Майерсу надо смотреть не только что программа делает что она должна делать, но и то что она НЕ делает того чего НЕ должна делать. Например, для мобильных приложений надо мониторить что программа не “съедает слишком много памяти”, что после пролистывания 40 главных новостей в следующей 20-ке не начинают пропадать изображения, что менее чем через 5 минут активного листания новостей не происходит крэша и пр.

Методология RST вышеупомянутого Болтона говорит о том, что ты можешь брать mindmap или табличное представление (“модель”) тестируемой сущности (аналогичная “модель” сущности и проверок может быть и чеклистом) и начинать тестировать, расписывая свои идеи и сразу их проверяя. Заводишь пункты, работаешь, по mindmap или таблице можешь и отчитаться. Так быстрее: не нужно придумывать что-то под геркин.

Вы все богатство происходящего в тестировании сводите к “не нравится BDD”, спровоцировав на следующий ответ:
"Любители геркина пытаются все свести к трем словам. Не будь таким. Всегда думай что возможных проблем с приложением и путей тестирования намного больше чем три слова убогого геркина. "

#19

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

если у топикстартера нет времени и денег на внедрение новой методологии, будь-то бдд или что-либо другое - то наши разговоры тут излишние.

#20

да, спасибо всем что отвечали.
Да они и сами не знают чего хотят, денег нету, но улучшения хотят.
Потому и ищу что ж можно делать, в какие пути стоит смотреть и все же что нужно донести к клиенту и менеджеру.
как @rpwheeler сказал, есть время- есть красивости, вот т к этому и пришла. Благодарю!

1 лайк