QA Automation, часть 2: Автотестирование – Начало.
| February 6, 2012 | Posted by Andrey Rebrov under Статьи |
Часть вторая
Продолжаю серию постов, про автоматизацию QA процессов. Уже готов пост про связку Selenium 2 + TestNG, но прежде мне бы хотелось немного поговорить о самом процессе автотестирования и его внедрении.
Предыдущие статьи на эту тему:
Те, кто смотрели фильм “Начало” (Inception), помнят, что до того, как мы начинаем действовать, у нас появляется идея. А до того, как у нас появляется идея, должна возникнуть мысль, которая все и породит. Так что же побуждает нас перейти к автотестам, какие страхи нам приходится побеждать? Обо всем этом я и хотел бы поговорить в этом посте.
На определенном этапе своего развития команда подходит к этапу, когда уже члены команды притерлись друг к другу, мы пишем хорошие продукты и все у нас хорошо, но надо двигаться дальше. И здесь настает время Lean, бережливого производства. Команда начинает улучшать имеющиеся у нее процессы, уменьшать или вообще избавляться от потерь времени, ресурсов и так далее. И именно отсюда появляются задачи на автоматизацию процессов, чтобы экономить время высококвалифицированной команды QA и DEV на более сложные задачи, требующие непосредственного человеческого участия. Это отдельная большая тема, сегодня я хочу поговорить только о небольшом кусочке – автоматизации тестирования.
Итак, почему же мы начинаем заниматься автоматизацией тестирования:
- ручное выполнение тестов занимает слишком много времени;
- во время ручного тестирования, человек можно совершить ошибку;
- автоматизация позволяет освободить время для команды для решения сложных задач;
- автоматические регрессионные тесты первыми распознают возможные ошибки в приложении;
- автотесты позволяют получить информацию о приложении быстро;
- тесты являются хорошим видом документации;
- тесты позволяют нам писать код сразу на хорошем уровне (TDD).
- нельзя автоматизировать тесты, используя только свободное время, этим нужно заниматься полноценно;
- отсутствуют или не поставлены четкие цели;
- недостаток опыта;
- если кто-либо начинается заниматься автотестами, он теряет опыт в основной профессии (в 2001 еще не было роли тестировщик-автоматизатор);
- нужна высокая мотивация, чтобы заниматься автотестами, так как их сложно закончить, и приходится писать и переписывать;
- многие начинают заниматься автоматизацией ради автоматизации, а не ради улучшения качества продукта;
- уход в технологические проблемы автоматизации так же приводит к потери цели, а зачем же автотесты пишутся.
- отношение программистов – многие не понимают зачем нужны автотесты, если уже есть тестировщики, и уж тем более не хотят помогать писать подобные тесты, так как “мы тут сами зашиваемся, а тестируете вы и так нормально”;
- очень долгий период, когда нужно много вкладываться в автоматизацию – многие могут не довести до конца и сдаться;
- первоначальный вклад – прежде чем начать заниматься автотестами, нужно провести долгий анализ средств, стратегии и прочего, а как этим займешься, когда одна задача ASAPее другой;
- тесты приходится поддерживать и переписывать – “это понятно, непонятно только зачем команда разработки постоянно меняет UI приложения” мог бы сказать какой-нибудь тестировщик и начать тестировать как раньше;
- legacy code – одно из самых страшных проклятий команды разработки, очень часто руки опускаются и никто не занимается улучшением это кода, написанием тестов и так далее;
- страх – многие боятся, что ничего не получится, время уйдет, а продукт сдавать надо;
- старые привычки – вытекают непосредственно из предыдущего пункта: “раньше автотестов не было, но мы же как-то сдавали продукты”.
В своем следующем посте я хотел бы рассказать о стратегиях автоматизации, при этом частично я расскажу, как бороться с выше озвученными проблемами.
