Многие организации планируют тестирование, не осознавая всей ценности такого планирования. Тестировщики зачастую создают тест-планы просто потому, что всегда это делали (или процессы гласят им, что так надо). Если тест-план грамотно составлен – это мощное оружие в вашем тест-арсенале.
Писать тест-план или не писать – вот в чем вопрос! Этот вопрос регулярно поднимается в обсуждениях на Software Testing Clinic. Положительный ответ на этот вопрос, в свою очередь, породит множество новых вопросов. Вот некоторые из них, которые стоит задать себе или команде:
В какой форме тест-план должен быть?
Какую информацию он должен включать?
Для кого он предназначен?
Это ценные вопросы, заслуживающие подробных и взвешенных ответов. Их задают очень часто, и их необходимо задавать, чтобы убедиться, что план дает внятные ответы на различные вопросы бизнеса – к примеру, связанные с наглядностью, контролируемостью, передачей знаний или управлением изменениями.
Публикуем запись доклада Антона Малев-Ланецкого "Postman и Newman — автоматизация API для бедных" с прошедшего в Новосибирске QA DevDay.
Антон привык работать в условиях ограниченных сроков-бюджетов и с радостью делится своими лайфхаками. В докладе рассказывает, как подружить Postman и Newman, уйти от запуска руками и получить отчёт в удобном виде. Бесценный навык и бесплатная реализация.
Когда я слышу вопрос "У меня большой набор ручных тестов, какие из них (или, что еще хуже, "какие тест-кейсы") мне стоит автоматизировать", я беспокоюсь сразу о нескольких вещах.
Во-первых, концентрация на тест-кейсах сигнализирует о довольно убогом образе мыслей в отношении тестирования. Это связано с тем, что тест-кейсы зачастую формулируются как четкое следование явной процедуре с целью получения специфического результата. В лучшем случае следование процедуре подтвердит, что продукт может работать, а также предполагает, что любой не наблюдаемый в ходе процедуры и после нее результат не так уж важен.
Проблема тут в том, что процедуру можно варьировать потенциально бесконечным множеством способов, и множество факторов могут повлиять на сам тест или его результат. Будут ли люди пользоваться продуктом одним и только одним способом? Выявят ли эти специфические данные проблему? Могут ли другие данные выявить проблему, которую не найдешь при помощи имеющихся? Будет ли баг возникать каждый раз при следовании этому сценарию? Тест-кейсы зачастую активно подавляют исследовательскую жилку. Тест-кейсы – это не тестирование, а баги не следуют за тест-кейсами.
Без стратегии тестирования можно наверняка обойтись, если есть бесконечное количество квалифицированных сотрудников, времени и денег. Словом, возможность пилить один релиз годами. В таких гипотетических идеальных условиях никакая стратегия не нужна, потому что вы можете тестировать ваш продукт всеми существующими способами как угодно долго, применяя техники в любом порядке, на несколько кругов, и рано или поздно каким-то путем вы придете к production ready качеству.
В реальности же у проекта всегда подгорает дедлайн, трудоспособность/скиллы команды не резиновые, а требования к продукту постоянно эволюционируют – и вот тут без хорошего плана никак нельзя. Поэтому на помощь приходит стратегия тестирования.
В этой статье мы предложим вопросы, которые надо обсудить для составления стратегии тестирования, и покажем на примерах, как принимаются решения об инструментах тестирования в том или ином случае.
Большинство руководителей в IT-сфере выросли из технарей. Нам комфортнее работать с программами, чем с людьми, а слово “сервер” нам ближе и понятнее, чем слово “мотивация”. Чтобы решить эту проблему, биг-боссы компаний приглашают сторонних коучей и экспертов по мотивации, а IT-менеджеры пытаются ломать себя и следовать правилам с тренингов: хвалить, давать обратную связь, мотивировать и стимулировать. Такие натянутые действия тоже не приводят ни к чему хорошему!
Оказывается, люди мотивированы всегда, и их не надо пинать! Вопрос не в том, мотивированы они или нет, а в том, что мешает раскрытию их максимального потенциала.
В своём докладе Виктория расскажет о том, как решили эту задачу в Лаборатории качества, внедрив новую парадигму Менеджеров Счастья. В числе тех инструментов, которые помогли им, и которыми автор поделится с вами:
* анализ проблем, хотелок и пожелалок наших любимых сотрудников; * обучение линейных руководителей менеджменту счастья; * совместная проработка общих целей; * решение не поверхностных, а корневых проблем.
Не нужно создавать созданное, нужно научиться применять имеющееся. Все проще, чем кажется.
Если поискать в Интернете список мнемоник тестирования, можно найти более 30 мнемоник, связанных с тестированием. Одна из наиболее известных эвристик (мнемоник)– это SFDPO (San Francisco Depot), созданная Джеймсом Бахом. Мнемоники не только помогают держать в голове важные разделы, которые нужно покрыть во время тестирования – они также могут поспособствовать генерации новых идей.
Мнемоника MOBILE APP TESTING
Тестируя мобильные приложения, я в основном пользуюсь мнемоникой I SLICED UP FUN, созданной Джонатаном Колом. Она помогает мне сконцентрироваться на различных областях наших приложений. Сегодня я хочу поделиться своей собственной мнемоникой – она называется MOBILE APP TESTING. Правда, легко запомнить? Ниже – подробное описание мнемоники с объяснениями, подсказками и ресурсами, которые помогут вам тестировать мобильные приложения.
Heisenbug 2018 Moscow стартует уже на следующей неделе. На конференцию приезжают лучшие специалисты по тестированию и разработке. Но это еще не все!
У вас будет возможность познакомиться с одним из топовых блогеров русского ютуба, который ведет популярный канал о технологиях и ПО.
На заключительном кейноуте первого дня конференции выступит Валентин Wylsacom Петухов! Он расскажет об epic fails производителей девайсов и почему у новейшего Google Pixel 3 выросла вторая «бровь».
А еще на Heisenbug 2018 Moscow приедет Алексей Баранцев, он занимается тестированием аж с 1994 года!
Сейчас Алексей разрабатывает ядро в проекте Selenium WebDriver, а также развивает главный российский портал про тестирование Software-Testing.ru. Организаторы Heisenbug взяли у него интервью и опубликовали в своем хабраблоге.
Вы узнаете, что изменилось в представлениях о тестировании, как развивается Software-Testing.ru, какой браузер лучше всех реагирует на баг-репорты и, конечно же, насколько тщательно протестирован сам Selenium.
На конференции Алексей расскажет о том, с какими сложностями встречаются разработчики популярного инструмента Selenium, как они их решают и как сообщество контрибьютеров помогает в разработке этого инструмента.
О, благословенная страна тест-автоматизации, сберегающая столько денег, времени и сил! Мы беремся за автоматизацию, чтобы повысить эффективность и частоту проверок, однако большая часть усилий в области автотестов пропадает впустую. Это плохо, если учитывать, что правильно внедренные автотесты очень выгодны.
В проекте по начислению пенсии мы внедряли решение по автоматическому приему, отказу или постановку в очередь на ручную обработку уведомлений о состоянии здоровья – в зависимости от четырех разных оценок. Пока оно внедрялось, я сделала автоматизированный набор тестов, управляемый через данные, проверяющий все возможные комбинации и диапазоны оценок.
Финальный тест был запущен спустя месяц разработки и занял десять минут. Вообще-то пять, но менеджер проекта не верила своим ушам и заставила меня прогнать его повторно.
Этот проект отлично подходил для автотестов, но не все проекты так же хороши. Я собрала ряд рекомендаций для тех, кто раздумывает над внедрением автотестов.
30 ноября в московском офисе Mail.Ru Group пройдёт митап, полностью посвящённый мобильному тестированию.
Приходите поделиться опытом и пообщаться!!
Андрей Копейко (Mail.Ru Group) раскроет секреты построения «headless» Android-эмулятора для UI-тестирования дизайнерских приложений (спойлер: стандартными средствами такого не достичь);
Слава Фролов (Badoo) научит на какие грабли не наступать при переводе автоматизированных тестов на iOS12, а также расскажет о взаимодействии с отделом ручного тестирования, девелоперами и релиз-инженерами в процессе;
Дмитрий Меркурьев (AvitoTech) в своем докладе «Andorid CI: Impact Analysis» рассмотрит подход к оптимизации CI через анализ изменений проекта.
А еще в завершении дня у участников будет возможность вместе с экспертами обсудить преимущества и недостатки нативных инструментов автоматизации и Appium.
