“QA-Gramotno” – откровения, “постановка мозгов” и открытия, которые должен делать каждый тестировщик.
Подразумевается, что плох тот QC, который не хочет стать QA, но что для этого нужно? Грамотный подход нужен…
testitquickly.com 2011 /annual-report/
Домен
Был выбран после прочтения официального документа “О тестировании” в одной из компаний, в которой я работал. Сам процесс тестирования там был описан достаточно подробно и толково, но в самом конце этого документа, было написано: The time consumed for testing should be as short as possible.
Автор
Алексей Лупан, тестировщик.
- Заместитель гл. редактора Software-testing.ru.
- Жрец храма Панбагон.
- Официальный QA Trainer в компании SysIQ (Ukraine).
- Наш тренер в УЦ Люксофт в Киеве.
- Неоднократный докладчик конференции тестировщиков SQA Days.
- Номининант звания “Главный тестировщик Молдовы”.
Тел: +380 669 711 013 (Украина).
Skypе: astenix
Е-mаil: astenix@testitquickly.com
RSS (регулярность обновления – нерегулярно)
Когда работаю в Windows-environment, много записей о Unix не предполагается. И наоборот.
В моем профиле в LinkedIn есть много интересных людей (доступно при тамошней регистрации).
Рекрутерам: спасибо, не сейчас.
Специализация: тестирование веб-ориентированных аппликух:
- интернет-магазины,
- трейдинг ценными бумагами (и неликвидными тоже),
- социальные сети (так уж получилось).
По мере необходимости использую Selenium IDE как подспорье в ручном тестировании, особенно в сфере regression testing.
Автоматизация: на Java + WebDriver (Selenium 2.0) + TestNg в Eclipse.
Когда-то решил стать опытным тестировщиком, и целенаправленно учился тестированию комплексных веб-систем.
Опытным путем научился бережно относится к уже работающим процессам в компании, и умею внедрять процесс тестирования без резких изменений (см. мой доклад на конференции SQA Days).
Основные мантры тестировщиков: прочитать.
Рабочее предложение
ПодКласс
Индивидуальные занятия, обучение для тестировщиков, которым нужно углубиться в специфику работы.
Тест-сессии
Поскольку постоянное тестирование необходимо не всем и не всегда, а дело это недешевое, я продаю трехчасовые тест-сессии:
- пришел на три часа в офис (или удаленно),
- провел пару раундов тестирования,
- написал подробный отчет о состоянии приложения и о проделанной работе.
По стоимости работочасов мои услуги стоят столько же, сколько и работа постоянного тестировщика. Но поскольку я прихожу лишь при действительной необходимости, такой подход обходится проекту В РАЗЫ дешевле, а результаты иногда сопоставимы с работой full-time работников.
Семинары
Семинары и доклады на темы, связанные с тестированием, для специалистов отдельных компаний.
Иногда возможен выезд за пределы Киева (см. выездное выступление в Днепропетровске).
География
Кишинев, Киев, Москва, Одесса, Харьков, Херсон, Днепропетровск, Санкт-Петербург, Бобруйск.
Переводы
Читаю блоги о тестировании на английском, французском и румынском языках (румынские тестировщики предпочитают жить в Канаде и писать в сети только на английском пиджине). Иногда что-то из прочитанного перевожу для себя.
Не стремлюсь передать текст полностью; чаще это пересказ, зачастую – тезисный.
Запись чужих выступлений
Мне удобнее и быстрее прочитать текст, нежели прослушать или просмотреть видео с чьим-то выступлением на тему тестирования.
Поэтому те выступления, интервью и презентации, которые мне очень интересны, я собственноручно “перевожу” в текст. Это занимает много времени, несмотря на все мои уловки и хаки, но результат важнее.
После согласования текста с автором “звука”, я публикую итоговый материал у себя в разделе Переводы. Согласование необходимо потому, что “слова на бумаге” иногда выглядят неадекватно, даже у самых адекватных людей.
Живьем
This page has the following sub pages.
Комрад, порадовал коллегу !
Спасибо!
Твои тексты – как свежий ветер в этой долбанной индустрии
Приятно читать.
Вдохновляет.
а можно поныть в жилетку ?
вот у меня … сейчас что я делаю знаешь ?
есть больше сотни багов исправленных программерами
мне нужно перепроверить что они исправлены
читаешь описание , воспроизводишь , пишешь да или нет
+ свои комменты
берёшь следующий
как рабочий на заводе
взял заготовку, выточил гайку напильником, положил её в ящичек
взял другую заготовку и так дальше …. ВСЮ ЖИЗНЬ
а денег – гавно (это самый интересный аспект)
Направь, Отче !
Адеса – Мама, специально для вас есть уникальное заграничное средство. Даже два, хотя они весьма полярны по своему свойству. Следует выбрать одно и не “слезать” с него до самого финиша.
“Просветлин”
- быстро и не оглядываясь чекаем баги, закусывая их чем-то вкусным (рулет с халвой, например). Главное тут – скорость. Потому что реально скучно…
- в процессе чеканья ищешь по-наитию места, где могут быть ещё не обнаруженные баги. Менеджеры и программисты к такому не готовы, и начнут ныть, что дэдлайн и вообще пора домой. И начнут бояться страшного тестировщика, который даже в процессе банального багчеканья находит новые дефекты. Вероятно, они покумекают и незаметно подкинут ещё рулета, чтобы тестировщик расслабился…
Цель этого средства: превратить пациента в самого главного тестировщика, который надсматривает за теми, кто лишь недавно начал возиться с гайками и напильниками.
Тут главное – чтобы программеры не поймали вечером где-то на Степовой улице и не побили за все баги и рулеты с халвой разом.
“Нирванин”
- Жизнь есть страдание. Страдание есть получение зарплаты. Зарплата есть сплошное страдание. Сколько ни напрягайся, будет не зарплата, а одно страдание.
Собственно, ясно, отчего многие рабочие уважают культуру неумеренного пития? Весь день возишься с заготовками, и к вечеру сам как заготовка.
Могу честно сказать, что на уровне менеджеров наличествует та же мантра, но в слегка ином обличье.
И программисты тоже могут изрядно порассказать о долгих часах своей бессмысленной работы, когда надо кодить, кодить, кодить, кодить, кодить, кодить, кодить, кодить, спеки – пространные мифы древних греков, тим-лид – зверь, а продакт-менеджер с ним заодно…
ЗЫ Самый интересный аспект непропорционально увеличивается в зависимости от разности выполняемых задач и наработанных умений эти самые задачи выполнять. Еще раз: непропорционально, но увеличивается если растет количество и качество умений.
Ишшо один вариант поведения описан в Почему тестировщиков всегда будет мало
С удовольствием полазил по сайту и почитал статьи. Нашел для себя много полезного. Но смутило отсутствие очень привычной и полезной кнопки подписки по RSS..
Спасибо.
Сейчас сделаю.
Алексей, спасибо! Очень свежо и интересно! Буду чаще заглядывать.
С уважением.
Спасибо! Прикольно =)
Отличный сайт!
Здравствуйте, Алексей!
Хочу предложить Вам следующую статью для раздела “переводы”.
Top Five (Wrong) Reasons You Don’t Have Testers
(http://www.joelonsoftware.com/articles/fog0000000067.html)
Примечателен пункт 4: Anybody qualified to be a good tester doesn’t want to work as a tester.
Хорошо перекликается с Вашей статьей “Почему тестировщиков всегда будет мало”.
- Albert
Спасибо.
Эта статья уже переведена.
Оригинал на русском Джоэле.
К слову, хорошим тестировщиком истинный программист Джоэль считает тетю, которая находила какие-то хитрые комбинации (“Она нажала Alt!”). А это свойство весьма осбуждаемо. Оно очень полезно ПОСЛЕ того, как проверена корректность работы всех требований и спецификаций… Хотя и весьма способствует ореолу “Эти хитрые тестеры как-то не так кнопки нажимают…”
“ПОСЛЕ того, как проверена корректность работы всех требований и спецификаций…”
Тут бы самое время заявиться Майклу Болтону (который не певец, а бизнес-партнер Джеймса Маркуса Баха) с авторитетнейшим утверждением: “тестеру никакие требования (requirements) и спецификации (test specifications) не нужны! В процессе тестирования правильный настоящий тестер сам во всем разберется! Эксплоратори тестинг форева, и все айда на мой платный курс рапид тестинга. “
Реально неуравновешенного Болтона мы будем побивать Джо Страццерой, который аж в 2006 году сказал, что “There are ALWAYS Requirements“…
Э, нет, уже не получилось однажды. Был у меня такой блогодиалог (http://automationbeyond.wordpress.com/2009/11/25/7-questions-on-testing-vs-checking/) с Майклом Болтоном, и я ссылался как раз на указанный пост (“There are ALWAYS…”). Но этот увертливый тип заявил, что я все не так понял, и requirements и specifications вообще противоположные понятия.
Цитирую.
“Execution steps are specification. That is, execution steps are specific actions to take or ideas to follow. I think you’re confusing requirements (documents) with specification.
Testers don’t need requirements documents or specifications to discover or reveal or infer requirements. Testers can then compare their discoveries or inferences with the client’s actual requirements—the advantage being that testers can alert clients to requirements of which they were not previously aware.”
Настало время платить по старым счетам
После года усиленного изучения этого heuristic-based exploratory testing и взятого у самого Болтона курса Rapid Software Testing, подтверждаю: для тестирования требования и спецификации не нужны. В процессе исследования продукта тестер найдет все, что ждали и не ждали, а также проблемы (неточности, ошибки) в самих требованиях.
В натуре, эксплоратори тестинг рулез форева, а курс своих денег еще как стоит
Спасибо, много интересного для себя почерпнул.
[...] О сайте [...]
Просмотрел твое видео “Selenium IDE как артефакт пикника на обочине”, и в каждом слове находил себя самого. Кишинев,единств. тестировщик, поставленные задачи. Буду следовать твоим советом.
Прям в каждом
ну как, я на 2-ой неделе работы, пока все совпадает.