Which test entities help testing - Test cases, scripts, conditions or scenarios?

[@EvilTester]

More information in the show notes for this video: eviltester.com/show/019-test-entitites-cases-scripts/

[@beagleamarelos]

Thanks for sharing this video, EvilTester! I am a beginner tester and have heard from other KZbin people and colleagues/bosses that I needed to document my tests because it was the right thing to do. I used to think that I was doing pretty well because I used to write long documents about test cases and all of that. Truth is that at the small company that I work for, people knew so little about testing (I'm the first tester at that company and I sort of started the whole testing thing there back when I was a UX designer) that they didn't know how to advise me better. So yeah, it took me some time, but I realized that my documents were pretty useless and time consuming and stopped using them. I think I got a bit bad at testing in these past months even though I have been learning a lot about technical stuff (but yeah, I still don't automate, I'm getting there) because I got kinda discouraged. Documentation did help me keep track of what I was doing and helped me know what I needed to do, so I will try doing something similar to your test ideas and test logs. I think it's gonna help me. I will keep watching your videos, thanks again for sharing your knowledge :-)

[@BrittanyBird1]

Amazing video! I agree with the need to simplify our testing. Thank you for sharing this!

[@handofdecay]

Thank you for making these videos!

[@samuelturnbull9625]

Interesting and insightful video, thank you. How would you apply this simplified testing approach in a case where the testing entirely surrounds sets of data input ---> output scenarios? For example, you need to test a letter template designed to handle 100s of variations of data inputs based on 20+ unique data fields, where outputs are derived both directly (one to one mapping), and mediately, using logical processes of varying complexity? It seems here you would still want (at least partly) a fairly up-front formalized approach to test case design so that you maximize your efficiency and effectiveness in the choice of data input sets, and are able to clearly track exactly what you've done (e.g. here is the table of data I created which represents the various key variations I want to test, based on identified risks etc.). Appreciate your thoughts, or perhaps any other examples you can offer about applying a more fluid test session approach.

[@EvilTester]

Yeah, I would probably build a model and then identify the strategies I want to take to cover the model. When I've done this in the past I didn't use a table, I used data definitions, and then combined them. I've also automated very early in cases like this so that I created a single execution path and then traversed over the data combinations as input to the script. I did a talk describing one case study where I used this approach back in 2011 www.eviltester.com/conference/seleniummeetup2011_conference/ Also I covered some approaches in this talk as well www.eviltester.com/conference/eurostar2012-thinking-visually-webinar/

[@samuelturnbull9625]

@@EvilTester Thank you!

[@markberry6574]

Interesting, I agree largely where you have experienced testers, but thats not the real world in a team situation. There are obviously alternatives, but scripts can - be used by inexperienced testers to learn a domain or system. - be useful for knowledge transfer to offshoring, or maintenance teams - offer clear traceability to help ensure coverage. - when included in tools the 'automation' of the reproduction steps needed to re-create a defect for the developers is useful - for inexperienced testers - e.g. UAT people or new employees - scripts offer examples of the types of testing to do and 'how' to structure test I dont know what the answer is, i'm pretty comfortable with this for small experienced teams but less so with mixed ability experience and outsourcing