автоматизация | Жизнь - это движение! А тестирование

Показаны сообщения с ярлыком автоматизация. Показать все сообщения

среда, 29 мая 2024 г.

Шпаргалка по XPath и CSS-селекторам

Для написания автотестов используются XPath и CSS-селекторы. Они помогают найти элемент на странице, чтобы потом с ним как-то взаимодействовать (кликнуть, ввести текст, или что-то другое).

Я видела много статей о том, что это вообще такое, но мне очень не хватало шпаргалки по разным селекторам, причем в разрезе «Вот он в CSS и он же в XPath» для сравнения.

А мне такое для студентов надо. Поэтому решила сделать сама. Вдохновлялась страничкой «Xpath cheatsheet», но сделала на свой вкус — под автоматизацию, а не XPath вообще. И с комментариями, с ними удобнее.

Пишите, если где-то накосячила. Хотя я все селекторы проверяла на тестовых страницах, но мало ли… И надеюсь, вам такая шпаргалка тоже пригодится! =)

Ссылка на ХАБР

(там таблички нормально отрисовываются и есть содержание кликабельное)

воскресенье, 26 мая 2024 г.

CSS, XPath: локаторы или селекторы? Разбираемся в терминах

Я обычно слышу такие словосочетания для поиска элементов на HTML-странице:

CSS-селекторы
XPath-локаторы

Но как правильно их называть?

Можно ли и то, и то назвать селекторами? Или локаторами? Сходила за уточнениями к Алексею Баранцеву, разработчику инструмента Selenium и автору курсов по автоматизации тестирования (где селекторы и применяем). Итак:

Почему XPath лучше для поиска N-ого элемента, чем nth-child в CSS

В CSS есть псевдокласс :nth-child() — он находит один или более элементов, основываясь на их позиции среди группы соседних элементов. ©

Но у него есть ряд минусов:

не срабатывает в firefox (даже когда в хроме всё нормально);
срабатывает с оговорками — и поэтому xpath выражение для поиска будет лучше.

Давайте посмотрим на примере.

Создадим такой html-файл (можно сделать текстовый файлик и потом переименовать расширение в «.html»):

<html>
<body>
<div attr='1'>Блок 1</div>
<p>Блок 1</div>
<div attr='2'>Блок 2</div>
<div attr='3'>Блок 3</div>
</body>
</html>

Открываем файлик в хроме (это важно!).

А теперь попробуем найти второй div. Попробуем через XPath:

//div[2]

Всё работает! Найдет один элемент, второй по счету div:

Теперь попробуем через CSS:

четверг, 1 декабря 2022 г.

Телеграм бот как помощь в воспроизведении багов (видео)

Ссылка на youtube

Уже опубликовано видео моего доклада с SQA Days 30!

Напомню его аннотацию =)

Телеграм-бот как помощь в воспроизведении багов
Что делать, если заказчик нашел ошибку в системе? Воспроизвести локально, написать автотест, отдать разработчику. Вроде несложно. Но что, если у заказчика ошибка есть, а у нас нет? То есть проблема кроется в хитрой комбинации исходных данных. Нужно разбираться, что именно могло повлиять.
Мы прошли длинный путь такой диагностики. Сначала собирали данные через SQL-скрипты, потом автоматизировали их и даже внедрили в систему. А потом упростили задачу разворачивания билда, делегировав это… Телеграм-боту!

четверг, 24 ноября 2022 г.

Как продумать тесты для автоматизации (в двух словах)

Продолжение статьи «Что такое автоматизация»

Не все можно автоматизировать. Не все нужно автоматизировать. Нельзя просто взять чек-лист ручного тестирования и все переложить на код.

Бывает, что автоматизировать этот функционал ОЧЕНЬ сложно. Разработка автотеста займет много времени, причем разработчика, а не тестировщика — это не окупится, быстрее проверить вручную.

Бывает, что чек-листов у вас очень много. Тогда надо выбирать те, которые нужно автоматизировать в первую очередь. По каким принципам выбирать?

среда, 5 октября 2022 г.

1 автотест = 1 проверка (на примере Postman-a)

Вообще это правило и ручных тестов касается, но сегодня поговорим на примере автоматизации в Postman. Итак, общее правило тестов, особенно автоматических:

