Организация приемочного тестирования силами матерых тестировщиков
•Download as PPTX, PDF•
0 likes•311 views
Тестировщик и его взгляд на бизнес тестирование. Как охватить необъятное или совместить своё желание всё проверить как в обычном функциональном тестировании и проверку с точки зрения бизнеса. Организация такого тестирования, взаимодействие с командой разработки и тестирования. Какие плюсы и минусы от того, что в UAT тестировании участвуют матерые тестировщики, а не люди, которые эксплуатируют систему.
Recommended
More Related Content
What's hot
What's hot (19)
Similar to Организация приемочного тестирования силами матерых тестировщиков
Similar to Организация приемочного тестирования силами матерых тестировщиков (20)
More from COMAQA.BY
More from COMAQA.BY (20)
Организация приемочного тестирования силами матерых тестировщиков
- 1. Организация приемочного тестирования силами матерых тестировщиков Минчева Надежда
- 2. Acceptance testing *User acceptance testing (есть определенные конкретные конечные пользователи, для которых собсвенно и разрабатывается программное обеспечение)
- 3. Пользовательское тестирование Знание функционала Реальные данные Бизнес сценарии
- 4. Недостатки пользовательскго тестирования Не тестировщики Нет тест кейсов Не понимают, что от них хотят Безобразные протоколы *В худшем случае систему один раз хотя бы запустят и то не факт
- 5. Сопровождение приемочного тестирования Планирование Документация Обмен знаниями
- 6. Недостатки сопровождения приемочного тестирования Тест кейсы не бинеса Затраченное время Не проверяются хитрые сценарии Не проверяются интеграционные сценарии
- 7. Отдел приемочного тестирования Тестировщики Документация Проверяются хитрые сценарии Проверяются интеграционные сценарии Production данные
- 8. Все виды тестов при приёмке Функциональное Регрессионное Бизнес тестирование Проверка инеграции Проверка быстродействия
- 9. Недостатки отдела приемочного тестирования Время Хорошая документация Организационные проблемы Очень затратно
- 10. Недостатки На все проверки 1 спринт Дожен быть опытный тестировщик Распараллеливание разных видов тестов
- 11. И еще недостатки Не всегда знаем, что нужно пользователям Пользователи не знают о доработках Дефекты отклоняются и потом находятся на Production
- 12. Итог Последний вариант очень затратный, но самый эффективный Допустим только для долгоиграющих проектов Для остальных проектов лучше проводить приемочное тестирование силами пользователей, учитывая их особенности
Editor's Notes
- Всем доброго вечера. Я Минвева Надя, много лет занимаюсь тестирование ПО.
- Я хочу поговорить с вами о аксептенс тестировании. До матерых тестировщиков дойдем еще. Но пока что, что под этим понимает. На самом деле работу обчного тесровщика можно назвать приемочной проверкой после разработки. Так что все тестировщика априори делают приемочное тестирование. Ну конечно же не об этом будем сегодня говорить. А о приемочном тестировании бизнесом. Приемочном тестировании реальными пользователями. Но если разбираться в этом вопрососе, то грань между реальными пользователями и тестировщиками не такая уж и четкая. Перед тем, как рассматривать варианты аксептенс тестирования, если честно интересно, кто вообще участвоавал, сопровождал приемочное тестирование из зала. Мои герои, пожнимите ручки. Спасибо, почти все.
- Первый вид - это когда пользователи, непосредственно те, кто будет использовать систему делают приемочное тестирование. - они знают функционал - они знают зачем этот функционал, иногда лучше вас - знают варианты вводимых.обрабатываемых данных, которые используются в системе - могут рассмотреть такие бизнес сценарии, про которые вы бы никогда не догадались, а они это делают каждый день
- Минусы - пользователи должны быть мотивированы, иначе приемочное тестирование сведеться к формальному запуску и закрытию системы без проверок - пользователи - не тестировщики, как правило, они даже не понимают, что от низ требуется - на протоколы по примочному тестивроанию с недочетами и дефектами хочется смотреть закрыв глаза, потому что в них как правило либо ничего не понятно, либо требует все равно комментариевВ итоге: - в лучшем случае будет проведено приемочное тестирование, но в обычном варианте, это будет за день до отправки налоговой отчетности в ЦБ на продакшене, когда пользователи со слезами на глазах и криками прибегут к вашей поддержке и стуча ножкой будут требовать починить им систему. А ошибка всего лишь кроется в одном маленьком жалком амперсанте, который используется во французских фамилиях. - от вас потребуется время, чтобы разобрать протокол, уточнит нехватающую информацию, воспроизвести те, случаи, которые описаны и сверить с требованиями. Как правило на это уходит не один день. При том не только тестировщика, но и аналитика, который уточняет те моменты, которые не были прописаны в требованиях. В итоге: - в лучшем случае будет проведено приемочное тестирование, но в обычном варианте, это будет за день до отправки налоговой отчетности в ЦБ на продакшене, когда пользователи со слезами на глазах и криками прибегут к вашей поддержке и стуча ножкой будут требовать починить им систему.
- Второй случай: когда приемочное тестирование сопровождается командой разработки. Тест кейсы даем, проводим демонстрации, собираемся разобрать случаи из протокола. - приемочное тестирование проводится - тестироващики и пользователи больше узнают о системе
- Минусы: - Время на подготовку, проведение и обработку результатов и для тестировщиков и для пользователей - пользователи не тестировщики - нужна помощь в разделении проблем с системой с проблемами ее настроек и окружением - не успевают проверить сложные замысловатые сценарии, в которых участвуют другие системы - на продакшене вылезают либо хитрые кейсы, либо интеграционные, либо перформанс
- Третий вариант: Приемочное тестирование осуществляют профессиональные тестировщики. - знают что тестировать и как - меньше времени на проверку обычных сценариев, чем у обычных пользователей - нормальная документация (тест кейсы, баг репорты, предложения по улучшению) - проверка интеграционных вещей - тестируют на данных близких к реальными
- Если организовывать целый отдел приемочного тестирования, то можно сдлеать все виды тестов: - функциональное, где проверяем простые сценарии, чтобы убедиться, что хоть что-то работает - регрессионное, на окружении заказчика - бизнесс тестирование - это как раз с хитрыми сложными сценариями, на которые у команды разработчиков скорее всего не было либо времени, либо знаний, либо данных. - проверка интеграционных сценариев с другими системами - организация перформанс тестов
- Минусы - время затраченное на обучение тестировщиков системе - время по выявлению Usage сценариев - должна быть хорошая документация - организацонные проблемы - затратно
- Но как видите - это очень много. А если жить по скраму, то это все нужно сделать за один спринт. Без автотестов тоже как-то тяжело жить, хотя бы енвайромент чек и смоки. Еще один минус то, что тестировщик должен быть не начинающий, т.е. иметь хорошую экспертизу в тестировании похожих продуктов. И прекрасно знать тест дизайн. Для того чтобы можно было его сразу кинуть на функциональное тестирование. Еще один минус, что функциональное и последующий за ним регресс делаются в параллели с бизнес тестом. Иначе не успеть.
- И если не рассматривать сферического коня в вакууме, то часто возникают следующие ситуации: - команда аксептенс тестировщиков не знает, что хотел ПО - дефекты, открытые на стадии приемки, реджектиться, а потом вылезают в продакшене - необходимо общение с реальными пользователями ина это нужно выделять время и ресурсы
- Крнечно последний вариант очень затратный, но самый эфективный из всех, если опираться на одну из многих метрик по качеству программного обеспечения. Ту, по которой отслеживается количество и критичность найденных дефектов на продакшене. По последнему варианту таких дефектов будет меньшле. Но и затрат на организацию, очень много. И допустимо только для долгоинрающих проектов, планы по развитию которых есть на несколько пятилеток вперед.
- Это не парадигма. Такое разделение использовала только, потому что мне так проще было представить тот материал, который я хотела до вас донести. Ничего координально нового не было сказано, просто рассказала про свой опыт организации приемочного тестирования.
- Это не парадигма. Такое разделение использовала только, потому что мне так проще было представить тот материал, который я хотела до вас донести. Ничего координально нового не было сказано, просто рассказала про свой опыт организации приемочного тестирования.