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

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

 

 

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

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

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

 

 

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

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

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

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

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

может это?

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

 

 

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

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

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

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

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

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

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

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

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

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

 

 

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

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

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

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

 

 

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

 

 

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

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

 

 

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

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

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

 

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

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

да, так и есть

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

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

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

 

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

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

 

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

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

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

 

 

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

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

 

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

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

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

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

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

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

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

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

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

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

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

 

 

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

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

 

 

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

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

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

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

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

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

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

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

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

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

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

 

Как говорил величайший менеджер двадцатого столетия: «Меняться совершенно не обязательно. Выживание - дело добровольное.»

Если вам платыт за растрату денег фирмы, я ничего не могу с этим сделать.

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

так ведь может эти две трассировки и есть та самая "растрата денег фирмы"?

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

 

 

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

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