Русский
Русский
English
Статистика
Реклама

Ручное тестирование

Как выбрать мобильные девайсы для тестирования и не налажать

05.07.2020 02:06:52 | Автор: admin
Данная статья написана специально для OTUS преподавателем курса QA Lead Анастасией Шариковой.





Всем привет! Меня зовут Анастасия Шарикова, я руковожу отделом тестирования в Bookmate и веду телеграм канал Yet another QA.

Уверена, что многие, когда приходили на позицию QA Leada, ожидали сложных и интересных задач по выстраиванию процессов, настройке системы автотестов, налаживанию функционального и нефункционального тестирования, в конце-концов задач по управлению сотрудниками. Но в итоге оказалось, что все это есть, но сочетается с такими бытовыми штуками, как расчет зарплат, определение бюджета на отдел и прочих проблем, связанных с финансами и зачастую от этого никуда не деться, особенно в маленьких и средних компаниях. Тем не менее, внимательность к таким темам отличный способ дополнительно повысить качество вашего продукта и найти и предотвратить проблем уже на самых ранних этапах.

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

В этой статье будет сделан акцент именно на подбор девайсов для ручного тестирования, так как у подбора ферм для автотестов есть свои особенности, и на эту тему лучше поговорить отдельно.

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

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

Основные параметры, влияющие на подбор:


  • Внешняя аналитика: тут нам на помощь могут прийти как международные подборки по самым популярным устройствам (такие, как, например deviceatlas.com), так и банальные варианты типа сортировки в яндекс.маркете по самым популярным устройствам. Тут важно не купиться на удочку самых лучших телефонов, т.к мнение экспертов зачастую очень расходится с мнением обычных потребителей. Главное помнить про то, на какую страну и ЦА ориентирован ваш продукт, и основываться на этом условии.
  • Внутренняя аналитика: в этом случае у нас огромное количество вариантов, на что можно опираться, к тому же это самые четкие данные и именно по нашему продукту. Что же мы тут можем использовать? Данные систем аналитики, таких как Firebase или информацию по устройствам из Google Play. И важно не забывать брать в расчет не только устройства и оси, которыми пользуются ваши сотрудники, но и те, на которых система чаще всего ловит ошибки и креши.
  • Тенденции на рынке: каждый месяц на рынок выходят новые игроки и устройства, появляются обновления осей и новые лидеры рынка, и все это важно учитывать. Примеры то, насколько стало больше за последний год устройств со шторкой/бровкой или санкции США против Huawei.


Не забываем про особенности нашей аудитории:


Всегда важно помнить об особенностях конкретно вашего продукта и его ЦА и стараться избегать субъективности даже если вам кажется, что iPhone 11 Pro венец творения компании Apple, это не принесет вам особой пользы в работе, если аудитория вашего приложения для обработки фотографий школьники, которым родители подарили шестой или седьмой айфон. Это же работает и в обратную сторону если вы знаете, что вашим сервисом пользуются обеспеченные люди и оно будет установлено в основном на iPad Pro новейшей модели то придется раскошелиться на него, иначе жди беды.
Особенно важно заметить про страны пользования почти у всех стран есть свои фишки, так что аудитория приложения для условной Индии в среднем будет отличаться от пользователей из Скандинавии.

Важные особенности и фишки на примере iOS и Android:


Конечно, в рамках статьи не охватить все-все сложности и особенности, но я постараюсь упомянуть основные:

