Вот у меня тот же вопрос возник.

 

В реальной работе тестировщика тест-планы и тест-кейсы не требуются наверное в 95% случаев.

 

Неправда.

 

а особенно в современном эджайле,

 

Что ещё за современный аджайл?

 

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

 

Это… (да это троллинг!)

сразу видно что не читали обсуждение, а только выборочные предложения

почитайте, там конкретно же показано, что первый сертификат ISTQB учит именно водопадной модели, и только потом даёт доступ к сертификату по гибкой модели

вот в этом и проблема

 

 

Далее описан фундаментальный процесс в традиционной последовательности. А как его еще описать? Не говорить про то, что нужно проводить анализ перед началом работы?

так выше обсуждение почитайте

этот базовый сертификат подробно описывает все шаги "традиционной модели" она же "водопадная" - которая скорее всего не нужна будет на работе так как у всех эджайл

а вот что должно быть в базовом сертификате, так это просто краткое упоминание традиционной/фундаментальной/водопадной модели, и дальше описание как работать по эджайлу, как это сделано у них же но в другом сертификате "Тестирование в гибких методологиях"

https://www.istqb.or...n-syllabus.html

 

 

ISTQB не учит плохому, а учит теории. 

ну а Вы прочитали обсуждение, или только заглавие?

там можно прочитать, что "Сертифицированный тестировщик" учит не тому процессу который используется в большинстве компаний - то есть данный сертификат учит как работать по водопадному процессу, хотя большинство компаний уже давно перешли на эджайл. И вот эта теория "сначала создайте тесты, только затем выполняйте тесты" вредна и не работает в эджайле

 

Ок, предположим, что мы идём к чувакам из ISTQB, кладём их всех на пол и начинаем их судить:

 

— Вы утверждаете, что начинать тестирование надо начинать именно с написания тест-плана и тест-кейсов, а потом конечно, гоу-гоу на выполнение этих тест-кейсов.

 

— Ну, здравый смысл же… Сперва вымой руки, затем садись за стол…

 

— Но ведь всё поменялось! Теперь ведь:

(1) вместо тест-планов есть спринт-рефайнмент,

(2) вместо тест-кейсов — чек-листы и исследовательское тестирование,

(3) вместо ручной регрессии — автоматизированные тесты.

(4) Тест-менеджеров и тех практически не осталось! Пора уже принять современные реалии.

 

И вот здесь я не согласен. Ничего не поменялось. Спринт-рефайнмент что, отменяет тестирование? Исследовательское тестирование что, отрицает тест-кейсы? Автоматизация что, решает проблему регресса? Автоматизация, кстати, чего именно?  Функциональных тестов? Юнит тестов? Аджайл что, отменяет/заменяет установки "традиционной модели" (она же "водопадная", она же Соня Канцельбоген, воровка на доверии и особа, приближённая к императору)?

 

И если ответы будут «Да!», то мне сейчас, глядя на лежащих на полу чуваков из ISTQB, придётся признать, что мой собрат не понимает того, чем он занимается, и несёт в эфир белиберду белиберденьскую, бо его, походу, укусил какой-то дурак с неправильным аджайлом. Придётся извиняться перед этими чуваками.

 

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

 

Понятно ли я говорю?

очевидно что пост номер 7 вверху так и не прочитали:

https://software-tes...khomu/?p=174614

эджайл от водопада между прочим сильно отличается. По водопаду мы получаем софт на тестирование, составляем тест-план и начинаем писать тест-кейсы, тестируем только после того как написали кейсы. Всё в порядке водопада

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

 

 

Что-то мне говорит, что методику "начинать тестирование как можно раньше" я слышал еще до эджайла)

конечно и раньше такое было, но не в "фундаментальном процессе тестирования". В водопаде вообще сложно начать тестировать "раньше", так как тестировщик получит продукт только в конце процесса

я недавно был на лекции Monika Stöcklein-Olsen, которая участвует в разработке ISTQB, и она приводила пример из своей практики, где применяла этот процесс:

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

 

 