1 тест = 1 проверка

Почему именно так? Да потому что проще будет понять "почему всё упало".

Давайте посмотрим на примере Users. Дергаем метод http://users.bugred.ru/tasks/rest/getuser:

{

"email": "test_cu_11@mail.com"

}

* Email может меняться, так как система живая, данные создаются и удаляются.

Итак, мы хотим проверить ответ и пишем такой автотест:

воскресенье, 17 января 2021 г.

Unit, API и GUI тесты — чем отличаются

Давайте рассмотрим стандартную пирамиду автоматизации

Если говорить о программе:

UI-тесты — честные тесты, «как это делал бы пользователь» (они же GUI, graphical user interface)
API-тесты — опускаемся на уровень ниже, выкидывая лишнее.
Unit-тесты — тесты на отдельную функцию

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

Unit — тесты на отдельную мелкую функцию (посчитать одну ячейку отчета)
API — тесты на конкретный функционал, который состоит из отдельных функций (загрузить весь отчет)
GUI — честный тест через графический интерфейс, «как это делал бы пользователь» (открыть браузер, войти в систему, перейти в отчеты, и наконец вызвать отчет).

В качестве аналогии давайте рассмотрим создание платья. Вот я заказала себе платье по фигуре. Мастер выслушает мои пожелания, снимет мерки, а потом приступит за работу. Сначала он сделает выкройку и раскроит ткань. Если проверять каждую деталь, сравнивая с выкройкой — это будут юнит-тесты.

вторник, 12 января 2021 г.

Что такое автоматизация

Автоматизация — это написание автоматических тестов. Допустим, мы тестируем регистрацию на сайте ХХХ (подойдет практически любой сайт). Как мы это делаем?

Открыли браузер
Открыли нужный сайт
Нажали на кнопку «Регистрация»
Ввели тестовые данные
Нажали «Зарегистрироваться»
Убедились, что регистрация успешна — например, что появилась кнопка с личным кабинетом, а внутри ваше имя и емейл.

Эту процедуру надо повторить N раз. Разные имена, пароли, емейлы... Если вы все это делаете сами — это ручное тестирование. Автоматизация — когда это делается автоматически роботом. Один раз написали скрипт, а дальше он сам все проверяет.

Конечно, не все так просто — иначе ручное тестирование было бы не нужно. Робот — довольно тупое существо. Ему что скажешь делать, то он делать и будет. А значит, для того, чтобы попивать кофеек, нужно:

Продумать тесты для автоматизации.
Расписать их по шагам. ОЧЕНЬ подробно. Вот многие не любят тест-кейсы за их очевидность «какую кнопочку нажать», а тут именно так и надо.
Написать скрипт, который будет этот тест выполнять.
Поддерживать автотесты.

Разберемся с каждым пунктом по отдельности в следующих статьях :)

PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков

воскресенье, 3 мая 2020 г.

Задание по регулярным выражениям от Егора

Это мощная и хитрая задача с подколками. Идеальна для проверки знаний по регуляркам. Автор — мой коллега Егор Симонов, крутой технический специалист.

Если хотите обучить сотрудника регулярным выражениям, дайте ему:

Книгу Бена Форта — «Регулярные выражения 10 минут на урок»
Задачку от Егора

У нас на работе ровно так и делают

Когда я пришла в ХФЛабс, мне сказали к концу испытательного срока сдать Егору задачи по SQL и регулярным выражениям. На тот момент я немного знала SQL — в реальной жизни не применяла, но меня программист научил всяким джойнам. Регулярки не знала вообще.

И вот мне книжку дали, я ее честно прочитала. Читается книга легко. Повторяешь все за автором — вообще элементарно! Так что «фигня вопрос, sql знаю, регулярки тоже, успею!». Откладывала задания, пока до делайна не осталась неделя. Или две? Не помню точно, помню только, что не успела :)

понедельник, 2 сентября 2019 г.

Что такое framework? Объяснение для новичков

Ссылка на youtube

Мне тут ютуб интересный видосик подсунул. Посмотрела, оценила, рекомендую! Автор — Сергей Немчинский. Разработчик, спикер конференций, владелец тренингового центра по разработке.

