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

Международный Интернет-холдинг имеет центры разработки окромя Москвы?

По шагам расписываю.

1. Открываем google

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

3. Первая же ссылка нам дает ответ, что название компании Social Discovery Ventures

4. Название компании мы знаем - найти их сайт уже не проблема, как и их вакансии

5. На сайте смотришь где располагаются их оффисы

PS:

Можно покопаться чуть глубже и узнать, что вилка этой вакансии 90-120 т.р.

Регрессионное тестирование (regression testing):Тестирование уже протестированной программы, проводящееся после модификации для уверенности в том, что процесс модификации не внес или не активизировал ошибки в областях, не подвергавшихся изменениям. Проводится после изменений в коде программного продукта или его окружении. [ISTQB Глоссарий 2.3]

Материалы:

1. Регрессионное тестирование (Про Тестинг)

2. Санитарное тестирование (Про Тестинг)

3. Регрессионное тестирование (Роман Шейко)

4. Caren N. Johnson

   1. Эвристики ХРОНИЧеского регрессионного тестирования (раз перевод)

   2. RCRCRC: Эвристика регрессионного тестирования (два перевод)

5. Размышления о регрессионном тестировании от Майкла Болтона, или "все могло быть гораздо хуже". (Андрей Ладутько)

6. О вреде и пользе регрессионого тестирования (Сергей Высоцкий)

7. Регрессионный рай и ад (Сергей Высоцкий)

8. SQA Days 6: Реальное упрощение регрессионного тестирования (Интервью)

9. Автоматизированное тестирование с нуля. Часть 1. (Сергей Мартыненко)

10. Recession Testing is the new RegressionTesting (Maverick Tester) - eng

Стратегия регрессионного тестирования (Алексей Виноградов):

Тестировать важное, тестировать то, где недавно ломалось, тестировать то, где недавно копались и тестировать то, что давно не тестировали.

Что включать в регрессию в первую очередь (Игнат Круковский):

1. Наиболее критичные для клиента модули

2. Наиболее забагованные модули

Что нужно для регрессионного тестирования:

1. Время

2. Ресурсы

3. Список изменений

4. Критичность фич

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

6. Тестовое окружение (тестовые среды, сервера, инструменты разные)

7. Регрессионная библиотека, то есть список регрессионных тестов

Когда проводить регрессию:

1. Регрессия нужна в случае рефакторинга (Роман Шейко)

2. Циклы регрессии планируют при накоплении критической массы изменений в продукте (Константин Коваль)

3. Когда много изменений и они идут часто - регрессия необходима (Роман Шейко)

Когда можно отказаться от регрессии:

1. В каком случае регрессионное тестирование не проводят (Обусуждение)

2. От регрессии можно отказаться, когда разовый проект (Кирилл Ремизов)

3. Если времени на всё не хватает (Константин Коваль)

Прочее:

1. Автоматизация регрессионного тестирования (Обсуждение)

2. Регрессионный тестовой набор (Обсуждение)

3. Регрессионное тестирование: как упростить и автоматизировать (Обсуждение)

4. Методы реализации регрессионного тестирования по расширенным тестовым наборам (Диссертация 2003 года)

5. Стратегия регрессионного тестирования HipChat:

   1. Константин Коваль

      1. часть 1

      2. часть 2

   2. Алексей Фёдоров

Выражаю благодарность Роману Шейко за 6 сессию weekend testing - во время которой и был создан данный документ.

Встречный вопрос.

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

2. Какой продукт сдают продукт заказчику (Вид снаружи) и Как обстоит ситуация с продуктом для команды разработки (Вид изнутри)

5. Тестирование по старым чек-листам и Тестирование наобум

6. Картины: Автоматизаторы готовят расстрел багов и Бокс Тестировщика-Исследователя против Противника-Тяжеловеса 

