Всяко разно из жизни одного IT-шника

QA Expert Day

Кто этот парень перед нами?

Кто этот парень перед нами?

Имя: Андрей СильчукВозраст: 28 летМесто работы: DataArtДолжность: Project ManagerОпыт: manual + Automation + managementУвлечения: фигурное катание, Star Wars, snowboarding

Agenda

Agenda- Никаких четко заданных рамок- Только диалог- Вопрос-ответ- Спрашивать можно ВСЁ! Не бывает глупых вопросов, бывают «лекторы», которые не знают ответы на заданные вопросы

- Только реальные кейсы из жизни

Agenda- Technical cases

- Soft cases

- Others

You might think …

Don’t worry …

Main Aim

It is time for …

Case 1 – cross OS file manager

Case 1 – cross OS file managerWinSCP etc.

Case 2 – communication- Попытаться понять, что чувствует человек- Найти общий интерес- Уделить 30 секунд в начале разговора на общение на отвлеченные темы

Case 3 – email filtering- Используйте правила для фильтрации почты! Это важно!

Case 3 – email filtering- Разносите все по разным папкам, так проще искать

Case 3 – email filtering- Используйте категории

Case 4 – command line- В QA области обязательно умение работы с command line

- Даже если оно вам не нужно в сегодняшнем проекте, оно обязательно пригодится в следующем

- Если же не будет надобности проектной, это умение облегчит вам жизнь повседневную (grep, sed, find etc.)

Case 5 – double check- Убедитесь, что ваш собеседник вас понял правильно, иначе это может привести к очень плачевным последствиям

- Не бойтесь переспрашивать или повторяться

Case 6 – Security testing- Web Security Dojo - Training Environment for Web Application Security Penetration Testing

Case 6 – Security testing- Overview https://www.mavensecurity.com/resources/web-security-dojo/

- Download Web Security Dojo from http://sourceforge.net/projects/websecuritydojo/files/

Case 7 – acceptance != f*ck off

Case 7 – acceptance != f*ck off1. Первое правило сдачи проекта: никому не

сдавай проект на отъеб… лишь бы сдать2. Второе правило сдачи проекта: никогда не

сдавай проект на отъеб… лишь бы сдать3. Третье правило сдачи проекта: в сдаче

проекта участвуют только двое (заказчик и команда)

4. Четвертое правило сдачи проекта: не более одной сдачи проекта за раз

Case 7 – acceptance != f*ck off5. Пятое правило сдачи проекта: проект при

сдаче должен быть «без обуви и голый по пояс (а лучше и голый полностью)»

6. Шестое правило сдачи проекта: сдача проекта продолжается столько, сколько потребуется

7. Седьмое правило сдачи проекта: если заказчик принял проект или делает вид, что принял проект, или говорит «Это же именно то, что я хотел» – проект сдан.

8. Восьмое правило сдачи проекта: команда обязана сдать проект

Case 8 – test case review andknowledge sharing. MUST HAVE!- Обязательно проводите review ваших тест кейсов внутри команды.

- Можно давать на ревью, как разработчикам, так и коллегам тестировщикам

- Ревью должно быть, как автоматических тесткейсов, так и мануальных

- Проводите knowledge sharing внутри команды, после полного цикла тестирования новой фичи

- Knowledge sharing можно проводить и после «победы» над сложным, с вашей точки зрения, кейсом

Case 9 – cross cultural communication- Общение с израильтянами- Общение с немцами- Общение с индусами- Общение с англичанами- Общение с американцами

Case 10 – never “tint” reports- Никогда не аппроксимируйте/подкрашивайте репорты и результаты тестового прогона.

- Лучше пошлите промежуточный результат и сообщите когда ожидать конечного результата

Case 11 – short same typeprojects- Какие сложности могут возникнуть при работе с короткими, однотипными проектами и как их побороть

- DEV guide- QA guide- «Общие» тесты- Возможность переиспользовать environment

Case 12 – “donkey” customer- Проанализировать ваш solution- Обговорите его с коллегами- Все еще уверенны что решение верное, а заказчик упирается?

- Пришлите N-1 вариантов различных решений- Пришлите решение N = 1 решению- Profit!

Case 13 – users are stupid.Time to time customers also- Всегда рассчитывайте на пессимистический сценарий – конечный пользователь/заказчик «тупой»

- Анализируйте ошибки пользователей с различных форумов и других источников

- Предлагайте улучшения в продукт

Case 14 – remote access tools- Remote desktop manager, mremote etc.

Case 15 – smth important?ONLY EMAILS!- Любой важный таск обязан быть письменно подтвержден и сохранен

- С другой стороны, никогда не тыкайте этим письмом в виноватого, старайтесь это сделать более дипломатично

Case 16 – just useful advices- Имейте хотя бы общее представление и базовые скилы в автоматизации

- Тоже самое касается и программирования на каком-либо ООП языке

- Если вы работаете c не техническим заказчиком, начинайте работу только после окончательного апрува спецификации на ту или иную фичу. А лучше ВСЕГДА начинайте работу только после окончательного апрува подробной спецификации на фичу

- Personal Task planning (trello, onenote etc.)

Case 17 – just funny cases

Case 18 – and remember…

Вопросы?