А вот объяснение «что такое framework» нужно не только разработчикам, но и тестировщикам! Буквально пару дней назад в чатике моей школы для начинающих тестировщиков спрашивали, что это значит.

Так что же такое framework

Дальше идет мое объяснение, а не пересказ видео, ибо «зачем??»

Можно писать весь код программы самому с нуля. Да, конечно. А еще можно вырастить дерево, самому его спилить, обработать и смастерить табуретку. Или пойти в магазин и купить готовую. Что проще, лучше и быстрее?

А если вам нужен молоток? Это еще и металл обрабатывать надо! Можно самому, но получится намного хуже, чем если взять готовое. Ведь первый блин всегда комом. Что-то не учел и все, продукт не работает!

Также и в разработке. Если есть спрос на функционал — его проще написать один раз. Тщательно протестировать ОДИН РАЗ, а потом переиспользовать. Так появились библиотечки и фреймворки. Граница между ними бывает размытой, ведь и то, и другое — уже написанный вместо тебя код. А разница в чем:

Библиотека (Library) — Вызывается внутри кода. Бизнес-логика твоя, но какой-то функционал подключаешь из библиотечки (забор данных из файла, drag&drop...)
Фреймворк (Framework) — Сам вызывает твой код. То есть это уже готовый код, который ты лишь слегка расширяешь под свои нужды.

Фреймворк вызывает твои кусочки кода, но они оформлены согласно спеццификации фреймворка.

Чем фреймворк отличается от программы

Программа — конечный продукт
Фреймворк — можно и нужно расширять

А как расширяется тестовый фреймворк? Вот, например, в folks есть готовый тестовый фреймворк, который умеет читать эксельки, заполнять по ним БД и проводить по этой базе поиск.

Фреймворку нужно, чтобы в тесте была экселька, какие-то конкретные колонки в ней, xml-файл, где указано «что искать и что должно вернуться». Но сами эксельки пишет тестировщик. Вот вам и функция расширения.

Фреймворку абсолютно начхать, какие данные внутри экселек. Он делает свою работу, ему главное, чтобы были нужные файлы. И он будет ругаться, если вместо них получит что-то еще. Но наполнение данных — это не его забота. Это забота тестировщика, который расширяет фреймворк своими автотестами.

PS — статья написана в помощь студентам моей школы для начинающих тестировщиков. В ней в том числе есть задание пощупать folks с готовым тестовым фреймворком, так что заходите, у нас весело!

воскресенье, 14 июля 2019 г.

Чит-лист для создания Xpath

Ссылка — https://devhints.io/xpath

Ссылку подкинули в флудильне выпускников как "полезняшку по Xpath". Ну а я просто решила сохранить полезняшку в блоге ¯\_(ツ)_/¯

PS: сохранила также ссылку на Testbase в навыке автоматизации, теперь не потеряется!

пятница, 25 января 2019 г.

Все ругают самописные тестовые фреймворки. А мы своим довольны

Ссылка на Хабр

Коллеги с соседнего проекта написали статью про один из наших тестовых фреймворков. Очень круто все описали!

О том, как развивались автотесты продукта Фактор, где сейчас этих автотестов тысячи. Да, это бывает по тысяче строк в одном файле, казалось бы «фи, скукота, я то думал, тысяча строк юнит-тестов». Но нет, мы пришли к DDT и тому, чтобы один раз написать фреймворк, а потом получать «один тест = одна строка во входном и выходном файле».

Ребята рассказали про заглушки внутри тестов, учет статуса задачи в JIRA и про другие примочки. Это круто, я когда-то хотела про каждую отдельный постик написать. А, может, еще и напишу, но уже сейчас можно посмотреть «а как у них это работает».

Может, даже идеи для ваших автотестов появятся. Потому что с JIRA мы круто сделали, я считаю. Прикиньте, тест вроде заскипан (падение игнорируется при прогоне), но, если вдруг заработал сам по себе, система сигнализирует об этом. А то бывает же, что делаешь другую задачу и тут, опа-опа, что-то еще починил ¯\_(ツ)_/¯

Так что приятного чтения!

См также:
Автотесты на уровне API для Java-приложений — про тесты на моем проекте
Больно пилить автотесты? Проси улучшать! — и как мы их улучшали

среда, 23 января 2019 г.

Expected «null», but was «null» в автотестах

Как мне нравится, когда автотесты падают на null и пробелах))) Первый раз при отладке такого теста ты вообще не понимаешь, что не так. Потом запоминаешь...

Собрала несколько любимых примеров из жизни, зацените:

Null

Допустим, должна быть пустая строка, а ты туда текстом null вписал. Тест падает:

expected «null», but was «null»

Угадай, что не так ¯\_(ツ)_/¯

вторник, 3 апреля 2018 г.

Folks — open-source проект с API-тестами на Java

Ссылка на youtube

Знакомьтесь, это Folks! Проект с открытым исходным кодом, сделанный на основе реальной системы. И в этом его ценность — это не просто абстрактный тестовый проект, написанный под студентов, неприменимый в реале.

Ссылка на документацию — https://testbase.atlassian.net/wiki/spaces/FOLKS/overview (доступна без авторизации)

Что интересного есть в проекте:

Требования на поиск — можно проверить свои познания в тест-дизайне и тест-анализе.
Фреймворк автоматизации — самое важное, что дает система. Возможность пощупать реальный фреймворк автоматизации. Увидеть, что автотесты — это не обязательно чистый код, это могут быть просто... Эксельки. Да-да!
Код есть, GUI нет — тоже важное свойство. Если вы хотите проверить какую-то теорию, то только через автотесты. Для тестировщика важно уметь придумывать тесты ДО того, как их можно будет пощупать, но это тяжело. Осилите?))
SOAP и XSLT — добавили в систему недавно, чтобы поиск можно было дергать и по SOAP в том числе. Сделано под будущий курс интеграционного тестирования, но пользоваться можно уже сейчас!

Тут и свои навыки тест-дизайна можно проверить, и баги в коде найти, и поавтоматизировать попробовать... Welcome!

См также:

Автотесты на уровне API для Java-приложений — доклад с SQA Days, где я рассказываю принципы, заложенные в тестовый фреймворк автоматизации.

В дальнейшем на примере фолкс я планирую рассказать для своих студентов, что такое система контроля версий и все такое.

Также буду делать дополнительные обучающие видеоролики, чтобы еще проще было начать автоматизировать в фолкс. Буду показывать, как это все делается. Ждите

среда, 11 октября 2017 г.

Копипаста такая копипаста...

Выступаю в роли разработчика — у меня на входе есть табличка с данными, а мне надо их переложить в другую табличку в плоскую запись. Примерно вот так:

Мы уже решали задачку похожего плана, а править готовое всегда проще, чем писать с нуля ツ

Полезла в решение прошлой задачи. Кручу, верчу select.
Тут замечаю — одно поле не селектится. В описании есть, в селекте нету. Уточняю — так и должно быть? Нет.

Хожу, смеюсь — делаю одну задачу, нахожу баги в другой!

Тут коллега подмечает — так ту, другую, ты же тестировала. Хм. И правда, я. Может, автотест не написала? Написала!

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

Открываю сейчас свой же тест. На входе field_1 = true, а на выходе field_1 = false. Зато тест зелененький!

Так что вы это там... Поаккуратнее с копипастой =)

среда, 28 декабря 2016 г.

Больно пилить автотесты? Проси улучшать!

Есть у нас в базе таблица, где хранится плоская запись. Точнее, хранилась, теперь там BLOB. Но не суть. В плоской записи 600 полей, которые называются field_1, field_2... field_600.

В коде зашит меппинг этих филдов на нормальные названия:

<entry key="cat" value="6"/>
<entry key="dog" value="13"/>
...
<entry key="human" value="15"/>

Файлик с меппингом назовем... Ну, допустим, р2о (plain to object). Он с хитринкой — так как в java отсчет начинается с нуля, а не с единицы, то к value надо было добавить 1, чтобы получить field в базе. Вот, например, key="cat" → в базе это был field_7.

