https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/#toc-start

I have been assigned to read the first chapter, and the introductions of the subsequent chapters two through six. My first take-away line from the first chapter is that this book was written for me, not for my boss or professor. I find this ironic, since I wouldn’t even know about this book if not for my professor assigning it to me. I understand the meaning is to read it for my own benefit above all else, which I agree with.

Martin Gustavson summarizes apprenticeship as having the attitude that there is always a better way to do things than what you produce. Does this mean that as soon as I believe I have produced something that I believe is perfection, I am now a journeyman? I feel like this definition is not very accurate.

The outcome of an apprenticeship depends on how much effort one wants to put into it, it is more my responsibility to succeed than my master’s/teacher’s. I’d like to add that having a good or bad teacher directly effects how much I am going to learn. In high school, I barely passed algebra 2 with a D, whereas in college, I got an A in calculus. Obviously there is a huge leap in difficultly of the two subjects, so why did I preform much better in the harder class? The main difference between the two classes (and the two outcomes) was based on the crappy high school teacher I had versus the professional college professor. That concept will repeat in an apprenticeship setting.

Chapter two’s introduction starts with an interesting story about a philosopher and a zen master. I found this passage particularly interesting. Every time the master tries to explain something, the philosopher excitedly interrupts him by expressing what he has learned or studied elsewhere. By interrupting the lesson, the philosopher misses out on information. The phrase “empty your cup” refers to the concept that you must come to new experiences with an empty mind in order to fill it with as much knowledge as possible. New learners especially have this problem where they rudely can’t listen and learn. I may be guilty of this, but at least now I am conscious of it.

Chapter three is all about the “long road” in reference to the endless journey of knowledge. It bothered me particularly when the chapter states the importance of long term goals over things like salary and leadership. If I understand this correctly, long term goals in this context only means more knowledgeable in a specific field, with the trade off being you wont make as much money. My long-term goal is solely to make as much money as possible.

I would rather rich and dumb than smart and poor, depending on your definition of “dumb.” The book seems to define “dumb” in this context as “not knowing as much about programming as you could” which I can live with. As long as I am smart enough to be a good person, I would rather make more money. Overall, I think this book prioritizes knowledge too much, knowledge is the means to wealth and power, not the other way around.

Chapter four is about not becoming comfortable as the smartest person in your development group. If that happens, the book encourages leaving that group and becoming the dumbest person in a different group, then working your way up again, which makes sense and is agreeable.

Chapter five reiterates that perpetual learning is important no matter what your skill level. It covers prioritizing a reading list and continuously learning as much as possible.

Chapter six is related to five in that you must maintain your own learning. Once you graduate, you don’t have assignments or due dates to keep you on track. Beneficially, this means you also don’t have to learn anything you don’t think is relevant/interesting.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.

https://www.softwaretestinghelp.com/early-testing/

This week I read the post from the site linked above. It talks about effective quality assurance strategy in the early stages of a project. Uncaught bugs or fundamental flaws in the foundations of the software life cycle can result in setbacks for the later stages. Ultimately, it is more efficient to test early and test often than to spend resources going back to fix an early issue. If this is the case, sometimes the best solution is to rewrite many built features of a software project just to change the foundation, which is the worst case scenario in a time crunch environment.

There is a balance to be achieved between spending enough time testing early as to not create fundamental mistakes, and spending too much time testing without devoting enough resources to producing a working prototype. Software projects are typically planned on a time based release quarterly, half-yearly, or yearly, depending on the size of the project and the goals in mind. Because time is of the essence, defects need to be organized based on severity, time allocation, and expected collateral impact for the rest of the code.

This cycle can be broken down into steps; the developer creates, the tester tests the creation and ranks severity, the developer responds by fixing the most important issues, and the tester evaluates the fixes. Ultimately, this cycle never ends as long as they are employed. Constantly, there are new features and new bugs, and it is impossible to discover every bug from every new feature, the product is never defect free. In this way, testing is especially important in the early stages of development since it plays better into the long term which we expect to never end.

Now that I’ve summarized why and how early testing occurs, the final segment of the site reviews the primary targets for early testing. To begin, stakeholders determine which features will be the most effective by generating the most revenue, complying with standards, catching up to a competitor, or succeeding a competitor. These selected new features are the focus of early testing since they usually involve many lines of code with a high possibility of intersection. QA and development leaders both need to work together when working on these high priority features in the early stages of development. This collaboration must be stressed as especially important to the work efficiency of the entire project.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.

https://testingpodcast.com/

This week, I listened to PerfBytes Black Friday, Hour 4 at the link provided above. This podcast is centered around the business practices of major retailers and how that reflects on the work of IT departments. Especially right after thanksgiving, retail companies see a huge spike in consumer activity with black Friday and the holiday season, which results in a big strain on eCommerce.

They begin a practical assessment of retail websites by scoring the load times and response requests over time. They discovered that some retailers don’t put enough resources into their websites. Olight is a manufacturer of flashlights whose website scored a D, which is unacceptable from a consumer standpoint especially around black friday and the holiday season. For comparison, they also scored a competing website, Maglight, which performed the same or worse in all areas.

