#Theory #Metodologies
Theoretical review of the main software development methodologies with their comparative characteristics and areas of application.
Meetup : 26.03.2021 at 18:00 (Minsk)
Watch
Theoretical review of the main software development methodologies with their comparative characteristics and areas of application.
Meetup : 26.03.2021 at 18:00 (Minsk)
Watch
#TestCase #TestDesign
It's hard to run uniform testing when you don't have your test cases written up!
Read
It's hard to run uniform testing when you don't have your test cases written up!
Read
Comparison with the Web and examples of how Appium works with Android
Meetup сегодня в 18:00 (по Минску)
Join
Meetup сегодня в 18:00 (по Минску)
Join
Вы - тестировщик на проекте без документации
Если вы один из таких счастливчиков, помните - за эти страдания в следующей жизни точно родитесь сыном арабского шейха. А сейчас не пугайтесь, верьте в свои силы и воспользуйтесь нашими советами:
1) Изучайте свой продукт с позиции обычного юзера. Трогайте, нажимайте и наблюдайте. Робинзон Крузо смог - и вы сможете.
2) Много общайтесь с Product owner, бизнес-аналитиком, разработчиками и другими людьми, которые имеют отношение к развитию проекта.
3) Научитесь понимать код продукта. Это лучшая документация. На первых порах вам поможет разработчик, дальше дело пойдет легче.
4) Самостоятельно создайте минимальный набор документов по проекту. Чек-листы, схемы, майндмапы, - все это - важный вклад в будущее и лучшая защита от склероза.
Если вы один из таких счастливчиков, помните - за эти страдания в следующей жизни точно родитесь сыном арабского шейха. А сейчас не пугайтесь, верьте в свои силы и воспользуйтесь нашими советами:
1) Изучайте свой продукт с позиции обычного юзера. Трогайте, нажимайте и наблюдайте. Робинзон Крузо смог - и вы сможете.
2) Много общайтесь с Product owner, бизнес-аналитиком, разработчиками и другими людьми, которые имеют отношение к развитию проекта.
3) Научитесь понимать код продукта. Это лучшая документация. На первых порах вам поможет разработчик, дальше дело пойдет легче.
4) Самостоятельно создайте минимальный набор документов по проекту. Чек-листы, схемы, майндмапы, - все это - важный вклад в будущее и лучшая защита от склероза.
#тестирование #подготовка_технической_документации
В жизни каждого тестировщика непременно наступает момент, когда он спрашивает себя: "А насколько глубоко и полно я охватываю разработку и поддерживание тестовой документации на проекте? Какая из них будет полезной, и необходимо ее держать в актуальном состоянии а какую стоит забыть, как в страшном сне?"
Более подробно о тестовой документации предлагаем ознакомиться в статье.
Читать
В жизни каждого тестировщика непременно наступает момент, когда он спрашивает себя: "А насколько глубоко и полно я охватываю разработку и поддерживание тестовой документации на проекте? Какая из них будет полезной, и необходимо ее держать в актуальном состоянии а какую стоит забыть, как в страшном сне?"
Более подробно о тестовой документации предлагаем ознакомиться в статье.
Читать
#sql #Типы_данных
Запрашиваем разные типы данных в SELECT правильно
9 из 10 запросов тестировщика к БД - это SELECT. Сталкивались с ситуацией, когда обращение написано вроде бы правильно, но не срабатывает? Возможно, дело в том, что вы неправильно запросили какой-то тип данных. Есть свободная минутка? Давайте вспомним, как делать это верно.
P.S. Сохраните себе шпаргалку на будущее, возможно это сэкономит вам нервы и время.
Запрашиваем разные типы данных в SELECT правильно
9 из 10 запросов тестировщика к БД - это SELECT. Сталкивались с ситуацией, когда обращение написано вроде бы правильно, но не срабатывает? Возможно, дело в том, что вы неправильно запросили какой-то тип данных. Есть свободная минутка? Давайте вспомним, как делать это верно.
P.S. Сохраните себе шпаргалку на будущее, возможно это сэкономит вам нервы и время.
В одном из предыдущих постов мы начали цикл, посвященный форматам ответа сервера. В том посте мы разобрали JSON. Наступила очередь XML.
XML - eXtensible Markup Language, расширяемый язык разметки. Как и JSON, XML является текстовым форматом. По сравнению с JSON его несколько сложнее читать, да и сам формат более объемный. Зато, за счет своей структуры, он позволяет структурировать информацию с большим количеством критериев.
Основой XML является тег. Это некий маркер, обернутый символами "<" и ">". Например: <link>
Разделяют открывающий тег и закрывающий тег. Закрывающий тег вместо знака "<" начинается с сочетания символов "</". Например: </link>
Все, что находится между открывающим и закрывающим тегом, является содержимым этого тега: <link>Кликай сюда</link>
Помимо содержимого у тега может быть любое количество атрибутов. Это пары ключ-значение, которые прописываются внутри открывающего тега после названия этого тега.
Например:
XML - eXtensible Markup Language, расширяемый язык разметки. Как и JSON, XML является текстовым форматом. По сравнению с JSON его несколько сложнее читать, да и сам формат более объемный. Зато, за счет своей структуры, он позволяет структурировать информацию с большим количеством критериев.
Основой XML является тег. Это некий маркер, обернутый символами "<" и ">". Например: <link>
Разделяют открывающий тег и закрывающий тег. Закрывающий тег вместо знака "<" начинается с сочетания символов "</". Например: </link>
Все, что находится между открывающим и закрывающим тегом, является содержимым этого тега: <link>Кликай сюда</link>
Помимо содержимого у тега может быть любое количество атрибутов. Это пары ключ-значение, которые прописываются внутри открывающего тега после названия этого тега.
Например:
<link open="andersenlab.com">Кликай сюда</link>В этом примере "open" является атрибутом, а "andersenlab.com" - содержимом атрибута. Один и тот же тег с различными атрибутами может нести разные значения, что довольно удобно для структурирования информации.
В XML теги можно вкладывать друг в друга, что также способствует структурированию. Например, давайте посмотрим на XML с описанием сотрудников какой-то компании:
Таким образом нам удалось структурировать наши отделы при помощи XML.
Как и JSON, XML очень легко парсится почти любыми языками программирования. Для описания конкретного элемента или нескольких элементов в XML-структуре используется Xpath — (XML Path Language) язык запросов к элементам XML-документа.
XML и HTML очень похожи, но не стоит их путать. У двух этих языков разное назначение и особенности.
<employees>В нашем примере теги "employees" объединяют "developers" и "QAs" - это два департамента нашей компании. В тегов "developer" и "qa" есть два атрибута. Если присутствует атрибут "position" со значением "lead", значит это тимлид нашей команды. А вот "status" со значением "inactive" означает, что человек больше в компании не работает.
<developers>
<developer position="lead">Олег</developer>
<developer>Настя</developer>
</developers>
<QAs>
<qa position="lead" status="inactive">Евгения</qa>
<qa position="lead">Света</qa>
<qa>Арсений</qa>
<qa status="inactive">Степан</qa>
</QAs>
</employees>
Таким образом нам удалось структурировать наши отделы при помощи XML.
Как и JSON, XML очень легко парсится почти любыми языками программирования. Для описания конкретного элемента или нескольких элементов в XML-структуре используется Xpath — (XML Path Language) язык запросов к элементам XML-документа.
XML и HTML очень похожи, но не стоит их путать. У двух этих языков разное назначение и особенности.
#Test_design
As part of the Quality Assurance Team, we must provide high-quality products/services and provide real value to our customers.
Most often, companies admit to using the wrong business model or lacking Quality.
These mistakes leave room for discussion while involving QA expertise usually improves competition and provides better Testing processes.
Читать
As part of the Quality Assurance Team, we must provide high-quality products/services and provide real value to our customers.
Most often, companies admit to using the wrong business model or lacking Quality.
These mistakes leave room for discussion while involving QA expertise usually improves competition and provides better Testing processes.
Читать
#Pairwise_testing
Условие задачи:
Программа может быть проинсталлирована на 3 операционные системы. Каждая ОС имеет 3 версии. Каждая версия доступна на 4 языках.
Программа доступна в 2 версиях - демо и полная. Каждая инсталляция длится 5 минут, для смоук теста нужно ещё 10 минут.
Один тестировщик может выполнять ручное тестирование, ему доступно неограниченное количество систем со всеми нужными языками и ОС.
Сколько времени нужно запланировать на тестирование?
Читать
Условие задачи:
Программа может быть проинсталлирована на 3 операционные системы. Каждая ОС имеет 3 версии. Каждая версия доступна на 4 языках.
Программа доступна в 2 версиях - демо и полная. Каждая инсталляция длится 5 минут, для смоук теста нужно ещё 10 минут.
Один тестировщик может выполнять ручное тестирование, ему доступно неограниченное количество систем со всеми нужными языками и ОС.
Сколько времени нужно запланировать на тестирование?
Читать
#Test_design #equivalence_class
В этой статье поговорим об одной из самых распространенных техник тест-дизайна — классах эквивалентности.
Рассмотрим технику на примере формы регистрации. Возьмем какое-нибудь поле, например — поле ввода имени пользователя. Диапазон значений, которые в него можно ввести, бесконечен: короткие и длинные имена, случайные буквы, цифры и множество других вариантов. Но бесконечно тестировать эту форму не вариант, поэтому нам надо выделить в группы похожие друг на друга значения, которые нашей программой будут обрабатываться одинаково.
Таких групп будет уже гораздо меньше. Все значения внутри группы будем считать одинаковыми с точки зрения тестирования. Это означает, что при их вводе мы ожидаем, что получим схожий результат. Например, имена Олег и Марина — разные, но для тестирования достаточно ввести одно из них. Второй, скорее всего, обработается формой абсолютно также.
Такие группы будут называться классами эквивалентности. Помимо одинакового ожидаемого поведения, они должны тестировать одинаковый функционал. Например, нельзя относить к эквивалентным значениям те значения, которые тестируют разные поля. Каждому полю — свои группы.
Естественно, первым делом возникает желание посмотреть, как отреагирует поле на различные цифры, спецсимволы и нули. Но надо помнить, что наша задача — не ломать приложение, а выяснить, как оно работает, и начинать стоит с позитивных тест-кейсов. А чтобы их выделить, надо понимать, какое именно поле мы тестируем.
В нашем примере мы рассматриваем поле для ввода имен, а значит позитивными кейсами тут будут настоящие имена наших пользователей.
Возьмем обычное имя, состоящую из одного слова: Света. Вторая группа — это короткие имена, например, Ян. Следующий кейс — длинное имя, Максимилиан. Добавим имена с пробелами — Рэй Чарльз. И имена со спецсимволами: Семьюель Л. Джексон и Кири-Кири.
Вот по такому принципу мы стараемся объединять возможные имена в группы и делать только одну проверку для каждой группы. Это существенно сокращает время на тестирование, не снижая его эффективность.
В этой статье поговорим об одной из самых распространенных техник тест-дизайна — классах эквивалентности.
Рассмотрим технику на примере формы регистрации. Возьмем какое-нибудь поле, например — поле ввода имени пользователя. Диапазон значений, которые в него можно ввести, бесконечен: короткие и длинные имена, случайные буквы, цифры и множество других вариантов. Но бесконечно тестировать эту форму не вариант, поэтому нам надо выделить в группы похожие друг на друга значения, которые нашей программой будут обрабатываться одинаково.
Таких групп будет уже гораздо меньше. Все значения внутри группы будем считать одинаковыми с точки зрения тестирования. Это означает, что при их вводе мы ожидаем, что получим схожий результат. Например, имена Олег и Марина — разные, но для тестирования достаточно ввести одно из них. Второй, скорее всего, обработается формой абсолютно также.
Такие группы будут называться классами эквивалентности. Помимо одинакового ожидаемого поведения, они должны тестировать одинаковый функционал. Например, нельзя относить к эквивалентным значениям те значения, которые тестируют разные поля. Каждому полю — свои группы.
Естественно, первым делом возникает желание посмотреть, как отреагирует поле на различные цифры, спецсимволы и нули. Но надо помнить, что наша задача — не ломать приложение, а выяснить, как оно работает, и начинать стоит с позитивных тест-кейсов. А чтобы их выделить, надо понимать, какое именно поле мы тестируем.
В нашем примере мы рассматриваем поле для ввода имен, а значит позитивными кейсами тут будут настоящие имена наших пользователей.
Возьмем обычное имя, состоящую из одного слова: Света. Вторая группа — это короткие имена, например, Ян. Следующий кейс — длинное имя, Максимилиан. Добавим имена с пробелами — Рэй Чарльз. И имена со спецсимволами: Семьюель Л. Джексон и Кири-Кири.
Вот по такому принципу мы стараемся объединять возможные имена в группы и делать только одну проверку для каждой группы. Это существенно сокращает время на тестирование, не снижая его эффективность.
В рамках этого цикла статей мы рассказываем про форматы ответа сервера. В предыдущих статьях мы уже разобрали JSON и XML. Теперь очередь дошла до GPB.
GPB (Google Protocol Buffers) - это протокол, разработанный компанией Google. Коротко его называют “протобуф”.
В отличие от JSON и XML, этот формат ответа не получится прочитать без дополнительного софта, так как протокол передает данные в бинарном виде, то есть в виде единичек и ноликов. Давайте разберемся, как он работает.
В клиент-серверной архитектуре, где клиент создает запросы серверу и сервер на них отвечает, важно следить за количеством передаваемой информации. Чем ее больше, тем дольше пользователь будет ждать ответа, тем медленнее будет работать приложение. Особенно в условиях плохого или просто медленного интернета.
Потому для действительно больших приложений, обменивающихся с сервером большим количеством информации, XML подходит не очень хорошо - он, как мы видели на примере в нашей предыдущей статье, довольно громоздкий.
Ребята из Google придумали следующий подход. Они решили, что сервер может шифровать сообщения специальной программой. А клиент, то есть приложение - расшифровывать. Таким образом зашифрованное сообщение весит гораздо меньше и будет передаваться быстрее.
Здесь мы не будем приводить примеры алгоритмов шифровки, так как они довольно сложные. Только уточним, что работает процесс шифрования и дешифрования довольно быстро, так что на это не тратится существенно много времени.
Переход на GPB может дать заметный прирост к скорости работы приложения. Многие компании постепенно переходят на этот протокол.
GPB (Google Protocol Buffers) - это протокол, разработанный компанией Google. Коротко его называют “протобуф”.
В отличие от JSON и XML, этот формат ответа не получится прочитать без дополнительного софта, так как протокол передает данные в бинарном виде, то есть в виде единичек и ноликов. Давайте разберемся, как он работает.
В клиент-серверной архитектуре, где клиент создает запросы серверу и сервер на них отвечает, важно следить за количеством передаваемой информации. Чем ее больше, тем дольше пользователь будет ждать ответа, тем медленнее будет работать приложение. Особенно в условиях плохого или просто медленного интернета.
Потому для действительно больших приложений, обменивающихся с сервером большим количеством информации, XML подходит не очень хорошо - он, как мы видели на примере в нашей предыдущей статье, довольно громоздкий.
Ребята из Google придумали следующий подход. Они решили, что сервер может шифровать сообщения специальной программой. А клиент, то есть приложение - расшифровывать. Таким образом зашифрованное сообщение весит гораздо меньше и будет передаваться быстрее.
Здесь мы не будем приводить примеры алгоритмов шифровки, так как они довольно сложные. Только уточним, что работает процесс шифрования и дешифрования довольно быстро, так что на это не тратится существенно много времени.
Переход на GPB может дать заметный прирост к скорости работы приложения. Многие компании постепенно переходят на этот протокол.
На новом TAD Talk отправимся в мир мобильного тестирования и узнаем все о его специфике, возможностях и стратегиях.
Когда: 7 мая 18:00 - 20:00 (Minsk)
Register
Когда: 7 мая 18:00 - 20:00 (Minsk)
Register
Всем привет!
Meetup сегодня: 06.05 в 18:00 (по Киеву)
Тема: What you should pay attention choosing mobile devices for testing. Device-specific bugs, emulators and simulators, selection criteria, an example of choosing a device for a project
Трансляция: Zoom
Meetup сегодня: 06.05 в 18:00 (по Киеву)
Тема: What you should pay attention choosing mobile devices for testing. Device-specific bugs, emulators and simulators, selection criteria, an example of choosing a device for a project
Трансляция: Zoom