iOS


  • В сравнении с андроидом, мало устройств, и они не так уж и часто выходят, аналогично и с осями, которые надо учитывать.
  • Проще держать адекватный усредненный набор типов экранов и не забывать что у некоторых есть retina, это может быть важно для некоторых типов тестов. Но, конечно, не всегда. Тем не менее, основные баги по верстке можно словить на комбинации четырех-пяти айфонов от пятого до одиннадцатого. И не забывайте про шторку!
  • Учитывайте, какие вы поддерживаете версии iOS и старайтесь сделать так, чтобы они равномерно распределялись по устройствам.
  • Не забывайте про магию Split View режима и старайтесь держать хотя бы одно устройство, которое его поддерживает
  • Проблемой при закупке может всегда возникнуть цена, особенно, если вы стараетесь выпускать адаптированные версии в первую же неделю продаж но, с другой стороны айфоны и долго не протухают, так что это можно считать долгосрочным вложением. Конечно, кто-то тут может со мной поспорить, но на моей практике именно техника Apple жила дольше при постоянном использовании для нужд тестирования.


Android


  • Очень много устройств и это боль. И тут точно никуда без аналитики потому что именно на ней и должна в случае андроида оцениваться ваша аудтория, иначе придется покупать что попало, а это не приводит к продуктивным результатам. Опять же, есть соблазн тестировать на том, что модно, современно и быстро работает, но если ваши юзеры сидят на китайских Oppo то вы можете и не узнать, что там, оказывается, ничего и не запускается.
  • Учитывайте особенности оболочек андроида и сторов особенно внимательно надо работать с теми, которые отключают по умолчанию сервисы Google Play, в том числе и стор. Старайтесь держать в парке разные варианты, в том числе и голый андроид.
  • Если с планшетами в Apple все довольно просто, то в андроиде это чистое безумие, потому что большинство из них имеют старые оси, плохого качества экраны и очень медленное железо. Конечно, этого и стоило ожидать от планшетов за 1999 рублей, но если ваша аудитория ими пользуется, а вы делаете тяжелую игрушку, то ее может вырубать прямо на старте. Пример из жизни: компания, в которой я работала, заключила контракт с одним из производителей телефонов о том, что они предустанавливают наше приложение к ним, но когда телефоны пришли в офис оказалось, что в них настолько мало памяти, что не запускаются даже предустановленные приложения из коробки. Пришлось, конечно, упрощать наш сервис.
  • Помните, что несмотря на традиционное отношение к андроиду, как дешевым телефонам, в последние годы их флагманы стоят сравнимо с флагманами Apple, а то и больше, к тому же у них часто появляются такие экспериментальные особенности, как скошенные экраны, раскладушки и прочее.


Где покупать?


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

  • Официальные представители: да, часто это может быть дороже, но зато скорее всего это более надежно и лучше гарантия. И лайфхак для тех, кто дочитал до этой части статьи: не всегда, но часто, если написать письмо в представительство определенного производителя о том, насколько вам нужно определенное устройство, объяснив, как вы будете его использовать, вам могут выслать его или бесплатно и навсегда, или во временное пользование. А это часто очень актуально.
  • Розничные магазины: тут я объединяю все магазины, которые продают не левак, с чеками и гарантией, например, своей. Серый не всегда плохой, особенно это может касаться айфонов, например. Главное покупать в проверенных местах, а не в палатке на рынке.
  • Avito и прочие: конечно, тут я объединяю все варианты покупки б/у у частников. Конечно, этого стоит избегать, но если вы осознаете, что вам кровь из носа нужен телефон, который не выпускают уже 3 года, а ваши юзеры упорно им пользуются то иногда стоит пойти на риск.
  • Сотрудники: и еще один лайфхак если спросить у ваших коллег, то наверняка выяснится, что у пары-тройки сотрудников в тумбочке валяется ненужный телефон, который они благородно могут отдать во временное или бессрочное пользование вашему отделу!


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



Узнать подробнее о курсе QA Lead от OTUS.


Подробнее..

Тесты должна писать разработка (?)

19.02.2021 16:11:01 | Автор: admin
Привет! Есть старый холивар на тему, кто же должен писать тесты: разработчики или тестировщики. Вроде как если в команде есть тестировщики, то логично, что тесты пишут они, правда? С другой стороны, ребята из разработки (помимо самой разработки) точно знают, как работает их код и как будет вести себя в тех или иных ситуациях. Как минимум предполагают.