Сами по себе поля field_* проблем не приносили, потому что обычно база заполнялась из файликов, а дальше уже темная магия все разруливала и сразу красота! А вот в автотестах всегда черт ногу сломит. Открываешь тест, тебе надо поправить фамилию. А у тебя на входе эти 600 полей. И в каждой сборке свой меппинг. Где-то фамилия — это номер 2, где-то номер 4, где-то 6, и так далее.

И вот ты такой открываешь тест, который надо поправить. Открываешь р2о. Находишь там нужное тебе поле. Сидишь, тупишь, вспоминая, надо от value отнять единичку или прибавить... Правишь тест. Профит! Но затупы на «отнять или прибавить» особенно раздражали.

А уж если кто-то внес изменения в р2о! Изменил одно поле? Все, гудбай все тесты → рассыпались как карточный домик, надо ходить и уныло актуализировать. Так как актуализацией занималась я, то и страдала тоже я

Страдала я громко, плакалась на митингах и в чатике:
— Опять тесты развалились из-за р2о. Давайте сделаем так, чтобы они не падали??
— Оля, отстань! Зачем тратить на это ресурсы? Не так уж часто р2о меняется. Один раз в год подняла тесты, это проще, чем тратить пару дней разработчика.

В общем, в случае пожара — горите.

Тебе тяжело? Ты и страдай

суббота, 21 февраля 2015 г.

Лайфхак. Как уговорить разработчиков начать писать автотесты

Обсуждали в чате со студентами, как писать автотесты. После гугления возникает мнение, что начинать надо с Selenium и GUI тестов. Но это же не так. Какой в них смысл, если ничего нет на уровне ниже?

Начинать надо с unit-тестов, которые пишут разработчики. Потом писать тесты на уровне API. Чем они хороши, я рассказывала в этом докладе. А потом уже заавтоматизировать через GUI минимальную часть. Но тут возникает проблема...

Проблема

Unit-тесты у нас никто не пишет, а к мнению джуниоров мало прислушиваются.

Особенно разработчики. Как их убедить начать?

Лайфхак

Лайфхак подходит только в ситуации мальчик-разработчик и девочка-тестировщица!

А вы выберите самого умного разработчика (или самого дружелюбного, по ситуации), принесите ему блинчиков на масленицу и скажите:

— Ох, Вася, как было бы здорово юнит-тестами наше приложение покрыть! Ты такой умный, помоги, пожалуйста, начать... Вот ты мне приложение отдаешь, руки только через полдня до него доходят, а там баг! Мог бы фидбек быстрее получать, будь у тебя тесты (объясняете проблему в его мире)...

Главное — похвалить! И накормить

И облегчить его боль, если это возможно. Например, попросить начать писать unit-тесты, то есть сделать фреймворк и 1-2 теста. И отдать в таком виде тестировщику на пополнение. Да, придется вникать, как тесты пишутся, ну и что? Прокачаете скилы автоматизации, круто же!

И разработчику не сильно внапряг заниматься "не своим делом", один тестик много времени не займет. И вообще не надо разработчикам давать тестами код покрывать, знаем мы их "покрытие" (поучительная история).
.
Написали unit-тесты, просите фреймворк для API. Джуниор его полгода будет пилить, а разработчик за день сделает. Особенно если никто не будет его просить еще и тесты туда добавлять

Не верите, что лайфхак работает? Это вам еще везет, надо просить потратить рабочее время на рабочие же нужды. А мне для того самого доклада про API-тесты нужно было попросить сделать мне приложение тестовое во внерабочее время...

Так что я к нему пришла с вкусняшками:

— Здравствуй, Васенька! Хочешь конфетку?
— Ух ты, спасибо! *довольный, жует*
— Слууууушай, я тут хочу на конференции выступить... *ручки за спину, взгляд — сама скромность*
— Ну и что?
— А было бы так здорово показать им реальный код! Представляешь, скачал — и оно все само запустилось! У нас же такие классные тесты, я бы вот это и это показала...
— *Взгляд становится настороженным* А от меня ты что хочешь?
— А можешь сделать мне такое тестовое приложение? Я вообще не знаю, с чего начать! А ты у нас ТАКОЙ умный, любую сложную задачу как орешки щелкаешь! (это правда, он умеет за пару часов сделать то, что казалось невозможным)
— *Гордо приосанивается* Ну да, это так.
— Ну вот! Я уверена, что у тебя такая задача буквально часик займет, ты же так быстро все делаешь! А я одна не справлюсь (((( Помоги мне, пожалуйста! А я тебе котлеток сделаю))))
— Ну лааадно, давай посмотрю...