7. Тестировщик  в музее Багов смотрит на мотылька обнаруженного 9 сентября 1945 в машине Mark II Aiken Relay Calculator и думает, а что будет если... - Результат его действий отображен на рисунке 2

8. Тестирование нового функционала и Тестирование критичного функционала

10. Канер в молодости; Канер на пенсии

PS: Как вариант Александров. Он дедушка русского тестирования. =) 

 

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

 

У меня сложилось впечатление, что руководство автора темы совершенно не понимает, чего хочет. Реально, такое впечатление, что хотят внедрить всё, что нагуглить удалось :)

 

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

 

Так может вы расскажете об оценке рисков и возможности их снижения? Это тема уровня senior и выше.

Или вы готовы рассказать о метриках в тестировании? Что, как, почему, для чего будет оценивать? Кому предоставлять отчет и кто несет ответственность?

Бизнес задачи - тоже  не уровень junior или middle специалиста.

И я не слышал о junior специалистах умеющих проводить тестирование безопасности iOS и Android Приложений.

С другой стороны определить зоны ответственности отдела тестирования, составить план работ до релиза (на написание стратегии тестирования у автора нет ни опыта, ни времени). Сейчас ему нужно определиться с тем, за что он несет ответственность и в каком случае он её несёт. Затем эту зону ответственности автор собой закрывает. И в случае, если он не успевает, он сразу идет к начальству и говорит, что ВСЕ ПРОПАЛО, нужно срочно принять меры (автор докладывает начальству комплекс мер, которые помогут решить задачи которая стоит перед отделом тестирования). В любом случае нужно узнать у начальства, что нужно СРОЧНО ВПЕРВУЮ очередь сделать, а что может подождать. 

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

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

Alexeysetyamin@gmail.com

Читайте Савина.

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

И подтягивайте умение находить самому общедоступную информацию.

Добрый день. 

Выскажите, пожалуйста, свое мнение.

 

Я учусь в Германии и заинтересовалась тестированием. Взяла книги в библиотеке, по отзывам хорошие,  остановилась на Спильнере и Линце.

Тут на форуме тоже советую начать именно с книг и теории (что очень логично), и потом подключать практику.

 

Тут маленькая ремарка. Мне всегда надо четко изучать-читать один источник (либо книгу, либо материалы курса, либо к преподавателю). Если я одновременно учу одно и то же по 2-3 книгам (в данном случае это основы тестирования), то получается катастрофа. Долго описывать почему так происходит, поверьте на слово.

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

 

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

 

Так вот, тут настоятельно советуют Савина. Книжка хорошая, я уже пролистала. Но смущает ее объем за 300 страниц (то есть ее надо брать как основную). И она на русском...

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

Конечно хочется читать на родном языке (нюансы понятнее, милее душе). Но практично ли это?

 

Посоветуйте, что бы вы лично делали на моем месте? 

Основы изучали бы по Савину или брали бы книгу на английском или немецком языках, если работу планируете искать не в россии?

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

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

Сделай так:

@base_url = "https://code.google.com"

Для чего этот план вам нужен? Кому кроме вас он нужен? И вы уверены, что кто-то, кроме вас/команды тестировщиков будет его читать/использовать более одного раза? Для чего вам в плане этот пункт - точно без него нельзя обойтись?

Можете попробовать под себя подогнать вариант Сергея Мартыненко:

1    Стратегия тестирования

Текущий подход к контролю качества подразумевает следующие вехи проекта:
Подсистема готова к демонстрации заказчику
Подсистема готова к промышленной эксплуатации

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

[Здесь ваша таблица]

Для проверки готовности прототипа служат приемо-сдаточные испытания. Критерий готовности - акт сдачи прототипа подписанный приемо-сдаточной комиссией. Приемо-сдаточные испытания описываются в отдельном документе. Либо как раздел шесть частного технического задания, согласно ГОСТ 34.602-89, либо в отдельном документе содержащем программу и методику испытаний.

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

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

