Перейти к содержимому

Управление требованиями
онлайн, начало 6 июля
Комплексная система подготовки тестировщиков по программе ISTQB FL
онлайн, начало 28 июня
Тестирование юзабилити (usability)
онлайн, начало 28 июня
Школа Тест-Аналитика
онлайн, начало 5 июля

Рейтинг Контента


#98005 С чего начать в тестировании?

Написано Natalya Rukol 01 Декабрь 2011 - 01:23

Если вы думаете, что хотите работать в тестировании - подумайте ещё раз :)

Если вы абсолютно точно уверены в своём желании - следуйте следующим принципам:

1. Старайтесь как можно раньше найти работу. Курсы, книги, статьи - лишь помощь в работе, а не наоборот!

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

3. Читайте книги, читайте много книг! Так вы очень выгодно выделите себя среди "покликать пришёл".

4. Если вы хотите стать разработчиком, аналитиком или РМом, то работа в тестировании вам никак не поможет. НИКАК! Идити в разработку или аналитику, не тратьте попусту своё время и нервы коллег.

5. Тестирование - обширная область, выберите интересный для вас вектор развития. Специалисты по анализу, автоматизации, безопасности, нагрузке, юзабилити, управлению - это совсем разные тестировщики. Попробуйте всё, выберите интересную область для развития и специализируйтесь.

6. Самое главное при устройстве на работу - опыт. Как его получить, если без него работу найти сложно? Регистрируйтесь на uTest.com и fixber.ru, тренируйтесь, указывайте этот опыт в резюме.

to be continued...
  • 23


#144022 задача - тестирование подсчета типа треугольника

Написано mike1999 11 Сентябрь 2015 - 09:22

"тестирование подсчета типа треугольника"

Я вот в тестировании 8 лет, на текущей работе уже тест-лид, сам собеседовал не раз. Решил сменить компашку, до этого собеселования нигде не проходил. И что вы думаете - на первом же интервью мне выдают задачу (дословно):

"- Составьте пожалуйста список тестов, для функции, на входе которой три параметра, а на выходе треугольник"

повторяю - это была дословная  постановка задачи. И с умным видом он откинулся на спинку кресла.

 

Это мне предложил технарь из компании "Открытые технологии". ТЕХНАРЬ БЛ& !!! Я вот конкретно эту задачу не встречал, и догадаться что за параметры передаются в функцию не мог. Попробывал было задать наводящие вопросы, что мол за значения в параметрах? (ну там длины это или тройки координат в пространстве) на что был ответ - типа "...вы мне скажИте какие это параметры..." ... что за параметры, что за треугольник на выходе. попробуй догадайся.... Ну я ему совставил кейсы для троек координат в пространстве(отголоски текущей работы) ...

 

... к чему это я .. А да... товарищи собеседующие кандидатов, прежде чем тестить кандидата потрудитесь вникнуть в суть задачь. Оригинальная задача звучит так: "Составьте список тестов для функции, в которую передается три значения длин, а на выходе функция выдает - одно значение BOOLEAN - true, если существует треугольник со сторонами такой длины, и false если не существует".

 

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

 

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

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

 

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

Форма намеренно заторможена на нажание кнопки "0" - пауза секунд 5.

Правильный пароль известен.

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

Все кидаются проверять и перебирать пароли.

Как результат :

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

Половина вводит только пятизначные значения.

Половина вводит только цифры.

95% не проверяют вход при пустом пароле и вход с пустым паролем о комбинациях(0/NULL) я уже не говорю.

95% не проверяют кнопку "Отмена".

95% не уточняют может ли пароль содержать спецсимволы с клавиатуры терминала.

Один человек за 3 года проверил смену языка.

Никто не проверяет добавление к правильному паролю других цифр и спецсимволов.

Никто не проверяет обрезанный с конца пароль.

 

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

 

 

Ох скока я понаписал...


  • 12


#99835 Гуру выскажите своё мнение

Написано astenix 21 Январь 2012 - 04:35

Перенумеровал вопросы, чтобы впоследствии было проще их идентифицировать.

1)
Что такое функциональное тестирование, в чем отличие от GUI тестирования?

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

Нет.

Во-первых, ответьте на другой вопрос: "Что надо тестировать в контексте функционального тестирования?"

Ответ на этот вопрос выведет вас на правильный ответ о том, что такое функциональное тестирование.

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


GUI тестирование - это тестирование интерфейса приложения согласно требованию (иногда без требований) и по определенным правилам (для web свои правила, для windows приложений - другие и т.д.)

Да.

После слова "приложения" сделайте смелую точку.


2)
Что такое метод черного ящика?