Дисклеймер: меня зовут Эрик Бурыгин, я давно работаю тестировщиком, веду студентов на курсе Инженер по тестированию, поэтому может показаться, что тестировщик просто хочет перекинуть кусок работы на разработчиков. На самом деле у описываемого подхода есть как плюсы, так и минусы, поэтому статья носит в том числе и дискуссионный характер. Буду рад увидеть в комментах мнения как разработчиков, так и тестировщиков.

Если тесты пишет разработка, можно решить сразу несколько проблем, например:

  • Ощутимо ускорить релизный цикл.
  • Снять нагрузку с тестирования.

В большинстве команд процесс выглядит примерно так:

  1. Разработчик создаёт новые фичи и допиливает существующие.
  2. Тестировщик всё это тестирует и пишет различные тест-кейсы.
  3. Автоматизатор, оправдывая название должности, автоматизирует всё по написанным тест-кейсам из п.2.

Вроде бы всё выглядит просто.

Но в этой парадигме есть слабые места.

Допустим, разработчик доделал свою фичу и благополучно отдал её в тестирование. Но фича получилась не medium rare, а откровенно сырая. Это приведёт к переоткрытию задачи и дополнительным фиксам, причём итераций может быть от одной до N, в зависимости от размера этой фичи, её сложности, влияния на смежные процессы, добросовестности самого разработчика. А ещё от того, как у вас в принципе устроены процессы внутри разработки, насколько тщательно смотрятся пул-реквесты, запускается ли приложение перед отправкой на тестирование.

В общем, переменных хватает.

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

Автоматизатор же после получения написанных тест-кейсов покрывает тестами функционал. Здесь есть довольно большая вероятность, что задача попадёт в существующую очередь, поэтому тесты будут написаны с задержкой.

Просто нужно больше разработчиков


Увы, не панацея. Скорее наоборот. Чем больше в этой схеме у вас будет разработчиков, тем сильнее будет нагрузка на тестирование. В итоге будет увеличиваться или релизный цикл, или сама команда тестирования.

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

На восемь разработчиков обычно приходится два тестировщика и один автоматизатор. Автоматизация при этом не участвует в релизном цикле напрямую скорее находится поблизости. И возникает вопрос: как сделать описанные процессы более эффективными, да ещё и не потерять в качестве?

Давайте попробуем сдвинуть этап автоматизации с третьего места на первое, на этап разработки.

Что получится


Получится сразу неплохой набор плюсов, смотрите:

  • разработчики пишут тесты одновременно с написанием самой фичи, что существенно улучшает её качество;
  • падает нагрузка на тестирование: тестировщикам теперь надо посмотреть результаты тестов и оценить, в достаточной ли степени задача покрыта тестами;
  • ручного регресса в схеме больше нет за ненадобностью.

А что тестировщики?

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

При этом надо понимать, что ручное тестирование всё равно никуда не денется у вас всегда будет что-то, что по какой-то причине автоматизировать либо невозможно, либо не имеет смысла.

Так вот, к новой парадигме. Круто же? Да хоть прямо сейчас внедрять. Если получится сделать две вещи.

  1. Продать эту идею разработке. Потому что далеко не каждый разработчик сразу захочет писать тесты, ведь это может быть скучно, или он просто не хочет: у вас, вообще-то, тестировщики вон там для чего сидят?
  2. Продать эту идею менеджерам. Потому что при прочих плюсах у вас увеличивается время разработки каждой фичи.

