В тази сесия ще говорим за test cases в Drupal.
Темите, които ще засегнем са:
– Какво са test cases?
– Защо се нуждаем от тях?
– Защо трябва да ги ползваме?
– Какво е Testlink?
– Как да пишем преизползваеми(reusable) test cases в Drupal?
– Как да подобрим работата на екипа чрез изготвяне на добри test cases?
– Как да използваме test cases като “acceptance criteria”?
2. За мен
• Божидар Бошнаков
• QA Engineer @ ProPeople
• bboshnakov@propeople.dk
• Skype: bo6nakov
• linkedin.com/in/bboshnakov
3. За какво ще говорим
• Какво са test cases?
• Защо се нуждаем от тях?
• Защо трябва да ги ползваме?
• Какво е Testlink?
• Как да пишем reusable testcases в Drupal?
• Как да подобрим работата на екипа чрез изготвяне на
добри test cases?
• Как да използваме test cases като “acceptance
criteria”?
4. Защо точно test cases?
Вероятно най-големият проект правен някога на
Drupal!
http://wearepropeople.com/clients/copenhagen-municipality
5. Какво са test cases?
• Test case e...
• Позитивни test cases
• Негативни test cases
• Test suites
6. Защо се нуждаем от тях и защо
трябва да ги ползваме?
• Кога е добре да използваме test cases?
• Откриване на дефекти на ниво
спецификация
• Обединяване на важна информация на
едно място
• Въвеждане на нови хора в екипа
7. Какво е Testlink?
• Test cases
• Test suites
• Test plans
• Test projects
• Управление на
потребителите
• Доклади
• Статистики
8. Защо избрахме Testlink?
• Безплатен
• Интеграция с Jira, Mantis и Bugzilla
• Лесен за ползване
• Лесна поддръжка
• Добър контрол на потребителите
• Добър набор от доклади в различни
формати
• Execution workflow
16. Процес на създаване
Анализ на
спецификацията
Анализ на
критичните за
бизнеса функции
Изясняване на
възникналите
неясноти
Разбиване на
отделни
функционалности
Създаване на
достатъчно на
брой test suites
Създаване на
достатъчно на
брой test cases
17. И когато вече всички си
задавате въпросът – „Къде
е Drupal?!?!“
18. Как да пишем
преизползваеми test
cases в Drupal?
19. Как да подобрим работата на екипа
чрез изготвяне на добри test cases?
• Включване на целият
екип в общата работа
по изготвянето на test
cases
• Включване на
клиентите в процеса
на изработка като
ревюиращо лице
Здравейте на всички. Казвам се Божидар Бошнакови, работя в Propeople като QA инженер.
За не дългото време в което съм част от екипа на Propeople научих доста нови неща, също така Propeople е мястото къде се запознах с Drupal. Видях доста от плюсовете и минусите на Drupal но като цяло смятам че плюсовете са доста повече. Drupal за мен стана синоним на голяма група от професионалисти в web development, от хора готови да споделят, готови да помагат и лично за мен това е най – положителното нещо в работата с Drupal. В работата си в някои големи проекти видях част от възможности на Drupal и смело мога да твърдя, че те са доста големи.
ПРОЧЕТИ СПИСЪКА
РЪЧНО тестване изцяло
Първо искам да кажа няколко думи с които искам да ви разкажа защо реших да направя тази лекция и защо точно test cases? Като част от силният екип на Propeople имах честа да ръководя QA дейностите по вероятно най – големия проект правен някога на Drupal. Проекта беше базиран на AGILE методология на работа и беше определено голямо предизвикателство. Идеята на проекта беше, прилагане на Drupal интрАнет базирана платформа която да замести съществуващи CMS системи за всички отдели в общината на Копенхаген. Но, сега няма да говоря за този проект, той беше споменаван няколкократно от моите колеги по – рано, а за тези които искат да научат повече за Agile и Scrum методи на работа, утре моят колега Бисер Симеонов ще изнесе пред вас лекция. Нещото което искам да кажа е, че на базата на работата която беше свършена по този проект, осъзнах голямата нужда от тест кейсове. Когато имаш наистина много на брой различни функционалности, модули, роли и хора в екипа нуждата от тест кейсове е огромна.
Днес ще се помъча на базата на опита и знанията които имам да ви разкажа какви са добрите страни на тест кейсовете, как да правим качествени тест кейсове от които има реална полза и защо те са добър подход в работа с Drupal проекти.
Тест кейс в софтуерното инженерство е съвкупност от условия с очакван резултат насочени към дадена функционалност, чрез които тестера определя дали приложението работи, тъй както е създадено да работи. Има два основни вида тест кейсове – позитивни и негативни. В позитивните кейсове се описва сценарий в който функционалността се предполага, че работи, а негативните тест кейсове съдържат такъв сценарии които цели да счупи конкретната функционалност. Също така всеки тест кейс може да съдържа предварителни условия които трябва да бъдат изпълнени и валидни за да се изпълни самият тест кейс. Препоръчително е на всеки тест кейс да се задава подходящо кратко наименование и кратко описание на точния сценарий който ще бъде тестван в с него. Почти винаги дадена функционалност да бъде из тествана качествено са нужни повече от един тест кейса. Когато има повече от един тест кейс за една функционалност то те се групират в test suites. Тест сюта представлява колекция от тест кейсове, които са предназначение да се използват за тестване на дадена отделна функционалност. Тест сютовете често съдържат подробни инструкции или цели за колекциите от тест кейсове в тях. Почти никога нужните тестове които трябва да се направят на една функционалност за да сме сигурни, че тя работи правилно, не могат да бъдат описани в тест кейсове.
За малки проекти не винаги тест кейсовете са добро решение. Положителните страни тест кейсовете са за големи проекти и такива които се работят дълго време или имат следващи фази, продължения и надграждания. Но както повечето от вас предполагам знаят и самият Drupal не е най – подходящото решение за малки проекти.
Както малко по – късно в лекцията ще обясня, идеята на тест кейсовете е те да се създават преди функционалностите които ще бъдат тествани чрез тях. Това естествено става на базата на някакъв тип спецификация където най – често са описани основните функционалности и изисквания на клиента. И когато на база спецификация, тестера започне да създава тест кейсове и позитивни и негативни сценарии, много често се откриват голямо количество от дефекти, не добре дефинирани изисквания и не ясни функционалности. Което съответно помага да се предвидят и предодвратят бъдещи проблеми. Това помага не само на тестерите а и на целия екип
Когато проекта е голям почти винаги се налага на някакъв етап да се включват външни хора за малки или големи таскове и тогава тест кейсовете са перфектният тип документация които е нужен, човек да получи цялата нужна информация за проекта в най – кратко време.
Test designer
Guest
Senior tester
Tester
Admin
Leader
Всички поддържат manual tests и управление на дефектите
IBM Rational Quality Manager – JIRA
Meliora Testlab – JIRA, Jenkins
Testlink – JIRA, Mantis, Bugzilla
Подобни модули и функционалности
Слаби места на дадени функционалности и модули
Силни страни на фунционалности и модули
Места където трябва да се отдели повече внимание