Коллеги, а можно уточняющий вопрос?
Цитата из Вики:
 

Данный подход обладает недостатками. Вот, например, если в условии x > 1 программист допускает ошибку и пишет x < 1 или x > - 1, то с помощью нашего теста эта ошибка не будет обнаружена.

 

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

Во первых, о statement coverage test  Майерс говорит, что он настолько слаб, что, как правило, оказывается бесполезным. 

Во вторых, можно, но, как и писал выше Freiman, с тестом лучше. 

Вики

Чем ветка фолс хуже тру, во втором случае?  

Прочитайте Майерса "Искусство тестирования программ", глава 4 - в ней расписана данная тема. 

У вас чёрный ящик. С чего вы взяли, что не влияют?

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

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

Автоматизация это круто. Но готово ли вам руководство выделить на неё достаточно времени-ресурсов? 

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

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

Вопрос: Если у вас не менялся процесс разработки-тестирования с чего количество жалоб клиентов должно уменьшиться? 

Вы уверены, что проблема факапов именно в тестировании? Может где-то можно процесс разработки ПО улучшить, если это в ваших силах?

Если руководство готово выделить деньги на инструмент для автоматизации можно на TestComplete обратить внимание.

Про Microsoft Office Word нужно уточнять:

1. Для чего проводится тестирование

2. Что нужно тестировать производительность, функциональность, надежность...

3. Какое тестирование уже проводилось

4. Сколько времени в моем распоряжении

5. Какая документация, требования мне доступны 

6. Какие ресурсы выделено и возможно ли их расширение в случае необходимости

7. Какие вещи наиболее критичны для проверки

8. Кто отвечает за проект и кому можно задавать вопросы

9. Есть ли критерии приемки проекта

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

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

1. Какое поле для выставления шариков (вдруг оно 4 по горизонтали и 4 по вертикали)? 

2. Попробовать выстроить шарики по горизонтали 4,5,6 в ряд одного цвета

3. Попробовать выстроить шарики по вертикале 4,5,6 в ряд одного цвета

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

5. А что будет если у нас 3 шарика сверху поля в линию и 2 снизу по той же линии - будет ли программа считать, что у нас 5 шариков идут подряд - и если да то правильно ли это (Хотя имхо на собеседовании эту проверку лучше не показывать собеседующему)

и т.д. 

В общем случае:

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

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

Неплохо сделать критерии приёмки программы в тестирование (если в приёмке есть ошибки - тестирование не начинается) и критерий остановки тестирования (после нахождения, например, 30 ошибок среднего и выше приоритета Тестирование останавливается и не продолжается до тех пор пока количество ошибок среднего и выше приоритета не сократиться хотя бы до десяти) 

Ваши тест-кейсы очень плохие. 

Прочтите для начала статью "Что такое тест-кейс и как его писать" от Ольги Киселевой. 

Исправьте ваши тест-кейсы на основе полученной информации.

1. Для начала можно организовать критерий приёмки проекта в тестирование.

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

3. Гнать впереди паровоза тоже не нужно -  есть менеджер, который отвечает за проект и за программистов. Вы не СПАСИТЕЛЬ ПРОЕКТА и КРИЧАТЬ ЧТО ВСЕ ПЛОХО И МЫ ПРОПАЛИ не ваша обязанность - вы должны обеспечить свою часть работы в виде тестирование.

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

5. Зарубите идею о KPI до тех пор пока все не станет рельсы. 

6. На эти 3-4 недели до дедлайна ваш процесс должен быть максимально прозрачен, чтобы ваш руководитель был в курсе, что вы делаете и почему ИМЕННО ЭТО вы делаете.

Как KPI поможет развитию отдела? И почему он вам нужен?

Решение какой проблемы вы хотите с помощью него достигнуть?

Не получится ли, что при увеличении работы после внедрения KPI выхлоп отдела снизится, особенно, если благодаря нему будет считаться премия?