автоматизация тестирования огурцом
•Télécharger en tant que PPTX, PDF•
0 j'aime•251 vues
Доклад на GDG Almaty 24 июня 2017
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à автоматизация тестирования огурцом
Similaire à автоматизация тестирования огурцом (20)
автоматизация тестирования огурцом
- 1. Автоматизация тестирования Огуречные технологии (Cucumber)
- 2. Вадим Глебов Веб разработка — более 15 лет, Разработка ПО — более 20 лет, Управление разработкой — более 10 лет, Обучение и консультирование — более 10 лет Профиль: https://www.linkedin.com/in/vglebov/
- 4. У кого есть автоматизированные тесты?
- 5. У кого тесты выполняются от лица пользователя?
- 6. Для чего нужно автоматизированное тестирование в процессе разработки? ● Измерять качество, увеличивать качество ● Бороться с регрессией ● Снижать уровень стресса у разработчиков ● Обеспечивать возможность рефакторинга ● Обеспечивать быструю обратную связь о состоянии кода ● Формализовать требования в итеративной разработке в виде сценариев тестирования как часть критериев готовности задачи
- 7. Кто тестирует ПО? * разработчики * владелец продукта (аналитик, руководитель проекта) * пользователи
- 8. А как же тестировщики?
- 9. Выходит, что тестировщики не нужны? ● улучшения UI/UX ● распутывать сложные инциденты, ● перерабатывать сценарии тестирования, рефакторить их, ● помогать разработчикам с автоматизацией, ● придумывать новые способы тестирования, ● ускорять прохождение тестов. !!! Но ни в коем случае не заменять автоматизированные тесты !!!
- 10. А куда девать тестироващиков после автоматизации тестирования? ● Аналитик требований ● Эксперт по качеству ● Разработчик
- 11. А сколько нужно тестов? ● 1 ● 10 ● 100 ● 1000 ● ...
- 12. А нужно ли тестировать всю функциональность? Только критичные функции Все успешные сценарии Все неуспешные сценарии Все регресии
- 13. Может ли автоматизация тестирования заменить ручные тесы? Компьютер тупой, может не заметить косяки Разработчик обязательно должен проверить новую функциональность самостоятельно Перед релизом нужно самостоятельно убедится, что обновленная функциональность исправка, а старую проверят тесты
- 14. тестирование внедряют в крупных проектах, а наш мелкий автотесты это дорого Для внедрения тестов нужны специально обученные люди Отсутствие видения и нужных навыков у разработчиков. Технические трудности Какие основные трудности при внедрении тестирования?
- 15. Ruby - Cucumber, PHP - Behat, Java - Cucumber-jvm, ios, android - Calabash, Python - Lettuce, C# - Specflow, 1C - Vanessa-behavior С чего начать?
- 16. Как выглядит сценарий на Gherkin?
- 17. Что под капотом?
- 18. ● Книга про Огурец https://pragprog.com/book/hwcuc/the-cucumber-book ● Книга рецептов https://pragprog.com/book/dhwcr/cucumber-recipes ● Сайт Огурца https://cucumber.io/ ● Книга "как тестируют в гугл" https://www.ozon.ru/context/detail/id/24868052/ ● Огурец для 1С http://vanessa.services/docs Что почитать?
- 19. Aslak Hellesøy
- 22. Один из сценариев показанный на видео
Notes de l'éditeur
- Всем привет! Меня зовут Вадим Глебов, я разработчик программного обеспечения. Я пришел поговорить на одну очень важную для меня тему - автоматизация тестирования. Я давно уже сделал для себя вывод, что без автоматизированных тестов качества ПО добиться практически невозможно. Тесты меня много раз спасали. Усилия затраченные на внедрение всегда окупались. Однако многие компании и команды еще не внедрили у себя автоматизированные тесты Давайте поговорим об этом
- В своем выступлении я ориентируюсь в первую очередь на разработчиков ПО и их руководителей. Хочу немного больше узнать о вас. Кто из присутствующих разрабатывает ПО в данный момент или проходит стажировку? Кто руководит разработкой? Нужно ли тестировать ПО? Риторический вопрос Есть, кто считает что не нужно? Почему не нужно?
- У кого в проекте, продукте есть автоматизированные тесты? А у кого автоматизированных тестов нет? А надо?
- Тесты бывают разные: модульные, функциональные, интеграционные, приемочные, smoke Автоматизация тестирования быстро развивается и единой, понятной классификации тестов нет,, это сильно сбивает с толку. В Гугл, например, ввели свою классификацию тестов: маленькие, средние, большие Тесты можно условно разделить на две группы: тесты на некоторый отдельный механизм системы (модульные, интеграционные, функциональные) Имитация поведения пользователя, выполнение некоторых сценариев через пользовательский интерфейс (приемочные) У кого в проекте, продукте применяются тесты от лица пользователя? Сколько сценариев автоматизировано? Какие инструменты используете?
- Что такое качество ПО? Степень соответствия реализации требованиям Превзойденные ожидания пользователей Отсутствие дефектов Стабильная работа без сбоев Грамотная архитектура Чистый код Все это аспекты качества невозможно достигнуть без автоматизации тестирования Что такое регрессии все знают? Это когда вы починили дефект, проверили, поставили в продакшен, прошло время и дефект вернулся. Чтобы проверять регрессии создаются отдельные сценарии тестирования, которые убеждаются, что этот дефект отсутствует. Уровень стреса Когда тестов нет разработчик часто чувствует себя при внесении изменений в коде, как сапер на минном поле Ум анализирует последствия внесения изменений, не может проследить все цепочки выполнения и появляется страх Иногда приходится действовать наугад. Проблема в том, что обратная связь очень длинная. Если при внесении изменений ошибся, то ошибка может проявится через дни или недели или месяцы, когда ты уже забыл зачем менял код. Вникать в код по новой уходит всегда много времени, ведь он рефакторится по той же самой причине - очень низкая скорость обратной сязи. Когда в проекте автоматизированные тесты правильно внедрены покрывают, то обратная связь становится очень быстрой. Страх уходит, разработчики начинают делать рефакторинги осознанно. Формализация требований Если к традиционному описанию задачи приложить сценарий тестирования, то при прочтении таких требований понимание конечного результата по задаче многократно увеличивается. Выполнение сценариев является одним из критериев готовности. Я как разработчик использовал этот прием для улучшения качества своей работы: Читаю описание задачи Составляю сценарии тестирования, Добавляю их к описанию задачи Отправляю на утверждение аналитику или владельцу продукта И не дожидаясь ответа приступаю к разработке В процессе реализации я автоматизирую составленный сценарий Когда я закончил, демонстрирую результат, который соответсвует составленным сценариям Если есть замечания, вношу их в сценарии, затем в код В некоторых проектах владельцы продукта осваивали язык сценариев и начинали добавлять к требованиям пользовательские сценарии Скорость и качество коммуникации растет, качество требований растет, меньше переделок, меньше разговоров.
- Кто тестирует ПО? разработчики вносят изменения в код и прежде чем сказать я закончил, нужно убедиться, что ничего не сломал, а для этого нужно все протестить. Протестировать все функции системы. Когда система маленькая это сделать нетрудно, Однако на ручное тестирование ИС требуются часы, дни, недели, месяцы. Тестирует владелец продукта (аналитик), ведь он делает приемку и принимает решение о выпуске ПО в продакшен Пользователи, идеально, когда пользователи не находят дефектов. Кто должен больше всего заботится о тестировании? Разработчики. Так получилось, что разработчики массово уходят от ответственности за качество, прикрываясь различными оправданиями. Ребята, давайте перестанем себя обманывать и признаем, что мы отвечаем за качество в первую очередь!
- Мой опыт использования ручных тестировщиков показал, что они плохая замена автоматизированным тестам. Компьютер не устает, у него не замыливается глаз.
- Так и есть не нужны. Нужны эксперты по качеству, которые будут заниматься творческой работой !!! Но ни в коем случае не заменять автоматизированные тесты собой. Чтобы превзойти ожидания пользователя система должна быть удобной для использования. Одна и та же функциональность может быть представлена в пользовательском интерфейсе совершенно по-разному. Кто-то должен позаботится об удобстве пользователей, практика показывает, что разработчики не справляются с такой задачей, им нужна помощь. Инциденты В работе любой системы происходят инциденты, понимание и устранение их причин это путь увеличения качества. Рефакторинг С развитием системы развивается язык тестов, сценарии нужно актуализировать, переписывать более понятным языком, устранять дублирование. Уменьшать количество тестов без потери качества тестирования. Скорость Чем быстрее обратная связь от вносимых разработчиком изменений, тем ниже стресс, медленные нестабильные тесты могут погубить эту обратную связь. Поэтому кто-то должен заботится о скорости и стабильности. Чем сложнее система, тем актуальнее встает вопрос скорости тестирования.
- Переквалифицировать в аналитов требований, пусть проверяют требования на входе, перед разработкой, тестировщики этим и так занимаются, только после разработки, если дать им возможность анализировать до, то они смогут выявить нестыковки в требованиях и устранить их до разработки. Переквалифицировать в экспертов по качеству.
- Для проверки критичного функционала достаточно написать 1 длинный сценарий, который охватит весь критичный функционал. Если у вас будет всего один правильный тест, то он будет уменьшать риски попадания дефектов в продакшене в критичном функционал. Создание 1 теста не выглядит слишком дорогим, если он будет спасать от ошибок На практике я встречал системы с количеством тестов более 500, которые около 12 часов. Чем больше тестов, тем дольше они выполняются
- Создание тестов процесс не быстрый, поэтому нужно составить план по покрытию системы тестами и приоритезировать его. В первую очередь нужно тестировать те функции, что являются критичными для конечного пользователя.
- Может ли автоматизация тестирования полностью заменить ручные тесты Нет, конечно. Ручное тестирование имеет свое место, автоматизация тестирования сильно сокращает потребность в ручном тестировании, но не убирает ее полностью, компьютеры еще не настолько умны, чтобы замечать косяки верстки, неудобство интерфейса, опечатки и т.д. Автоматизация сильно уменьшает боль от механического повторения одних и тех же тестов от версии к версии ПО.
- Основное препятствие неверие в успех, страх неудачи Для тех, кто решился большое препятствие - отсутствие поддержки в команде. Если тесты внедрять, то писать, запускать и поддерживать тесты должны научиться все члены команды. Если тесты поддерживает только один человек в команде, то часто бросает этим заниматься. Чинить сломавшийся тест должен тот кто сломал, а не тот кто написал. Много технических трудностей, но они все преодолимы, если не сдаваться
- Выбрать подходящий инструментарий https://cucumber.io/docs Прочитать тематическую литературу https://pragprog.com/book/hwcuc/the-cucumber-book или погуглить статьи, их много Пройти туториал Написать первый тест к своей системе