Первая часть статьи: Жми на кнопки, получишь результат
Миф № 3. Тестирование приложений на мобильных устройствах — это легко
Андрей (тестировщик, специализация — мобильные приложения):
«Со стороны тестирование на планшетах, смартфонах и прочих «мобилках» выглядит простецким занятием: сидит человек да и тыкает пальцем в экран, иногда что-то записывая. Но на самом деле, в это время кипят страсти сродни приключениям Индианы Джонса. Ведь что такое мобильное устройство? Это компьютер, который не стоит дома на столе, а бегает вместе с вами. К тому же он маленький, с батарейкой, без мышки, иногда работает как телефон, при этом связь с интернетом зависит от положения Марса в третьем доме и политической ситуации в стране. А ведь еще «джи-пи-эс», и надо найти все спутники, а гироскопом определить положение в пространстве…
Вот и тестируется приложение в условиях, приближенных к полевым:
— в офисе отыскиваются места с плохим приемом сигнала Wi-Fi, 3G, GPRS и т.п. (приложение не должно пугаться и ломаться при отсутствии Интернета);
— телефон поворачивается в пространстве (экран приложения должен, так сказать, повернуться к пользователю лицом);
— на телефон делаются входящие звонки и присылаются SMS (ничто не должно сбить с толку приложение);
— если в приложении есть карта, проверяется работа с GPS (странно было бы узнать, что находишься в Тихом океане);
— проверяются жесты («одно лишнее движение и все удалено» — такого не должно быть);
— проверяется встроенная клавиатура (набор текста в 700 символов для проверки полей ввода превращается в не самое легкое занятие на экране смартфона);
— аккумулятор доводится до истощения, а иногда просто вытаскивается;
— имитируется ситуация «телефон-в-кармане-а-блокировки-нет»;
— и другое экстремальное тестирование.
Единственное, не охваченными остались тесты приложений при нахождении под водой, в пустыне, при ускорении свободного падения, но это уже другая история».
Миф № 4. Юзабилити тестирование — пустышка
Алексей (тестировщик, специализация — юзабилити и автоматизированное тестирование):
«Очень часто от заказчика слышишь, что тестирование юзабилити того не стоит. Любой заказчик может сам сесть, пройтись по сайту, покликать на формы и точно сказать, что удобно, а что — нет. Смысл кому-то платить ради этого, когда всё понятно и очевидно? Эх, если бы всё действительно было так просто, то не существовало бы огромного множества книг, статей, мнений, методик, средств, программ, таблиц, публикаций и форумов. Да и не было бы нужды в специалистах. К счастью, всё это есть, а специалисты востребованы. Результаты исследований NNGroup сообщают, при улучшении юзабилити каждый сайт мог бы увеличить свои продажи в среднем на 79%.
Опыт нашей работы показывает, что тестирование юзабилити при должном подходе можно формализовать и добиться большей объективности оценок. В свою очередь улучшение результатов тестирования повышает комфортность от взаимодействия человек-компьютер. Так, например, популярные и часто используемые на многих сайтах выпадающие меню и списки после проверки оказываются менее удобными, а часто даже вредными! И это несмотря на просьбы заказчика «поставить выпадающий список тут, там и в этом углу».
Заказчик интерфейса — это потребитель. А потребитель, как известно, далеко не всегда понимает, как ему на самом деле будет удобнее. Указать на ошибки в интерфейсах взаимодействия, подсказать способы улучшения может только специалист. Но даже на основе своего богатого опыта специалист не может полностью оценить все без проведения дополнительного тестирования на реальных пользователях.
Не все так просто, если хочется результата».
Миф № 5. Автоматизированное тестирование? Нужно быть очень крутым программистом!
Алексей:
«Часто приходится слышать, что разработка автоматических тестов — это слишком сложно, нужно много кодировать, да и вообще проще вручную всё сделать… Да, разработка автотестов сложна и требует времени, не всегда целесообразна. Но вовсе необязательно знать десяток языков программирования и различных паттернов. Современные средства тестирования во многом сами помогают писать код для автотестов. Например, Selenium IDE в своей среде имеет экспериментальную возможность экспортировать записанный код в C#, Java и Python проекты. К тому же существуют конструкторы тестов и специальные нотации для них. Если совсем туго с программированием, то автотест можно написать в конструкторе JMeter (если забыть, что он для нагрузки, и использовать одного пользователя) или использовать автокликеры. Более совершенные методы — это использование MSC диаграмм.
Даже если тест невозможно формально автоматизировать полностью, можно попытаться автоматизировать хотя бы часть процесса, которая облегчит сбор данных для их последующего анализа. Так, например, идеальным решением было автоматизировать сбор записей с базы данных, которые требовали последующего эвристического анализа. Из-за особенностей сервиса обращаться к базе можно было только в определенные ночные часы. И автоматизация нас сильно выручила.
Не нужно забывать, что для написания автоматических тестов нужно быть, прежде всего, хорошим тестировщиком. А понимание алгоритмов и техническое образование помогут конструировать качественные автотесты, даже без отличного знания языков программирования».
Метки: интервью, тестирование
И почему Python всегда последний по списку?
Чтобы быть хорошим автоматизатором, нужно быть хорошим программистом. Автотесты это тот же самый код, что и продукт. А говнокод в продукте думаю сами знаете к чему приводит.
<<Например, Selenium IDE в своей среде имеет экспериментальную возможность экспортировать записанный код в C#, Java и Python проекты.
И вы этим пользуетесь? И считаете что за вас все сделают Современные средства тестирования? Не надо быть такими наивными.
Любой тест вначале должен быть прогнан в ручную функциональным тестировщиком и уже потом автоматизирован. Если этим занимается один и тот же человек, то это должен быть хорошим программистом и хорошим тестировщиком. Что в принципе редкость.
Тесты — не тот же продуктивный код, который уходит к заказчику. Допустимо и костыли вставлять. Качество кода – это вопросы его читабельности и переиспользования. Нежелательно его запускать, но на небольших проектах это не так критично. Тесты как таковые не тестируются, когда они элементарны (атомарные) и с простой логикой. А сложные тесты — никто и не пишет. Ведь потом их надо тестировать. Писать тесты на тесты… тесты на тесты… на тесты…
А прогон автотеста — это обычная отладка. Без неё никуда. Плюс, не надо сливать в одно: написание автоматического теста и разработка теста как такового – разные понятия. Суть – не надо быть супер программистом. Достаточно что-то знать и уметь кодить. В остальном — помогут современные средства на первых шагах.
Основная мысль статьи — не надо бояться. Писать тесты чуточку проще с точки зрения кода, чем писать программы. Алгоритмов и паттернов разработки нужно знать меньше. Больше дружить с логикой и понятием «верифицируемый».
Ну, если выпустить в продакшен и забыть, то наверно, да и костыли пойдут. Ccontinuous integration с таким подход загнется на второй день.
>>А прогон автотеста — это обычная отладка.
Это если костыли в коде автотестов, тогда прогон автотестов сводится к постоянной отладке. Я б такого автоматитзатора в шредер :)
>>Плюс, не надо сливать в одно: написание автоматического теста и разработка теста как такового – разные понятия.
А кто сливает это все в кучу? Я? Неправда. Это абсолютно разные процессы, каждой из которой могут заниматься разные люди (я бы сказал даже должны). У нас вначале тесты в системе управлениями тестами, а потом уже выборочная автоматизация этих тестов.
>>Основная мысль статьи – не надо бояться.
Ну извините, я этого по тексту не понял значит. Мне показалось, что мысль в том, что не нужно бояться писать автотесты, если о программировании что-то слышали и писали на чем-то «Hello, World!!!»
>> Continuous integration с таким подход загнется на второй день.
Верно, но это не обсуждалось. Чем сложнее проект, тем больше нужно усилий и качества.
>> Это если костыли в коде автотестов, тогда прогон автотестов сводится к постоянной отладке.
Ну, это глупость. Переиспользование тестов, кода, развитие функционала, так или иначе, приводит к частому изменению как набора тестов, так и их содержания. Костыли в коде нужны в случае сложных тестов, особенностей фреймворка и языка. Если у человека пока не хватает знаний и навыков писать более качественный код для тестов — это не повод его останавливать и не давать развиваться.
>> У нас вначале тесты в системе управлениями тестами, а потом уже выборочная автоматизация этих тестов.
Все верно. Поэтому еще раз прогонять вручную автотест функциональному тестировщику незачем. Я не правильно понял, когда вы написали про ручной прогон теста.
>> Мне показалось, что мысль в том, что не нужно бояться писать автотесты, если о программировании что-то слышали и писали на чем-то «Hello, World!!!»
Немного грубо, но уловили опять же правильно. Страх перед кодированием и мнение «Я должен быть гуру и аццкий сотона C# (& etc.)» не должны быть препятствием к разработке и написанию автотестов.
К чему собственно я все это:
1. Автоматизация тестов — это полноценная разработка со своим циклом.
2. Код автотестов должен проходить весь процесс написания кода.
3. Надеяться, что современные средства с помощью своих Recoder напишут вам все сами, глупо.
4. Автоматизатор должен обладать скилами, которые не такие как у обычных программистов, но они есть и должно быть нехилые.
5. Если при изменении кода продукта приходится постоянно рефакторить, то это очень плохая автоматизация с большими затратами. Хорошие тесты должны искать баги, а дергать каждый раз кого-то, кто поправит очередной костыль. При это я не говорю, что тесты не требуют совсем рефакторинга.
6. Бояться писать не нужно, но под пристальным контролем старшего брата.
7. У автотестов есть тоже пользователи. Те же программисты должны уметь их запускать, чтобы просто проверить проявление замечания или проверить, что после исправления все исправлено.
P.S. Я про это пишу не просто так. Со всеми проблемами я сталкивался при работе.
Полностью согласен с Александром.