Какие технологии приминяются для тестирования у вас?

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

Ваше начальство жжот
Обычно с тестировщиков довольно много спрашивают.
Если есть время, изучите сначала материалы на форуме. Он тут довольно компактный, не замусоренный.
Вот отсюда можно начать.
А тут литература почти на любой вкус. Сканов никто не выкладывает, но вы же умеете искать ;)
P.S. Ложка дёгтя: орфографию тоже подучить не помешает.

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

а что обычно спрашивают?

а что обычно спрашивают?

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

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

а что обычно спрашивают?

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

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

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

Я работаю единственным тестировщиком на веб проекте (понятно что есть тест кейсы, только которые я сам придумаю).

Куда вы записываете свои тест-кейсы?

Про литературу - на портале есть такой раздел, "Литература", слева выбираете ))
Как примеры: http://software-test...428-rukol-books
http://software-test...eview/658-books

нет. Продукт не такой уж и маленький. Но устойчивый.

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

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

Выглядеть это может например так: "Здрасте, гражданин начальник, по данным гугл аналитикс на вебинтерфейс нашего продукта заходят 6% пользователей с браузера дельфин, а в нем аяксы криво отрабатывают. 6% это 5 миллионов пользователей, мы будем ради них это чинить?"
Или так: "Внедренцы говорят, что Самый Большой Клиент переводит все сервера на соляру, давай я на ней инсталляцию и интеграцию с веб-сервисами погоняю".

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

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

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

Теперь расскажу про то, что я сделал, освоил и применил на практике:

- написал функциональные спецификации по всем трем продуктам
- по данным спецификациям написал чек-листы. Чек-листы особо не пригодились. Тестирую в основном держа бОльшую часть кейсов в голове (т.к. функционал продуктов на данный момент еще не такой большой), или же методом свободного поиска.
- провожу автоматизированное тестирование для веб-сайта с помощью Selenium IDE (Selenium RC/WebDriver на данный момент для моих целей не нужен, т.к. IDE вполне справляется с теми задачами по тестированию, которые мне нужны) во время добавления больших фич. Написал довольно много тестов, покрывающих бОльшую часть функционала. Можно сказать, что данные тесты представляют собой некое подобие смоук-тестов.
- провел нагрузочное тестирование веб-сайта с помощью JMeter. Пока самое элементарное - симуляция числа обращений к разным страницам сайта. Да, на сайте очень многое кэшируется, поэтому необходимо будет проводить тесты, направленные на динамическое изменение.
- приходится тестировать веб-сайт на безопасность. Пока что опять самое элементарное - XSS и т.п.
- по тестам с помощью Selenium IDE и JMeter написал документации, в которых четко описывается, для чего каждый тест нужен и что делает. В основном это было сделано для самого себя, чтобы потом не запутаться в созданных тестах (в большой степени это, конечно же, относится к Selenium IDE).
- тестирование декстопного приложения на данный момент пытаюсь автоматизировать с помощью Sikuli IDE, правда, чувствую, что выбор данного инструмента заведомо проигрышный вариант.

В общем, как-то так... Многое пропустил и не написал, но важное, думаю, все же огласил.

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

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

Я работаю единственным тестировщиком на веб проекте (понятно что есть тест кейсы, только которые я сам придумаю).

То есть вы первый тестировщик на этом проекте? До вас никого не было?

Худо-бедно освоил салениум иде. Но он не позваляет полностью автоматизировать процессы тестирования.

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

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

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

• Зачем этот функционал?
• Как им будут пользоваться наши пользователи?
• О, кстати, а кто они, эти пользователи?
• Какую проблему они хотят решить с помощью этого функционала?
• А что они умеют?
• Смогут ли они воспользоваться этим функционалом или надо 5 раз выполнить обряд RTFM, прежде чем станет ясно, что тут надо делать?
• Смогут ли воспользоваться этим новички?
• А будет ли им это удобно?
• А если пользователь эксперт, то сможет ли он решить свою проблему быстро, опираясь на свой опыт в схожих областях?
• Кстати, о схожих областях - что там есть у конкурентов? Как оно сделано?
• Быстро ли это работает?
• А если с точки зрения пользователя, который опаздывает на поезд?
• А если пользователь имеет сайт не на локальной машине, а пытается достучаться к нему из Арзамаса-16?
• А если он посмотрит с айфончика на этот сайт, что он увидит?
• А если пользователь сидит в макдаке с лагающим вай-фаем?
• Кстати, а не посмотреть ли статистику GA, чтобы знать, какие у нас пользователи и не предпочитают ли они разномастный Андроид благородной айоси? Или может они все поголовно гики с хромом? Или напротив, госслужащие с 6-м ие? А если они все разные, то кто из них приносит больше денег?
• А хороши ли дефолтные настройки функиционала для денежных пользователей?
• А для тех, кто только хочет стать денежным пользователем?
• А для экспертов?
• А правильно ли оно работает именно для наших пользователей с их осью, браузером и сетью? И с теми настройками, которые они выставят?
• А какие есть ограничения с точки зрения пользователей?
• Как эти ограничения соотносятся с нашими ограничениями на клиентской стороне? А на серверной стороне?
• А клиентские валидации соответствуют серверным?
• А как мы сообщаем пользователю об ошибках? Предлагает ли функционал пути их исправления и подсказки?
• Что пользователь получает в виде результата?
• Удобно ли ему будет с этим дальше работать для решения своей проблемы?
• Что пользователь скорее всего захочет сделать после получения результата от тестируемого функционала? Может ли он это сделать?

Но я бы хотел стать квалифицированным тестировщиком. Какие технологии мне стоит освоить?

С технической точки зрения, стоит понимать те технологии, которые используются конкретно у вас:
HTML, JS, CSS - на клиенте
как устроен транспорт данных между клиентом и сервером - HTTP, TCP/IP, DNS, виды запросов, XML, AJAX
на сервере - зависит уже конкретно от вашего продукта. Но скорее всего стоит знать основы SQL

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

Ну и еще можно посмотреть в сторону нагрузки и безопасности, если оно надо:
XSS, SQL-injection
модели нагрузки и основные метрики нагрузочного тестирования: время ответа сервера, количество одновременно обрабатываемых запросов

Что используется у вас для тестирования?

Голова и умелые руки

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

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

Может посоветуете какую-нибудь литературу?!

Там выше уже давали ссылки на две подборки. Подкину свой вариант:
Про тестирование вообще:
1. Савин - для общего ознакомления, что такое тестирование. Но только в качестве нальчальной книжкис обязательным продолжением чтения потом более серьезных книг
2. Тетирование программного обеспечения - Сэм Канер, Джек Фолк, Енг Кек Нгуен
3. Lessons learned in software testing

По исследовательскому тестированию:
Exploratory testing by J.Whittaker

Практические советы по тестированию:
How to break Web Software - J.Whittaker

О том,как должны выглядеть веб-сайты:
1. Не заставляйте меня думать - Стив Круг

О проектировании взаимодействия с пользователями (и о том, почему с подавляющим большинством программ невозможно работать. не испытывая чувтсво раздражения и почему ленивые пользователи не хотят учиться использовать наши новые крутые фичи):
1. "Психбольница в руках пациентов" - Алан Купер
2. "интерфейс" - Д.Раскин

Об IT-производстве в целом:
1. "Мифический человеко-месяц" - Ф.Брукс

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

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

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

Хорошая спецификация содержит в себе все данные для проверок и требует минимума дополнительной документации. Посмотрите выступление Сергея Мартыненко с ЛАФ-2011или с SQADays-10.

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

Приоритезация наше все!
Коли много багов не исправляются, значит менеджмент считает, что они не так важны. Есть всего 2 причины этого:
1. Вы не донесли важность конкретных багов до руководства. Тут Ищите статью Джеймса Баха на тему, "Когда стоит останавливать тестирование". Может надо для некоторых багов добавить примеры печальных последствий, к которым они могут привести?
2. Вы не там ищете. Пострайтесь выяснить, каковы приоритеты пользователей и заказчика, на что следует обращать внимание в первую очередь, а какие ошибки стоит ргуппировать кучей, с надедждой, что их когда-нибудь исправят?

По нему составил тесты для Селениум ИДЕ.

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