Это не собеседование, домашнее задание.)

тогда начинайте выполнять

 

Мы прожили без тест кейсов и без планирования тестирования 6 месяцев в следствии реорганизации команды и компании в целом. В результате я месяц разгребаю, описываю и систематизирую новый функционал, перерабатывая в будни и по выходным периодически. И конца и края этому не видно. А всё потому что тест кейсы не делались на функционал который был не приоритетный, а потом он неожиданно стал приоритетный. И оказалось что там миллиард багов, а новые разработчики вообще не понимают, как что работает. Как по мне, да же если у нас аджайл, и что иногда нам нужно например:

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

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

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

3. Человеческий фактор никто не отменял. Я давеча проводя "исследовательское" тестирование, после двух недель переработок пропустил на прод абсолютно банальный баг с неправильным суммированием в столбце "итого". Просто не заметил/забыл посмотреть/хз что ещё..и всё. При тестировании расчетов верить нельзя да же самому себе. 

Да же если у вас лендинг с 5тью кнопками и чисто визуальным JSом, всё равно хотя бы единожды написать подробные тест кейсы надо, да же если на их поддержку потом забьют. 

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

 

 

"завтра выкатываем, забей на регресс"

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

 

 

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

ну и кто будет платить за создание и поддержку этой "документации по тестированию" которой будут редко пользоваться, то есть отдача маленькая?

 

 

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

можно всегда почитать документацию по продукту, плюс можно код открыть

 

 

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

опять же новые люди могут читать документацию по продукту, там всё описано как продукт работает

 

 

3. Человеческий фактор никто не отменял. Я давеча проводя "исследовательское" тестирование, после двух недель переработок пропустил на прод абсолютно банальный баг с неправильным суммированием в столбце "итого". Просто не заметил/забыл посмотреть/хз что ещё..и всё. При тестировании расчетов верить нельзя да же самому себе. 

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

 

Да же если у вас лендинг с 5тью кнопками и чисто визуальным JSом, всё равно хотя бы единожды написать подробные тест кейсы надо, да же если на их поддержку потом забьют. 

наоборот не надо, зачем тратить деньги на создание документации которую выбросят в мусорку? эти деньги можно потратить на автоматизацию тестирования

почитал их сайты и разобрался что к чему:

https://www.rstqb.or...tification.html

вот он, путь сертификации: 

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

а потом мы получаем доступ к ещё одному базовому же сертификату "Тестирование в гибких методологиях", который уже основан на нормальном эджайле

все остальные курсы основаны опять же на водопадной модели, как и первый сертификат

вот и проблема: 

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

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

вот многочисленные "выпускники ISTQB" со знанием водопада попадают конечно же в эджайл компании и пытаются применять "полученные знания", в которых надо писать тест-кейсы

Этот сертификат "Тестирование в гибких методологиях" по факту должен быть объединён с "Сертифицированный тестировщик" и быть одним входным сертификатом

 

 

https://www.youtube....h?v=DvMh4_ak6r4

ну и к чему тут троллинг?

 

 

ISTQB вообще не учит, с чего начинать тестирование.

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

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

 

Почитайте силлабусы для Advanced.

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

ну открыл например Адвансд Техникал Аналист, то же самое что и в фаундейшн:

пункт "1.5.2 Creation of Test Cases"

то есть тот же самый "фундаментальный процесс" и в продвинутых сертификатах

 

 

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

тут даже не про уровень формальности. Для примера: в эджайле можно и нужно начинать тестирование как можно раньше, чтобы дать фидбэк, а по "фундаментальному процессу" надо сначала писать тест-кейсы и только потом начинать тестирование

В реальной работе тестировщика, а особенно в современном эджайле, тест-планы и тест-кейсы не требуются наверное в 95% случаев

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

Может, пора уже принять современные реалии?

 

Я с  ISTQB незнаком, поэтому уточняющий вопрос - а он учить, что надо начинать с ТК или учит как их составлять?

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