Какие минусы тут могут вас поджидать.

  1. Большая часть разработчиков просто не умеет тестировать, потому что они разработчики, а не тестировщики. И это нормально. Тут вы можете или научить их тестировать, что будет не самой тривиальной задачей, или просто писать тест-кейсы для них. Что де-факто ломает сам процесс.
  2. На старте автоматизация будет занимать больше времени, ведь не будет кодовой базы тестов, инфраструктуры и привычных подходов задача-то новая.
  3. Будут нужны понятные отчёты для тестирования. Но имейте в виду: даже самый понятный отчёт не всегда можно сразу научиться правильно читать.
  4. Не каждую задачу вы сможете легко и быстро покрыть тестами. В ряде случаев вам придётся на тесты тратить больше времени, чем на саму реализацию фичи.
  5. Масштабные задачи будет сложно отдавать одновременно с тестами, это занимает довольно много времени.
  6. Для этих же масштабных и сложных задач надо будет всё равно закладывать время на то, чтобы просто в них вникнуть, потому что нет другого способа проверить правильность тестов, которые писали разработчики.

Что же делать?




В принципе у каждой из проблем есть решение.

  1. Разработчики не умеют тестировать.
    Можно консультировать их на первых этапах, чтобы помочь разобраться.
  2. Нет кодовой базы, инфраструктуры и подходов.
    Всё решается только временем. На размеченные функции писать тексты проще.
  3. Понятные отчёты.
    В отчёты надо включать все шаги, а название каждого теста должно сразу отражать, что именно им проверяется.
  4. Приходится тратить много времени на ряд задач.
    Спасает здравый смысл: не всё стоит покрывать здесь и сейчас.
  5. Сложно отдавать задачи, когда нет подходов и инструментов.
    Тоже решается постепенно, главное время для анализа и внедрения того или иного инструмента. И это должно быть отдельной задачей.
  6. Проблема масштабных задач.
    Их можно сразу отдавать без тестов либо частично покрытыми тестами. Но это в любом случае не отменяет погружения в контекст.

Вывод