это метод тестирования без знания (понимания) кода, на котором написано приложение.

Нуууу, почти...

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

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

Кстати, выражение "метод черного ящика" не очень грамотное. Следует говорить более высоким штилем, вроде "тестирование методом черного ящика".

Можете нагуглить на яндекс.словарях определение слова "метод"?


3)
Что такое исследовательское тестирование?

это тестирование без определенной стратегии.

Нет.

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

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

Посмотрите описание источника этого подхода - есть целая книга под названием “Secrets of a Buccaneer-Scholar“ от автора этого вида тестирования. Конечно, не обязательно читать всю книгу, чтобы понять суть - достаточно предложенной по линку статьи. Там как раз 5 000 слов :)

Термин, кстати, озвучен (и понят) неправильно, бо в обратном переводе его понимание очень резко меняется. Исследование = research, а не exploration. Надо говорить "Тестирование методом свободного поиска" - много об этом знает Алексей Баранцев и тренинги по этому делу проводит.


4)
Как проверяется спецификация?

не понял вопроса. Подскажите плыз...

Что такое "спецификация"?

Чем "спецификация" отличается от "требований"?

Что от чего зависит и что из чего проистекает?

Яндекс.энциклопедия рулит.


Что такое:
5.1)
стратегия тестирования

Стратегия тестирования - это анализ спецификации (требований) с целью уменьшить кол-во тест-кейсов, не утратив при этом качества теcтирования.

Нет.

Что такое "стратегия" вообще?


5.2)
план тестирования,

План тестирования - определяет объекты тестирования, фокус усилий при тестировании, приоритеты, методы, какие инструменты будут использоваться. Это самый большой из тест-документов, определяющий как будет происходить тестирование.

Вместо того, чтобы ответить "что это" вы ответили на вопрос "что оно определяет".

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

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

Не факт, что это самый большой документ ;)


5.3)
test script,

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

Опыт не всегда помогает определить термины.

В разных ситуациях под этим термином подразумеваются разные артефакты.

Что такое "скрипт"?


5.4)
check list,

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

Чек-лист - список того, что нужно проверить.

To-do list — список элементарных действий для достижения какой-либо цели

Check list — список, содержащий ряд необходимых проверок для какой-либо работы, по резултатам прохождения списка мы сможем узнать состояние/корректной этой самой работы (понятие растяжимое, тут может быть как и дизайн проекта, так и работоспособность чайника)

у каждого действия может быть проверка, иерархию можно строить сколь угодно сложную, но зачастую этого не нужно, вот пример to-do листа:

Выход на работу:
— Одеть пальто
— Обуть туфли
— Надеть шляпу

В тоже время пример check list-a
(check list: проверка внешнего вида)
— чистота пальто
— блеск туфель
— прямота шляпы

Сами проверки так же заключают в себя действия, но список этих проверок это check list.

- Читать.
- Читать.
- Читать.


5.5)
test case,

test case - набор условий и данных, который определяет: совпадает ли реальный результат выполнения определенного требования с ожидаемым. Т.е. есть ли баг или нет.

Нет, у вас слишком упрощенное определение.

Что такое "кейс" (в оригинале - 'case')?

Зачем нужно придумывать кейсы для того, чтобы что-то протестировать?


5.6)
User Story,

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

http://ru.wikipedia.org/wiki/User_story


5.7)
Use Case?

Use Case -это формат требования, который четко определяет конкретную операцию, выполняемую юзером.

Так просто? :)

http://ru.wikipedia....й_использования


6)
Что такое и для чего используется парное тестирование?

буду рад подсказке

Совершенно логичное определение: "Парным бывает молоко. Вот и тестирование бывает таким же" :)

На деле же вот http://citforum.edun...testing/tandem/


7)
Дано поле ввода числовой оценки. Ограничения – значение от 1 до 100, целые и дробные (десятичная до десятых долей). Назвать классы эквивалентности и граничные значения для числовой оценки, привести пример позитивного и негативного тест-кейса.

тут у нас две границы 1 и 100 и три эквивалентных класса: <1 , >=1 но <=100 и >100.
В данном случае нам нужно три позитивных тест-кейса: взять 1, гдето посреди 1 и 100 (например 50) и взять 100.
и два негативных теста: чуть меньше 1 (например 0,9) и чуть больше 100 (например 100,1).


Давайте это пока пропустим.


8)
Каковы классы эквивалентности и граничные значения при записи CD диска объемом 700 МB?
класса два:<700 и >700 , границы две: 0 и 700 Мб

Тоже пропустим.


9)
Что такое тонкий клиент, толстый клиент, JAVA, Sakai (и город, и программа, и строительная компания...), JIRA, LMS.

