Как есть?

Просто по итогу лид берет задачи на нем весящие раскидывает на тестеров, на них весит 20+ тасков, а на лиде 10

Тестеры загребаются, лид курит

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

Коротко у нас: 1. Задачи распределяются на тестировщиков для инвестигейта 2. Тестировщики ознакамливаются с бизнес-требованиями или спецификацией. Уточняют вопросы у ПМ или овнера 3. Определяют естимейты на создание сценариев/Их выполнение/Автоматизацию 4. Обговаривают их с Тимлидом и правят при необходимости 5. Профит

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

Ага

Знач он странный

НО! бывает что только определенный тестер может протестить определенную вещь

Не давать тестеру 20 задач и когда тестер открывает jira и не знать за что браться

неприятный бас-фактор, но бывает

Ну, для этого есть приоритеты

если кто-то не согласен с ними, он может обратится к тим-лиду

А брать по-важности. Просто желательно предупредить. Что одному тебе это тестить займет - столько-то.

https://pp.vk.me/c637322/v637322299/28b9c/IbeAPszFGJc.jpg

На этом твои волнения окончены, спрос с тимлида

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

все

Да тут дело не в том, что задания дают не по специфике. Задание как раз дают по специфике только заданий куча и приоритет не спасает у трех стоит Highlest, у четырех high, и еще куча medium

Вот по этому я и написал. Может у кого-то, что-то по другому)))

Ну так и тестишь)

да нет, у всех приоритетность

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

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

профит

задачи распределяют между куа и вперед)

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

а за этим должен следить тимлид/ПМ/скрам-мастер

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

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

Он даже не может сказать слова, что не успел

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

По логике, qc должен проходить по готовым кейсам, а qa это не только тестирование и багрепорт "это не работает", но и исследование, в каком месте ошибка, в запросе или еще где. Или исследование, как пользователь смог сделать то, что вроде бы невозможно, в таком духе

интересно. у нас разделение на тестировщиков и тест-аналитиков.

и оно скорее формально.

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

вообще тема хорошая, который раз заходит в чат.

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

воистину

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

думаю, есть какие-то основные, базовые вещи. а всё остальное - в зависимости от проектной роли)

так вот я - кто? :)

по этому описанию

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

Человек, девушка. Звать Ольга.

щас бы Дашу запостить...

окааай, на самом деле я котик конечно. Но в интернете никто не знает!

Тут все котики

не правда, я сова

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

Qa знает и делает больше, чем qc, но это не значит, что перестает делать то, что делает qc

кто такой qc ?

Если есть qa и qc, значит должен быть и qb

лол

quality assurance

quality control

Quality control = testing engineer

а quality assurance?

Грубо - это process management, в узком понимании, так как кьюа занимается тем, чтобы сам процесс разработки был качественно построен и минимизировал появление ошибок разработки самой структурой процесса

Но это не совсем корректное определение

но qa обычно не лезут к девам

ой я куа

Но если чтото слышите об iso/cmmi и тд - это кьюа

Процесс настраивают девопсы

я лезу.............

К девам лезут все

ERROR: S client not available

я лезу.............

И ansible, docker, swarm, jenkins вот это вот все?

Процесс настраивают девопсы

о каких процессах речь

мне кажется мы о разных вещах говорим

Процесс настраивают девопсы

Шта? Девопс - это не позиция, а процесс и от утилит он не зависит

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

девопс, это не позиция а методология

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

так срачик о девопсах, у меня дежавю

Нет, принято только по глупости

исторически так сложилось

Так что факт

Но мы говорим в целом, а не о конкретном подходе

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

Девопс или херопс пофиг

о роман) собственно после вашего сообщения и стало интересно)

Если ты им говоришь как настраивать докеры и дженкинсы то это странно

вы когда ребятам гвоорите работать сами етстите или только говорите как тестить?

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

Если ты им говоришь как настраивать докеры и дженкинсы то это странно

причем тут дженкинсы и докеры

Тулзы к процессу отношения не имеют

Без тулзов процесс будет абстрактной медузой ниочем

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

Процесс - это и есть методология, имплементированная на практическом уровне

Из серии "наш план: давайте все делать быстро и хорошо"

Без тулзов процесс будет абстрактной медузой ниочем

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

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

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

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

нас**ть на докер, джиру, что угодно

процесс формулируется по входящим данным

нас**ать на процессы, методологии, что угодно

тулзы - это исходящие данные

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

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