Повышение эффективности процесса тестирования.

Добрый день!
Прошу поделиться своими мнениями.
Отдел тестирования существует 3,5 года. Тестируем в основном web приложения. Разработка ведется по скраму. Основной объем работ - функциональное ручное тестирование. Тестировщики используют чек-листы для проверки функциональности.

Руководство ставит цель - повысить эффективность процесса тестирования. Первое что приходит в голову - автоматизация тестирования.

Как еще можно повысить эффективность процесса тестирования?

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

Согласна с Натальей. Надо сначала выяснять, что конкретно не устраивает Ваше руководство. И чего они хотят достичь.

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

Обеими руками поддерживаю Наташу.

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

И спросить руководство, что не устраивает или что хотят получить (цель, а не средство) - первое дело.

Но можно и самим пораскинуть мозгами. Руководство может и не знать чего хочет. Эффективность повысится если вы будете предоставлять или больше информации или будете делать это быстрее. Как это сделать быстрее - тяжело сказать, для этого надо работать у вас. А вот больше информации вы сможете предоставлять когда начнете делать новые виды тестов. Посмотрите какие аспекты вы тестируете, а какие нет и начните их тестировать (неплохо, правда, узнать будут ли результаты такого тестирования интересны программистам и начальству).

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

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

А вот это уже зависит от того, как мерить эффективность :)

Автоматизация ни в какой перспективе не может повысить эффективность, если неизвестно, что такое эффективность :))

Автоматизация, тест-кейсы, метрики - любые штуки, которые вы внедряете в свой процесс, лишь ИНСТРУМЕНТЫ. Если вы знаете, что вам нужно с точки зрения РЕЗУЛЬТАТА, тогда можете выбрать инструмент(-ы), а если не знаете - то врядли сможете говорить об эффективности..

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

У нас продукт состоит из 10 различных модулей. Есть 15 заказчиков. У каждого заказчика устанавливается несколько модулей. (1-5 штук)
Внедрение производится хаотично, т.е. может быть за одну неделю внедрение к 5-ти заказчикам. Нет четкого плана.
Проблема состоит в том, что для каждого заказчика существует своя БД и большинство ошибок обнаруживается из за кривой (не корректно обновленной) БД. Т.е. тестировать приходится каждый модуль для каждого заказчика отдельно.

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

Нужно построить процесс тестирования таким образом, чтобы при одновременном разворачивании системы у 15 заказчиков не возникало необходимости ставить непроверенный/непротестированный продукт (то есть он должен быть вовремя проверен)

Это средство. Поднимитесь еще на одну ступень выше, посредством вопроса "Зачем?"

Нужно построить процесс тестирования таким образом, чтобы при одновременном разворачивании системы у 15 заказчиков не возникало необходимости ставить непроверенный/непротестированный продукт (то есть он должен быть вовремя проверен)

Это средство. Поднимитесь еще на одну ступень выше, посредством вопроса "Зачем?"

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

У нас продукт состоит из 10 различных модулей. Есть 15 заказчиков. У каждого заказчика устанавливается несколько модулей. (1-5 штук)
Внедрение производится хаотично, т.е. может быть за одну неделю внедрение к 5-ти заказчикам. Нет четкого плана.
Проблема состоит в том, что для каждого заказчика существует своя БД и большинство ошибок обнаруживается из за кривой (не корректно обновленной) БД. Т.е. тестировать приходится каждый модуль для каждого заказчика отдельно.

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

Примерно то, что вам интересно и рассказывал Олег Ладыгин на предыдущей встрече нашего сообщества в Питере http://sqagroup.spb....f-creating-tms/
Там не только тестирование но и сборка, т.к. разные сборки включают в себя разные модули, базы или таргетированы на разные платформы. Соотвественно тесты привязаны к томы, что вошло в сборку.

Примерно то, что вам интересно и рассказывал Олег Ладыгин на предыдущей встрече нашего сообщества в Питере http://sqagroup.spb....f-creating-tms/
Там не только тестирование но и сборка, т.к. разные сборки включают в себя разные модули, базы или таргетированы на разные платформы. Соотвественно тесты привязаны к томы, что вошло в сборку.

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

Чтобы далее не делать оговорок по каждому поводу, скажу в целом: "Все фирмы болеют примерно одинаково, скорее всего вы не исключение. Но может быть что и исключение."

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

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

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

А вот это похоже на правду.
1) Скорость выполнения заказа более важна, чем объем выполняемых заказов в единицу времени. Т.е. вам скорее нужна не эффективность, понимаемая как <кол-во заказов>/<единицу времени * одного сотрудника>, а именно средняя скорость выполнения заказов.
2) Чтобы работать именно с тем, что нужно заказчику нужно рассматривать процесс целиком. Субоптимизация участка тестирования является классической грубейшей ошибкой.
3) Берити и расписывайте процесс целиком.

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

1) Скорость выполнения заказа более важна, чем объем выполняемых заказов в единицу времени. Т.е. вам скорее нужна не эффективность, понимаемая как <кол-во заказов>/<единицу времени * одного сотрудника>, а именно средняя скорость выполнения заказов.

1. что такое объем выполненных заказов?
2. разве объем выполненных заказов в единицу времени - это не скорость выполнения?
3. А что такое скорость выполнения заказа?
4. а средняя скорость выполнения заказов как рассчитывается?

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

Сергей, это здорово, что ты продвигаешь идеи ТОС, однако вопрос: ты не можешь привести примеры реального применения положений теории ТОС при разработке программного продукта на заказ? ну или на продажу? Спасибо

2) Чтобы работать именно с тем, что нужно заказчику нужно рассматривать процесс целиком. Субоптимизация участка тестирования является классической грубейшей ошибкой.
3) Берити и расписывайте процесс целиком.

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

Примерно то, что вам интересно и рассказывал Олег Ладыгин на предыдущей встрече нашего сообщества в Питере http://sqagroup.spb....f-creating-tms/
Там не только тестирование но и сборка, т.к. разные сборки включают в себя разные модули, базы или таргетированы на разные платформы. Соотвественно тесты привязаны к томы, что вошло в сборку.

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

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

1. что такое ...?
2. разве ...?
3. ...
4. ...

Сергей, это здорово, что ты продвигаешь идеи ТОС, однако вопрос: ты не можешь привести примеры реального применения положений теории ТОС при разработке программного продукта на заказ? ну или на продажу? Спасибо

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

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

Давайте вы попробуете начать изучение с литературы. Что касается применения TOC в IT, сходу не скажу. Но есть мегауспешный пример внедренния похожей модели управления. http://cartmendum.livejournal.com/ и далее ищите "Историю одной доски". Максим внедрял не TOC, а менее эффективный, но более простой канбан/кайдзен. Впрочем получилось более, чем неплохо.

Сергей, это здорово, что ты продвигаешь идеи ТОС, однако вопрос: ты не можешь привести примеры реального применения положений теории ТОС при разработке программного продукта на заказ? ну или на продажу? Спасибо

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

Тикстоун

1. уверен, вы правильно поняли своё руководство, что его не устраивает;
2. только идиот решит, что здесь автоматизация неэффективна, (если ваша система доступна для автоматизации).

Крайне ценная инфа, не так ли, 1960207?

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

Мой продукт ~60 модулей, ~30 не меняются, остальные уникальными и не очень наборами для каждого клиента (~100 штук).

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

Оказалось, что автоматизировать интегрционное тестирование модуля для того, чтоб разрелиживаться им раз, например, в месяц - нафиг не надо. А раз, например, в неделю - надо.

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