Это тонкий клиент, толстый клиент, JAVA, Sakai (и город, и программа, и строительная компания...), JIRA, LMS.

Гуглёж - не болезнь :)


10)
Какое ПО для тестирования вам знакомо (test management)?

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

Тем более, что вопрос явно дурацкий: между термином "ПО для тестирования" и "Система управления процессом тестирования" - маленькая марианская впадина...


11)
Что такое “локализовать баг” и как это сделать?

Подразумевается "определить местонахождение дефекта". Можно просто сообщить о том, что есть дефект. А можно сообщить, где именно он находится - или сразу в коде, или только в приложении.

Не путать с "локализация ПО", бо второе подразумевает перевод и адаптацию к определенной культуре.


И внимание: overquoting запрещен :)
  • 9


#151452 Пожалуйста, помогите мне с этой задачей

Написано Little_CJIOH 25 Май 2016 - 10:15

Ни один человек на этом формуе задавший конкретный вопрос не уйдет без конкретного ответа.

Ни один человек поднявший проблему и поделившийся своим виденьем не уйдет без фидбека и предложений.

 

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

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


  • 8


#147968 Оклад тестировщика

Написано Nena_X 21 Январь 2016 - 17:19

Блин, читаю и понимаю что я какой то штучный неудачник :) второй месяц без работы сижу и получил очередной отказ потому что нашли кого получше на вакансию обычного QA

 

Алексей, как опытный ИТ рекрутмент консультант дам Вам ряд советов, основанных на анализе резюме с НН: 

 

1) обновление Вашего резюме на НН было 9 января, Ваше сообщение 20 января - надо обновляться каждые три дня, чтобы было много просмотров. НН сейчас основной инструмент поиска персонала.

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

3) в резюме указан перерыв с июня 2015 г. и опять же он ничем не пояснен - проходили ли курсы, занимались ли фрилансом или самообразованием, ухаживали за больным родственником - неясно. Рекрутер может сделать вывод "в 27 лет мужик не работает полгода, наверно он ленивый". Рекомендую этот момент прояснить сразу, то есть в резюме. Это джависты могут год не работать, а потом на 200000 пойти без объяснений, с Вашим опытом такие штуки опасны.

4) то, что ранее Вы работали кладовщиком и в юности продавцом по 2-3 месяца (опять же с перерывами) в разрезе поиска позиции тестировщика неважно. Рекомендую удалить это полностью, либо отобразить как один опыт, например: "Июнь 2006 - Август 2013 - Разные места работы - Обязанности: работал не в ИТ сфере. Параллельно получал образование в направлениии информационной безопасности и изучал то-то и то-то". 

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

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

7) Советую убрать желаемую зарплату - так будет больше звонков, а уже в процессе диалога договоритесь, выясните, совпадают ли ожидаемые вилки у Вас и у работодателя. 

8) в ИТ сфере очень ценится самообучение, поэтому список прочитанных книг или просмотренных онлайн-курсов (помимо имеющихся сертификатов) будет очень большим плюсом.

 

Это только то, что сразу бросается в глаза. У Вас профильное образование, и не одно, Вы молоды и имеете опыт - Вы 100% сможете трудоустроиться, но надо поработать и над резюме, и скорее всего над самопрезентацией и ответами на основные вопросы на интервью (в интернете много тем об этом). Применив мои рекомендации и направив 10-20 откликов на разные позиции - не только на НН, но также проявив активность на ЛинкедИн (написав ряду рекрутеров, разместив пост о поисках) и сделав адресную рассылку в HR отделы ИТ компаний - Вы обязательно получите результат! Надеюсь, мои советы будут полезны не только Вам. Заранее приношу извинения за прямоту - это то, как видит Ваше резюме потенциальный работодатель в лице рекрутера. 

 

Готова провести очную сессию и дать другие рекомендации (конечно, не задаром). Успешно трудоустраиваю ИТшников, сроки получения оффера - от 2 дней =)

 

И удачи в поисках всем ищущим!


  • 8


#98006 Обучение тестировщиков

Написано Natalya Rukol 01 Декабрь 2011 - 01:24

Курсы для начинающих тестировщиков:

 

Школа успешных тестировщиков, v. 2.0
Расширяет кругозор, ускоряет карьерный рост

10 занятий Наталья Руколь

 

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

3 занятия Алексей Баранцев

 

Онлайн-интенсив для начинающих тестировщиков
Стать хорошим тестировщиком всего за неделю? Давайте попробуем! 1 неделя
7 занятий Ольга Киселева

 

Онлайн-интенсив для начинающих тестировщиков (3-х недельная версия)
Стать хорошим тестировщиком всего за три недели? Давайте попробуем! 7 занятий Ольга Киселева

 

Конференции:
SQA Days (крупнейшая очная конференция в СНГ, 2 раза в год)
ConfeT&QA (онлайн, для разных уровней подготовки)

Дополнительно:
Региональные сообщества тестировщиков - отличная возможность общаться с теми, кто "в теме"
Рассылка для начинающих тестировщиков (пока приостановлена)
Wiki для тестировщиков (в процессе создания, помогайте!)
Портал с книгами для тестировщиков (качайте и делитесь!)


  • 7


#109016 Тестирование верстки сайта

Написано aya 25 Август 2012 - 16:07

Не представляю для чего может понадобиться тест-кейс на проверку вёрстки.
Согласен с Freiman что хватит чек-листа со списком браузеров.

Вёрстку часто проверяют в Photoshop или Gimp так:
1. Делается снимок экрана в браузере
2. Добавляется к макету как отдельный слой
3. На добавленный слой ставится прозрачность
И смотрим что и как где свёрстано.

При всём этом, тестировщик должен владеть минимальными понятиями о вёрстке (и более хорошими, если макет составлял не квалифицированный человек (очень сложный для реализации макет)).

Лучше использовать PixelPerfect для Firefox или PerfectPixel для Chrome :)

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

Для тестирования верстки использую этот чеклист: http://habrahabr.ru/post/114256/
  • 7


#35645 Тестовое задание "ListBoxer".

Написано m1st 17 Ноябрь 2006 - 01:24

Здравствуйте!
Слышал, что многие начинающие тестировщики желали бы ознакомиться с тестовым заданием при устройстве на вакансию QA engineer. Предлагаю Вашему вниманию именно такое тестовое задание - программку: "ListBoxer".
Многие начинающие тестировщики ждут Вашей помощи! Это может быть все, что угодно - от ссылок на литературные источники до выполнения самого задания.
Далее текст задания:

Найдите максимальное количество ошибок, намеренно допущенных в программе "ListBoxer".

Полное описание принципа работы программы доступно через меню "Help", после ее запуска.

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

•	Составить план тестирования приложения Listboxer.
•	Расписать тестируемые требования к приложению Listboxer, отдельно указать требования которые нельзя протестировать по каким-либо причинам.
•	Указать функциональность приложения, требования к которой не определены, противоречивы или некорректны.
•	Провести тестирование приложения Listboxer.
•	Предоставить отчеты о найденных дефектах, определить готовность приложения к выпуску.

Скачать программу: Прикрепленный файл  ListBoxer.zip   1,46МБ   4252 Количество загрузок:
  • 6


#156028 Работа с DOM

Написано Little_CJIOH 11 Ноябрь 2016 - 12:51

Это самый адекватный ответ на заданные вопросы. Нефиг садится за штурвал если тангаж от крена не отличаете.

https://www.codecade...om/learn/python
  • 6


#149030 Что нужно делать на новом месте работы?

Написано Freiman 02 Март 2016 - 13:22

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

Вообще у вас была отличная возможность стать менеджером/лидом, набраться опыта и набить шишек - http://software-test...botu-pomoshnik/ - но вы ее профакапили.
  • 6


#145452 Как организовать свою работу и работу помошника?

Написано Freiman 27 Октябрь 2015 - 14:26

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

Что делать?
1. Выделить на новичка определенное количество времени и в строго определенные часы. Например, 9-9.30, 13-13.30, 18-18.30
Это может снизить его производительность, но повысит вашу. В данном случае, как я понимаю, ваше время сильно важнее, ибо релиз.

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

3. Попросить поизучать систему методом свободного тыка. Ужасно неэффективно, но иногда других вариантов нет.
Дайте ему список вопросов для изучения - какие пользовательские задачи решает продукт, как работает контроль доступа, с какими внешними системами может взаимодействовать продукт (платежи и пр.), итд итп.
  • 6


#120783 FAQ: отчет об ошибке. Как, что, зачем? Шаблоны баг-репортов

Написано ch_ip 11 Август 2013 - 16:09

Исходно к созданию данного FAQ послужил пост Sana в этой ветке форума:

помогите, пожалуйста, найти/составить приближенный к идеалу отчет про ошибки (такой себе шаблон)

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

что еще добавить/изменить? было бы не плохо посмотреть на пример

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

Итак, подборка ссылок из интернета (дополнения приветствуются):
Статьи


Доклады
50. Прекрасный доклад Алексея Лянгузова на SQA Days "Грамотная работа с дефект-трекером — путь к успеху". Очень подробно о том, как именно писать ошибки (а вы знаете 4 способа написания заголовков?) и о том, что еще можно делать с БТС

