О, ребят, вспомнил тут. Кто был в этом году на qaconf - видюшки с конференции доступны где-нибудь? Просто вроде обещались расшарить, а прошло несколько месяцев уже, но что-то нигде и ничего...

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

По-моему стандарт тут нипричем. Все= что тестирование само по себе автоматизировать.. ах черт же, istqb

О, ребят, вспомнил тут. Кто был в этом году на qaconf - видюшки с конференции доступны где-нибудь? Просто вроде обещались расшарить, а прошло несколько месяцев уже, но что-то нигде и ничего...

+1

Похвастаюсь. Епам вот взял и написал. Пользуйтесь на здоровье. https://marketplace.atlassian.com/plugins/com.epam.jira.tm.test_management/server/overview

Это ваше?

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

я согласен с Вами. Прото хотел поинтересоваться у людей:)

Мне как-то пришлось писать мигратор с YouTrack на Redmine, Карл

Зажали бюджет на ютрек

Это ваше?

Да, разработка Эпама

#whois разніе вебпроекті мануал тестинг, autmation jun чем могу коллеги жи Харьков кто-то добавил, а кто?

привет)

#whois разніе вебпроекті мануал тестинг, autmation jun чем могу коллеги жи Харьков кто-то добавил, а кто?

Написано, что сами вошли )

#whois всем привет. Меня зовут Зиля. Уфа. Функциональный тестировщик в Bell Integrator.

#whois всем привет. Меня зовут Зиля. Уфа. Функциональный тестировщик в Bell Integrator.

Увидел в фб у Насти)) пока не знаю чем могу быть полезна. Проект частично можно отнести к банковским системам

Нас 270!)

Ура!)

Растём) Коллеги, доброго дня. Вопрос на засыпку. Кто на самом деле у себя в командах применяет техники тест-дизайна? И как считаете тестовое покрытие?

У кого какие подходы?

Растём) Коллеги, доброго дня. Вопрос на засыпку. Кто на самом деле у себя в командах применяет техники тест-дизайна? И как считаете тестовое покрытие?

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

Почему?

потому что agile ))))

Растём) Коллеги, доброго дня. Вопрос на засыпку. Кто на самом деле у себя в командах применяет техники тест-дизайна? И как считаете тестовое покрытие?

матрица покрытия + наличие критичных багов

Растём) Коллеги, доброго дня. Вопрос на засыпку. Кто на самом деле у себя в командах применяет техники тест-дизайна? И как считаете тестовое покрытие?

считаем так: 1. есть функциональный блок(основной) 2. у этого блока есть подфункциональный блок и т.д. 3. определяем как и что должно быть покрыто для каждого множества и подмножества и сколько для этого всего багов

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

если таковые есть, решаем релизиться

Почему?

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

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

+

Растём) Коллеги, доброго дня. Вопрос на засыпку. Кто на самом деле у себя в командах применяет техники тест-дизайна? И как считаете тестовое покрытие?

покрытие - через привязку к реквайрментам в СилкЦентрал, а также к Quality Goals, но работает это пока не так как нужно ибо переход в СЦ состоялся только 2 года назад, до этого творился ад в эксельках с макросами на наличие багов (даже критичных) в оценке покрытия, предпочитаю забивать, то есть большинство реально критичных багов являются блокирующими для функционала или даже продукта и они покрываются априори почти без исключений, как раз не критичные для работы, но репортнутые с филда - вот те анализируем и уточняем реквайрменты

Растём) Коллеги, доброго дня. Вопрос на засыпку. Кто на самом деле у себя в командах применяет техники тест-дизайна? И как считаете тестовое покрытие?

Это вот "на самом деле" как бы выдаёт, что Вы знаете как должно быть на самом деле =) Может разовьёте мысль? Что Вы понимаете под тест дизайном? Техниками тест-дизайна? Подсчетом тестового покрытия?

