top 20 practical software testing tips you should read before testing any application
Пожелавам на всички тестери да прочетат актуализираните в тази статия практики за тестване на софтуер . Прочетете внимателно всяка точка и се опитайте да ги приложите в ежедневните си тестови дейности. Това очаквам от читателите чрез тази статия. Ако не разбирате никаква практика за тестване, поискайте повече разяснения в раздела за коментари по-долу.
Въпреки това ще научите всички тези практики за тестване чрез опит. Но защо не научите всички тези неща, преди да направите грешка?
Хайде да разгледаме тях!
Ето някои от най-добрите практики за тестване, които научих от опит:
клониране на твърд диск към ssd софтуер
# 1) Научете се да анализирате задълбочено резултатите от теста си. Не пренебрегвайте резултатите от теста. Крайният резултат от теста може да бъде „премине“ или „не успее“, но отстраняването на първопричината за „неуспех“ ще ви даде решение на проблема. Тестерите ще бъдат уважавани, ако не само регистрират Грешки но също така предоставят решения.
# две) Научете се да увеличавате максимално Тестово покритие всеки път, когато тествате дадено приложение. 100% покритие на теста може да не е възможно, но все пак винаги можете да опитате да достигнете до него.
# 3) За да се осигури максимално тестово покритие, разбийте приложението си под тест (AUT) на по-малки функционални модули. Напишете тестови случаи на такива отделни модулни модули. Също така, ако е възможно, разбийте тези модули на по-малки части.
Например, нека приемем, че сте разделили приложението си за уебсайт на модули и „приемането на потребителска информация“ е един от модулите. Можете да разбиете този екран „Информация за потребителя“ на по-малки части за писане на тестови случаи: Части като тестване на потребителския интерфейс, Тестване на сигурността , Функционално тестване на формуляра „Информация за потребителя“ и др.
Приложете всички тестове за тип и размер на полета за форма, отрицателни и валидационни тестове върху полетата за въвеждане и напишете всички такива тестови случаи за максимално покритие.
# 4) Докато Писане на тестови случаи , първо напишете тестови случаи за предвидена функционалност, т.е. за валидни условия според изискванията. След това напишете тестови случаи за невалидни условия. Това ще покрие очакваното, както и неочакваното поведение на тестваното приложение.
# 5) Мислете положително. Започнете да тествате приложението с намерението да намерите грешки / грешки. Не мислете предварително, че в приложението няма да има грешки. Ако тествате приложението с намерение да намерите грешки, определено ще успеете да ги намерите Фини грешки също.
# 6) Напишете вашите тестови случаи в самата фаза на анализ на изискванията и проектиране. По този начин можете да се уверите, че всички изисквания могат да бъдат проверени.
# 7) Направи твое тестови случаи, достъпни за разработчиците преди кодиране. Не дръжте тестовите си случаи с чакане, за да получите окончателно издание на приложението за тестване, мислейки, че можете да регистрирате още грешки. Позволете на разработчиците да анализират внимателно вашите тестови случаи, за да разработят качествено приложение. Това ще спести и времето за повторна работа.
# 8) Ако е възможно идентифицирайте и групирайте вашите тестови случаи за Тестване на регресия . Това ще осигури бързо и ефективно ръчно тестване на регресия.
# 9) Приложенията, изискващи критично време за реакция, трябва да бъдат щателно тествани за ефективност. Тестване на производителността е критична част от много приложения. В Наръчник Тестване, това е най-игнорираната част от тестерите поради липсата на необходимия голям обем данни при тестване на производителността.
Разберете начините да тествате приложението си за ефективност. Ако не е възможно да създадете тестови данни ръчно, напишете някои основни скриптове, за да създадете тестови данни за тестове за производителност или помолете разработчиците да напишат такъв за вас.
# 10) Програмистите не трябва да тестват собствения си код. Както е обсъдено в нашия предишен пост , основно Unit Testing на разработени приложения трябва да е достатъчно за разработчиците да пуснат приложението за тестери. Но вие (тестерът) не трябва да принуждавате разработчиците да пуснат продукта за тестване.
Оставете ги да си отделят времето. Всеки от водещ до мениджър знае кога модулът / актуализацията е пуснат за тестване и съответно може да прецени времето за тестване. Това е типична ситуация в Пъргав среда на проекта.
# 11) Отидете отвъд тестването на изискванията. Тествайте приложението за това, което не трябва да прави.
# 12) Докато правите регресионно тестване използвайте предишната графика на грешки (Графика на грешки - брой грешки, намерени спрямо времето за различни модули). Тази модулна графика на грешки може да бъде полезна за предсказване на най-вероятната грешка в приложението.
# 13) Запишете новите термини, понятия, които научавате по време на тестване. Дръжте текстовия файл отворен, докато тествате всяко приложение. Запишете напредъка на тестването и наблюденията в него. Използвайте тези наблюдения в бележника, докато подготвяте окончателния доклад за тестовото издание. Този добър навик ще ви помогне да предоставите пълен недвусмислен протокол от теста и подробности за освобождаването.
# 14) Много пъти тестери или разработчици правят промени в кодовата база за тествано приложение. Това е задължителна стъпка в средата за разработка или тестване, за да се избегне изпълнението на обработката на транзакции на живо, както при банкови проекти.
Запишете всички такива промени в кода, направени с цел тестване и по време на окончателното издание се уверете, че сте премахнали всички тези промени от крайните файлови ресурси на клиентската страна за разполагане.
# 15) Дръжте разработчиците далеч от тестовата среда. Това е необходима стъпка за откриване на всички промени в конфигурацията, които липсват в документа за издаване или внедряване. Понякога разработчиците правят някои промени в конфигурацията на системата или приложението, но забравят да споменат тези в стъпките за внедряване.
Ако разработчиците нямат достъп до тестовата среда, те няма да направят такива промени случайно в тестовата среда и тези липсващи неща могат да бъдат заснети на правилното място.
# 16) Това е добра практика включете тестери още от самата фаза на изискванията за софтуер и дизайн. По този начин тестерите могат да получат знания за надеждността на приложението, което води до подробно покритие на теста. Ако не бъдете помолени да участвате в този цикъл на разработка, можете да направите заявка до вашия ръководител или мениджър да включите вашия екип за тестване във всички процеси на вземане на решения или срещи.
# 17) Екипите за тестване трябва споделят най-добрите практики за тестване , опит с останалите отбори в тяхната организация.
# 18) Увеличете разговора си с разработчиците за да научите повече за продукта. Винаги, когато е възможно, общувайте лице в лице за бързо разрешаване на спорове и за избягване на недоразумения.
Но също така, когато разбирате изискването или разрешавате спорове - уверете се, че комуникирате със същите презаписани начини за комуникация като имейлите. Не дръжте нищо устно.
# 19) Не бягайте Няма време да изпълнявате задачи с високо приоритетно тестване. Приоритизирайте тестовата си работа от висок към нисък приоритет и планирайте съответно работата си. Анализирайте всички свързани рискове, за да дадете приоритет на работата си.
# 20) Напишете ясно, описателно, недвусмислено Доклад за грешка . Не предоставяйте не само симптомите на грешката, но и ефекта на грешката и всички възможни решения.
Не забравяйте, че тестването е творческа и предизвикателна задача. И накрая, всичко зависи от вашите умения и опит как да се справите с това предизвикателство.
Над вас:
Споделянето на вашия собствен опит, съвети или тайни за тестване в коментарите по-долу определено ще направи тази статия по-интересна и полезна !!
как да видите xml файл
Споделете вашите мисли / предложения за тази статия.
Препоръчително четене
- Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
- Тестване на софтуер QA Assistant Job
- Емоционална задача ли е тестването на софтуер?
- Курс за тестване на софтуер: Към кой институт за тестване на софтуер трябва да се присъединя?
- Изборът на софтуерно тестване като кариера
- Тестване на софтуер Техническо съдържание Writer Работа на свободна практика
- Какво е тестване на маймуни при тестване на софтуер?
- Тестване на приложения - в основите на софтуерното тестване!