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

Публикации floyder

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


#118367 Взаимодействие отделов тестирования и разработки

Отправлено автор: floyder 31 мая 2013 - 07:29 в QA: обеспечение качества

А дефекты всё равно найти надо

В чем цель тестирования? Кто ваш заказчик? Кто конечный потребитель?

Люди могут быть отличные, процессы - не очень. И наоборот. Вас хотят мотивировать и тотально контролировать. Так не бывает. Программист > Тестировщик - извините, это вообще бомба.
Много копей было сломано в обсуждениях KPI тестировщиков. Однозначный вывод на сегодня - исчисляемых сбалансированных KPI для тестировщиков не существует. Можно считать метрики, опираться на них при принятии решений, но завязывать на них финансы - самоубийство.
Косвенным образом можно посчитать сроки-качество (сроки: отклонение от baseline, качество: число критичных/блокер багов после релиза).



#117662 Необходим совет

Отправлено автор: floyder 07 мая 2013 - 14:58 в Начинающему тестировщику

Даже если стоит "опыт от года", работодатель в большинстве случаев готов будет взять начинающего тестировщика. При условии, что зарплата будет соответствовать вашему уровню.
Пройдите хотя юы одно собеседование. Оно вам поведует больше, чем все наши советы на форуме.
Вот еще неплохая заметка про собеседование со стороны работодателя:
http://rinauzhevko.b.../2012/09/3.html



#116991 Организация процесса тестирования "с нуля"

Отправлено автор: floyder 11 апреля 2013 - 15:21 в Управление тестированием

Если у вас отсутствует документация на проект, добро пожаловать в scrum. Для начала советую определиться с целью тестирования. Если цель - сделать заказчика счаствливым, тогда читаем дальше.
1. Ежедневные митинги с обсуждением тасков - позволят структурировать информацию и выбрать приоритеты (кто-то должен писать или озвучивать юзер кейсы)
2. Планнинг покер и другие игрушки - позволяют обмениваться участникам горизонтальной информацией



#115856 Сервис/способ удобного ведения маленьких ежедневных отчетов

Отправлено автор: floyder 17 марта 2013 - 11:59 в Управление тестированием

Есть желание командой вести что-то типа скрам-стендапа, только письменного, где будут записываться некие мини-репорты о том, чего сегодня делал. Очевидное решение - гугльдоки, но хочется послушать опытных коллег, может быть, посоветуете что-нибудь более удобное. Для сервиса ограничение - простой, бесплатный, и очень желательно интегрированный с basecamp'ом - есть ли что-то такое?


Какую роль в процессе занимаете вы? Чего вы хотите от отчетов?



#109947 Динамичная разработка и тестирование

Отправлено автор: floyder 19 сентября 2012 - 10:21 в Управление тестированием

kitsune
Статистику поднять можно. Но к ней нужны конкретные пути решений. Допустим, мы узнали, что defect leakage слишком большой. Что с этим делать?



Мне помогает переключение на другое приложение, а потом снова возврат к нужному.

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

Багхантинг не лучшая практика и приводит к

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


а применение

А как насчет ввести "Весовой коэффициент" бага?

приводит к конфликтам, тк "Весовой коэффициент" - экспертная оценка и зависит от мнения конкретной личности.


Скажите, эти критичные баги на поверхности того функционала, который был протестирован тестером?
Или по каким-то причинам нет?
То есть, личный прокол некоего тестера или скорее недочет тестовой стратегии/манагера или кадровой политики в общем.

Случаются и те, и те случаи. Эффект замыливания довольно высок при такой частоте регрессионных тестов. И стоит смириться с тем, что человек не робот, и на 100% полноту прохождения сценариев гарантировать нельзя. Опять же эффект пестицида.

Можно ли как-то роботизировать данный процесс?



#109859 Динамичная разработка и тестирование

Отправлено автор: floyder 17 сентября 2012 - 18:20 в Управление тестированием

Добрый день, коллеги!
Многие из нас встречались с ситуациями, когда динаимично развивающийся продукт пересыщается функционалом. Он становится неподъемным, и вероятность найти критичную багу в рандомном месте стремится к 1.
Расскажите пожалуйста как вы справляетесь с такими проблемами.

Моя вводная:
Прикладное приложение. Число тестовых шагов перевалило за 15000. Выпуски версий каждые 2 недели. При этом изменение функционала каждую итерацию происходит на 1000-2000 пользовательских действий. Также за итерацию на тест передается от 6 до 15 сборок-кандидатов, которые необходимо подвергнуть общему тесту. Имеем команду из 4-х тестировщиков: 1 штатный и 3 аутсорсера-багхантера.
Случается, что каждую итерацию тестировщики пропускают 2-3 критичных бага. Причем некоторые лежат на поверхности настолько, что вызывают недоумение у других коллег.
Пробовали тестировать на основе рисков - нереально выделить приоритетные места. Специфика отрасли такова, что разные клиенты по-разному интерпретируют дефекты, и порой критичность совершенно безобидного (на первый взгляд) бага становится максимальной, так как этого затребовал влиятельный заказчик.
Пробовали автоматизацию тестирования. Каждый год у приложения меняется платформа, и составить адекватную базу автоматизации оказалось не выгодно и не удобно.

Подскажите, куда копать, чтобы снизить риски сбоев. Может есть управленческие хитрости или интересные инструменты, способные помочь в ситуации. Сами используем TFS + Visual Studio.
Спасибо за внимание!