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

Тестирование без требований
онлайн, начало 25 января
Тестирование безопасности
онлайн, начало 27 января
Школа Тест-Аналитика
онлайн, начало 27 января
Тестирование мобильных приложений
онлайн, начало 27 января

Публикации Spock

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



#173497 характеристики ноута для работы

Отправлено автор: Spock 28 августа 2019 - 08:46 в Про тестирование обо всём подряд

последний МакбукПРО с максимальными параметрами отличный выбор для тестировщика

 

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




#173512 характеристики ноута для работы

Отправлено автор: Spock 29 августа 2019 - 08:34 в Про тестирование обо всём подряд

 

 

где-то от 3гб ОЗУ

даже 16Гб это сейчас мало для тестирования, ну или "необходимый минимум", лучше 32Гб

 

например 8Гб это на домашнем компьютере можно иметь который только для "побраузить интернет"




#175306 Яндекс из ассесоров-тестировщиков в тестировщики

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

 

 

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

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

 

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




#174252 Что такое Сходящиеся тесты?

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

https://whatis.techt...bug-convergence

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

 

может это?




#174245 Что такое Сходящиеся тесты?

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

это наверное Вы читали статью про математику, и тесты/проверки были на схождение




#174563 Что нужно, чтобы устроиться на первую работу тестировщиком

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

 

 

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

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

 

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

а другой может и побольше знает но уже не то (например Федя, напарник Шурика)




#175286 Что мы узнали из 3000 багов

Отправлено автор: Spock 22 января 2020 - 08:44 в Управление тестированием

мне например интересно как получается что половину тикетов регистрируют в нерабочее время

 

чем тогда тестировщики занимаются в рабочее время?

 

допустим тестер отработал 8 часов в рабочее время, завёл 5 багов, это 0.625 багов за час. Потом отработал 2 часа в нерабочее время и завёл 5 багов, это 2.5 бага в час.

 

продуктивность в нерабочее время больше продуктивности в рабочее время в 2.5 / 0.625 = 4 раза! в 4 раза, Карл!

 

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

 

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




#175290 Что мы узнали из 3000 багов

Отправлено автор: Spock 22 января 2020 - 09:05 в Управление тестированием

 

 

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

таких багов мало, они на статистику не повлияют




#175739 Что именно означает "запушить" "закомитить" "смерж

Отправлено автор: Spock 02 марта 2020 - 12:09 в Начинающему тестировщику

 

 

И потеряете хорошего начинающего кандидата только из-за того, что он не знает терминов?)

это просто для оценки кандидата, чтобы определить "начинающий" он или "продолжающий"

 

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

 

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




#175724 Что именно означает "запушить" "закомитить" "смерж

Отправлено автор: Spock 01 марта 2020 - 11:37 в Начинающему тестировщику

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




#175734 Что именно означает "запушить" "закомитить" "смерж

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

а вообще это хорошая идея кандидатов отсеивать

 

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

 

и тут типа вопрос кандидату: "вот у нас тут билд зафейлился, а мы резилить хотим, что делать? черри-пикать коммиты? ревертить чейнджи? накатывать фиксы?"

и смотришь как тот выкрутится :)




#173960 Четыре причины для тестирования валидации ввода (хоть это и скучно)

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

прихожу почитать Кристин когда хочется треша, не разочарован и в этот раз

 

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

 

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

 

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

 

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




#177120 Чек-лист или Тест-Кейс?

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

 

 

была задача написать чек-лист

 

 

сделала чек-лист (как я понимаю) ... очень подробно

 

 

у меня предоставление - чек-лист кратко

тут несогласованность есть, а не у фирмы

 

 

 

Нажать кнопку такую итд

это тоже признак чего-то сложного, типа тест-кейсов

 

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




#175331 Хороший Gherkin как путь к хорошей автоматизации

Отправлено автор: Spock 27 января 2020 - 08:42 в Автоматизированное тестирование

 

Пока еще ни разу не видел эффективно работающий BDD.

Коллеги, если вдруг кто-то смог у себя внедрить и это прям действительно помогло - поделитесь опытом.

да, так и есть

 

единственно возможный БДД это когда БДД используется прямо в коде, типа "create.client.with.name("Вася")"

 

остальное типа "Создать клиента с именем Вася" это полностью нерабочий вариант

 

а внедрить многие "смогли" и это будто им "помогло". Но если посчитать вкачанные ресурсы то это окажется полным провалом




#175371 Хороший Gherkin как путь к хорошей автоматизации

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

 

А вот для автоматизации тестирования в BDD есть язык gherkin.

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

 

То есть, вы предлагаете сделать описание поведения системы, а потом им не пользоваться?
Как говорят наши вежливые заокеанские коллеги "интересная идея"

Геркин не обязателен для БДД, ведь Геркин это только один из возможных языков

 

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

 

 

 