http://istqbfoundati...process-k1.html

вот это основа основ ISTQB: "Фундаментальный процесс тестирования", и там в третьем пункте про создание и выполнение тест-кейсов и тест-сьютов

не то чтобы "начинать с тест-кейсов", а просто "вот именно тест-кейсы надо делать, так как это часть фундаментального процесса тестирования"

ну 150 платится ведь даже с дохода 0

а вообще не количество найденных багов решает, а качество тестирования

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

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

 

 

Ну так опыт асессора-тестировщика и не должен помогать настраивать плагины в мавене, на мой взгляд) Это же совсем разные вещи, разве нет?

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

всё должно запускаться без проблем

так может надо было "протестировать аппликацию" а не "найти максимальное количество багов"?

может и взяли того человека, кто именно "протестировал"?

 

 

На вашем проекте вас никто учить не будет, не будет никакой "помощи старшего"

помощь старшего можно получить, просто надо знать "как"

сравните:

тестер Иван: уважаемый дев, у меня нет базовых и вообще никаких знаний разработки, научите меня пожалуйста программировать и покажите как тут что, конечно в рабочее время

тестеровщица Маша: я тут прочитала книгу по программированию, уже посмотрела авто-тесты на проекте, я могу помочь с их написанием и поддержкой. И вот еще просмотрела Ваш пулл-реквест, объясните пожалуйста вот этот именно момент в этом изменении

 

Спасибо! 

Тогда вопрос из вашей практики: как относятся к тому, что ты обучаешься программированию в рабочее время? 

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

 

 

Ответ "спроси свою команду, вы же за все отвечаете"

правильный эджайльный ответ

хороший тестировщик должен уметь сам себе находить себе работу, так как он лучше всех остальных знает что надо делать

 

 

Многие люди считают, что вообще все эти инструменты не нужны и лучше таблиц пока ничего не придумали. 

да, видимо все эти инструменты устарели с появлением скрама и развитием автоматизации тестирования. Ну может и кое-кому они действительно нужны, но это только 1% от всех

 

Похоже на то :(

Какие ещё варианты решения тут могут быть? 

наверное очевидно что не надо изобретать велосипед?

 

Вопрос не в том кто будет жать, а именно в возможности это сделать. 

Как я понимаю мы говорим немного о разных вещах. 

И интересно, вы на каждый мердж гоняете все тесты? Включая ui (мобилки, сайты, пофиг что), долгие интеграционные?

 

Также хочу оговориться что все очень сильно зависит от проекта.

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

 

 

И интересно, вы на каждый мердж гоняете все тесты? Включая ui (мобилки, сайты, пофиг что), долгие интеграционные?

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

 

Скрам.. такое себе...

Но я считаю что с развитием автоматизации тулы по типу TMS стали ещё актуальнее...
Ведь это реально удобно завести в таком туле описание ТК, собрать все ТК в тест ран и нажать кнопку на прогон. Потом тул по апи дает команду в CI/CD на запуск определенного пула тестов. При прогоне тесты автоматически, по апи, шлют свой статус в этот тул, где проставляется Passed/Failed and etc

 

Получается код отдельно, доки отдельно, тест резалты отдельно и все рады)  

тут непонятно зачем что-то собирать руками и нажимать на кнопку запуска

если у Вас будет несколько десятков разработчиков - кто будет эту кнопку постоянно жать?

 

 

Смелое утверждение. Даже мой опрос на хабре показывает, что примерно только 1/5 не использует специализированные инструменты. У вас, наверное, есть более широкие статистические данные. Поэтому, возможно, вы тоже правы  

а можно ссылку на опрос? ну я действительно не видел чтобы в 4х из 5ти компаний были бы установлены и активно использовались тулы типа тестрейла (ну или 4 из 5ти тестировщиков, зависит как считали. Но тоже не видел такой массовости)

 

 

а в чём именно изобретение велосипеда? 

а что Вы хотите сделать, если честно?