51. "Как заводить баги понятно всем" — доклад Казначеевой Анастасии на SQA Days-11
52. Доклад Сергея Атрощенкова Отчеты об ошибках, или как просто встать на путь постоянного совершенствования с конференции confetQA

Обсуждения на форумах:
71. Обсуждение на этом форуме, как писать баг-репорты, для начинающего тестировщика с примерами шаблонов
72. Ссылка на тему-рекламу семинара Сергея Мартыненко "Как описать дефект". Уже из программы семинара можно получить ряд вопросов, над которыми стоит задуматься
73. Пример, почему не всегда надо заносить все дефекты в баг-трекер (хорошее обсуждение темы, все ли баги надо заносить в баг-трекер)
74. Пример испльзования стандартных терминов при описании бага, чтобы его было легче найти (и не заводить дубликаты)
75. Обсуждение добавления скриншотов к описанию ошибки на этом форуме
76. Классификация полей в отчетах об ошибке (рекомендую прочитать все обсуждение. Полезно, несмотря на давность лет)
77. Как правильно ловить баги — инструкция для бета-тестировщиков игр с описанием того, как заводить баг-репорт.
78. Как правильно писать отчет об ошибке - объяснение на пальцах для блондинок
79. Обсуждение описания ошибки про сообщение об ошибке. Очень интересное обсуждение с разными вариантами описания одного и того же бага, а также споров на тему, что надо включать в отчет об ошибке, а что нет.

Другое

P.S. ключевые слова для поиска: Issue Document, bug report, defect report, issue report, отчет об ошибке, работа с багтрекером, описание бага, описание ошибки, шаблон бага, шаблон ошибки, bug template, issue template


  • 6


#115251 Selenium 2.30/31: падение после закрытия алерта

Написано barancev 28 Февраль 2013 - 19:07

Конструктивно, как исправить -- теперь метод должен выглядеть примерно так:

  private String closeAlertAndGetItsText() {
    try {
      Alert alert = driver.switchTo().alert();
      String alertText = alert.getText();
      if (acceptNextAlert) {
        alert.accept();
      } else {
        alert.dismiss();
      }
      return alertText;
    } finally {
      acceptNextAlert = true;
    }
  }

К сожалению, новые релизы Selenium IDE выходят реже, чем релизы WebDriver, поэтому пока код генерируется ошибочный. В следующей версии Selenium IDE это уже будет исправлено.
  • 6


#115107 5 золотых правил для тест кейсов

Написано notProgrammer 26 Февраль 2013 - 13:22

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

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

Ах Негро... Как же Вам тяжело, бедному: вокруг Вас все такие дураки... Только и остаётся, что писать агрессивные и некорректные сообщения на форуме, по ходу придираясь к словам.
  • 6


#109974 Вопрос на собеседовании на который не смог найти ответа.

Написано anr 19 Сентябрь 2012 - 14:48

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

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


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



- изначально неправильный подход того, кто проводил собеседование. Увы, такое встречается. Кто проводил собеседование? Руководитель компании или отдела тестирования?
Не взяли в такую контору - не велика беда )



На свое решение я потратила 40 минут.
Удалила вот почему: за обедом вдруг подумала, что, может быть, FreeMan1 очень тонко играет - хочет получить решение на свою тестовую задачку. Хотя, после первого прочтения условий такой мысли не возникло). FreeMan1, пожалуйста, простите мне мое недоверие!

Решение именно в том виде, как было, ниже,
но у меня появились новые мысли:
1) в тест-дизайне уделить внимание безопасности. Проверить, возможен ли тут аналог sql-инъекции. И как шифруются данные ; )
2) я указала, что не стала бы проверять для всех 59 потоков. Сейчас думаю, что я была не права. На практике сколько угодно случаев нелепых копи-пастов ; )

Очень жду конструктивной критики.
Моя реальная работа делается так: разработчик (их шесть, тестировщик один) делает фичу, я пишу для неё чеклист на бумаге, прохожу. Никому не сообщаю своих оценок, на вики сохраняю только то, что нельзя забывать. Поэтому оценить оценку в 50-90 часов мне трудно ))


Именно таким никогда не занималась на работе, но интересно стало быстренько попробовать.

Первым делом, я бы спросила, есть ли подробная документация (говорят, это надо первым делом спрашивать на собеседовании : )). Видимо ответ будет: "это всё, что есть"

Я поняла условие так: есть функция f(бинарные данные; номер потока) - читает, перерабатывает, сохраняет данные - функция запускается при каком-то условии - по таймеру, или по размеру файлов на диске. Тут ещё хочется задать вопрос, с какими параметрами приложения может быть связь - вопрос к спецификации, аналитикам, разработчикам.

