Так уж сложилось на практике, что самые главные инструменты для специалиста в сфере тестирования ПО - это его зоркий глаз, пытливый ум и интуиция. Тем не менее, жизнь тестировщика "и опасна, и трудна", и чтобы её сделать несколько комфортнее, существует ряд замечательных инструментов. И как раз о таких инструментах будет данный доклад.
Из семян взращиваются тестовые идеи – как сорняки. Следуйте за ними. Нам нужно как можно больше идей и мыслей, как можно больше покрытия, чтобы принимать наилучшие решения про общее тестовое покрытие. Поначалу это будет выглядеть уродливо и неорганизованно. Но дайте модели вырасти. Начните переставлять ветки, подрежьте некоторые из них. По мере роста веток создание карты побудит вас задавать более четкие вопросы участникам проекта. Карта становится инструментом по улучшению самой себя. Этим и прекрасны органические системы – бросьте в них семечко, и оно вырастет само по себе, с нами в роли безумного садовника.
Вот как выглядит модель тестового покрытия после чтения спецификации и разговора с разработчиком:
На этом этапе план тестового покрытия и план покрытия продукта практически идентичны по своей природе, за тем исключением, что план тестового покрытия описывает и включает в себя тип тестирования и вопросы для исследования.
10-11 марта, в Минске, сообщество COMAQA.BY проведет большую конференцию выходного дня, посвященную вопросам ручного и автоматизированного тестирования, DevOps, разработки в контексте автоматизации и менеджмента в тестировании.
Спикеры из ведущих IT-компаний Швеции, Германии, Финляндии, Ирландии, России и Беларуси соберутся вместе, чтобы рассказать о своем опыте в тестировании и управлении, поделиться личными практическими “секретами” и наработками.
Организаторы подготовили для вас:
16 докладов в первый день конференции от профессионалов-практиков;
Видеотрансляцию докладов (условно платную) для тех, кто захочет присоединиться удаленно;
3 потока мастер-классов во второй день конференции;
Обед и кофе-паузы для комфортного общения со спикерами и нетворкинга;
Сувениры от организаторов и партнеров конференции.
Наверняка многие тестировщики хотя бы раз сталкивались с ситуацией, когда времени на тестирование совершенно нет. Даже если им чуточку повезло, и хоть какое-то время осталось, то его все равно не хватит на проверку всего продукта. И не столь важно, почему так получилось (неправильно спланирована работа, заказчик захотел «прикрутить вон ту фичу» в самый последний момент, тестировщиков поздно подключили к проекту), – главное в том, что выходить из положения как-то нужно.
Итак, что же делать, когда времени вовсе не осталось, а тестировать хочешь не хочешь, но надо? Можно искать виноватых, кивать друг на друга, бегать в панике, но, как мне кажется, каждый понимает, что это неконструктивный подход. В этой статье я расскажу о своем опыте, позволяющем справиться с тесными временными рамками. Ниже я составила список подходов, которые можно применить в условиях сжатых сроков.
“Хорошими манерами обладает тот,
кто наименьшее количество людей
ставит в неловкое положение.”
Дж. Свифт
Привет, коллеги! Сегодня я бы хотел поговорить о Unit-тестировании и некоторых “правилах” при их написании. Конечно, они неформальные и не обязательны к выполнению, но при их соблюдении всем будет приятно и легко читать и поддерживать тесты, которые вы написали. Мы в Wrike видели достаточно Unit-тестов, чтобы понять основные проблемы, которые возникают при их написании и поддержке, и сформулировать несколько правил для их предотвращения.
1. Unit-тесты нужно писать. Да, как бы банально это не звучало, но писать их нужно. Каждый кусок логики приложения должен быть протестирован, чтобы в будущем избежать проблем. А они могут возникнуть при изменении логики, рефакторинге, или даже при обновлении версии зависимых библиотек. И чем больше покрытие кода тестами, тем быстрее проблема будет обнаружена и исправлена.
2. Это правило очень актуально для тех, кого заставляют покрывать код тестами, и оно звучит так: Тесты — это тоже код, и относиться к нему нужно как к рабочему коду. Это касается и нейминга переменных, и форматирования кода внутри теста, и, особенно, названий тестовых методов. Конечно, написание адекватного имени переменной занимает немного больше времени и ударов по клавиатуре, чем “int i = 0;”, но это повышает читабельность тестов и легкость их поддержки.
Представьте, что вы – владелец зоопарка, которому хочется узнать, что поделывают коллеги по профессии. Вы открываете руководство по большим кошкам. Оно выглядит примерно так:
«Вот пример большой кошки: она отличается тем, что у нее есть усы, она пушиста, и имеет пару глаз. По моему опыту, очень полезно заводить такую большую кошку в зоопарке. Всем заинтересованным лицам очень нравится моя большая кошка».
Посчитав прочитанное информативным и вдохновляющим, вы открываете другое руководство, где видите другую большую кошку:
«Недавно я читал про больших кошек, и с тех пор старался заполучить их в свой зоопарк. У моей большой кошки тоже есть усы, она пушиста и двуглаза, но мне нравится, что она более пушиста и менее полосата».
«Круто!» - думаете вы.
Вы уже видели два примера больших кошек, у которых, конечно, много общего, но которые сильно отличаются друг от друга. Как-то раз вы, вне себя от радости, общаетесь с коллегой – владельцем зоопарка, который рассказывает вам про своих новых больших кошек и помещение для них. Он очень рад, потому что постоянно слышал, что современные зоопарки используют больших кошек в своих выставочных залах, и что большая кошка – это пик современных зоопарковых практик.
В тестировании мобильных приложений есть очевидная трудность - огромное множество окружений.
Если учесть различные значения таких переменных, как операционная система и её версия, разрешение и размеры экрана, емкость АКБ, сотовый оператор, количество sim-карт, наличие или отсутствие WiFi, качество соединения по нему и ряд других влияющих параметров, то как итог получится невероятно большое количество комбинаций, на проверку во время тестирования которых потребуются колоссальные трудозатраты.
Компании, которые ведут бизнес онлайн, теряют миллиарды долларов годового дохода из-за бага - несовместимости их систем с доменными именами, состоящими из символов, отличных от латиницы. Исправление этого общеизвестного бага увеличило бы количество пользователей онлайн-сегмента приблизительно на 17 миллионов человек за счет числа тех, кто говорит на русском, китайском, арабском, вьетнамском, индийском языках.
Такое заключение сделала компания-лидер отрасли на основании своего нового исследования, спонсором которого является организация, ответственная за поддержание и актуализацию списка действительных доменных имен, International Corporation for Assigned Names and Numbers (ICANN) (Международная организация по распределению номеров и имен). Задача так называемой Координационной группы по вопросам всеобщего признания новых доменов (Universal Acceptance Steering Group), членами которой являются представители огромного числа интернет-компаний (например, Microsoft и GoDaddy), - мотивировать разработчиков ПО и владельцев сервисов производить обновления своих систем в отношении валидации набора символов справа от точки в имени домена или e-mail адреса, т.е. в домене верхнего уровня.
При внедрении и сопровождении бизнес-приложений всегда нужна «обкатка» на тестовых данных. Беда в том, что для тестов иногда используют конфиденциальные данные из баз корпоративных заказчиков, в том числе персональные. Как не допустить их утечки и в то же время протестировать систему в условиях, приближенных к «боевым»?
Откуда берутся тестовые данные
Тестовые данные получают по-разному, у каждого из подходов свои плюсы и минусы:
можно генерировать их в автоматизированном режиме. Для этого нужны специальные инструменты, довольно сложные;
можно вводить тестовые данные вручную, но это требует серьезных трудозатрат;
иногда разработчики берут рабочую базу, которая полностью копируется в тестовую среду. Но рабочая база обычно велика, и адекватно уменьшить её сложно.
Манипулирование в тестовых средах базами терабайтного масштаба — не самое дешёвое и приятное занятие, плюс могут возникнуть связанные с конфиденциальностью проблемы. Это особенно актуально, если речь идёт о заказчиках, например, из финансового сектора, которые оперируют чувствительной информацией и персональными данными — работа с ними регулируется требованиями российского законодательства.
Рано или поздно у заказчика возникает потребность «испортить» информацию при переносе за пределы производственной среды, чтобы исключить неправомочный доступ к ней задействованных в тестировании инженеров. Иногда тестированием занимаются сторонние организации, и в этом случае использование реальных данных — еще более рискованная затея. Есть несколько вариантов решения этой проблемы.
Карта – это визуальное представление области – символическая картина, выделяющая взаимоотношения между элементами пространства – предметами, регионами, темами.
Тестирование ПО похоже на исследование новых территорий. Принципы остаются такими же – где-то там существует нечто неизвестное, и мы стремимся с ним ознакомиться.
Исследуя новые территории, мы интересуемся определенными характеристиками. Возможно, это физические черты – линии побережья, горы, реки. Или это политические границы, подводный мир, распределение скал, рубежи, или все это, вместе взятое. Как отчитаться о найденном, о нашем понимании этой территории, на основании тех черт, которые нас интересуют? Мы рисуем карту.