BDD - это Методология Разработки Через Описание Поведения Системы. В которой зафиксированное описание служит и постановкой задачи на разработку и тестовыми сценариями.

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

 

TDD делает не это.

сделал тест, и только потом написал программу - вот это ТДД

сделал тест который написан понятным языком и нацелен на юзера - вот это БДД




#175367 Хороший Gherkin как путь к хорошей автоматизации

Отправлено автор: Spock 29 января 2020 - 11:24 в Автоматизированное тестирование

вообще БДД и Геркин это разные вещи

 

БДД это может быть и "create.client.with.name("Вася")" и "Создать клиента с именем Вася"

а Геркин это только "Создать клиента с именем Вася"

 

большие проекты на БДД возможны и хороши, если используется нормальный Язык Программирования, чтобы строки выглядели типа "create.client.with.name("Вася")". Всё будет реально понятно даже ручным тестировщикам

 

но большие проекты на Геркине не рекомендуются даже создателями Кукумбера в их книге. Создатели рекомендуют использовать Кукумбер на Геркине ТОЛЬКО для приёмочного тестирования, где небольшое количество достаточно простых тестов

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

 

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

 

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




#175369 Хороший Gherkin как путь к хорошей автоматизации

Отправлено автор: Spock 29 января 2020 - 12:54 в Автоматизированное тестирование

 

 

А вот для автоматизации тестирования в BDD есть язык gherkin.

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

 

 

 

BDD - это Методология Разработки Через Описание Поведения Системы. В которой зафиксированное описание служит и постановкой задачи на разработку и тестовыми сценариями.

это ещё TDD делал, где есть тесты с заранее описанным поведением системы

 

а вот в BDD тесты уже пишутся намного более понятным языком, тесты более нацелены на юзера




#173571 Формат и размер загружаемых файлов

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

 

 

Спасибо, Кэп! 

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




#173568 Формат и размер загружаемых файлов

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

 

 

Тестировать сферическую форму в вакууме можно только сферическими тестами в вакууме, хотя, конечно, набор ошибок там может быть весьма стандартный :) 

ну так это и есть сферическая форма в вакууме, вопрос с собеседования




#173746 У нас проблема с автотестами? Что делать?

Отправлено автор: Spock 13 сентября 2019 - 18:26 в Автоматизированное тестирование

 

 

Неплохо. К сожалению доказать руководству и разработчикам, почему не надо начинать с регресса автоматизацию, особенно когда прописано в kpi, практически невозможно(.

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




#173733 У нас проблема с автотестами? Что делать?

Отправлено автор: Spock 13 сентября 2019 - 16:07 в Автоматизированное тестирование

 

 

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

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

 

можно ли сказать что вторая система однозначно лучше? вроде все лучше видно, значит лучше?

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

 

а в первой системе используя "blame" можно трассировать до тикета и затем до эпика, и ресурсов на это уходит 0




#173735 У нас проблема с автотестами? Что делать?

Отправлено автор: Spock 13 сентября 2019 - 16:46 в Автоматизированное тестирование

 

 

Однозначно сказать нельзя, зависит от размера и критичности проекта. Если проект позволяет работать без требований - пожалуйста.
Но если у вас 2000 автотестов, которые требуют непрерывного внимания 5 инженеров только на поддержку и при этом никто не может точно сказать где и как тестируется фича Х. То вероятно кто-то был неправ.

ну вот у Гугла например - "аппликация" огромная, количество тестов просто несчетное. Но есть ли у них система управления требованиями, где все вот в тексте описано как где и что должно работать?

 

 

 

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

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

 

 

 

Но если у вас 2000 автотестов, которые требуют непрерывного внимания 5 инженеров только на поддержку и при этом никто не может точно сказать где и как тестируется фича Х. То вероятно кто-то был неправ.

на мастере все тесты должны быть зелеными, тогда и поддержки надо 0, и никакого "непрерывного внимания"




#173731 У нас проблема с автотестами? Что делать?

Отправлено автор: Spock 13 сентября 2019 - 12:05 в Автоматизированное тестирование

 

 

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

прям загадками говорите, ну точнее труизмами

 

вообще на любой вопрос можно ответить труизмом




#173723 У нас проблема с автотестами? Что делать?

Отправлено автор: Spock 13 сентября 2019 - 08:25 в Автоматизированное тестирование

 

 

  • Существует трассируемость требований на тесты. Да, мы знаем что и как покрыли. 

  • Существует трассируемость тестов на задачи, да мы знаем что протестировано, где и как.

а вот это не оверкилл будет?

 

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




#173760 У нас проблема с автотестами? Что делать?

Отправлено автор: Spock 13 сентября 2019 - 19:27 в Автоматизированное тестирование

 

 

Нет ничего нормального)

если у кого нет ничего нормального - надо начинать с юнит-тестов тогда :)





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