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

Публикации Spock

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



#173701 "Сложности" терминологии

Отправлено автор: Spock 11 сентября 2019 - 08:11 в Свободное общение

 

 

На собеседовании выглядит никак. Лучше правду говорите.

там наверное главное не потеряться если вдруг спросят о чем-нибудь типа "дымового тестирования" ;)




#173651 "Сложности" терминологии

Отправлено автор: Spock 06 сентября 2019 - 10:07 в Свободное общение

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




#173653 "Сложности" терминологии

Отправлено автор: Spock 06 сентября 2019 - 11:14 в Свободное общение

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

 

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

 

Right-click on the scroll bar to activate the quick navigation menu.
При щелчке правой кнопкой мыши на полосе прокрутки появляется меню быстрых перемещений.



#173364 25 лет преподавания

Отправлено автор: Spock 19 августа 2019 - 21:37 в Свободное общение

поздравляю с юбилеем!




#176720 API Autotests: Сгенерированный клиент или вручную созданные модели?

Отправлено автор: Spock 26 мая 2020 - 14:57 в Автоматизированное тестирование

ну Вы наверное и тесты еще писали не в коде проекта? и код ревью не проходили поэтому?




#176247 Cookie должны быть обязательно?

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

- ―Ты что, с ума сошел? Дорогой друг прилетает издалека, на минуточку. А у вас нет торта.
- ―Но ведь мы же не знали!
―--А что вы вообще знали? Вы должны были надеяться. Изо всех сил.




#174197 Help - Pair wise test

Отправлено автор: Spock 26 октября 2019 - 10:17 в Про тестирование обо всём подряд

 

 

Составить входные данные для проверки формы методом попарного тестирования и с помощью граничных значений.

только мне кажется что попарное тестирование тут неприменимо?

 

что тут просто следует протестировать каждое поле в отдельности?




#174192 Help - Pair wise test

Отправлено автор: Spock 25 октября 2019 - 21:08 в Про тестирование обо всём подряд

 

 

2. Вы забыли граничные значения внутри интервала;

ну это наверное спорный вопрос, вне и на границе должно хватить




#174529 help! вопрос по Chrome DevTools

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

 

 

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

вот как они влияют:

 

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

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




#174430 help! вопрос по Chrome DevTools

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

возьмите например Android Studio или какой-нибудь эмулятор Андроида, создайте профиль нужного девайса с нужной версией операционки

 

и откройте там Хром




#174433 help! вопрос по Chrome DevTools

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

 

 

Почему бесполезной? На что по вашему она влияет?

гляньте сами на скриншот, там же видно

 

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




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

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

 

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

 

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

 

Неправда.

 

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

 

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

 

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

 

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

 

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




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

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

 

 

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

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

 

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

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




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

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

 

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

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

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

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

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

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

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

 

 

 

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

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

 

 

 

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

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

 

 

 

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

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

 

 

 

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

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

 

 

 

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

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

 

 

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

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




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

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

 

 

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

 

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

 

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

 

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

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




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

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

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

 

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

 

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




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

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

 

 

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

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

 

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




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

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

 

 

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

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

 

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

 

 

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

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

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

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

 

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

 

 

 

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

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




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

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

 

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

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

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

 

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

 

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




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

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

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

 

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

 

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

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

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

 

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

 

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

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

 

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

 

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

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




#173479 Jira+Bitrix24 синхронизация

Отправлено автор: Spock 27 августа 2019 - 08:43 в Управление тестированием

 

 

Она не работает так надо (да, я знаю, что из коробки вообще мало что работает (:  )

ну а как можем помочь если мы знаем только что "ну вот не работает"?

 

что там именно не работает?




#173453 Jira+Bitrix24 синхронизация

Отправлено автор: Spock 26 августа 2019 - 12:40 в Управление тестированием

ну а в чём проблема?

 

поставили задачу, делайте?

 

https://www.bitrix24...grations24.jira




#174581 Jmeter отправляет меньше запросов чем должен по настройкам Thread grou

Отправлено автор: Spock 24 ноября 2019 - 12:45 в Начинающему тестировщику

отлаживайте скрипт

 

не надо сразу слать тысячи запросов и потом ломать голову "куда делись они"

 

шлите 100 запросов и смотрите как они работают, всё ли в порядке

потом шлите тысячу, потом две и так далее

 

а ответы сервера кстати можете смотреть прямо на сервере