Июль, 2015

18+ советов начинающему тестировщику!

Опубликовано: 16.07.2015 | 12504

Мы провели опыты на своих тест-менеджерах и лишили их печенек аж на три дня! Звучит ужасно, но такие суровые меры были необходимы для получения качественной информации ;)

А как же иначе? Ведь мы решили дать «пару» советов начинающим (и не очень) тестировщикам, и обычного серфинга по тематическим форумам вкупе с хождением по встречам и конференциям было недостаточно для дельной статьи.

Наши советы основываются на опыте, так что бывалый специалист и сам уже должен был прийти к этим фишкам. Но почему бы не узнать больше прямо сейчас вместо того, чтобы учиться на собственных ошибках потом? Итак, вот одни из лучших хитростей тестирования ПО, которые мы собрали:

1. Продумывайте тестовое покрытие

Хоть 100% и недостижимая высота, вы всегда должны стараться охватить продукт наиболее полно. Поэтому разрабатывать тестовое покрытие нужно с умом, комбинируя разные техники тест-дизайна. При этом важно координировать свои действия с требованиями менеджера, чтобы не изучать одну фичу глубоко и долго, когда на самом деле от тебя хотят полного тестирования ПО. Так можно и дедлайны запороть.

Разделите продукт на функциональные модули. Так вам будет намного легче тестировать!

2. Дефрагментируйте тестируемое ПО

Чтобы обеспечить максимальный охват продукта тестами, разделите его на более мелкие функциональные модули. Напишите тест-кейсы для этих отдельных блоков. А если возможно, то разделите функциональные модули на ещё более мелкие части. К примеру:

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

Метод визуализации дерева во всей красе. Даже с медведем!

Помимо этого,

Некоторые тестеры во время работы представляют дерево. Березу там, или клен.

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

3. Будьте последовательны

Основная мысль, которую с детства закладывают в умы будущих тестировщиков – начинай с позитивных сценариев, в первую очередь проверь основные действия юзера. Что происходит, если отойти от этого скрипта? К примеру, джуниор тестирует процесс заказа товара.

На эту задачу отведено 8 часов. 6 часов спустя, джуниор в ударе: он проверил валидационные сообщения, увидел ошибку 404 и положил базу, закинув в поле имени 5999 символов. Пошел 7 час, и тут оказывается, что на третьем шаге заполнения данных падает исключение при нажатии кнопки Оплатить. Блокирование основного сценария на седьмом часу теста, Карл! А должен был быть внесен в систему отслеживания ошибок уже в первые 10 минут работы.

Блокер, Карл!

4. Тестируйте с охотой!

Начиная тестирование ПО, включите свои охотничьи инстинкты и настройтесь на поиски ошибок. Незачем думать, что в продукте не будет багов. Если вы будете достаточно дотошным, вы сможете найти даже самые незаметные проблемы!

5. Но без фанатизма

Когда вам в руки попадает уже качественное, «вылизанное» ПО с микроскопическими багами, которые конечный пользователь никогда не найдет, поубавьте пыл. Даже если под проверку такого билда выделено время, те же 8 часов, то не тратьте их на попиксельное тестирование админки. Проекты делаются для определенного конечного пользователя и решения чьих-то задач и проблем. Подумайте, что им действительно нужно.

6. Поделитесь тест-кейсами до разработки

Не прячьте свои кейсы от программистов до самого получения билда с мыслью о том, что так вы сможете обнаружить больше багов. Если кодеры проанализируют ваши записи до начала разработки, то продукт получится более качественным. Кроме того, вы сэкономите время на повторную работу и исправление багов.

Пусть вам встречаются только безобидные мелкие баги!

Да и вообще, не бойтесь общаться с прогерами побольше (в меру конечно, не надо садиться рядом и целый день смотреть в монитор программиста, чтобы вас потом изгоняли общими усилиями разработчиков, админа и бубна).

7. Определите свои тест-кейсы для регрессионного тестирования