Приложение он мне написал

Котлетки свои тоже получил ))) Тут главное было — подойти заранее, я пришла с просьбой за полгода до выступления и где-то через месяц у него дошли руки сделать мне folks. Так что лайфхак вполне реальный

После обсуждения лайфака в чате студенты попросили: Ольга, пишите еще в блог такие небольшие лайфхаки от себя, мелочь, а джуниорам полезно и не все очевидно!) Я бы с удовольствием читала.

Так что вот — пишу! Появился лейб "лайфхак", ну и в названии будет мелькать, если влезет)))

четверг, 27 февраля 2014 г.

Первый автотест - куда уходит время?

Сразу оговорюсь - я пишу о своей ситуации, когда тестовый фреймворк (API-тестов) уже готов. Задача тестировщика сводится к его небольшому расширению на свой модуль. Потому что про то, как написать первый автотест на каком-нибудь Selenium для GUI тестов, я пока даже заикаться не хочу, это еще дольше!

Только, пожалуйста, без холиваров. Конечно, через Record And Play можно тест сваять за минуту, но мы все-таки стараемся писать такие тесты, которые потом будет удобно поддерживать. А это уже сложнее.

Итак, когда перед нами стоит задача - создать новую сущность, мы сразу прикидываем, сколько времени нам понадобится. Допустим, заложили 1-2 дня на все-провсе, проверить вручную, написать автотесты итд.

При этом тесты тривиальные, фреймворк есть, а значит, написать тест (2 эксель таблички с состоянием БД) занимает ну минут 5-10 с отладкой. В идеале, ага.

А теперь посмотрим, как это происходит в реальной жизни. Конечно же, на конкретном примере.

воскресенье, 27 октября 2013 г.

Тестовых инструментов на самом деле больше, чем ты думаешь

Продолжу практику выписывания интересных советов из книжки Lesson Learned in Software Testing (№ 141), в вольном переводе:

You may have more test tools than you realize.

Секундомер - один из примеров отличного инструмента для тестирования! Измерение времени отклика системы - это одна из важнейший активностей тестировщика. Секундомер прост в использовании, гибкий и точный. Многие тестировщики и разработчики уверены, что все это лучше как-то заавтоматизировать, подключиться к системным часам и прочее... Но использование простого секундомера зачастую является лучшим выбором для black box testing.

A test tool does not have to be labeled "Test tool". Testers have dozens of other tools useful.

Инструменты для тестирования далеко не всегда так и называются - "инструменты для тестирования". Тестировщик может найти десятки инструментов с другими названиями, которые будут ему очень даже полезны. Многие из них дешевые или вообще бесплатные. Вот некоторые из них:

Disk imaging tools - Позволяет быстро восстановить систему к определенному состоянию.
Dependency walkers - Отображает dynamic libraries (боюсь, по русски это прозвучит менее понятно ), которые использует приложение.
File scanners - Ищет и записывает, какие системные файлы были изменены.
Memory monitors - Следит за утечками памяти.
Macro tools - Делает простым повторение рутинных задач.
"Little languages" such as Sed, Awk, Grep and Diff - Этот инструмент дает возможность очень просто автоматически редактировать файлы, извлекать данные, искать какую-то информацию или просматривать diff (разница между двумя файлами). Первоначально разрабатывался под Unix, но сейчас такой инструмент есть практически на всех платформах.

----------------------------------------------------------------------------------------------

От себя хочу добавить, что, действительно, на форумах часто спрашивают "Ребята, а какие есть инструменты у тестировщика?". Да любые! В первую очередь мозг

Мы как разработчики, им же нужен один блокнот. Ну IDE сильно жизнь упрощает. Но это же не значит, что они только IDE и используют. Те же команды в Unix, те же макросы, те же скрипты, логи и т.д. и т.п.

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

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

Важным опытом является, пожалуй, именно знание того самого "Little languages". Ну просто потому, что это чаще всего пригождается в работе. Хотя, кому как. Ищите то, что будет именно Вам в тему!