Подход со всеми своими плюсами и минусами имеет право на жизнь. А если ещё и правильно настроить процессы, то это поможет вам и релизный цикл ускорить, и штат не раздувать (:
Подробнее..

К вопросу о сертификации ISTQB

16.06.2021 14:10:53 | Автор: admin
Добрый день, уважаемый Habr. Мне кажется, что у большинства членов комьюнити сложилось довольно скептическое отношение к сертификации вообще и к ISTQB в частности, поэтому не хотелось бы сводить разговор к холивару на эту тему. А хотелось бы обсудить, некоторые моменты, которые лично меня ставят в этом вопросе в тупик, думаю, что похожие проблемы испытывают и другие русскоязычные тестировщики, перед которыми, в силу различных причин, стоит задача получения сертификата.

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

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

Англоязычный глоссарий:

test procedure: See test procedure specification

test procedure specification: A document specifying a sequence of actions for the execution
of a test. Also known as test script or manual test script. [After IEEE 829] See also test
specification

test specification: A document that consists of a test design specification, test case
specification and/or test procedure specification

test script: Commonly used to refer to a test procedure specification, especially an automated one

test case: A set of input values, execution preconditions, expected results and execution
postconditions, developed for a particular objective or test condition, such as to exercise a
particular program path or to verify compliance with a specific requirement. [After IEEE
610]

******** Те же термины из русско-язычного глоссария ********

процедура тестирования (test procedure): См. спецификация процедуры тестирования.

спецификация процедуры тестирования (test procedure specification): Документ, описывающий последовательность действий при выполнении теста. Также известен как ручной сценарий тестирования. [IEEE 829] См. также спецификация теста

спецификация теста (test specification): Документ, состоящий из спецификации проектирования теста, спецификации тестовых сценариев и/или спецификации процедуры тестирования.

автоматизированный сценарий тестирования (test script): Обычно используется как синоним спецификации процедуры тестирования, как правило, автоматизированной.

тестовый сценарий (test case): Набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнения определенного пути программы или же для проверки
соответствия определенному требованию. [IEEE 610]

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

Ну что же, идем в англоязычный глоссарий, и видим, что несмотря на упоминание об автоматизации этот терми содержит и другой посыл Commonly used to refer to a test procedure specification. Идем по указанному посылу где смысл начинает плавно меняться: A document specifying a sequence of actions for the execution of a test. Also known as test script or manual test script.

Опа, и нас переносит из области автоматизации в прямо противоположную ей область: Also known as test script or manual test script. Таким образом, выходит, что тестовый скрипт это все же нечто иное, чем скрипт, написанный для автоматизации теста. Но тогда что же это? Буду весьма обязан, если кто-нибудь из специалистов возьмет на себя труд принять участие в обсуждении этой группы, связанных между собой терминов.

По всему выходит, что центральной фигурой здесь выступает test specification на которую, в конечном итоге замыкаются все ссылки англоязычного глоссария: test specification: A document that consists of a test design specification, test case specification and/or test procedure specification. Как видите он собирает в себя вообще все, что можно, и вместо поставленной задачи разобраться в различии между терминами test script и test case, мы вдобавок, получаем кучу новых понятий никак не проясняющих, а лишь усугубляющих наше (ну мое по крайней мере) недоумение.

Очень бы хотелось прильнуть к неиссякаемому источнику коллективного разума, чтобы найти объяснение всем вышеуказанным терминам и тому, как они соотносятся друг с другом. На экзамене и в учебнике, написанном авторами всей документации по ISTQB, идет постоянное жонглирование этими терминами и многие вопросы строятся на попытке подловить испытуемых на их толковании.
Подробнее..

Белковый тестировщик

19.01.2021 18:13:47 | Автор: admin

Вступление

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

Тип нервной системы

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

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

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

Зрение

В подавляющем большинстве случаев тестировщики получают информацию через зрительный канал. При этом человек отчётливо видит только те объекты, проекция которых попадает на область сетчатки глаза, называемую центральной ямкой и состоящую из колбочек. Колбочки это светочувствительные рецепторы глаза, отвечающие за дневное зрение и имеющие нередко отельные нейроны. Диаметр центральной ямки соответствует приблизительно двум градусам поля зрения. Следовательно, только пара градусов вокруг точки фиксации взгляда воспринимаются человеком отчетливо. Помимо этого, область, где волокна зрительного нерва соединяются с сетчаткой глаза, вовсе лишена светочувствительных рецепторов. Эта зона называется слепым пятном и занимаем промежуток поля зрения между 10 и 20 градусами по горизонтали от точки фиксации взгляда. Однако мы воспринимаем мир отчетливо, без выпадающих фрагментов. Это связано с тем, что головной мозг умеет достраивать восприятие, основываясь на предыдущем опыте. При этом данная часть отражаемого мира является иллюзорной. Особенно это очевидно, если взглянуть на иллюзию, обнаруженную физиологом Лудимаром Германом.

На пересечении белых линий мы видим серые пятна, хотя в действительности их там нет.

Иллюзия Мюллера-Лайера демонстрирует влияние прошлого опыта на восприятие.

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

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

Итак, выполняя тестирование следует учитывать, что адекватную информацию о продукте возможно получить только на точке фиксации взгляда. Способ с быстрым прокликиванием сайта, надеясь, что таким образом все недостатки будут обнаружены, является неэффективным. В таких условиях максимум, что мы сможем наблюдать это способность человеческого мозга воссоздавать зрительный мир на основе предыдущего опыта. Эффективнее будет подходить к тестированию, как к процессу постоянных замеров, для проверки заранее подготовленных гипотез.

Внимание

Внимание человека от части зависит от характеристик раздражителя. Одной из таких характеристик является интенсивность. Рассмотрим элементы веб-страницы известного поисковика.

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

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

Здесь обнаружить пропавшую ссылку становится еще сложнее. Это связано с колебаниями внимания: очень много интенсивных изменений.

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

В XIX веке Вильям Гамильтон провел эксперимент по измерению объема внимания. Он бросал горсть бобов в ящик и пытался определить их количество. Оказалось, что ответы точные, если количество бобов не превышает 6-7 штук.

Век спустя Дональд Бродбент использовал методику дихотомического слушания для изучения механизмов внимания. Суть методики заключается в том, что в одно ухо испытуемого предъявляются три цифры, а в другое (в то же самое время) три други цифры. В одном случае испытуемых просили воспроизвести цифры, предъявляемые через какое-либо ухо. В другом случае их просили воспроизвести в порядке предъявления. Ожидалось, что точность ответов будет около 95%, т.к. воспроизвести необходимо всего 6 элементов. Но в обоих экспериментах результаты оказались значительно ниже. В первом случае верность воспроизведения была около 65%, а во втором 20%. Бродбент объяснил эту разницу необходимостью во втором эксперименте чаще переключать внимание.

Дэниел Саймонс и Дэниел Левин провели эксперимент, в котором помощник экспериментатора с картой университетского городка в руках просил ничего не подозревающих прохожих показать дорогу до близлежащего здания. После 10-15 секунд разговора, между помощником и прохожим протискивались двое других помощников, несущих дверь. В это время первый помощник подхватывал задний конец двери, а помощник, который прежде нес эту часть двери, оставался стоять за дверью и продолжал спрашивать дорогу. Если смотреть со стороны прохожего, дверь на короткое время скрывала его собеседника, а когда ее уносили, перед ним оказывался другой человек. Два помощника были по-разному одеты и различались ростом примерно на 5 см. Их голоса также явно различались. Оказалось, что более 50% испытуемых не обнаруживали подмену людей.

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

Итак, находить баги значительно проще, проводя тестирование на стабильном стенде. Нельзя упускать возможность дробить продукт на модули и тестировать сначала изолировано каждый модуль, а затем переходить к системному тестированию. Каждый присутствующий баг в продукте снижает вероятность обнаружения другого бага из-за возрастания колебания внимания. Не бойтесь возвращать задачу на доработку, обнаружив только основные баги. Дальнейшее тестирование забагованной функции мало эффективно. Учитывайте, что ожидаемый результат желательно зафиксировать в визуальном виде и держать при себе во время тестирования. Помните, что переключение внимания сильно снижает качество тестирования. Старайтесь не прыгать по задачам, а доводить начатое до завершения. Автоматизируйте все повторяющиеся процедуры. Взаимодействуйте с группой людей не более 7+-2 человека, т.к. большее количество людей превысит объем вашего внимания.

Установки

Дмитрий Узнадзе проводил эксперимент, во время которого испытуемым предлагалось несколько раз ощупывать правой рукой маленький шар, а левой большой. Затем в обе руки помещались одинаковые шары. Но испытуемым казалось, что в правой руке шар большего размера, чем в левой.

Абрахам и Эдит Лачинс предлагали испытуемым решить мыслительную задачу: при помощи трех сосудов получить нужный объем воды.

С 1 по 8 задачи решаются по формуле b - a - 2c, а вот 9 решается более простым способом a - c. Оказалось, что успешно преодолев первые восемь задач, испытуемые не могли справится с простой девятой.

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

Мышление

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

Полученные результаты говорили о том, что наводящие задания, выполняемые перед основным, никак не влияют на успех. Однако если испытуемые получали наводящие задание после неудачных попыток решить основное решение основного задания приходило на ум мгновенно.

Итак, стратегия составления перед тестированием исчерпывающего плана может оказаться не такой эффективной, как кажется на первый взгляд. Вся информация, которую вы обдумаете перед тестированием, во время тестирования будет недоступна в силу особенностей человеческого мышления. Лучшие результаты можно получить проводя тестирование в несколько этапов. На первом этапе мы проводим первичный сбор информации. Затем выполняем тест-кейсы из списка основных возможностей функции, при этом параллельно исследуем тестируемую функцию и накапливаем нужную информацию. Далее, на основе полученных данных во время первичного тестирования, готовим новую группу тест-кейсов и выполняем второе тестирование. Важно помнить, что во время тестирования вам обязательно придут на ум тест-кейсы, о которых на стадии планирования вы даже не догадывались.

Заключение

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

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru