По мотивам поста «Легкий способ провалить тестирование».
Как избежать провалов в тестировании продукта?
1. Тестировщик должен быть в курсе изменений в продукте.
Очень часто все ровно наоборот. О том что фичу порезали или изменили на 90 процентов узнаешь последним. Информация доходит урывками и частенько искажена. Иногда приходят какие то промежуточные требования. Иногда из требований только строчка в бэклоге.
Иногда тупо нет прав на документы, потому что не твоя область.
Нет конечно можно постоянно тусить среди манагеров, чтобы быть в курсе всех изменений, обхаживать девелоперов, чтобы они поясняли с божественной высоты откуда и почему возник такой вот говнокод. НО! Если постоянно тусить, то работать будет некогда, а ухаживать я предпочитаю за женой.
Задумайтесь есть ли у Вас канал связи с тест командой или они получают информацию по остаточному принципу?
Полная и своевременная информация — это хороший старт. Как следствие хорошо написанные тестовые спеки и заранее подготовленный environment.
2. Чужие баги
Очень хорошо помогать коллегам с точки зрения проекта, но хороши ли с точки зрения коллег?
Как коллеги относятся к таким неожиданным конкурентам? Не лишают ли их премии за это? Ну или может на доску позора вешают? Залез я как то в чужую область и стал там баги находить, думаете чем кончилось? Правильно, злыми соседями, которым я как бельмо на глазу стал мешать. Прежде чем требовать от команды репортить все и вся, проверьте есть ли для этого возможность. Не рассыпется ли дружная команда на мелкие враждующие группировки.
3. Мелкие баги и баги/импрувменты интерфейса.
Если 90% таких багов остаются забытыми или отправляются в реджект, не стоит удивляться, что их перестают заводить.
Отрепортить мелкую багу порой ничуть не быстрее, чем сложную. Работать же впустую никому не охота. Импрувменты же вообще частенько реджектятся чуть ли не в момент появления.
4. Лаборатория
Не стоит забывать про условия тестирования. Если у кастомера система из 10 стоек с 30 свитчами, 3 серверами, модулем сотовой связи, пара сотен ип телефонов и еще какое то хитрое самодельное оборудование, а у вашего тестера один комп на селероне, то стоит задуматься, над тем, как он вообще тестирует.
Эта одна из постоянных проблем тестирования, особенно если продукт дорогой. Тут всегда надо искать золотую середину. Если это возможно то часть тестирования лучше спуливать заказчику в реальную среду. Всякие альфа бета тесты. Ну вы слышали наверное.
5. Сроки и отчетность.
Если работу оценивают по количеству отрепорченных багов или выполненных тестов, то ничего тут не поделаешь. Приходится писать и исполнять кучу бесполезных говнотестов и рыться там где можно найти соответсвующее число багов. Рыться же в поисках «той самой» мега значимой, но трудно воспроизводимой проблемы никто не будет.
Такие провалы происходят исключительно на уровне менеджмента. Винить в этом тестировщиков просто глупо.
Почти постоянно на эту проблему накладываются нереальные сроки -> из кучи говнотестов выполняются самые простые -> баги тоже сабмитятся самые бесполезные -> качество продукта ниже плинтуса.
6. Что происходит с багами вида: not reproducible, observed and etc?
Если их отправляют в режект (а именно это как правило и происходит!), то их тоже перестают заводить. Только в одной фирме я видел, что такие баги не закрывали, а отправляли в специальный статус и не закрывали. Но там делали медицинское оборудование и даже почти невозможная возможность появления баги повторно была критична. Остальные в массе своей забивают на такие проблемы.
7. Автоматизация vs ручное тестирование.
Очень часто менеджмент хочет автоматизировать все и вся. Это понятно, тогда можно разогнать команду и гонять автотесты. Также этого хочет процентов 90 новичков. Это тоже понятно. Самый легкий способ показать на что способен и тп.
Реальность же такова, что порой автоматизация вообще не стоит потраченных усилий. Не стоила она их в 4 из 5 крупных проектах где я учавствовал. Почему так выходило? Причины были разные. В одном проекте лоборатория переезжала раз в полгода и чтобы скрипты запускались на новом месте приходилось тратить кучу времени. В другом написание среды для написания тестов доверили программерам. В итоге, чтобы написать простейший тест приходилось использовать жуткие неудобные конструкции. Большинство тестов были практически нечитабельны. В третьем срок жизни проекта был настолько низок, что быстрее было бы прогнать все тесты вручную пару раз.
Стоит отметить также, что легко как правило автоматизируется тесты, которые и руками то легко выполнялись. Нестабильные тесты стабильно же валились и после автоматизации и их приходилось перевыполнять по несколько раз.
Решение об автоматизации и о том, что собственно надо автоматизировать и какими средствами весьма непростой вопрос.
Забывают многие и о последствиях. В одном проекте было автоматизировано практически все. И так получилось, что коллектив сменился за некоторое время полностью. Начальство взамен набирало абы кого (автотесты пускать большого ума не надо). А когда пришла пора больших изменений, то выяснилось, что из тестировщиков никто даже и не знает, что делает продукт и зачем он вообще нужен.
8. Положение тестировщика в общей структуре компании.
Если сотрудник на служебной лестнице стоит на уровне уборщицы, то ожидать от него выдающихся результатов не стоит. Казалось бы очевидная вещь, не так ли? Большинство же набирает тестовую команду из «отбросов» программистов, студентов и по служебной лестнице у многих ведущий тестировщик котируется на уровне джуниора программиста.
Мне частенько приходилось слышать: «Вот подучишь языки и перейдешь в девелоперы. Человеком станешь!».
Автор: mtikhon