То есть, проверяем f(bin,i) и scheduler(?). Плюс, считаю, нужно и нагрузочное тестирование.

Что делать:

1. Разворачиваем окружение.
Сервер, на котором работает приложение: установка OS, ftp server, database, тестируемого приложения, конфигурация. Машина, с которой будут идти тестовые данные. Сетевой интерфейс между ними.

[часов 16 надо - учитывая риски, что админов не окажется на месте и всё такое. Возможно, в живом проекте всё это уже есть, и этот шаг пропустится]

2. Тест-дизайн.
Чтение с диска: размеры файлов, блокировки...
f(bin,i) - чтобы написать идеи, надо знать, каким образом перерабатываются данные перед сохранением в таблицу. Наверно, я бы сказала, что для каждого i специально проверять не буду )
сохранение данных в таблицу
scheduler

При составлении тест-дизайна формируются и требования к эмулятору входных данных - след. пункт.

[Зависит от процессов компании. Написание тест-кейсав - часов 20, подробный план тестирования - часов 10]

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

[написание: 6 часа, доделка, отладка, проверка, со всякими рисками - 10 часов. Итого - 16]

4. Выполнение тестов

[функциональные тесты - 8 часов, нагрузочные - вообще не знаю )) , рассуждать буду так: отладка + калибровка + отработка - часов 8 человеческого присутствия, плюс выполнение - часов 20, в том числе ночью.]

5. Оформление, анализ результатов

[функциональные тесты - 2 часа, нагрузочные - опять не знаю )) , кажется миллион, но отвечу 6]

По времени получилось 50-90 часов


  • 6


#103008 Pairwise testing | All pairs | orthogonal array testing - минимизация,

Написано rpwheeler 27 Март 2012 - 00:16

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

Подробнее всего по теме мне понравилась блестящая статья Майкла Болтона. Очень рекомендую, там хорошо рассказано о самом методе, его целях и преимуществах, и о том, что иногда лучше не долго составлять комбинации, а "прыгать в воду и плыть".
http://www.developse...iseTesting.html

На сайте, посвященном этой методике, есть ссылки и на и другие статьи по теме:
"Articles and Other Resources on topic"
http://www.pairwise.org/articles.asp

А здесь ссылки на инструменты. Есть устаревшие, есть рабочие:
"Pairwise Testing - Available Tools"
http://www.pairwise.org/tools.asp

Jenny - один из рабочих.
http://burtleburtle....math/jenny.html
(список комбинаций от Jenny можно легко превращать в текстовый какой-нибудь программой для множественной замены)


Ранее подымавшиеся по вопросу темы на форуме, из тех, что мне помогли и для тех, кто предпочитает почитать о теме по-русски:

http://software-test...rum/topic/2113/
Сайты посвящённые Pairwise Testing

http://software-test...rum/topic/1599/
Зависимые тесты как сократить число тестов

http://software-test...forum/topic/90/
Ортогональные матрицы для тестирования

http://software-test...forum/topic/91/
Пример ортогональной матрицы


Дополнения в тему, естественно, приветствуются :)
  • 6


#63502 Новости и online QA курс от автора "Тестирование дот ком"

Написано rsavin 12 Декабрь 2008 - 02:40

Дорогие друзья,

это ваш покорный слуга Роман Савенков широко известный в узких кругах под псевдонимом "Роман Савин".

Во-первых СПАСИБО за все ваши теплые слова и за поддержку. Вы вдохновили меня, чтобы написать английское издание по мотивам "Тестирование дот ком."

Начал я, в общем, переводить, и думаю, что можно сделать лучше. Если кто-то помнит, то в русском издании я использовал примеры как будто есть такой чумовой стартап www.testshop.rs. "Так вот," - подумал я, "а что если сделать отчаянный шаг и написать такой веб-сайт, чтобы читатели (или вернее "студенты") могли воочую увидеть примеры из книги и иметь возможность интеракции с софтом, включая использование баг тракинг системы, QA automation и т.д." В общем, я стал параллельно писать англ. издание и кодировать.

Закончил где-то месяц назад. В печатной форме получился об'ем примерно в 2 (!) раза больше, чем русское издание (405 страниц формата А4). Так что в английском издании очень много нового (хотя некоторые параграфы были мною тупо переведены из "Тестирование дот ком"). И назвал я это дело Practical Course "How to Become a Software Tester". "Курс" - потому что это уже не чтение, а непосредственное самобучение по системе книга - софтвер - книга - софтвер - и тд.

