1. Стратегию тестирования описываю в тест-плане.

2. Работа отдела, Работы с ошибками, Написания сценариев и пр - это больше относится к внутренней документации отдела.

P.S. Это личные выводы.

Спасибо, полезная статья.

 

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

Я задавал ему кучу вопросов. Что будет, если я добавлю тут спецсимвол? Что будет, если я не заполню это поле? Затем мы сразу же пробовали проверить это на практике в среде разработчика.

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

Был подобный случай.

Результат такого подхода был следующим:

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

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

- У разработчика появляется уверенность того, что с тобой(тестировщиком) можно и по другим фичам/проектам использовать такой подход.

- Приходит к тебе(тестировщику) понимание того, что разработчик не будет действовать по принципу: "И так сойдет".

- Зачастую такие проекты гораздо качественне.

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

- Ну и самое может банальное, просто хорошее человеческое отношение между тобой(тестировщиком) и разработчиком.

P.S. Да, звучит как утопия. Если кто был в такой ситуации - поймет. 

P.P.S С одним из таких разработчиков дружим семьями 

За вчера разобрался с использованием SQL запросов в плане внутреннего и внешнего объединения.

Если кому будет полезно, вот ссылка на уроки по которым. Мне было трудно понять запросы такого типа так нужно было "пощупать" создание таблиц и понять работу с внешними ключами.

Так же понемногу начал ознакомление с тестированием мобильных приложений. Спасибо Molechka за ссылку.

P.S. Не приходилось использовать такие запросы, но когда придет случай, уже знаю что да как =)

 

В последнее время несколько раз пришлось использовать sleep.

1. На странице примерно 40 динамических полей, каждое из которых сохраняет значение при клике на другой элемент. 

Если не использовать sleep то доходит до того, что летит 30+ запросов на сохранение и некоторые отваливаются по timeout.

2. Есть необходимое условие - загрузка 10 фоток на странице, загрузка идет по 1й фотке.

Если без остановки заливать одну за другой, то от такой скорости загрузки валятся скрипты и следовательно что-то не сохраняется.

 

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

 

2 недели доказывал разработчикам то, что пользователь возможно столкнется с подобной ситуацией.

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

В конце сказали примерно так: "Если все таки пользователь столкнется с такой проблемой, то тогда будем думать."

В последнее время несколько раз пришлось использовать sleep.

1. На странице примерно 40 динамических полей, каждое из которых сохраняет значение при клике на другой элемент. 

Если не использовать sleep то доходит до того, что летит 30+ запросов на сохранение и некоторые отваливаются по timeout.

2. Есть необходимое условие - загрузка 10 фоток на странице, загрузка идет по 1й фотке.

Если без остановки заливать одну за другой, то от такой скорости загрузки валятся скрипты и следовательно что-то не сохраняется.

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

Советую Вам удалиться с такими предложениями.

Если нужно чекать ссылки на сайте попробуйте юзать Xenu, Screaming frog или аналогичные тулзы.

Давайте посмотрим в корень проблемы, сайты на которые вас ведет редирект, сторонние?

2.2.2. Важность требований

Продуктная документация (product documentation, development documentation49) используется проектной командой во время разработки и поддержки продукта.

Она включает:

o План проекта (project management plan50) и в том числе тестовый план (test plan51).

o Требования к программному продукту (product requirements document, PRD52) и функциональные спецификации (functional specifications53 document, FSD54; software requirements specification, SRS55).

o Архитектуру и дизайн (architecture and design56).

o Тест-кейсы и наборы тест-кейсов (test cases57 , test suites58).

o Технические спецификации (technical specifications59), такие как схемы баз данных, описания алгоритмов, интерфейсов и т.д.

Отдал сегодня своим стажерам это на прочтение, на что получил закономерные вопросы:

- "А как тогда тестировать если всей этой документации нет?"

- "Бывают ли вообще проекты со всей этой документацией?"

- "А можно ли требовать это документацию?"

- "У кого ее требовать?"

На основе своих наблюдений пришел к выводу:

Начинающий тестировщик, прочитавший данную информацию, придет на свое первое место работы и просто впадет в ступор.

Впадет в ступор потому, что:

- документации всей может не быть

- вообще может не быть документации

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

- восприятие такой информации он может принять за общепринятую стандартизированную практику, которая применяется везде,

но в действительности это далеко не так.

Спросил отдел разработки о таком кол-ве документации. На что получил от сеньеров внятный ответ:

"пункты 2 и 5 достаточно часто бывают, 3 реже, но тоже делают"

Так же один из фронтендщиков сказал такое: "А зачем вся эта документация для сайта-визитки?". 

Вроде бы он пошутил, но на самом деле стоит задуматься.

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

Так же хочу отметить, что 8 этапов в разделе "2.1.2. Жизненный цикл тестирования" перенасыщает начинающего тестировщика

информацией. Проще для понимания описано в книге Савина, там всего 3 пункта и они достаточно содержательны для базового понимания.