Clearly, these shopping websites were not up to par with the expected performance and don’t seem to have an interest in upgrading. Major online sellers like Amazon and Home Depot also sell these products but with a much more marketable look and feel to their web pages. This test proves that these manufacturers should invest more in their website and might make more revenue by selling directly rather than paying a margin to the dominating online retailers. The need for quality assurance exists, but there also exists a trend from not well known companies like Olight and Maglight to let bigger shopping websites carry the majority of their sales for them at a cost. In this way, it may seem not worth the effort of upgrading a website.

Next the hosts go over ways to better communicate performance engineering between multiple departments especially around high traffic times of the year. Typically, the conversation starts with cost estimates going by a specific plan for that year. The priority for business leaders higher up the corporate chain is to cut costs as much as possible, however, cutting the IT departments budget results in drastic sales consequences. The best way to cause change in the industry and prevent these risks is to better communicate cost.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.

http://thetesteye.com/blog/?utm_source=fuel&utm_medium=referral&utm_campaign=lrfuel

This week I read the introductory blog post from The Test Eye, written by Martin Jansson in 2017 as a description of the authors goals and intentions as he writes further posts. In the post linked above, Jansson describes the pros and cons to agile frameworks in his opinion as a professional tester.

Firstly, Jansson states that a main advantage in an agile organization is that no single person bears the blame for the overall quality of the final product, if it happens to fail or come short of expectations. It takes a team where the result is everybody contributing their own level of effort into the project, which is a very good concept for a team building environment. However, Jansson believes there can still be improvements within the framework.

Jansson expresses that these frameworks are meant to be altered and changed dynamically to fit the specific situation appropriately. If the agile transformation is followed exactly, there will be circumstances where it will fail since they have limitations, so its important to be flexible in that way with this kind of environment.

He continues by explaining that coaching in an agile organization also proves difficult fundamentally, since no one person can be an expert in all necessary fields. Rather, its more efficient for this expertise to come from within each department to guide implementation. This approach is supported by the fundamental concepts of an agile framework, where change and improvement over time are stressed.

Jansson then critically assesses the inclusion of testing in frameworks such as SAFe. He believes they could improve by including more various testing material, since currently there isn’t much of any content about testing. He also shares that testing is undervalued currently and is misrepresented as something “everyone is expected to work with.”

Although he has these criticisms, Jansson still admires many good ideas and material laced throughout the frameworks. His goal is to suggest improvements and adjust them as agile transformation continues into the future. I will continue to follow these posts since the writing style is interesting and informative, I suggest to The Test Eye to anybody who hasn’t heard of it already.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.

https://dojo.ministryoftesting.com/dojo/lessons/testing-for-developers

This is the first time I’ve heard the ministry for testing’s super tester bros and from the Mario themed intro, I already appreciate the pure nerd culture of this podcast. They open the conversation with a discussion about a malware app, a clone of WhatsApp that tricked people into downloading spyware. This is a common problem, most searches bring up some kind of harmful software further down the results.

The conversation continues into various avenues revolving around security, particularly regarding a recent flaw in Apple’s sign in program. For a short period of time, anybody could sign in without credentials by clicking “Sign In” enough times with a blank username and password. This simple-to-use security breach is unexpected for a company as big as apple, since this is a type of problem could be avoided by better testing and coding.

At the 19:30 mark, they brought in two developers to talk about how they work with testers. Although the target in a dynamic software development environment is to release the product in working order as quickly as possible, they both express that there is a lot more value in collaboration over rushing. The quality of the end project doesn’t depend solely on the tester or the developer alone. Having a tester by the developer to share insight and do some “peer testing” will also help the developer understand how the further processes work, so he may be able to design around them. This will help save time in a project, since the developer wants the code to pass, or at least not fail, on the first few attempts after handing it to the tester.

Towards the end of the podcast, the hosts shared stories about encounters in their career. A typo was detected on the front page of a company that one of the hosts worked at. At the time, this error was given a low priority score since it didn’t actively change or effect the working order of the website, however, he reflected on how many people saw that typo and immediately disregarded the website as worthy of doing business with. In that way, this small error was in fact very high priority and greatly changed the effectiveness of the website to bring in customers in a way that had nothing to do with its true functionality.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.

I’m a Computer Science major, about to graduate this year, without a real understanding of where to go after my degree. Since my future is fairly open, I was curious to research the professional QA field and how some testers got their start in the industry. After a quick google search, I followed the link below and found some helpful insight from current professionals on the topic.

https://techbeacon.com/6-new-careers-paths-ideas-software-qa-testers-professionals