Теперь приятная часть: онлайн версия учебника и софтвер для треннинга абсолютно бесплатные. Поначалу я, конечно, хотел бессовестно нажиться на страданиях американского народа, угнетаемого финансовым кризисом, и начал продавать курс за большие деньги, но, во-первых у меня никто его особо не покупал, а во-вторых даже если и покупали, то нифига по нему не занимались. Как я знал, что не занимались? Просто смотрел на активность в базе данных. Ребята, поймите меня правильно, я потратил примерно 1.5 года на то, чтобы создать курс, который бы помог людям, а тут, понимаешь, дело совсем не движется. Вот и решил я сделать доброе дело и бесплатно выложить учебник плюс открыть доступ к тренировочному сайту.


URL учебника: www.qatutor.com.
URL тренировочного сайта: www.sharelane.com (прошу учесть, что нужно взять учебник и используя его уже работать с sharelane.com).

Спасибо вам за все, ребята.

С уважением,
Савин
  • 5


#159284 Какой тестовый фреймворк выбрать на C#: MSTest, NUnit, xUnit?

Написано barancev 28 Март 2017 - 14:20

Никому не верьте :)

 

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

 

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


  • 5


#132351 В каком случае регрессионное тестирование не проводят?

Написано ch_ip 18 Июль 2014 - 09:33

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

Регрессия необходима практически всегда, когда нет выстроенного процесса разработки, и поэтому всем страшно, что при изменениях в одном месте отвалится что-то в совершенно непредсказуемом другом. Когда такое бывает?

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

Если хотя бы половина из этого для проекта верна, то да, регрессия необходима всегда, т.к. никто не может предсказать последствия изменений и какие есть риски от конкретных изменений.
При грамотно выстроенном процессе тестирования, когда есть юнит и интеграционные тесты, запускающиеся при каждом изменении + функциональные тесты, которые запускаются каждую ночь на новых сборках, нужна минимальная регрессия, а в каких-то случаях можно обойтись и без нее. Плюс даже в тех случаях, когда она есть, необходимо периодически пересматривать, действительно ли нужен все тот же комплект проверок и думать, как оптимизировать.
В блоге у Оли Киселевой есть хорошая статья о том, как мы уже оптимизировали нашу регрессию — "Всегда ли нужна ручная регрессия? Жизнь_боль как двигатель прогресса"
+ сейчас мы думаем над тем, как полностью сделать ее автоматической и сократить затраты на весь цикл регрессионного тестирования до 4-6 часов одного человека в релиз (при это сама автоматическая регрессия, выполняемая роботом, может занимать до 2-3 дней). Стоит учесть, что наш продукт часто является критичным в цепочке основных бизнес-процессов Заказчика, поэтому мы не можем позволить себе пропустить ошибки, из-за которых система встанет (высокие финансовые риски для наших Заказчиков и репутационные риски для нас самих)


  • 5


#117654 Тестовое задание от компании на позицию Junior QA

Написано Alex_UA 07 Май 2013 - 11:28

Выслали тестовое задание протестировать регистрационную форму (просьб о выполнении задания тут НЕ БУДЕТ)

Кейс 1.
Тестирование Web формы.
Рассмотрите регистрационную форму, находящуюся по следующей ссылке: http://mobidev.com.ua/thousantsthinks/
Составьте тест кейсы, произведите полное тестирование и выпишите найденные баги, если таковые найдутся. Любые, даже самые не существенные замечания, приветствуются, поэтому обязательно сообщайте их нам в письме.


Добрый день!

Отписался тов. Bazeman в личку более подробно. Для всего сообщества хотел бы поделится информацией "из первых рук"))
Меня зовут Алексей, я HR Group Leder в компании MobiDev (и это одно из наших тестовых заданий для QA).
Сейчас вакансия закрыта и форма не работает. Кандидату Bazeman мы обратную связь уже дали.
Если кому интересно - могу поделится общими впечатлениями от выполненных тестовых (брали 3 junior QA), пришлось внимательно изучить до сотни выполненных тестовых (про количество резюме вообще молчу). Заранее прошу прощение за очепятки)) Итак. по-порядку:
1. Резюме.
В тексте вакансии четко написано: Upper intermidiate English (т.к. нужно быть готовым работать со стороной заказчиков). Процентов 40% резюме откидывали именно по этому критерию. Я все понимаю, что попытка не пытка, но каждое резюме забирает у нас минимум 10-20 минут... мне очень жаль моего времени....
Кроме того, если у кандидата нет опыта работы, ЭТО НЕ ЗНАЧИТ что резюме должно быть ПУСТОЕ на 3 строчки! Вреде Савин очень доступно описал что в резюме нужно указывать весь ваш опыт, даже то, что Вы прошерстили этот форум !