И сгруппируйте их заранее. Так вы значительно упростите и ускорите себе повторное ручное тестирование.

8. Не забывайте о производительности

В продуктах, требующих критического времени отклика, нужно тщательно анализировать производительность. И так как у каждого тестировщика есть отдельная область задач, важно стараться видеть картину в целом. Обращайте внимание не только на свою часть работы (функциональность, gui, совместимость, например), но и привлекайте внимание менеджера проекта к проблемам в производительности, в безопасности, да в целом, в процессе работы. Тогда менеджер сможет сразу среагировать и подключить нужных специалистов к проекту.

9. Не давайте разработчикам тестировать их собственный код

И в целом не стесняйтесь не доверять разработчикам. Программисты могут качественно проводить автономное тестирование основных модулей разрабатываемого продукта. Но в большинстве случае кодер пропустит часть багов, потому что сам писал ПО и думает, что оно и так идеально работает.

Увы, так идеально разработка ПО выглядит только в голове у прогера.

Поэтому вот этот функционал он пропустит, про это поле забудет, и вот эта кнопочка им была написана, значит, с ней всё ок. Задача же тестировщика – проверить все возможные и невозможные состояния и комбинации действий, в которых софт работать не будет.

10. Выйдите за рамки требований

Иногда требования не отражают всей полноты функционала продукта, особенно, если она гибко разрабатывается под меняющиеся условия. Так что как бы не было детализировано техническое задание, оно не всеобъемлюще. И отмазкой «этого не было в ТЗ» вы вряд ли кого-либо порадуете – все и так знают, что нет смысла бронировать билеты на дату в прошлом. Поэтому тестируйте продукт не только строго следуя документации, но и опираясь на свои собственный здравый смысл, ощущения, идеи, пользовательский опыт, опыт коллег и эталонное ПО на рынке.

11. Оглядывайтесь назад

Во время выполнения регрессионного тестирования вам пригодится ранее заполненная документация, содержащая распределение дефектов по функциональным модулям во времени. Так вам будет проще спрогнозировать наиболее вероятные баги и проблемные места в ПО.

Пишите чем угодно и на чем угодно!

12. Ведите конспекты

Записывайте новые термины, понятия, свои наблюдения и ход тестирования. Вы можете пользоваться специальным приложением или софтом, а можете просто открывать любой текстовый редактор. Эти выкладки и записи очень помогут вам при написании отчетов о результатах тестирования и будут полезны для усвоения новой информации.

13. Записывайте тестовые изменения кода

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

14. Делайте засечки

Мы уже говорили про запись хода тестирования. При тестировании одного из модулей, вы сосредотачиваетесь на нем и не планируете отрываться. Но по ходу дела всегда выскакивают какие-то баги в смежной функциональности. И чтобы резко на них не переключаться, удобно делать своего рода засечки, понятные вам, на бумажке, в текстовом редакторе или где-то еще. А когда вы приступите к тестированию смежного модуля, то скажете себе большое спасибо за уже помеченные 30-40% багов.

15. Обменивайтесь опытом

Важно наладить общение, чтобы новые знания, методики и практики циркулировали внутри команды и за её пределами.

Общение - ключ ко всему! И к дружному коллективу, и к уникальному продукту.

16. Настройте обратную связь с программистами

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

17. Планируйте свое время

Расставляйте правильные приоритеты. Последовательно переходите от наиболее важных задач к задачам низкого приоритета. Не забывайте давать глазам отдых, подумайте о разбиении своего рабочего времени на равные модули по 20-30 минут. Так вам проще будет контролировать свои пики активности и использовать их на полную мощность, при этом вы не будете перенапрягаться.

18. Учитесь писать отчеты

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

Не забывайте: тестирование – это творческая и амбициозная задача. То, как вы справитесь с этим вызовом, зависит от ваших навыков, опыта и мышления.

P.S. Мы добавили возможность комментирования, поэтому будем очень рады, если вы поделитесь своими ежедневными тест-хаками!