Ищем QA-инженера (ручное тестирование веб- и мобильных приложений):)
Компания: Digital Agro
З/п до 170 000 net + квартальная премия 30% по итогу KPI
Формат работы: гибрид, офис (Москва)
Оформление по ТК РФ;
Компания "Digital Agro" предоставляет фермерам AgTech инструменты и сервисы, которые позволяют принимать решения на основе больших данных, повышать эффективность и обеспечивать устойчивость бизнеса.
Обязанности:
Проведение ручного функционального тестирования различных продуктов (Web, iOS, Android) в области цифровизации сельского хозяйства
Проведение конфигурационного, регрессионного, интеграционного тестирования
Анализ обнаруженных дефектов и документирование их в Jira
Формирование, поддержка и развитие модели регрессионного тестирования в системе Allure TestOps
Выделение и подготовка тестовых сценариев для последующей автоматизации
Требования:
Опыт в тестировании ПО от полутора лет
Глубокое понимание SDLC, принципов работы по SCRUM
Владение основными техниками тест-дизайна
Опыт в формировании регрессионной тестовой модели в любой TMS, понимание её ценности
Опыт тестирования REST API и Web-приложений обязателен
Опыт работы с Postman, DevTools
Знание SQL на уровне простых JOIN операций
Понимание механизмов взаимодействия компонентов в клиент-серверных приложениях на основе микросервисной архитектуры
Работа строго в офисе в Москве
Будет плюсом:
Опыт тестирования мобильных приложений для iOS и Android
Опыт автоматизации тестирования Web-приложений (Java + Selenium + REST Assured)
Опыт работы с Linux, Docker, Jenkins, Allure TestOps, PostgreSQL
Условия:
Новый MacBook Pro 16
Шикарный офис в Москва-Сити
Квартальные премии по результатам работы
Работа по Agile
Возможность развиваться в автоматизации тестирования на Java
Если вам интересно обсудить подробности вакансии, напишите рекрутеру Александре (TG: @AlexandraAndrianova (https://vk.com/id256314985), телефон: +79185243149, линкедин: https://www.linkedin.cn/in/александра-андрианова/ ).
Компания: Digital Agro
З/п до 170 000 net + квартальная премия 30% по итогу KPI
Формат работы: гибрид, офис (Москва)
Оформление по ТК РФ;
Компания "Digital Agro" предоставляет фермерам AgTech инструменты и сервисы, которые позволяют принимать решения на основе больших данных, повышать эффективность и обеспечивать устойчивость бизнеса.
Обязанности:
Проведение ручного функционального тестирования различных продуктов (Web, iOS, Android) в области цифровизации сельского хозяйства
Проведение конфигурационного, регрессионного, интеграционного тестирования
Анализ обнаруженных дефектов и документирование их в Jira
Формирование, поддержка и развитие модели регрессионного тестирования в системе Allure TestOps
Выделение и подготовка тестовых сценариев для последующей автоматизации
Требования:
Опыт в тестировании ПО от полутора лет
Глубокое понимание SDLC, принципов работы по SCRUM
Владение основными техниками тест-дизайна
Опыт в формировании регрессионной тестовой модели в любой TMS, понимание её ценности
Опыт тестирования REST API и Web-приложений обязателен
Опыт работы с Postman, DevTools
Знание SQL на уровне простых JOIN операций
Понимание механизмов взаимодействия компонентов в клиент-серверных приложениях на основе микросервисной архитектуры
Работа строго в офисе в Москве
Будет плюсом:
Опыт тестирования мобильных приложений для iOS и Android
Опыт автоматизации тестирования Web-приложений (Java + Selenium + REST Assured)
Опыт работы с Linux, Docker, Jenkins, Allure TestOps, PostgreSQL
Условия:
Новый MacBook Pro 16
Шикарный офис в Москва-Сити
Квартальные премии по результатам работы
Работа по Agile
Возможность развиваться в автоматизации тестирования на Java
Если вам интересно обсудить подробности вакансии, напишите рекрутеру Александре (TG: @AlexandraAndrianova (https://vk.com/id256314985), телефон: +79185243149, линкедин: https://www.linkedin.cn/in/александра-андрианова/ ).
Компания «Construction Solutions» на данный момент в поисках QA-инженера
Заработная плата до 180 000 руб до вычета НДФЛ
Формат работы: удаленная работа, но изредка нужно приезжать в офис (Москва)
Оформление по ТК
Construction Solutions разрабатывает сервис Live Commerce, помогающий ритейлерам и брендам продавать свои товары эффективнее. В качестве решения наш партнер получает себе мобильное приложение и web-виджет.
Требования:
- Опыт ручного и функционального тестирования Android и iOS-приложений от 2 лет;
- Понимание клиент-серверной архитектуры;
- Опыт тестирования API;
- Понимание жизненного цикла разработки;
- Понимание методологий тестирования;
- Опыт создания тестовой документации (тест-кейсы, чек-листы);
- Хорошие коммуникативные навыки, умение работать в команде.
Команда
Product Manager
Backend разработчики (Java)
iOS разработчики (Swift)
Android разработчики (Kotlin)
QA инженеры
Дизайнеры (Figma)
Преимущества работы у нас:
😎 Команда топ-менеджмента - ex-(Rambler, Связной, Утконос, Burberry)
💰 Хорошее финансирование
👨💻 Разработка продукта с нуля, отсутствие легаси
🌎 Продукт ориентирован на международный рынок
🪜 Возможность карьерного роста
🏃♂ Отсутствие бюрократии, не медлим в принятии решений
🌃 Есть возможность работать в современном офисе в Москва Сити
☕️ Бесплатный кофе, чай
Если вам интересно обсудить подробности вакансии, напишите рекрутеру Александре (TG: @AlexandraAndrianova (https://vk.com/id256314985), телефон: +79185243149, линкедин: https://www.linkedin.cn/in/александра-андрианова/ ).
Заработная плата до 180 000 руб до вычета НДФЛ
Формат работы: удаленная работа, но изредка нужно приезжать в офис (Москва)
Оформление по ТК
Construction Solutions разрабатывает сервис Live Commerce, помогающий ритейлерам и брендам продавать свои товары эффективнее. В качестве решения наш партнер получает себе мобильное приложение и web-виджет.
Требования:
- Опыт ручного и функционального тестирования Android и iOS-приложений от 2 лет;
- Понимание клиент-серверной архитектуры;
- Опыт тестирования API;
- Понимание жизненного цикла разработки;
- Понимание методологий тестирования;
- Опыт создания тестовой документации (тест-кейсы, чек-листы);
- Хорошие коммуникативные навыки, умение работать в команде.
Команда
Product Manager
Backend разработчики (Java)
iOS разработчики (Swift)
Android разработчики (Kotlin)
QA инженеры
Дизайнеры (Figma)
Преимущества работы у нас:
😎 Команда топ-менеджмента - ex-(Rambler, Связной, Утконос, Burberry)
💰 Хорошее финансирование
👨💻 Разработка продукта с нуля, отсутствие легаси
🌎 Продукт ориентирован на международный рынок
🪜 Возможность карьерного роста
🏃♂ Отсутствие бюрократии, не медлим в принятии решений
🌃 Есть возможность работать в современном офисе в Москва Сити
☕️ Бесплатный кофе, чай
Если вам интересно обсудить подробности вакансии, напишите рекрутеру Александре (TG: @AlexandraAndrianova (https://vk.com/id256314985), телефон: +79185243149, линкедин: https://www.linkedin.cn/in/александра-андрианова/ ).
www.linkedin.cn
Sign Up | LinkedIn
500 million+ members | Manage your professional identity. Build and engage with your professional network. Access knowledge, insights and opportunities.
Андрей Квапил (@kvaps (https://vk.com/id342039346) на Хабре) создает платформы для автоматического управления инфраструктурой, участвует в open-source-сообществе, пишет статьи и выступает на конференциях.
В интервью Андрей рассказал, как прошел путь от эникейщика до Cloud-архитектора, почему для работы с Kubernetes нужно перестроить свой мозг и почему комментарии на Хабре иногда полезнее статей.
https://vk.cc/c8vTY3
В интервью Андрей рассказал, как прошел путь от эникейщика до Cloud-архитектора, почему для работы с Kubernetes нужно перестроить свой мозг и почему комментарии на Хабре иногда полезнее статей.
https://vk.cc/c8vTY3
- - - - - - - - -
Из тестировщика в разработчики. Почему так делать не стоит?
- - - - - - - - -
Сергей Немчинский проводит карьерные консультации. Часто к нему приходят люди, которые решают сначала стать тестировщиками, чтобы потом перейти в программирование. Почему они принимают такие решения и почему так лучше не делать?
https://www.youtube.com/watch?v=PPbVK9B_CVY&list=WL&index=10
Из тестировщика в разработчики. Почему так делать не стоит?
- - - - - - - - -
Сергей Немчинский проводит карьерные консультации. Часто к нему приходят люди, которые решают сначала стать тестировщиками, чтобы потом перейти в программирование. Почему они принимают такие решения и почему так лучше не делать?
https://www.youtube.com/watch?v=PPbVK9B_CVY&list=WL&index=10
YouTube
Из тестировщика в разработчики. Почему так делать не стоит?
Как вы знаете, Сергей Немчинский проводит карьерные консультации. Часто к нему приходят люди, которые решают сначала стать тестировщиками, чтобы потом перейти в программирование. Сегодня поговорим о том почему они принимают такие решения и почему так лучше…
Вопрос #17
Q: Расскажите про основные особенности следующих видов тестирования: Cессионное тестирование и Поиск багов (Session Based Testing & Bug Hunts)
A: В те времена, когда исследовательское тестирование только появилось, многие не понимали, чем занимаются тестировщики. Они начинали работу без предварительного планирования, без объяснений относительно того, что и как они собираются делать. Поэтому для многих людей исследовательское тестирование представлялось одним огромным облаком. Позже кто-то умный решил разделить это облако на небольшие облака, соответствующие сессиям. Так и возникло сессионное тестирование.
При использовании этого подхода у тестировщика есть точки тестирования, с которыми он собирается работать на протяжении одной сессии, небольшой объем документации, которому он должен следовать. Но при этом у него гораздо больше свободы, чем в случае с подробным сценарным тестированием.
Сессионное тестирование предусматривает наличие:
1. Сессий тестирования
2. Миссии и точки тестирования / идей для тестирования
3. Заметок во время сессии
4. Отчета после сессии (что мы обнаружили, каково качество системы и пр.)
Поиск багов имеет много общего с сессионным тестированием, но есть и важные отличия. В поиске багов принимают участие не только тестировщики, но и разработчики, а также пользователи.
Сессия поиска багов может длиться дольше, чем сессия тестирования. Так, для сессии поиска багов нормальной считается продолжительность от трех до четырех часов, а при сессионном тестировании уже через два часа, как правило, необходимо делать перерыв. Кроме этого, во время поиска багов работа обычно ведется парами (тестировщик плюс пользователь), и целью такой сессии является не только получение информации, но и одобрение системы пользователями.
Q: Расскажите про основные особенности следующих видов тестирования: Cессионное тестирование и Поиск багов (Session Based Testing & Bug Hunts)
A: В те времена, когда исследовательское тестирование только появилось, многие не понимали, чем занимаются тестировщики. Они начинали работу без предварительного планирования, без объяснений относительно того, что и как они собираются делать. Поэтому для многих людей исследовательское тестирование представлялось одним огромным облаком. Позже кто-то умный решил разделить это облако на небольшие облака, соответствующие сессиям. Так и возникло сессионное тестирование.
При использовании этого подхода у тестировщика есть точки тестирования, с которыми он собирается работать на протяжении одной сессии, небольшой объем документации, которому он должен следовать. Но при этом у него гораздо больше свободы, чем в случае с подробным сценарным тестированием.
Сессионное тестирование предусматривает наличие:
1. Сессий тестирования
2. Миссии и точки тестирования / идей для тестирования
3. Заметок во время сессии
4. Отчета после сессии (что мы обнаружили, каково качество системы и пр.)
Поиск багов имеет много общего с сессионным тестированием, но есть и важные отличия. В поиске багов принимают участие не только тестировщики, но и разработчики, а также пользователи.
Сессия поиска багов может длиться дольше, чем сессия тестирования. Так, для сессии поиска багов нормальной считается продолжительность от трех до четырех часов, а при сессионном тестировании уже через два часа, как правило, необходимо делать перерыв. Кроме этого, во время поиска багов работа обычно ведется парами (тестировщик плюс пользователь), и целью такой сессии является не только получение информации, но и одобрение системы пользователями.
- - - - - - - - -
Полезные статьи. Часть 2. Smoke-тестирование.
- - - - - - - - -
1. О понятии "Smoke-тестирование": https://en.wikipedia.org/wiki/Smoke_testing_(electrical)
2. Различия Smoke-тестирования и Sanity-тестирования: https://www.guru99.com/smoke-sanity-testing.html
3. Smoke-тестирование и Sanity-тестирование. Различия с примерами: https://www.softwaretestinghelp.com/smoke-testing-and-sanity-testing-difference/
Полезные статьи. Часть 2. Smoke-тестирование.
- - - - - - - - -
1. О понятии "Smoke-тестирование": https://en.wikipedia.org/wiki/Smoke_testing_(electrical)
2. Различия Smoke-тестирования и Sanity-тестирования: https://www.guru99.com/smoke-sanity-testing.html
3. Smoke-тестирование и Sanity-тестирование. Различия с примерами: https://www.softwaretestinghelp.com/smoke-testing-and-sanity-testing-difference/
Впорос №18
Q: Расскажите про основные особенности следующих видов тестирования: Исследовательское тестирование и туры (Exploratory Testing & Test Tours)
A: При проведении исследовательского тестирования акцент делается на личной свободе и ответственности тестировщика. Оно предполагает постоянный поиск ответов на вопросы: «как сделать лучше?», «какие тесты сейчас наиболее важны?». Вы не просто делаете то, что написано в сценарии, вы постоянно думаете. Кроме этого, все этапы тестирования (проектирование, выполнение, интерпретация результатов и пр.) проходят не последовательно, а параллельно на протяжении всего проекта.
При проведении исследовательского тестирования иногда бывать сложно сфокусироваться на чем-то конкретном. И в этом случае помогают исследовательские туры. Туры отражают основные цели и задачи, которые ставятся при проведении тестирования.
Цитируем Джеймса Уиттакера: «Исследовательское тестирование без хорошего руководства подобно блужданию по городу в поисках интересных достопримечательностей. Руководство дает возможность понять, куда вам нужно следовать».
В книге «Исследовательское тестирование ПО» Джеймс Уиттакер пишет о самых разных исследовательских турах. Вот некоторые из них:
1. Тур по функциям – протестировать все функциональные возможности приложения.
2. Тур по требованиям – протестировать на предмет того, соблюдены ли коммерческие требования.
3. Тур по данным – протестировать обработку данных.
4. Тур по вычислениям – протестировать все вычисления.
5. Тур по процессам – протестировать поддержку рабочих процессов приложением.
6. Тур по экранам – протестировать все экраны.
7. Тур по компонентам с плохой репутацией – протестировать те части приложения, которые ранее имели много ошибок.
8. Тур по интерфейсам – протестировать все интерфейсы.
9. Асоциальный тур – протестировать некорректное использование.
10. Тур грабителя – протестировать на предмет того, можно ли получить неавторизованный доступ.
Q: Расскажите про основные особенности следующих видов тестирования: Исследовательское тестирование и туры (Exploratory Testing & Test Tours)
A: При проведении исследовательского тестирования акцент делается на личной свободе и ответственности тестировщика. Оно предполагает постоянный поиск ответов на вопросы: «как сделать лучше?», «какие тесты сейчас наиболее важны?». Вы не просто делаете то, что написано в сценарии, вы постоянно думаете. Кроме этого, все этапы тестирования (проектирование, выполнение, интерпретация результатов и пр.) проходят не последовательно, а параллельно на протяжении всего проекта.
При проведении исследовательского тестирования иногда бывать сложно сфокусироваться на чем-то конкретном. И в этом случае помогают исследовательские туры. Туры отражают основные цели и задачи, которые ставятся при проведении тестирования.
Цитируем Джеймса Уиттакера: «Исследовательское тестирование без хорошего руководства подобно блужданию по городу в поисках интересных достопримечательностей. Руководство дает возможность понять, куда вам нужно следовать».
В книге «Исследовательское тестирование ПО» Джеймс Уиттакер пишет о самых разных исследовательских турах. Вот некоторые из них:
1. Тур по функциям – протестировать все функциональные возможности приложения.
2. Тур по требованиям – протестировать на предмет того, соблюдены ли коммерческие требования.
3. Тур по данным – протестировать обработку данных.
4. Тур по вычислениям – протестировать все вычисления.
5. Тур по процессам – протестировать поддержку рабочих процессов приложением.
6. Тур по экранам – протестировать все экраны.
7. Тур по компонентам с плохой репутацией – протестировать те части приложения, которые ранее имели много ошибок.
8. Тур по интерфейсам – протестировать все интерфейсы.
9. Асоциальный тур – протестировать некорректное использование.
10. Тур грабителя – протестировать на предмет того, можно ли получить неавторизованный доступ.
👍1
Вопрос №19
Q: Мы поговорили об основных видах тестирования с точки зрения подхода к его планированию. Перечислите основные характеристики этих подходов.
A:
Сценарное тестирование:
1. Сфокусировано на подготовке
2. Сфокусировано на планировании
3. Опирается на методы
4. Подчиняется процессу
5. Сфокусировано на документации
Исследовательское тестирование
1. Сфокусировано на действии
2. Гибкое
3. Прагматичное
4. Ставит в центр внимания тестировщика
5. Сфокусировано на выполнении тестов
Может возникнуть ощущение, что исследовательское тестирование лучше сценарного. Это не так. Сценарное тестирование так же ценно, как и исследовательское, но тут все зависит от ситуации.
Однако эффективность исследовательского тестирования все же выше, чем сценарного. Это доказывается различными исследованиями. В частности, в 2011 году проводилось исследование, в котором принимало участие две команды. Они одновременно работали над тестированием одного и того же приложения, причем первая использовала сценарное тестирование, а вторая – исследовательское. Затем они тестировали второе приложение, но теперь первая команда использовала исследовательское тестирование, а вторая – сценарное. Это исследование показало, что при исследовательском тестировании эффективность обнаружения ошибок была намного выше. Подобные результаты были получены и при проведении других исследований эффективности методов тестирования.
Q: Мы поговорили об основных видах тестирования с точки зрения подхода к его планированию. Перечислите основные характеристики этих подходов.
A:
Сценарное тестирование:
1. Сфокусировано на подготовке
2. Сфокусировано на планировании
3. Опирается на методы
4. Подчиняется процессу
5. Сфокусировано на документации
Исследовательское тестирование
1. Сфокусировано на действии
2. Гибкое
3. Прагматичное
4. Ставит в центр внимания тестировщика
5. Сфокусировано на выполнении тестов
Может возникнуть ощущение, что исследовательское тестирование лучше сценарного. Это не так. Сценарное тестирование так же ценно, как и исследовательское, но тут все зависит от ситуации.
Однако эффективность исследовательского тестирования все же выше, чем сценарного. Это доказывается различными исследованиями. В частности, в 2011 году проводилось исследование, в котором принимало участие две команды. Они одновременно работали над тестированием одного и того же приложения, причем первая использовала сценарное тестирование, а вторая – исследовательское. Затем они тестировали второе приложение, но теперь первая команда использовала исследовательское тестирование, а вторая – сценарное. Это исследование показало, что при исследовательском тестировании эффективность обнаружения ошибок была намного выше. Подобные результаты были получены и при проведении других исследований эффективности методов тестирования.
👍1
Вопрос №20
Q: На основании каких критериев можно считать тестирование завершенным?
A: Выходные критерии – это совокупность условий, которые должны быть выполнены, чтобы фаза тестирования была успешно закрыта.
Любое изменение в списке выходных критериев должно быть одобрено заинтересованными лицами, ответственными за утверждение этого документа.
Возможные выходные критерии:
1. Достигнут дедлайн (релиза, тестирования и т. д.)
2. Достигнут необходимый процент успешно пройденных тест-кейсов.
3. Покрытие кода/функционала/требований достигло нужного уровня
4. Все дефекты исправлены или закрыты.
5. Все тест-кейсы выполнены.
6. Завершен бета- или альфа-период тестирования.
7. Бюджет, выделенный на тестирование, исчерпан.
Выходные критерии устанавливаются заранее, при планировании тестирования.
Q: На основании каких критериев можно считать тестирование завершенным?
A: Выходные критерии – это совокупность условий, которые должны быть выполнены, чтобы фаза тестирования была успешно закрыта.
Любое изменение в списке выходных критериев должно быть одобрено заинтересованными лицами, ответственными за утверждение этого документа.
Возможные выходные критерии:
1. Достигнут дедлайн (релиза, тестирования и т. д.)
2. Достигнут необходимый процент успешно пройденных тест-кейсов.
3. Покрытие кода/функционала/требований достигло нужного уровня
4. Все дефекты исправлены или закрыты.
5. Все тест-кейсы выполнены.
6. Завершен бета- или альфа-период тестирования.
7. Бюджет, выделенный на тестирование, исчерпан.
Выходные критерии устанавливаются заранее, при планировании тестирования.
Вопрос №21
Q: Что такое чек-лист в тестировании?
A: Чек-лист — это документ, описывающий что должно быть протестировано. При этом чек-лист может быть абсолютно разного уровня детализации. На сколько детальным будет чек-лист зависит от:
1. Требований к отчётности
2. Уровня знания продукта сотрудниками
3. Сложности продукта.
Что должно быть в чек-листе?
1. Список проверок (с требуемой степенью детализации)
2. Статус проверок: сборка, на которой проводилось тестирование, тестовое окружение (если применимо), тестировщик
3. Результат проверки
Инструменты ведения чек-листов
1. Таблицы Excel/OpenOffice для самостоятельной работы
2. Таблицы GoogleDocs для распределения в команде
3. Специальное программное обеспечение для создания и хранения тестовой документации
Q: Что такое чек-лист в тестировании?
A: Чек-лист — это документ, описывающий что должно быть протестировано. При этом чек-лист может быть абсолютно разного уровня детализации. На сколько детальным будет чек-лист зависит от:
1. Требований к отчётности
2. Уровня знания продукта сотрудниками
3. Сложности продукта.
Что должно быть в чек-листе?
1. Список проверок (с требуемой степенью детализации)
2. Статус проверок: сборка, на которой проводилось тестирование, тестовое окружение (если применимо), тестировщик
3. Результат проверки
Инструменты ведения чек-листов
1. Таблицы Excel/OpenOffice для самостоятельной работы
2. Таблицы GoogleDocs для распределения в команде
3. Специальное программное обеспечение для создания и хранения тестовой документации
👍2
Вопрос №22
Q: Приведите примеры чек-листа в тестировании
A: Приведем 5 примеров чек-листов:
1. Чек-лист «Структуризатор» - используется для структуризации информации о статусе продукта, подходит командам опытных тестировщиков.
2. Чек-лист «Незабыватор» - используется «чтобы ничего не забыть проверить», сфера применения сильно зависит от уровня детализации
3. Чек-лист «Тесткейсозаменитель» - используется как альтернатива тест-кейсам в случаях, когда требования к качеству достаточно высокие, а ресурсов на создание тест-кейсов нет
4. Чек-лист «Статусопоказатель» - используется для оценки динамики качества ПО, анализа причин появления дефектов и/или пропусков дефектов
5. Чек-лист «Окруженияучитыватель» - используется для оценки состояния ПО на разных окружениях
Q: Приведите примеры чек-листа в тестировании
A: Приведем 5 примеров чек-листов:
1. Чек-лист «Структуризатор» - используется для структуризации информации о статусе продукта, подходит командам опытных тестировщиков.
2. Чек-лист «Незабыватор» - используется «чтобы ничего не забыть проверить», сфера применения сильно зависит от уровня детализации
3. Чек-лист «Тесткейсозаменитель» - используется как альтернатива тест-кейсам в случаях, когда требования к качеству достаточно высокие, а ресурсов на создание тест-кейсов нет
4. Чек-лист «Статусопоказатель» - используется для оценки динамики качества ПО, анализа причин появления дефектов и/или пропусков дефектов
5. Чек-лист «Окруженияучитыватель» - используется для оценки состояния ПО на разных окружениях
👍2
Вопрос №23
Q: Что такое Cheat-sheet в тестировании?
A: Чит-лист – список повторяющихся проверок. Чит-листы составляются с целью их последующего многократного использования. В связи с этим такие списки создаются в отношении распространённых и часто встречающихся составляющих программного обеспечения, с которыми предстоит работать неоднократно не только на текущем проекте, но и на последующих.
Примерами могут быть следующие: валидация поля редактирования для ввода электронного адреса, инъекции SQL и XSS, список проверок для проведения юзабилити тестирования.
Чит-листы также отлично зарекомендовали себя как инструмент для документирования корпоративных стандартов компаний, которые должны быть соблюдены, а потому и проверены в обязательном порядке (например, требования к интерфейсу разрабатываемого ПО).
Примеры чит-листов:
1. Чит-лист регистрации от Алексея Лупана: https://wiki.software-testing.ru/%D0%A7%D0%B8%D1%82-%D0%BB%D0%B8%D1%81%D1%82_%D1%80%D0%B5%D0%B3%D0%B8%D1%81%D1%82%D1%80%D0%B0%D1%86%D0%B8%D0%B8_%D0%BE%D1%82_%D0%90%D0%BB%D0%B5%D0%BA%D1%81%D0%B5%D1%8F_%D0%9B%D1%83%D0%BF%D0%B0%D0%BD%D0%B0
2. Чит-лист по Web UI контролам от Игоря Любина: https://wiki.software-testing.ru/%D0%A7%D0%B8%D1%82-%D0%BB%D0%B8%D1%81%D1%82_%D0%BF%D0%BE_Web_UI_%D0%BA%D0%BE%D0%BD%D1%82%D1%80%D0%BE%D0%BB%D0%B0%D0%BC_%D0%BE%D1%82_%D0%98%D0%B3%D0%BE%D1%80%D1%8F_%D0%9B%D1%8E%D0%B1%D0%B8%D0%BD%D0%B0
3. MySQL SQL Injection Cheat Sheet: https://pentestmonkey.net/cheat-sheet/sql-injection/mysql-sql-injection-cheat-sheet
Q: Что такое Cheat-sheet в тестировании?
A: Чит-лист – список повторяющихся проверок. Чит-листы составляются с целью их последующего многократного использования. В связи с этим такие списки создаются в отношении распространённых и часто встречающихся составляющих программного обеспечения, с которыми предстоит работать неоднократно не только на текущем проекте, но и на последующих.
Примерами могут быть следующие: валидация поля редактирования для ввода электронного адреса, инъекции SQL и XSS, список проверок для проведения юзабилити тестирования.
Чит-листы также отлично зарекомендовали себя как инструмент для документирования корпоративных стандартов компаний, которые должны быть соблюдены, а потому и проверены в обязательном порядке (например, требования к интерфейсу разрабатываемого ПО).
Примеры чит-листов:
1. Чит-лист регистрации от Алексея Лупана: https://wiki.software-testing.ru/%D0%A7%D0%B8%D1%82-%D0%BB%D0%B8%D1%81%D1%82_%D1%80%D0%B5%D0%B3%D0%B8%D1%81%D1%82%D1%80%D0%B0%D1%86%D0%B8%D0%B8_%D0%BE%D1%82_%D0%90%D0%BB%D0%B5%D0%BA%D1%81%D0%B5%D1%8F_%D0%9B%D1%83%D0%BF%D0%B0%D0%BD%D0%B0
2. Чит-лист по Web UI контролам от Игоря Любина: https://wiki.software-testing.ru/%D0%A7%D0%B8%D1%82-%D0%BB%D0%B8%D1%81%D1%82_%D0%BF%D0%BE_Web_UI_%D0%BA%D0%BE%D0%BD%D1%82%D1%80%D0%BE%D0%BB%D0%B0%D0%BC_%D0%BE%D1%82_%D0%98%D0%B3%D0%BE%D1%80%D1%8F_%D0%9B%D1%8E%D0%B1%D0%B8%D0%BD%D0%B0
3. MySQL SQL Injection Cheat Sheet: https://pentestmonkey.net/cheat-sheet/sql-injection/mysql-sql-injection-cheat-sheet
👍2