воскресенье, 30 июня 2013 г.

Во время автоматизации ты ищешь баги или теряешь время?

Очередной совет из книжки Lesson Learned in Software Testing, № 111, оставил очень и очень спорное впечатление. В вольном переводе он звучит так:

Примите во внимание, что во время автоматизации вы не ищите баги.

Когда вы рассчитываете стоимость автоматизации, мы предполагаем, что вы фокусируетесь на непосредственной стоимости. А что еще вы могли бы сделать в то время, которое вы потратили на автоматизацию? Какие тесты вы не прогнали? Какие баги вы не нашли?

Во многих проектах непосредственно автоматизация означает приостановку тестирования и нахождения ошибок. Эта проблема является одним из аргументов использования техник "автоматизации заранее (авансом)", которые позволяют вам подготавливать автоматизированные тесты перед тем, как приложение будет выдано в тестирование. Например, data-driven strategy позволяет описывать тест-кейсы заранее. Вот в этом случае автоматизация как раз не приостанавливает поиск ошибок и даже ускоряет процесс тестирования и поиска ошибок.

В целом, зерно истины здесь есть. Действительно, автоматизация стоит колоссальных усилий. Особенно на этапе проб и ошибок, первых скриптов итд. Хорошо, когда приходишь в компанию - а там уже налаженный процесс. А если все не так?

И действительно, новомодные подходы типа TDD очень крутые и дают огромный выигрыш. НО. Я не согласна с тем, что автотесты на готовую систему не ищут ошибок.

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

На простых GUI тестах! А все потому, что, написав скрипт 1 раз, очень легко его повторить, немного видоизменив. Например, в поле "индекс" можно ввести 6 чисел, чтобы система посчитала ввод корректным.

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

А писать это в тестах весело и прикольно! И тут, внезапно, находятся баги. Как на тестах, которые когда-то проходил вручную, потом подзабил, так и на тех, о которых додумался только сейчас. Или на что внимания раньше не обращал.

В общем, в тестах ты ищешь каждую мелочь, обращаешь внимание на малейшие детали - ведь робот тупой, что ты скажешь проверять, то он и проверит, поэтому ты выполняешь тест вручную, наблюдаешь за результатом и оп-па! Оно, оказывается, давно не работает!

В общем, я за TDD и все такое, но категорически не согласна с тем, что во время простой GUI автоматизации баги не ищутся. Ищутся! Просто тестирование идет медленнее.

среда, 29 мая 2024 г.

воскресенье, 26 мая 2024 г.

четверг, 1 декабря 2022 г.

Телеграм-бот как помощь в воспроизведении багов

четверг, 24 ноября 2022 г.

среда, 5 октября 2022 г.

воскресенье, 17 января 2021 г.

вторник, 12 января 2021 г.

воскресенье, 3 мая 2020 г.

понедельник, 2 сентября 2019 г.

Так что же такое framework

Чем фреймворк отличается от программы

воскресенье, 14 июля 2019 г.

пятница, 25 января 2019 г.

среда, 23 января 2019 г.

вторник, 3 апреля 2018 г.

среда, 11 октября 2017 г.

среда, 28 декабря 2016 г.

суббота, 21 февраля 2015 г.

Проблема

Лайфхак

четверг, 27 февраля 2014 г.

воскресенье, 27 октября 2013 г.

воскресенье, 30 июня 2013 г.

среда, 29 мая 2024 г.

воскресенье, 26 мая 2024 г.

четверг, 1 декабря 2022 г.

четверг, 24 ноября 2022 г.

среда, 5 октября 2022 г.

воскресенье, 17 января 2021 г.

вторник, 12 января 2021 г.

воскресенье, 3 мая 2020 г.

понедельник, 2 сентября 2019 г.

воскресенье, 14 июля 2019 г.

пятница, 25 января 2019 г.

среда, 23 января 2019 г.

вторник, 3 апреля 2018 г.

среда, 11 октября 2017 г.

среда, 28 декабря 2016 г.

суббота, 21 февраля 2015 г.

четверг, 27 февраля 2014 г.

воскресенье, 27 октября 2013 г.

воскресенье, 30 июня 2013 г.