P.S. Все это исключительно личное мнение и наблюдение за своими стажерами.

 

Антон, по первому пункту про отсутствие (или низкое качество) документации ситуация явно выходит за рамки обсуждения книги :). Если вернуться к контексту, то:
1) Я рассматриваю обучение "совсем начинающих" по аналогии с автошколой: сначала учим ПДД и "как правильно". Если есть желание ездить как в "Mad Max: Fury Road", то это это будет потом, в особых случаях при понимании и осознании всех условий и последтвий.
2) У начинающих тестировщиков и так часто бывает ступор, но информация о документации даёт хотя бы какой-то ориентир. Даже если документации нет: появляются идеи о том, какие вопросы задавать.

3) Чем больше будет людей, которых "с пелёнок" приучали к адекватным процессам, тем быстрее эти процессы станут адекватными. Да, не сразу. Но если ничего не предпринимать, ситуация точно не будет улучшаться.

 

1. Для начала, как мне кажется, нужно сначала показать новичку "автомобиль" и "дороги", чтобы он сам задал  правильный вопрос: "А как ездить по дороге?".

2. Стоит новичкам в одном предложении отметить, что в зависимости от ситуации может быть та или иная документация.

3. Абсолютно согласен, что надо приучать "с пеленок". Правда можно донести до читателя(новичка), что бывает не всегда так и стоит стремиться к таким "адекватным процессам".

Святослав, лично для себя считаю эту книгу весьма полезной, как справочник.

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

Я не имею такого опыта, как у вас, в прокачке 150-200 человек в год. Возможно в этой ситуации книга полезна.

Цель критики в адрес книги - сделать ее более понятной для новичков, так как информация в ней действительно полезная.

Алексей, спасибо за пояснение.

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

Судя по количеству вопросов от стажеров - нет.

Опираясь на Ваше мнение - нет.

Вывод очевиден. 

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

Ожидал, что в конце статьи будет описан подход автора, но увы. =(

 

 

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

^{Надеюсь, те кто будут читать статью, не будут слепо следовать такому совету.}

^{Здесь не указан немаловажный фактор, как популярность устройства.} 

^{Так же при попытке определить схожесть устройства по общим параметрам, нужно обязательно учитывать "железо" деваса.}

^{Приведу пример.}

^{На проекте используется технология WebGL.(да, это сайт, но дочитайте до конца, пожалуйста)}

^{Есть 2 девайса на тестирование: samsung S3 и S4.}

^{Если покопаться в деталях, можем обнаружить, отличаются GPU у этих устройств. Другие различия нам сейчас не интересны.}

^{Если проигнорировать, как мне предлагали менеджеры проекта: "Да чего ты паришься, оба одной фирмы. Да проверь на последнем(S4) и все".}

^{Но тут самое интересное.}

^{GPU на S3 Mali-400 MP. Как выяснилось в процессе тестирования, его драйвер имеет проблемы при работе с WEbGL(он просто блочит WebGL).}

^{К сожалению ссылку которую нашел прошлым летом не могу найти, думаю многие догадаются почему =)}

^{Но если погуглить, то можно найти тому не один апрув.}

^{Так что, если выкидываете девайс из списка тестов, хорошо подумайте.}

P.S. этот gpu установлен на многих девайсах.

Добрый день уважаемые форумчане!

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

Буду рад любым советам.

Сам тестированием мобильных приложений никогда не занимался(только веб и гейм-дев).

Заранее спасибо!

Проверьте вход и регистрацию под максимально возможным количеством вариантов.

А то вдруг, например, если ВК и ФБ зареганы на 1 email, можно будет войти только через то, что зарегали первым?

Благодаря Оле, вспомнил 1 кейс.

Есть пользователь к аккаунту которого был привязан мой вк.

Регистрирую нового пользователя и нажимаю "Использовать учетную запись соц.сети" (в данном случае использовал вк)

И о чудо! Я залогинился под тем пользователем с моим вк.

Специфичных кейсов не встречал.

Обычно хватает просто залогиниться через соц.сеть.

Если вы будете проверять логин в соц.сети, то это как бы не ваша уже компетенция, а компетенция тех кто тестирует соц.сеть =)

Я может что-то не понимаю, но Зачем проверять тот же самый функционал под разными ролями?
Одной проверкой првоеряешь, что функционал пашет.

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

Наверное потому, что может быть такой сценарий:

Выставил права в админ-панели, а в БД флаг не был установлен. Может быть так, что к БД нет доступа.

Как Вы в таком случае будете утверждать что эта роль имеет соответствующие права?

А вы думаете это просто проверять верстку автотестами?)

Ну оно то теоретически возможно, но оно того не стоит.

Запускаю автотесты на FF. 

В остальных браузерах поверхностно пробегаюсь по остальным браузерам.

Недавно на одном из приложений для IOS ввел всем известный набор символов "لُلُصّبُلُلصّبُررً ॣ ॣh ॣ ॣ

冗" - ничего не произошло. Но если удалить 2 последних символа то приложение падает, актуально для iphone 5s.