Firstly, it surprised me to find out that many QA testers ended up in their positions without a lot of intention. To quote QA professional Shelley Rueger, “I don’t know that there is a standard way to start in QA.” Originally, Rueger went to MIT to become a research physicist, quite a long step away from her current career of 15 years so far. Its surprising to me how somebody could invest so much into their future but mysteriously end up in a different field entirely, a trend common across all majors. I suppose the future is just that unpredictable, which actually offers me relief since I’m so unsure of where I’ll end up.

All that being said, going into QA is certainly worth planning out long term if anybody is considering it professionally, since the first few years are typically rough. Jeremy Hymel, the QA manager at QAlytics, shares his experience; “The early years in a tester’s career are rough, the pay is not great, and they are not treated as well as developers.” Once the hardships are over however, this article lists multiple points to jump off of as a QA tester. I will summarize the following paths: Product Management, DevOps, and Customer Experience.

Product management is a common fit for advancing QA testers, since they have extensive experience ensuring the best software possible. This quality is essential to the success of software reliant companies and they will often recognize a good QA tester to take the role of feature development.

Testers are more suited than software developers in the advancing role of DevOps. QA testers can easily practice the skills needed for a career in release management, product stability, or automation engineering.

It also makes a lot of sense that a QA tester could pursue a Customer Experience role. The tester assumes the role of the customer with every software test, therefore they have plenty of experience seeing the point of view of the user.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.

http://thetesteye.com/blog/page/3/?utm_source=fuel&utm_medium=referral&utm_campaign=lrfuel

I’ve been delving into the writings of Rikard Edgren, a software tester who writes blog posts on thetesteye.com. I think its useful to see what professionals think works well, so today I’m talking about his post titled “ISO 29119 – a benevolent start” which I’ve provided the link to above. Although this post was written some time ago, I believe it provides general foundations of what a test system should include.

He first states that he tries to see the good in a system first, so a lot of the writing that follows is of appreciation for what this system does right in his opinion and provides suggestions for concepts that should be included in further systems. Edgren breaks down his thoughts about the testing standard into three parts, concepts and definitions, test processes, and test documentation.

Regarding the definitions of the system, Edgren compliments the simplistic terminology used in ISO 29119. Compared to other testing standards, this one is more flexible while also limiting multi-faceted words. He also appreciates the use of Diverse Half-Measures in order to cover all the bases in terms of test coverage.

The test process for ISO 29119 prioritizes testing strategy, which gives way to multiple advantages. For instance, it ensures that important goals are followed, met, and easily communicated for the future. The feedback is also more detailed rather than just a simple pass/fail. Additionally, this is a hopeful sight for test standards to come, Edgren is excited that testing strategy is starting to become more common and more of a priority going forward.

Finally, Edgren praises certain aspects of the test documentation, which incorporates concepts from both traditional and agile projects. The importance of this being that previous documentation concepts don’t have to be set in stone for future projects, breaking traditions is sometimes beneficial. Edgren makes the point that the documentation should also have the stakeholders in mind, so diagrams and simple explanations could go a long way. Bridging the gap between tester and employer is vital, it is very important that both parties are on the same page regarding the results of testing.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.

I love video games and the prospect of making a career out of them has always been a dream that I believed too good to be true. However, the game industry has been on the rise for decades and increasingly proves to be a real career choice with the added benefit that even a small team can produce something that stands out. With this dream in mind, I’ve read the following article on how to get started in the game industry with advice and interviews from current game developers.

https://www.theguardian.com/technology/2014/mar/20/how-to-get-into-the-games-industry-an-insiders-guide

The first question asked to the panel is “What is the best way to start making game?” To which many emphasized the importance of learning the basics of coding. While some game development tools allow you to get started with little coding knowledge, its unavoidable that you eventually learn a programming language or two, C++ is recommended specifically. Game developments tools such as unity, RPG maker, and game maker studio help significantly with transferable concepts of what goes into making a game.

Another question was “If someone is looking to set up a small studio themselves – what advice would you give them?” A few panelists strongly advised not starting a studio early on and that a better choice would be getting experience in an already established studio before gaining the confidence to branch off on your own. However, if you were to start a studio you absolutely need a great programmer as well as an artist. Also it is very important that you have a team member who knows the business of the industry. Byron Atkinson-Jones shares that “the making of the game, that’s actually the easiest part. Managing things like business finances, making sure you can all eat regularly, marketing, PR, legal stuff, QA and selling the game once it’s done are the hardest.”

The next question asked was “Are there any key skills that people should have or things they should know that aren’t obvious or aren’t taught on design/coding courses?” To which many of the panelists stressed the importance of communication within a team. Learning to be a nice person while being open to criticism for the sake of the project are invaluable traits that cannot be taught in schools. You could be very skilled and experienced but if you don’t get along with group members and refuse to communicate effectively, your project will suffer greatly.

The last question ill go over in this post is “Is a degree in computer games programming or design a necessity?” The short answer from most of the panelists is no, you can go a long way with passion and devotion to video games as long as you have the portfolio to back it up. Aj Grand-Scrutton expresses that “a degree is effectively gravy compared to an actual portfolio” emphasizing that real experience dominates over just having a degree.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.