Тут есть и обратная сторона медали: некоторые пишут все что слышали: от MS Word до Objective C и все это в одной строчке. Мой вывод: "Чувак знает вёрд, а про С просто где-то слышал... 99,9% что я буду близок к истине.

Уважаемые Джуны! Компании ждут от вас стремления и готовности ПАХАТЬ! То-есть - прикладывать усилия. Если я вижу в резюме шаблонные фразы впихнутые через копипаст и без приведения текста к единому стилю - это БАН, тк такой кандидат на QA даже не удосужился перечитать и пересмотреть написанное.

И на финал - не ленитесь писать сопроводительные письма к вашим резюме! Я всегда читаю эту часть, даже если резюме могу просмотреть бегло, то сопроводительное письмо прочту обязательно! Хотя это не значит, что нужно копипастить сюда часть резюме...

2. Тестовое, кейс 1, Протестировать регистрационную веб форму, тест кейсы и баг репорты...

Вот что иногда пишет нам QA Team Leader после просмотра некоторых "шедевров"...

"...Уникальных сценарии есть,, валидации не все, нет кроссбраузерного, нет инъекций ,оформление 2"
"... сделал кроссбраузерное тестирование без ИЕ и нашёл 1 баг (( Мой вердикт: испепелиить окояного"
"... Валидацию проверил не всю, кроссбраузерного нет, спецсимволов нет. Уникальный сценарий только один. - значит скармливаем Кракену"
"...оформление 2, содержание тоже. Проверил только валидации и орф."
"...3 с минусом. кроссбраузерное делала, но бажище пропусила, уникальных сцеариев нет, валидации не все. По остальному старалась."
"...второй человек кто додумался залезть в базу и с заданием справился хорошо"
"...По тестированию читала только одну книжку. Многое путает. Идей в голове много но структурировать их не может. С заданием по нахождению багов справилась ужасно. Пусть читает книжки и тренируется искать баги. В общем, на костёр девушку(("
"...тестовое 3 с минусом, валидации не все, спецсимволов и инъекций нет, кроссбраузерного нет. тем не менее, уникальные сценарии есть, можем дать шанс"
"...Найдено 4 бага!!! (прим из более чем 40) - в печку. пускай читает книжки и тренеруется.... на собачках"

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

Ладно. думаю. картина ясна... хватит примеров.
Вот вижу что возник вопрос: а как же мы помогаем этим самым новичкам? Даем ли мы фитбек?
Отвечаю честно - Да, стараемся каждому дать ориентир куда дальше двигаться. В то же время, мы не даем по-пунктно что было так. а что нет. Мы говорим что нам понравилось. а что мы не нашли (то же кроссбраузерное делают далеко не все!!!)

А еще я стараюсь давать свой скайп и почту - если кандидат действительно (как написано в резюме) стремится к развитию, получив отказ, он будет пытаться выяснить не почему отказ, а что нужно подтянуть. К сожалению, как показывает практика, после первого отказа вопросами нас мучают единицы... И ни один не прислал повторно с учтенными замечаниями... Вот такая мотивация, брат...

И есть еще одно - самое сложное в моей работе...
Приходит кандидат на встречу. Смотрим по личным качествам - все при нем! Человек хороший и сотрудник будет отличный! Смотрим по проф знаниям и навыкам - тоже в порядке. Смотрим на мотивацию - глаза горят, во много уже сам пытался разобраться. И такие собеседование обычно затягиваются (тут коллеги меня зафукают. мол непрофессионально) т.к. с кандидатом приятно и интересно. НО всплывает какое-то НО... как правило - это слабый английский((( И приходится отказывать. Я нашел для себя выход в таких ситуациях: предлагаю такому кандидату взять как можно больше от встречи: максимально искренне отвечаю на все вопросы, рекомендую на что стоит обратить внимание, что подтянуть. Иногда даже рекомендую на какие другие компании стоит обратить внимание.

Подводя итог, хотелось бы высказать наверно уже не новую мысль: не важно какая у вас мотивация И ЦЕЛЬ (развитие, деньги, стабильность...) - все это достигается через !профессионализм! а он достигается через приложенные Вами Усилия! Это замкнутый круг:

УСИЛИЯ - ПРОФЕССИОНАЛИЗМ - РЕЗУЛЬТАТ
Если хотите чего-то - Усилия должны быть сначала!


Спасибо тем, кто приложил усилия и дочитал пост ))
Надеюсь, получилось интересно. :victory:/>

С уважением, Алексей,
HR Group Leader
компания MobiDev
  • 5


Яндекс.Метрика
Реклама на портале