Before I dive into my final installment of this CS series (for now), I wanted to say thank you if you actually read any of these posts and thank you to my new followers for dealing with the notifications you must have gotten.
For this last post, I wanted to discuss the article 5 Reasons You Are Wasting Your Testing Time by Joel Montvelisky. The author expresses how everyone can do testing but not everyone can do “good testing,” which incorporates more than just what is basic checking.
A short list of main reasons why a lot of people tend to waste time that could have been spent testing other things includes:
- Not having clear goals
- Not understanding what or how much the feature means to your End User
- Not keeping track of what was tested and potential discoveries
- Not consulting what you already know or using references
- Not giving feedback that could be shared to help others
I agree with most of what Montvelisky says as I have personally noticed what has happened from my experience as a Software Quality Assurance Intern when any of the five things above took place based on a task. It is important to understand that sometimes these things may be out of your control but you should still try your best to avoid miscommunication wherever possible.
Montvelisky’s content has not necessarily changed the way I will work as I have already been consciously making an effort to understand what I am reviewing, how stuff is meant to work, logging tasks, connecting tasks to previous occurrences, and communicating with the QA team. If I had read this article before I started working, it would have been more useful as it would serve as a foundation to how one should think of testing beyond the basic functionalities.
Something I wanted to emphasize is the post-test reviews and feedback sessions with peers. I found that if someone else needed to learn about a project or a task had to be communicated with a client, logging any kinds of notes or information was better than not having anything prepared to discuss. They do not necessarily have to be posted for everyone to access but it would be good to note it in any sort of text editor for future reference. I think an example of when to note things is if you found something that does not prevent your current task from being approved but it still affects something for the overall program.
Overall, when testing things I believe you should trust your instincts on reporting things you find. It helps when you try to imagine how much it could affect a program in the long run if not brought to someone’s attention, even if it may seem minimal.
Best of Luck,
Testing, testing. I may need your approval on this article I read by Software Testing Magazine on Approval Testing. Approval testing, as defined by this article, is a way of software testing that results in presenting the before and after of an application for a user (ex: software development team) to review it and potentially approve it. It’s more of a visual representation of testing and one of the major cons is how the results have to be checked manually.
Some testing tools mentioned include: Approval Tests, TextTest, Jest, Recheck, Automated Screenshot Diff, Depicted (dpxdt), and etc.
The main purpose of the software testing tool, using TextTest for example, is checking that the text output after running program from the command line in different ways.
What I found interesting is how a user can see that a test technically could have “passed” or “failed” but still decide to mark it as the other because they choose what feature they are looking for in the end. This makes it a little more flexible to use approval testing as it is more of a guide or guideline for a user instead of only seeing one word and then a short description of what could have gone wrong. I think this process is much more transparent or descriptive with a user about what could have gone wrong or what went right.
One way the content has changed how I will think about the testing is how there are so many more types of software or programs out there than we can imagine which help us better code or create our own software and programs. This one is especially good for visual coders and testers who like to see their results firsthand to compare what they are expecting with what they actually got.
Overall, I found this article was useful because it introduced me to thinking about a better way of logging the differences between what the reference result is versus the actual result. I did not disagree with any of it since it showed us how we can use approval testing to our advantage while still being honest about its limitations.
When using architecture patterns, how will you know which one to choose? Peter Wayner, an independent author for TechBeacon takes five architectures that the majority of programs today use and broke them down into their strengths and weaknesses. Through this, it seems like he is hoping to guide users to selecting the most effective software architecture pattern for their needs.
If this article does not clear up enough information, Wayner also brings up a book, Software Architecture Patterns by Mark Richards, which focuses further on architectures commonly used to organize software systems.
The fives types discussed in the article are:
- Layered (n-tier) architecture
- Event-driven architecture
- Microkernel architecture
- Microservices architecture
- Space-based architecture
The one I found most interesting is space-based architecture because at first when I thought of space, I was thinking of the other kind. The one with the sun and the stars and the moon. But then I realized–what does that have anything to do with software architecture? Space-based architecture is listed as “best for high-volume data like click streams and user logs” and I think this one is pretty important, especially during times like Black Friday and Cyber Monday. I personally experienced the frustration of not being able to access a site (adidas) due to high volume and it really does not help a business.
Another architecture I found thought-provoking is micro-services architecture because of the way Wayner introduced the concept, “[s]oftware can be like a baby elephant: It is cute and fun when it’s little, but once it gets big, it is difficult to steer and resistant to change.” The author providing an example of this made me think about how a site with so many users and things happening at once actually just had many different separate services but they were put together as one. I was a little surprised to think of Netflix in that way after all the times I’ve used it but it makes much more sense now.
Overall, I found all of the information pretty useful and clear to understand as Wayner described what they were and then listed the caveats and what they were best for. I would recommend using this as a reference or quick review of common software architecture designs if someone needs it.
Ever wondered what it was like to work for a tech company? Here’s a perspective from an entry-level/intern position at ten24 Digital Solutions!
Hi I’m Sam, a rising senior in uni! Throughout the past ~2 months I’ve been working at a company downtown and brought my camera to work one day to vlog what it’s like.
I truly appreciate how welcoming everyone at ten24 was, it makes it hard for me to believe I’ve only been a part of the team for two months so far! I didn’t even know this was possible but my love for technology grew even more through learning to use different software tools that I wouldn’t have known existed until now.
This is the 1st video of my internship series, feel free to stay tuned for more including ‘what’s in my bag’ and internship advice.
Shout out to Nina for helping me film that ending and eventually climbing into the backseat for a better shot haha!
Side note; working here has it’s perks like being in super-walking distance to city events and local coffee shops, lunch spots, and more!
Until next time, I’ll