У знакомого IOS разработчика от этого набора символов xcode повис =)

P.S. Фейсбук запрещает публиковать этот текст

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

 

Тут уместно вспомнить про LightSail, беспилотный космический корабль на солнечных батареях, который недавно потерял связь с Землей из-за ошибки в софте, и только спустя несколько дней смог перезагрузиться и возобновить обмен данными.

 

Поделитесь, с каким наиболее критическим багом сталкивались лично вы в своей практике?

 

Из моего опыта (конечно, размах трагедии не тот) – баг в ММОРПГ, при котором сервер передавал право на определение того, что это за предмет, клиентской части. Багоюзер ловил пакет какой-нибудь дешевой бесполезной фигни, подменял его на что-нибудь ценное, а дальше производил с предметом ряд манипуляций в игре. При определенной последовательности манипуляций сервер начинал доверять клиенту и воспринимал предмет, как ценный. Баг был выловлен при обнаружении, что экономика сервера падает стремительным домкратом, так как ушлые игроки вовсю начали багом пользоваться. Последовательность действий с предметом была такая, что, наверное, ни одному тестировщику в страшном сне бы не привиделось это проверять.

 

Расскажите о своем опыте, интересно)

по поводу бага в ММОРПГ - это было в Lineage 2. Он в паблике очень долго висел.

Работал как-то в игровой конторе.

Был багнутый навык:

Каждый 6 секунд в течении 1 минуты вводит персонажа в состояние невидимости.

Навык мог получить только 1-2 игрока на сервере.

Баг висел с момента открытия проекта, 2 года примерно. Писали разрабам(китайцам) - толку ноль. Ответ был в стиле: "Мы не можем его воспроизвести".

Баг заключался вот в чем: с определенной вероятностью крашатся клиенты у игроков которые видят игрока использующего этот скил.

Так как загруженность у меня была небольшая, мне дали его на тест. Время воспроизведения этого бага колебалось от 2 минут до 4 часов.

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

После недели возни с этим багов и ковыряния в логах, путем опытного тыка нашел ошибку.

Проблема была в анимации, так как пути к этой анимации, как и самой анимации попросту нет.

Отправил баг-репорт разрабам.

Они написали что у них все норм, но исходник анимации не предоставили.

По просьбе продюссера проекта начал думать это исправить.

Сделал то, что первое взбрело в голову: создал нужные директории и положил туда изображение весом в 10+ Мегабайт,

так как если кидать меньше картинку - в логах писалось что этот файл не может быть меньше 10Мб.

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

Однако при продолжении атаки игрока с багнутым скилом, все становится нормально.

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

Ну а так как все правки были у меня локально, этот баг не исправили.

Через неделю мне по скайпу звонил QA-лид и просил обьяснить как я его правил.

Но у него ничего не получилось. Так что по сейчас в этой игре есть этот баг.

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

Затем автоматизируйте их.

P.S. Старайтесь не использовать много логики в тестах без лишней необходимости, так как это может усложнить редактирование таковых.

Для начала задайте себе вопрос, насколько эффективно будет внедрение автоматизации?

На мой взгляд автоматизация нужна на проектах, которые длятся от 3х месяцев и выше.

Только после положительного ответа на вышеуказанный вопрос стоит думать уже об инструментах.

Автоматизация - это прежде всего инструмент, а не панацея.

Конечно,это может быть очень смешно,но я реально попросил помощи. спасибо за ваши "умные" ответы

Ответ заключается в знании теории. Посмотрите здесь что такое регрессионное тестирование.

А вот тут что такое ручное тестирование.

Выводы делайте сами.

 

Приветствую!

На сей раз у меня возникла проблема с написанием теста для проверки регистрации и восстановлением пароля.

Для регистрации использую сервис одноразовой почты dropmail.me

Реализовано:

1. Заходим, забираем почтовый ящик

2. Открываем новую вкладку, переходим на целевой сайт

3. Регистрируемся 

4. Разлогиниваемся и "забываем пароль"

 

Не реализовано:

3.1 Добавить проверку, что регистрация прошла успешно

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

    б) сам пароль (всегда 8 символов), который нужно сохранить в переменную, чтобы потом залогиниться

    а) ссылка, на которую надо кликнуть для подтверждения изменения пароля (откроется окно)

6. Залогиниться с новым паролем

7. Проверить, залогинился ли

 

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

 

PS: может посоветуете сервис одноразовой почты поприветливее интерфейсом, чтобы письма без задержек приходили (mail temp сначала нормально присылал, потом стал с задержкой в 1+ час)

 

1. Откажитесь от использования сторонних сервисов, того же почтового ящика.

Можно выдергивать данные прямо из бд.

2. Проверка того что пользователь зарегистрирован, можно тоже через бд. Там может стоять флаг и запись в таблице users

3. Ссылку на подтверждение тоже можно "дернуть" из бд

4. Проверка залогинен или нет может быть тот же аватар или ссылка на личный кабинет, в зависимости от логики.