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

Публикации Spock

331 публикаций создано Spock (учитываются публикации только с 29 марта 2023)



#174642 ISTQB учит плохому?

Отправлено автор: Spock 27 ноября 2019 - 16:30 в Тест-дизайн и ручное тестирование

 

 

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

 

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

 

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

 

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

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




#174614 ISTQB учит плохому?

Отправлено автор: Spock 26 ноября 2019 - 14:31 в Тест-дизайн и ручное тестирование

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

 

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

 

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

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

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

 

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

 

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

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

 

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

 

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

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




#174661 ISTQB учит плохому?

Отправлено автор: Spock 29 ноября 2019 - 11:12 в Тест-дизайн и ручное тестирование

 

 

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

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




#174676 ISTQB учит плохому?

Отправлено автор: Spock 29 ноября 2019 - 15:23 в Тест-дизайн и ручное тестирование

 

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

 

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

 

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

 

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

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

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

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

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

 

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

 

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

 

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

 

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

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

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

 

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

 

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




#174728 ISTQB учит плохому?

Отправлено автор: Spock 02 декабря 2019 - 13:10 в Тест-дизайн и ручное тестирование

 

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

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

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

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

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

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

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

 

 

 

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

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

 

 

 

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

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

 

 

 

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

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

 

 

 

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

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

 

 

 

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

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

 

 

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

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




#174724 ISTQB учит плохому?

Отправлено автор: Spock 02 декабря 2019 - 09:15 в Тест-дизайн и ручное тестирование

 

 

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

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

 

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

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




#174610 ISTQB учит плохому?

Отправлено автор: Spock 26 ноября 2019 - 13:44 в Тест-дизайн и ручное тестирование

 

 

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

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

 

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

 

 

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

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

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

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

 

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

 

 

 

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

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




#174671 ISTQB учит плохому?

Отправлено автор: Spock 29 ноября 2019 - 13:52 в Тест-дизайн и ручное тестирование

 

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

 

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

 

Неправда.

 

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

 

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

 

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

 

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

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

 

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

 

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




#174607 ISTQB учит плохому?

Отправлено автор: Spock 26 ноября 2019 - 12:45 в Тест-дизайн и ручное тестирование

 

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

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

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

 

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

 

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




#174276 Как подготовить тестовые данные для автотестов?

Отправлено автор: Spock 30 октября 2019 - 18:51 в Управление тестированием

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




#174312 Как подготовить тестовые данные для автотестов?

Отправлено автор: Spock 01 ноября 2019 - 14:54 в Управление тестированием

 

 

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

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

 

 

 

но громоздко получается

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




#174291 Как подготовить тестовые данные для автотестов?

Отправлено автор: Spock 31 октября 2019 - 20:33 в Управление тестированием

 

 

можно на этом моменте поподробнее?

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

 

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




#174782 Помощь с заданием

Отправлено автор: Spock 05 декабря 2019 - 08:46 в Начинающему тестировщику

 

 

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

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




#176695 Как получить опыт тестирования?

Отправлено автор: Spock 22 мая 2020 - 20:19 в Личный рост, карьера, развитие

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




#175505 Объем тестового задания при трудоустройстве

Отправлено автор: Spock 10 февраля 2020 - 09:36 в Круглый стол о работе в тестировании ПО

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

 

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

 

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




#175489 Объем тестового задания при трудоустройстве

Отправлено автор: Spock 08 февраля 2020 - 21:52 в Круглый стол о работе в тестировании ПО

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

 

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




#173469 Ошибка компиляции при запуске теста через Jenkins

Отправлено автор: Spock 26 августа 2019 - 19:45 в Автоматизированное тестирование

 

 

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

очень интересно, да

 

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




#173438 Ошибка компиляции при запуске теста через Jenkins

Отправлено автор: Spock 25 августа 2019 - 20:53 в Автоматизированное тестирование

велосипед как всегда "не едет"




#173467 Ошибка компиляции при запуске теста через Jenkins

Отправлено автор: Spock 26 августа 2019 - 18:44 в Автоматизированное тестирование

 

 

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

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




#173465 Ошибка компиляции при запуске теста через Jenkins

Отправлено автор: Spock 26 августа 2019 - 18:05 в Автоматизированное тестирование

 

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

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

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




#175204 Нужна помощь в составлении CV

Отправлено автор: Spock 17 января 2020 - 15:26 в Начинающему тестировщику

там еще фотку можно добавить




#175135 Нужна помощь в составлении CV

Отправлено автор: Spock 14 января 2020 - 14:26 в Начинающему тестировщику

да, просто пришел и тебя берут ))) Находишь любую компанию и говоришь "буду у вас работать", а они такие "Ок. Когда вас оформлять ?" ))

user12 да, это работает

 

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

 

тогда берут




#175119 Нужна помощь в составлении CV

Отправлено автор: Spock 13 января 2020 - 21:46 в Начинающему тестировщику

мне почему-то казалось что в Белоруссии на галеры вообще просто устроиться. Главное чтобы "глаза горели". Просто прийти и сказать что очень хочешь у них работать

 

"Desired position and salary" - и потом длинный список позиций

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




#175148 Нужна помощь в составлении CV

Отправлено автор: Spock 14 января 2020 - 19:07 в Начинающему тестировщику

 

Хм. Интересная неожиданность. А компании не обурели, что под каждую писать надо свое резюме?) Тем более, с таким уровнем фидбека

Но приму к сведению обязательно

не надо всё резюме "затачивать" - надо просто в резюме указать на какую именно оно позицию в компании

как тут например

https://europass.ced...urriculum-vitae

 

а вот действительно затачивать под компанию надо кавер леттер




#175164 Нужна помощь в составлении CV

Отправлено автор: Spock 15 января 2020 - 10:46 в Начинающему тестировщику

 

Career Starters, Students • IT, Internet, Multimedia • Art, Entertainment, Media • Human Resources Employment: project work, work placement, part time, full time

вот эта часть это вообще непонятный набор слов, убрать её всю

 

карир стартерс, кто они? Арт, энтертейнтмент, медия??? Хьюман ресорсес? Ворк плейсмент???

 

а ведь это самая первая и самая главная часть в резюме, большинство дальше и читать не будут