Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revisionBoth sides next revision
work:semana_9_de_2022 [2022/02/27 20:35] – created magsilvawork:semana_9_de_2022 [2022/03/01 15:07] – magsilva
Line 3: Line 3:
 ===== Research ===== ===== Research =====
   * While reading Amy Ko's blog, I read about [[https://www.pyret.org/ | Pyret]]. Interesting to learning that there is a language that allows the definition of test cases for each function. Actually, it supports not only test case automation, but also code documentation. Test cases are defined at the end of a function definition, after a 'where' clause. Code documentation is defined just after defining the function name and parameters, using a 'doc' clause. Nice and simple.   * While reading Amy Ko's blog, I read about [[https://www.pyret.org/ | Pyret]]. Interesting to learning that there is a language that allows the definition of test cases for each function. Actually, it supports not only test case automation, but also code documentation. Test cases are defined at the end of a function definition, after a 'where' clause. Code documentation is defined just after defining the function name and parameters, using a 'doc' clause. Nice and simple.
 +  * Read the paper "So you’ve graduated college and need to test apps: What barriers might you face?", from several fellow professors at UFMS. 
 +    * The authors conducted a opinion survey with novice testers, addressing the barriers they faced in planning, executing, and analyzing software testing activities. The open questions were analyzed with thematic synthesis, producing a mental map of barriers faced by those novice testers. The results corroborate with those provided in related studies (such as Igor Steinmacher's PhD thesis and related papers). However,  there are some themes and barriers that looks more critical when considering software testing. For instance, technical and onboard barriers looks tougher, as tooling for testing mobile applications changes much faster than for other types of applications, which renders documentation and specific technical knowledge on testing obsolete quicker. For instance, although we often learn and teach test automation using JUnit and Jest, the tests run for mobile applications usually consider different testing frameworks. Specific for mobile applications, there is a barrier regarding platform dependencies and their implications: how to effectively design and execute test cases for so many mobile devices? Well, there are several other barriers, but a look at Figures 1 and 2 of the paper will provide a better picture than further text here. 
 +    * About the implications, the authors suggest to include software testing activities since the beginning of formal Computing education. Nothing new here. TDD could address several barriers identified in the paper. Regarding the platform dependency barrier, we could design test criteria for contextual and hardware elements. Regarding context change, pair programming would be a nice addition, changing the project considered for each day or week. All of that should also foster proper documentation of software testing processes too :-)