Pull to refresh
11
0
Send message

Еще раз о невыносимой легкости тестирования

Reading time6 min
Views6.9K
Продолжаем разговор.

В своем недавнем посте я привел несколько примеров, как тестировщик порой сам может упустить дефект, который был у него практически в руках. По недомыслию, неопытности, наивности, от усталости, в спешке – неважно. Сам. Программист и общая культура разработки могут, конечно, помочь – мол, не баг это, но все же, в описанных случаях их роль вспомогательная.

mtikhon в своей статье «Легкий способ пройти тестирование» прекрасно дополнил тот список «внешними» проблемами, влияющими на результат тестирования. Внешними – в том смысле, что они зарождаются не в отделе тестирования, а в прочих подразделениях, а еще чаще – где-то на стыках подразделений, при взаимодействии отделов. (Я понимаю, что не всегда под тестирование формально выделен специальный отдел. Но это косметическая разница, сути не меняет: тут речь скорее о разделении ролей)
mtikhon’у слегка попеняли в комментариях, что список проблем изложен, а легкий способ их обойти – нет. Он, в свою очередь, уже справедливо отметил, что «способы как правило разнятся очень сильно». Вот на этой мысли я и хочу потоптаться чуть подробней.

Пожалуй, пойду прямо по тем же пунктам.
Читать дальше →
Total votes 4: ↑3 and ↓1+2
Comments0

Легкий способ провалить тестирование

Reading time3 min
Views17K
Иногда тестирование не приносит нужного результата. То есть работа кипит, фичи проверяются, баги чинятся, даже какая-то статистика собирается, но после релиза оказывается, что продукт напичкан дефектами, как подсолнух семечками, — и пользователи, что характерно, плюются.
Кто виноват? Все виноваты, конечно, — и руководители, и программисты, и аналитики, но они сами пусть учат свои уроки.
Ну и тестировщики.
Тоже.
Виноваты.
Да?
Да. И дело часто не в технических каких-то проблемах, а во вполне человеческих. Нет, бывает, конечно, что восстание машин ломает все планы, или что изначально планы были невыполнимы. Но даже и в не форс-мажорной ситуации у тестировщика достаточно способов провалить тестирование, работая в поте лица.
Читать дальше →
Total votes 35: ↑32 and ↓3+29
Comments23

Протестируем по-быстрому? Это не сработает

Reading time4 min
Views1.2K
Иногда очень хочется что-то протестировать «по-быстрому». Чаще всего это плохо работает, если только вы не знаете точно, что делаете и зачем.

1.

Вы руководите разработкой продукта в небольшой компании. Процесс разработки построен на базе двухнедельных итераций, периодически проводятся демо готовых вкусняшек для заказчика. Разработчики у вас достаточно сильные и опытные, продукт не выглядел чересчур сложным, так что тестировщиков на проекте изначально не было, и сейчас тоже нет.
За уже прошедшие со старта полгода вы неплохо поработали, заказчик в целом доволен ходом работ, хотя, конечно, падения и неадекватное поведение продукта во время демонстраций его смущают. Последняя демонстрация особенно удалась – из-за возникших технических проблем показать новые фичи не получилось. Заказчик потребовал больше внимания уделять стабильности и качеству продукта.
По планам до завершения проекта осталось три с половиной итерации, время разработчиков уже распланировано, и вы решаете нанять тестировщиков – чтоб они быстренько все протестировали, выгребли хотя бы основные проблемы и помогли тем самым выпустить достаточно хороший продукт.
Эй, это не сработает!
Читать дальше →
Total votes 21: ↑18 and ↓3+15
Comments18

Information

Rating
Does not participate
Date of birth
Registered
Activity