#whois привет, меня зовут Алексей! Работаю в КРОК. Функционально-мануальный тестировщик с восходящим навыком автотестов. Хочу держать руку на пульсе QA, интересно узнавать об опыте знатных и знающих специалистов. Узнал о чате от Radio QA.

тестдизайн - если взять по практике - то ваще всё, что описано тут https://www.amazon.com/Practitioners-Guide-Software-Test-Design/dp/158053791X, если брать по факту - ад и содом, то есть оптимальные варианты выбираются рандомом и реальная комбинаторика не используется. причина - недостаточные теоретические скиллы, в основном голая практика по наитию, но так как практического опыта очень дофига и много кросс-контроля, то все научились на своих и чужих ошибках. но в целом "на самом деле" - ниочинь

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

#whois привет, меня зовут Алексей! Работаю в КРОК. Функционально-мануальный тестировщик с восходящим навыком автотестов. Хочу держать руку на пульсе QA, интересно узнавать об опыте знатных и знающих специалистов. Узнал о чате от Radio QA.

@RichardGears , вот, а ты говорил что radioqa никто не слушает

Radio QA большие молодцы)

Да балаболки они.

Ничего путного или толкового. Одна польза - вон, человек пришел.

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

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

#whois привет, меня зовут Алексей! Работаю в КРОК. Функционально-мануальный тестировщик с восходящим навыком автотестов. Хочу держать руку на пульсе QA, интересно узнавать об опыте знатных и знающих специалистов. Узнал о чате от Radio QA.

В Москве?

В Самаре

Ах, прекрасный город.

Как там, Дно ещё не развалилсь? Скучаю по Ссмарскому жигулёвскому (((

Дно процветает)

А правда что со временем автотесты заменят QA?

Нет)

Ясно.

А правда что со временем автотесты заменят QA?

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

А куда еще может развиваться qa?

Смотря куда развиваться

оригинально - заменить слова картиночками, кек

Ну в менеджмент

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

3 из 4 в будущем видят себя автоматизаторами через пару лет

Одними автотестами проект жив не будет. А как же юзабилити и вот это всё? Автотесты – это дополнительный оч важный инструмент, но не панацея от всех болячек.

по моему мнению это как-то странно, хайп в автотестировании какой-то)

Ну в менеджмент

Это немножко не пересекается с моим вопросом. Если все покрыто автотестами а все qa ушли в менеджеры => профессия qa умерла в данном случае.

ERROR: S client not available

Одними автотестами проект жив не будет. А как же юзабилити и вот это всё? Автотесты – это дополнительный оч важный инструмент, но не панацея от всех болячек.

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

Юзабилити - это уже как-то в сторону UX/UI-engineer

Автотесты сейчас как чудо-кнопка "Сделать красиво" у дизайнеров.

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

"Ну смотрели, чего нам кажется неудобным"

по моему мнению это как-то странно, хайп в автотестировании какой-то)

Ну, всё настроил и сидишь, кнопочки жмёшь. )

"Ну смотрели, чего нам кажется неудобным"

топ-1 ответов

А за юзабилити отвечают a/b тесты уже :)

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

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

ну и иногда лимиты по тестированию железа

Либо вглубь, либо вширь - либо автотесты, либо тест-менеджмент/какая-нибудь роль, где меньше нагружают манкитестами регрессов.

3 из 4 в будущем видят себя автоматизаторами через пару лет

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

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

теперь так не говорят, потому что на работу таких брать не хотят

хотя и сейчас такое встречается, но гораздо реже.

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

Кто-то переходит.

Но обычно из области в оласть отпускают очень нехотя.

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

Компания закрывает позицию QA. Ей нужен QA. Зачем ей человек, который прямым текстом говорит, что долго на этой позиции не будет работать?

вряд ли он так сразу скажетс

Скажет.

по факту 95% не выполняют этого перехода

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

поэтому можно не переживать

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

лол ну тогда будет ошибкой его брать конечно

Да.

хмм как опрос добавить сюдысь

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