Новая статья: QA для самых маленьких. Тестирование в небольших проекта
#1
Отправлено 17 июня 2009 - 10:02
Вот что пишет о своей статье Дмитрий: "Статья представляет собой компиляцию известных любому грамотному тестировщику подходов, однако последнее время мне довелось много работать в небольших проектах, в которых как правило не используется большая часть описанного. Я старался отобрать наименее ресурсоемкие и в тоже время наиболее важные аспекты правильной организации тестирования. Статья ориентирована не только на тестировщиков но еще и на ПМов, которые слишком часто не знают, что такое тестирование и с чем его едят. Это моя первая попытка просуммировать накопившийся за четыре года опыт и представить его на всеобщее обозрение, так что очень интересен любой фидбек.
Читать статью...
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#2
Отправлено 17 июня 2009 - 20:53
могу добавить про хорошую, но часто игнорируемую практику - bugs status review. довольно много помню случаев, когда из-за отсутствия совместного ревью, баги плавали по багтрекингу почти до дедлайна, и потом фиксились как у студентов перед экзаменом вообщем )) На самом деле отсутствие ревью может существенно повысить временные риски
UPD:
Если команда небольшая, но распределенная, могут помочь smoke tests. Баги выявленные на смоуках будут довольно быстро пофикшены + тут присутствует психологический аспект - девелоперы сами стремятся пофиксить такие баги как можно быстрее
#3
Отправлено 18 июня 2009 - 04:12
Хорошая статья, все по делу. Хоть пунктов и 9, но все в 10-ку. Автору респект.В библиотеку добавлена статья Дмитрия Стеценко "QA для самых маленьких. Тестирование в небольших проектах".
...
Читать статью...
Alexey
#4
Отправлено 18 июня 2009 - 04:58
Хорошо работает CI, реагирующий на каждый коммит. Не думаю что в небольшой команде очереда коммитов будет бешенной.Хорошо работают ежедневные билды – когда версия собирается ночью или вечером
#5
Отправлено 18 июня 2009 - 07:22
могу добавить про хорошую, но часто игнорируемую практику - bugs status review. довольно много помню случаев, когда из-за отсутствия совместного ревью, баги плавали по багтрекингу почти до дедлайна, и потом фиксились как у студентов перед экзаменом вообщем )) На самом деле отсутствие ревью может существенно повысить временные риски
Она же (практика) - Bug Triage Meeting. Очень полезная штука! Позволяет также обсудить спорные дефекты.
Статья хорошая, легко читабельная. Правда ничего нового не декларируется :) Но это не страшно.
#6
Отправлено 18 июня 2009 - 13:22
хорошая статья, может претендовать.
могу добавить про хорошую, но часто игнорируемую практику - bugs status review. довольно много помню случаев, когда из-за отсутствия совместного ревью, баги плавали по багтрекингу почти до дедлайна, и потом фиксились как у студентов перед экзаменом вообщем )) На самом деле отсутствие ревью может существенно повысить временные риски
UPD:
Если команда небольшая, но распределенная, могут помочь smoke tests. Баги выявленные на смоуках будут довольно быстро пофикшены + тут присутствует психологический аспект - девелоперы сами стремятся пофиксить такие баги как можно быстрее
Мне всегда нравился подход товарища Джоэля, не имплементить новые
http://software-test...h...pid=68519
А смоук тесты да, особенно если они автоматизированные и повешены на сборку билда.
UPD: или CI как коллега Sapiens заметил.
#7
Отправлено 19 июня 2009 - 10:45
Правда, я назвала бы ее "QA для самых больших" :) поскольку имхо самое сложное - это донести вышеописанные идеи до менеджмента..
#8
Отправлено 02 июля 2009 - 07:21
Спасибо автору за статью.
#9
Отправлено 03 июля 2009 - 07:38
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных