SQA Days 2009 - фотовзгляд из первой секции

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

Первая секция проходила, как удачно выразился Михаил Мериин, в христианском зале с пролетарским потолком :)



Ромуальд Здебский. Докладчик, после которого просто страшно было выступать, потому что такой опыт выступлений, как у Ромуальда, не затмить:)



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



Саша Орлов. Блистателен и искрометен.
Практически текст для визитки :)



Михаил Мериин. Колоссальный опыт. Спасибо, что поделились!



Александр Александров. Мэтр всия тестирования. Всегда интересно слушать. Четко, структурированно, уверенно. Подкреплено практическим опытом.



Асхат Урузбаев. Асхат, с%;ко гибкий :)



Ну и по поводу часто обсуждаемой темы, зачем народ ездит на конференции? Не только слушать, но и рассказывать, не только спрашивать, но и отвечать, не только смотреть, но и показывать. Хочется отметить, что рассказывали, отвечали и показывали достаточно активно :) Общение бурлило.





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

Недостатки приняты организиторами к сведению, что-то аргументировано как политика конференции, что-то решено было корректировать в будущем. Главное, что диалог состоялся. Диалог организаторов с участниками.
Спасибо всем, кто был! :)





Читать далее...

Вы - новая команда тестирования на старом проекте.

Заказчик меняет команду тестирования на Вашу. Процесс поставлен и разогнан. Что делать в первую очередь?

Перед новой командой тестирования стоят задачи:

- «меркантильные»: сделать как минимум не хуже, чем было, то есть показать, что заказчик не зря сменил аутсорсера;

- «общечеловеческие»: выпускать качественный продукт.

Для их выполнения команде нужно будет улучшить процесс (или, как минимум, не испортить :) и в дальнейшем по нему работать.

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

Тут 2 варианта:

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

2) В условиях недостатка времени – просто включаться в работу по налаженному процессу и тогда улучшения вносить «по ходу», если остается время.

Рассматриваем первый вариант – у команды есть время на «вход».

Первым делом - анализ требований: есть ли, в каком виде, тестируемы ли? Тут можно говорить долго и много  ( В моем последнем жизненном примере проекта нет требований, есть только юзер мануал, который пришлось переводить из вида «If you want to print the document that you have received from your agent, please select File>Print» в «To print document user should be able to select File>Print». А также пришлось уточнять моменты типа «There is no limit how many files user can add to the collection.» Беспредел – это, конечно, хорошо, но проверить какую-то разумную цифру все же надо :)
В ходе работы выработалось несколько формальных правил, напишу о них отдельно.)

Затем - анализ покрытия требований тестами. Преследуем 2 цели: получить картину «как это есть сейчас», и составить план действий « что сделать, чтоб было так, как должно быть».

В ходе анализа покрытия:

- составляем матрицы прослеживаемости;

- анализируем матрицы: почему некоторые единичные требования покрыты десятками тестов, в то время как целые блоки других вообще не имеют соотвествующих тестов? Э то следствие расстановки приоритетов или уверенности в себе предыдущей команды?

- попутно анализируем тесты на предмет избыточности.

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

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

Так что, продолжение следует...





Читать далее...